January 2019 - Devel - libvirt List Archives

[libvirt] [PATCH 0/8] qemu: VNC: support encrypted server TLS keys
by Ján Tomko 21 Jan '19

21 Jan '19

Applies on top of my qemu.conf cleanups: https://www.redhat.com/archives/libvir-list/2019-January/msg00401.html https://bugzilla.redhat.com/show_bug.cgi?id=1602418 Ján Tomko (8): conf: introduce virDomainGraphicsNew conf: add privateData to virDomainGraphicsDef qemu: add qemuDomainGraphicsPrivate data with a tlsAlias qemu: prepare secret for the graphics upfront qemu_process: fix debug message qemu.conf: add vnc_tls_x509_secret_uuid qemu: add support for encrypted VNC TLS keys qemu: error out when vnc vncTLSx509secretUUID is unsupported src/conf/domain_conf.c | 27 ++++- src/conf/domain_conf.h | 5 + src/qemu/libvirtd_qemu.aug | 1 + src/qemu/qemu.conf | 6 ++ src/qemu/qemu_command.c | 19 +++- src/qemu/qemu_conf.c | 3 + src/qemu/qemu_conf.h | 1 + src/qemu/qemu_domain.c | 102 ++++++++++++++++++ src/qemu/qemu_domain.h | 13 +++ src/qemu/qemu_process.c | 2 +- src/qemu/test_libvirtd_qemu.aug.in | 1 + ...graphics-vnc-tls-secret.x86_64-latest.args | 36 +++++++ .../graphics-vnc-tls-secret.xml | 30 ++++++ tests/qemuxml2argvtest.c | 5 + 14 files changed, 241 insertions(+), 10 deletions(-) create mode 100644 tests/qemuxml2argvdata/graphics-vnc-tls-secret.x86_64-latest.args create mode 100644 tests/qemuxml2argvdata/graphics-vnc-tls-secret.xml -- 2.20.1

2 19

[libvirt] [PATCH] rpm spec: disable ceph on 32-bit architectures
by Daniel P. Berrangé 21 Jan '19

21 Jan '19

Ceph in upstream and Fedora has dropped support for building on host architectures which are 32-bit. Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- Pushed as a build fix for RPM builds libvirt.spec.in | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/libvirt.spec.in b/libvirt.spec.in index b04cf53eb8..567721f424 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -109,6 +109,12 @@ %define with_storage_zfs 0 %endif +# Ceph dropping support for 32-bit hosts +%if 0%{fedora} >= 30 + %ifarch %{arm} %{ix86} + %define with_storage_rbd 0 + %endif +%endif # RHEL doesn't ship OpenVZ, VBox, PowerHypervisor, # VMware, libxenserver (xenapi), libxenlight (Xen 4.1 and newer), -- 2.20.1

1 0

[libvirt] [PATCH] qemu: fix i6300esb watchdog hotplug on Q35
by Laine Stump 18 Jan '19

18 Jan '19

When commit 361c8dc17 added support for hotplugging the i6300esb watchdog device (first in libvirt-3.9.0), it accidentally contstructed the commandline for the device_add command before allocating a PCI address for the device. With no PCI address specified in the command, the watchdog would simply be placed at the lowest unused PCI slot. On a 440fx guest, this doesn't cause a problem, because libvirt's PCI address allocation algorithm would most likely give the same address anyway (usually a slot on pci-root), so nobody noticed the omission of address from the command. But on a Q35 guest, the lowest unused PCI slot is on pcie-root, which doesn't support hotplug; libvirt knows enough to assign a PCI address that is on a pcie-to-pci-bridge (because its slots *do* support hotplug), but qemu doesn't, so if there is no PCI address in the command, qemu just tries to plug the new device into pcie-root, and fails because it doesn't support hotplug, e.g.: error: Failed to attach device from watchdog.xml error: internal error: unable to execute QEMU command 'device_add': Bus 'pcie.0' does not support hotplugging The solution is simply to build the command string after assigning a PCI address, not before. Resolves: https://bugzilla.redhat.com/1666559 Signed-off-by: Laine Stump <laine(a)laine.org> --- src/qemu/qemu_hotplug.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c index a1c3ca999b..40c693483e 100644 --- a/src/qemu/qemu_hotplug.c +++ b/src/qemu/qemu_hotplug.c @@ -3280,9 +3280,6 @@ qemuDomainAttachWatchdog(virQEMUDriverPtr driver, if (qemuAssignDeviceWatchdogAlias(watchdog) < 0) return -1; - if (!(watchdogstr = qemuBuildWatchdogDevStr(vm->def, watchdog, priv->qemuCaps))) - return -1; - if (watchdog->model == VIR_DOMAIN_WATCHDOG_MODEL_I6300ESB) { if (qemuDomainEnsurePCIAddress(vm, &dev, driver) < 0) goto cleanup; @@ -3294,6 +3291,9 @@ qemuDomainAttachWatchdog(virQEMUDriverPtr driver, goto cleanup; } + if (!(watchdogstr = qemuBuildWatchdogDevStr(vm->def, watchdog, priv->qemuCaps))) + goto cleanup; + /* QEMU doesn't have a 'dump' action; we tell qemu to 'pause', then libvirt listens for the watchdog event, and we perform the dump ourselves. so convert 'dump' to 'pause' for the qemu cli */ -- 2.20.1

2 1

[libvirt] ANNOUNCE: libvirt-dbus 1.3.0 released
by Pavel Hrdina 18 Jan '19

18 Jan '19

I'm happy to announce the release of libvirt-dbus 1.3.0. libvirt-dbus wraps libvirt API to provide high-level object-oriented API better suited for dbus-based applications. You can download it here: https://libvirt.org/sources/dbus/libvirt-dbus-1.3.0.tar.xz * New features - Support for all relevant interface APIs up to libvirt 3.0.0 * Bug fixes - Storage volumes and with special characters in the name are now correctly listed * Build-system improvements - Detect flake8 automatically - Install daemon under @sbindir@ - Fix version check for dependencies Thanks everybody who contributed! Pavel

1 0

[libvirt] [PATCH 00/23] Clean up qemu.conf parsing
by Ján Tomko 18 Jan '19

18 Jan '19

Remove the odd three-phase defaults filling for TLS cert dirs and split out the huge function into smaller ones based on the entry groups in the augeas file. Ján Tomko (23): qemu: fix double space in augeas file qemu: group swtpm entry in augeas file qemu.conf: fill out TLS verify attributes after parsing qemu: fill out usage-specific TLS settings after parsing qemu_conf: split out virQEMUDriverConfigLoadSWTPMEntry qemu_conf: split out virQEMUDriverConfigLoadMemoryEntry qemu_conf: split out virQEMUDriverConfigLoadSecurityEntry qemu_conf: split out virQEMUDriverConfigLoadGlusterDebugEntry qemu_conf: split out virQEMUDriverConfigLoadNVRAMEntry qemu_conf: split out virQEMUDriverConfigLoadLogEntry qemu_conf: split out virQEMUDriverConfigLoadNetworkEntry qemu_conf: split out virQEMUDriverConfigLoadRPCEntry qemu_conf: split out virQEMUDriverConfigLoadDeviceEntry qemu_conf: split out virQEMUDriverConfigLoadProcessEntry qemu_conf: split out virQEMUDriverConfigLoadSaveEntry qemu_conf: split out virQEMUDriverConfigLoadRemoteDisplayEntry qemu_conf: split out virQEMUDriverConfigLoadSpecificTLS qemu_conf: split out virQEMUDriverConfigLoadSPICEEntry qemu_conf: split out virQEMUDriverConfigLoadNographicsEntry qemu_conf: split out virQEMUDriverConfigLoadVNCEntry qemu_conf: split out virQEMUDriverConfigLoadDefaultTLSEntry qemu_conf: rename checkdefaultTLSx509certdir qemu_conf: fix stray space src/qemu/libvirtd_qemu.aug | 9 +- src/qemu/qemu_conf.c | 751 +++++++++++++++++++++++-------------- src/qemu/qemu_conf.h | 8 +- src/qemu/qemu_driver.c | 3 + 4 files changed, 480 insertions(+), 291 deletions(-) -- 2.20.1

2 52

[libvirt] [PATCH v1 1/1] qemu_hotplug.c: assert disk->info.alias unique before hotplug
by Daniel Henrique Barboza 18 Jan '19

18 Jan '19

In a case where we want to hotplug the following disk: <disk type='file' device='disk'> (...) <address type='drive' controller='0' bus='0' target='0' unit='0'/> </disk> In a QEMU guest that has a single OS disk, as follows: <disk type='file' device='disk'> (...) <address type='drive' controller='0' bus='0' target='0' unit='0'/> </disk> What happens is that the existing guest disk will receive the ID 'scsi0-0-0-0' due to how Libvirt calculate the alias based on the address in qemu_alias.c, qemuAssignDeviceDiskAlias. When hotplugging a disk that happens to have the same address, Libvirt will calculate the same ID to it and attempt to device_add. QEMU will refuse it: $ virsh attach-device dhb hp-disk-dup.xml error: Failed to attach device from hp-disk-dup.xml error: internal error: unable to execute QEMU command 'device_add': Duplicate ID 'scsi0-0-0-0' for device And Libvirt follows it up with a cleanup code in qemuDomainAttachDiskGeneric that ends up removing what supposedly is a faulty hotplugged disk but, in this case, ends up being the original guest disk. This happens because Libvirt doesn't differentiate the error received by QMP device_add. An argument can be made for how QMP device_add should provide a different error code for this scenario. A quicker way to solve the problem is presented in this patch: let us check the generated alias against the aliases already presented in the disks in the VM definition. If a match happens, error out without calling device_add. After this patch, this is the result of the previous attach-device call: $ ./run tools/virsh attach-device dhb ~/hp-disk-dup.xml [sudo] password for danielhb: error: Failed to attach device from /home/danielhb/hp-disk-dup.xml error: operation failed: attached disk conflicts with existing device id 'scsi0-0-0-0' Reported-by: Srikanth Aithal <bssrikanth(a)in.ibm.com> Signed-off-by: Daniel Henrique Barboza <danielhb413(a)gmail.com> --- src/qemu/qemu_hotplug.c | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c index a1c3ca999b..7c770211ab 100644 --- a/src/qemu/qemu_hotplug.c +++ b/src/qemu/qemu_hotplug.c @@ -875,6 +875,27 @@ qemuDomainChangeEjectableMedia(virQEMUDriverPtr driver, } +/** + * qemuDomainDeviceAliasIsUnique: + * + * Searches the existing domain disks to check if a given alias is + * unique. */ +static bool +qemuDomainDeviceAliasIsUnique(virDomainDefPtr def, char *alias) +{ + int idx; + + for (idx = (def->ndisks - 1); idx >= 0; idx--) { + if (def->disks[idx]->info.alias && + (strcmp(def->disks[idx]->info.alias, alias) == 0)) { + + return false; + } + } + return true; +} + + /** * qemuDomainAttachDiskGeneric: * @@ -897,6 +918,13 @@ qemuDomainAttachDiskGeneric(virQEMUDriverPtr driver, if (qemuAssignDeviceDiskAlias(vm->def, disk, priv->qemuCaps) < 0) goto error; + if (!qemuDomainDeviceAliasIsUnique(vm->def, disk->info.alias)) { + virReportError(VIR_ERR_OPERATION_FAILED, + _("attached disk conflicts with existing " + "device id '%s'"), disk->info.alias); + goto error; + } + if (qemuDomainPrepareDiskSource(disk, priv, cfg) < 0) goto error; -- 2.20.1

2 2

[libvirt] [PATCH] qemu: process: Use enum belonging to correct type
by Peter Krempa 18 Jan '19

18 Jan '19

GCC was unhappy about comparison between two distinct enum types. Use the correct value instead. Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- Pushed as a build fix. src/qemu/qemu_process.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c index afa960a683..855bd9cb14 100644 --- a/src/qemu/qemu_process.c +++ b/src/qemu/qemu_process.c @@ -7835,7 +7835,7 @@ qemuProcessRefreshLegacyBlockjob(void *payload, return 0; } - if (jobtype == VIR_DOMAIN_BLOCK_JOB_TYPE_COMMIT && + if (jobtype == QEMU_BLOCKJOB_TYPE_COMMIT && disk->mirrorJob == VIR_DOMAIN_BLOCK_JOB_TYPE_ACTIVE_COMMIT) jobtype = disk->mirrorJob; -- 2.20.1

2 2

[libvirt] [PATCH] rpc: virNetClientNew: fix socket leak on error path
by Nikolay Shirokovskiy 18 Jan '19

18 Jan '19

if virNetClientNew finishes with error before sock is set to client object then sock does not get unrefed. This is unexpected by function clients like virNetClientNewUNIX. Let's make sure sock gets unrefed on any error path. Next some clients like virNetClientNewLibSSH2 try to unref sock on virNetClientNew errors. This is not correct even before this patch because in some cases virNetClientNew unrefed sock on error path by itself. Let's give up sock managment to virNetClientNew entirely. Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy(a)virtuozzo.com> --- src/rpc/virnetclient.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/src/rpc/virnetclient.c b/src/rpc/virnetclient.c index 2aced79..b7ffdcb 100644 --- a/src/rpc/virnetclient.c +++ b/src/rpc/virnetclient.c @@ -299,7 +299,7 @@ static virNetClientPtr virNetClientNew(virNetSocketPtr sock, int wakeupFD[2] = { -1, -1 }; if (virNetClientInitialize() < 0) - return NULL; + goto error; if (pipe2(wakeupFD, O_CLOEXEC) < 0) { virReportSystemError(errno, "%s", @@ -311,6 +311,7 @@ static virNetClientPtr virNetClientNew(virNetSocketPtr sock, goto error; client->sock = sock; + sock = NULL; client->wakeupReadFD = wakeupFD[0]; client->wakeupSendFD = wakeupFD[1]; wakeupFD[0] = wakeupFD[1] = -1; @@ -327,6 +328,7 @@ static virNetClientPtr virNetClientNew(virNetSocketPtr sock, VIR_FORCE_CLOSE(wakeupFD[0]); VIR_FORCE_CLOSE(wakeupFD[1]); virObjectUnref(client); + virObjectUnref(sock); return NULL; } @@ -513,7 +515,6 @@ virNetClientPtr virNetClientNewLibSSH2(const char *host, if (!(ret = virNetClientNew(sock, NULL))) goto cleanup; - sock = NULL; cleanup: VIR_FREE(command); @@ -522,7 +523,6 @@ virNetClientPtr virNetClientNewLibSSH2(const char *host, VIR_FREE(homedir); VIR_FREE(confdir); VIR_FREE(nc); - virObjectUnref(sock); return ret; no_memory: @@ -619,7 +619,6 @@ virNetClientPtr virNetClientNewLibssh(const char *host, if (!(ret = virNetClientNew(sock, NULL))) goto cleanup; - sock = NULL; cleanup: VIR_FREE(command); @@ -628,7 +627,6 @@ virNetClientPtr virNetClientNewLibssh(const char *host, VIR_FREE(homedir); VIR_FREE(confdir); VIR_FREE(nc); - virObjectUnref(sock); return ret; no_memory: -- 1.8.3.1

2 2

[libvirt] [PATCH] storage: More uniquely identify NPIV LUNs
by John Ferlan 18 Jan '19

18 Jan '19

https://bugzilla.redhat.com/show_bug.cgi?id=1657468 Commit be1bb6c95 changed the way volumes were stored from a forward linked list to a hash table. In doing so, it required that each vol object would have 3 unique values as keys into tables - key, name, and path. Due to how vHBA/NPIV LUNs are created/used this resulted in a failure to utilize all the LUN's found during processing. The virStorageBackendSCSINewLun uses virStorageBackendSCSISerial in order to read/return the unique serial number of the LUN to be used as a key for the volume. However, for NPIV based LUNs the logic results in usage of the same serial value for each path to the LUN. For example, $ lsscsi -tg ... [4:0:3:13] disk fc:0x207800c0ffd79b2a0xeb02ef /dev/sde /dev/sg16 [4:0:4:0] disk fc:0x50060169446021980xeb1f00 /dev/sdf /dev/sg17 [4:0:5:0] disk fc:0x50060161446021980xeb2000 /dev/sdg /dev/sg18 ... /lib/udev/scsi_id --replace-whitespace --whitelisted --device /dev/sde 3600c0ff000d7a2965c603e5401000000 /lib/udev/scsi_id --replace-whitespace --whitelisted --device /dev/sdf 350060160c460219850060160c4602198 /lib/udev/scsi_id --replace-whitespace --whitelisted --device /dev/sdg 350060160c460219850060160c4602198 The /dev/sdf and /dev/sdg although separate LUNs would end up with the same serial number used for the vol->key value. When attempting to add the LUN via virStoragePoolObjAddVol, the hash table code will indicate that we have a duplicate: virHashAddOrUpdateEntry:341 : internal error: Duplicate key and thus the LUN is not added to the pool. Digging deeper into the scsi_id output using the --export option one will find that the only difference between the two luns is: ID_TARGET_PORT=1 for /dev/sdf ID_TARGET_PORT=2 for /dev/sdg So, let's use the ID_TARGET_PORT string value along with the serial to generate a more unique key using "@serial_PORT@target_port", where @target_port is just the value of the ID_TARGET_PORT for the LUN. Signed-off-by: John Ferlan <jferlan(a)redhat.com> --- src/storage/storage_util.c | 61 +++++++++++++++++++++++++++++++++++++- 1 file changed, 60 insertions(+), 1 deletion(-) diff --git a/src/storage/storage_util.c b/src/storage/storage_util.c index a84ee5b600..d6d441c06d 100644 --- a/src/storage/storage_util.c +++ b/src/storage/storage_util.c @@ -3755,6 +3755,49 @@ virStorageBackendRefreshLocal(virStoragePoolObjPtr pool) } +static char * +virStorageBackendSCSITargetPort(const char *dev) +{ + char *target_port = NULL; + const char *id; +#ifdef WITH_UDEV + virCommandPtr cmd = virCommandNewArgList( + "/lib/udev/scsi_id", + "--replace-whitespace", + "--whitelisted", + "--export", + "--device", dev, + NULL + ); + + /* Run the program and capture its output */ + virCommandSetOutputBuffer(cmd, &target_port); + if (virCommandRun(cmd, NULL) < 0) + goto cleanup; +#endif + + if (target_port && STRNEQ(target_port, "") && + (id = strstr(target_port, "ID_TARGET_PORT="))) { + char *nl = strchr(id, '\n'); + if (nl) + *nl = '\0'; + id = strrchr(id, '='); + memmove(target_port, id + 1, strlen(id)); + } else { + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, + _("unable to uniquely identify target port for '%s'"), + dev); + } + +#ifdef WITH_UDEV + cleanup: + virCommandFree(cmd); +#endif + + return target_port; +} + + static char * virStorageBackendSCSISerial(const char *dev) { @@ -3813,6 +3856,8 @@ virStorageBackendSCSINewLun(virStoragePoolObjPtr pool, virStoragePoolDefPtr def = virStoragePoolObjGetDef(pool); virStorageVolDefPtr vol = NULL; char *devpath = NULL; + char *key = NULL; + char *target_port = NULL; int retval = -1; /* Check if the pool is using a stable target path. The call to @@ -3877,9 +3922,21 @@ virStorageBackendSCSINewLun(virStoragePoolObjPtr pool, VIR_STORAGE_VOL_READ_NOERROR)) < 0) goto cleanup; - if (!(vol->key = virStorageBackendSCSISerial(vol->target.path))) + if (!(key = virStorageBackendSCSISerial(vol->target.path))) goto cleanup; + if (def->source.adapter.type == VIR_STORAGE_ADAPTER_TYPE_FC_HOST && + STRNEQ(key, vol->target.path)) { + /* NPIV based LUNs use the same "serial" key. In order to distinguish + * we need to append a port value */ + if (!(target_port = virStorageBackendSCSITargetPort(vol->target.path))) + goto cleanup; + if (virAsprintf(&vol->key, "%s_PORT%s", key, target_port) < 0) + goto cleanup; + } else { + VIR_STEAL_PTR(vol->key, key); + } + def->capacity += vol->target.capacity; def->allocation += vol->target.allocation; @@ -3892,6 +3949,8 @@ virStorageBackendSCSINewLun(virStoragePoolObjPtr pool, cleanup: virStorageVolDefFree(vol); VIR_FREE(devpath); + VIR_FREE(target_port); + VIR_FREE(key); return retval; } -- 2.17.2

3 7

[libvirt] [PATCH v2] qemu: Assign device address before qemuDomainSupportsNicdev
by Wang Yechao 17 Jan '19

17 Jan '19

qemuDomainSupportsNicdev will check the device address type on aarch64. If it is invoked before device address assigned, hotadd vhostuser interface with no address specified will get error. Let qemuDomainEnsurePCIAddress run before qemuDomainSupportsNicdev. Signed-off-by: Wang Yechao <wang.yechao255(a)zte.com.cn> --- v1 patch: https://www.redhat.com/archives/libvir-list/2018-December/msg00435.html Changes in v2: - do not modify the address type, let qemuDomainEnsurePCIAddress do it. --- src/qemu/qemu_hotplug.c | 38 +++++++++++++++++++------------------- 1 file changed, 19 insertions(+), 19 deletions(-) diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c index 8da0233..f25c8db 100644 --- a/src/qemu/qemu_hotplug.c +++ b/src/qemu/qemu_hotplug.c @@ -1369,6 +1369,25 @@ qemuDomainAttachNetDevice(virQEMUDriverPtr driver, if (qemuAssignDeviceNetAlias(vm->def, net, -1) < 0) goto cleanup; + if (qemuDomainIsS390CCW(vm->def) && + net->info.type != VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI && + virQEMUCapsGet(priv->qemuCaps, QEMU_CAPS_CCW)) { + net->info.type = VIR_DOMAIN_DEVICE_ADDRESS_TYPE_CCW; + if (!(ccwaddrs = virDomainCCWAddressSetCreateFromDomain(vm->def))) + goto cleanup; + if (virDomainCCWAddressAssign(&net->info, ccwaddrs, + !net->info.addr.ccw.assigned) < 0) + goto cleanup; + } else if (virQEMUCapsGet(priv->qemuCaps, QEMU_CAPS_VIRTIO_S390)) { + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", + _("virtio-s390 net device cannot be hotplugged.")); + goto cleanup; + } else if (qemuDomainEnsurePCIAddress(vm, &dev, driver) < 0) { + goto cleanup; + } + + releaseaddr = true; + switch (actualType) { case VIR_DOMAIN_NET_TYPE_BRIDGE: case VIR_DOMAIN_NET_TYPE_NETWORK: @@ -1503,25 +1522,6 @@ qemuDomainAttachNetDevice(virQEMUDriverPtr driver, goto cleanup; } - if (qemuDomainIsS390CCW(vm->def) && - net->info.type != VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI && - virQEMUCapsGet(priv->qemuCaps, QEMU_CAPS_CCW)) { - net->info.type = VIR_DOMAIN_DEVICE_ADDRESS_TYPE_CCW; - if (!(ccwaddrs = virDomainCCWAddressSetCreateFromDomain(vm->def))) - goto cleanup; - if (virDomainCCWAddressAssign(&net->info, ccwaddrs, - !net->info.addr.ccw.assigned) < 0) - goto cleanup; - } else if (virQEMUCapsGet(priv->qemuCaps, QEMU_CAPS_VIRTIO_S390)) { - virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", - _("virtio-s390 net device cannot be hotplugged.")); - goto cleanup; - } else if (qemuDomainEnsurePCIAddress(vm, &dev, driver) < 0) { - goto cleanup; - } - - releaseaddr = true; - if (VIR_ALLOC_N(tapfdName, tapfdSize) < 0 || VIR_ALLOC_N(vhostfdName, vhostfdSize) < 0) goto cleanup; -- 1.8.3.1

3 4