June 2015 - Devel - libvirt List Archives

[libvirt] [PATCH] man: clarify usage of virsh blockcopy with --xml
by Ján Tomko 15 Jun '15

15 Jun '15

The --xml option is mandatory if an XML description is used. Otherwise the third parameter is treated as the destination. https://bugzilla.redhat.com/show_bug.cgi?id=1206406#c3 --- tools/virsh.pod | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/virsh.pod b/tools/virsh.pod index 9b57c8c..154922e 100644 --- a/tools/virsh.pod +++ b/tools/virsh.pod @@ -989,12 +989,12 @@ unlimited. The hypervisor can choose whether to reject the value or convert it to the maximum value allowed. =item B<blockcopy> I<domain> I<path> { I<dest> [I<format>] [I<--blockdev>] -| I<xml> } [I<--shallow>] [I<--reuse-external>] [I<bandwidth>] +| I<--xml> B<file> } [I<--shallow>] [I<--reuse-external>] [I<bandwidth>] [I<--wait> [I<--async>] [I<--verbose>]] [{I<--pivot> | I<--finish>}] [I<--timeout> B<seconds>] [I<granularity>] [I<buf-size>] Copy a disk backing image chain to a destination. Either I<dest> as -the destination file name, or I<xml> as the name of an XML file containing +the destination file name, or I<--xml> with the name of an XML file containing a top-level <disk> element describing the destination, must be present. Additionally, if I<dest> is given, I<format> should be specified to declare the format of the destination (if I<format> is omitted, then libvirt -- 2.3.6

2 1

[libvirt] [PATCH] storage: Disallow wiping an extended disk partition
by John Ferlan 15 Jun '15

15 Jun '15

https://bugzilla.redhat.com/show_bug.cgi?id=1225694 Check if the disk partition to be wiped is the extended partition, if so then disallow it. Do this via changing the wipeVol backend to check the volume before passing to the common virStorageBackendVolWipeLocal Signed-off-by: John Ferlan <jferlan(a)redhat.com> --- src/storage/storage_backend_disk.c | 20 +++++++++++++++++++- 1 file changed, 19 insertions(+), 1 deletion(-) diff --git a/src/storage/storage_backend_disk.c b/src/storage/storage_backend_disk.c index c4bd6fe..a283a86 100644 --- a/src/storage/storage_backend_disk.c +++ b/src/storage/storage_backend_disk.c @@ -851,6 +851,24 @@ virStorageBackendDiskBuildVolFrom(virConnectPtr conn, } +static int +virStorageBackendDiskVolWipe(virConnectPtr conn, + virStoragePoolObjPtr pool, + virStorageVolDefPtr vol, + unsigned int algorithm, + unsigned int flags) +{ + if (vol->source.partType != VIR_STORAGE_VOL_DISK_TYPE_EXTENDED) + return virStorageBackendVolWipeLocal(conn, pool, vol, algorithm, flags); + + /* Wiping an extended partition is not support */ + virReportError(VIR_ERR_NO_SUPPORT, + _("cannot wipe extended partition '%s'"), + vol->target.path); + return -1; +} + + virStorageBackend virStorageBackendDisk = { .type = VIR_STORAGE_POOL_DISK, @@ -862,5 +880,5 @@ virStorageBackend virStorageBackendDisk = { .buildVolFrom = virStorageBackendDiskBuildVolFrom, .uploadVol = virStorageBackendVolUploadLocal, .downloadVol = virStorageBackendVolDownloadLocal, - .wipeVol = virStorageBackendVolWipeLocal, + .wipeVol = virStorageBackendDiskVolWipe, }; -- 2.1.0

2 2

[libvirt] [PATCH] scsi: Adjust return status from getBlockDevice
by John Ferlan 15 Jun '15

15 Jun '15

https://bugzilla.redhat.com/show_bug.cgi?id=1224233 Currently it's not possible to determine the difference between a fatal memory allocation or failure to open/read the directory error with a perhaps less fatal, I didn't find the "block" device in the directory (which may be a disk entry without a block device). In the case of the latter, we shouldn't cause failure to continue searching in the caller (virStorageBackendSCSIFindLUs), rather we should allow trying reading the next directory entry. Signed-off-by: John Ferlan <jferlan(a)redhat.com> --- src/storage/storage_backend_scsi.c | 20 ++++++++++++++++++-- 1 file changed, 18 insertions(+), 2 deletions(-) diff --git a/src/storage/storage_backend_scsi.c b/src/storage/storage_backend_scsi.c index e6c8bb5..c5105ec 100644 --- a/src/storage/storage_backend_scsi.c +++ b/src/storage/storage_backend_scsi.c @@ -329,6 +329,15 @@ getOldStyleBlockDevice(const char *lun_path ATTRIBUTE_UNUSED, } +/* + * Search a device entry for the "block" file + * + * Returns + * + * 0 => Found it + * -1 => Fatal error + * -2 => Didn't find in lun_path directory + */ static int getBlockDevice(uint32_t host, uint32_t bus, @@ -354,6 +363,10 @@ getBlockDevice(uint32_t host, goto out; } + /* As long as virDirRead doesn't fail, if we fail to find the + * "block" file in this directory, allow caller to continue + */ + retval = -2; while ((direrr = virDirRead(lun_dir, &lun_dirent, lun_path)) > 0) { if (STREQLEN(lun_dirent->d_name, "block", 5)) { if (strlen(lun_dirent->d_name) == 5) { @@ -368,6 +381,9 @@ getBlockDevice(uint32_t host, break; } } + /* Keep retval = -2 unless there was a fatal error in virDirRead */ + if (retval == -2 && direrr < 0) + retval = -1; closedir(lun_dir); @@ -417,9 +433,9 @@ processLU(virStoragePoolObjPtr pool, VIR_DEBUG("%u:%u:%u:%u is a Direct-Access LUN", host, bus, target, lun); - if (getBlockDevice(host, bus, target, lun, &block_device) < 0) { + if ((retval = getBlockDevice(host, bus, target, lun, &block_device)) < 0) { VIR_DEBUG("Failed to find block device for this LUN"); - return -1; + return retval; } retval = virStorageBackendSCSINewLun(pool, host, bus, target, lun, -- 2.1.0

2 1

[libvirt] [PATCH] virfile: Report useful error fork approach to create NFS mount point fails
by Erik Skultety 15 Jun '15

15 Jun '15

Commit 92d9114e tweaked the way we handle child errors when using fork approach to set specific permissions. The same logic should be used to create directories with specified permissions as well, otherwise the parent process doesn't report any useful error "unknown cause" while still returning negative errcode. https://bugzilla.redhat.com/show_bug.cgi?id=1230137 --- src/util/virfile.c | 48 +++++++++++++++++++++++++++++++++++++++--------- 1 file changed, 39 insertions(+), 9 deletions(-) diff --git a/src/util/virfile.c b/src/util/virfile.c index 5ff4668..7675eeb 100644 --- a/src/util/virfile.c +++ b/src/util/virfile.c @@ -2376,6 +2376,7 @@ virDirCreate(const char *path, if (pid) { /* parent */ /* wait for child to complete, and retrieve its exit code */ VIR_FREE(groups); + while ((waitret = waitpid(pid, &status, 0)) == -1 && errno == EINTR); if (waitret == -1) { ret = -errno; @@ -2384,11 +2385,33 @@ virDirCreate(const char *path, path); goto parenterror; } - if (!WIFEXITED(status) || (ret = -WEXITSTATUS(status)) == -EACCES) { - /* fall back to the simpler method, which works better in - * some cases */ - return virDirCreateNoFork(path, mode, uid, gid, flags); + + /* + * If waitpid succeeded, but if the child exited abnormally or + * reported non-zero status, report failure, except for EACCES where + * we try to fall back to non-fork method as in the original logic. + */ + if (!WIFEXITED(status) || (WEXITSTATUS(status)) != 0) { + if (WEXITSTATUS(status) == EACCES) + return virDirCreateNoFork(path, mode, uid, gid, flags); + char *msg = virProcessTranslateStatus(status); + virReportError(VIR_ERR_INTERNAL_ERROR, + _("child failed to create '%s': %s"), + path, msg); + VIR_FREE(msg); + /* Use child exit status if possible; otherwise, + * just use -EACCES, since by our original failure in + * the non fork+setuid path would have been EACCES or + * EPERM by definition (see qemuOpenFileAs after the + * first virFileOpenAs failure), but EACCES is close enough. + * Besides -EPERM is like returning fd == -1. + */ + if (WIFEXITED(status)) + ret = -WEXITSTATUS(status); + else + ret = -EACCES; } + parenterror: return ret; } @@ -2400,15 +2423,14 @@ virDirCreate(const char *path, ret = -errno; goto childerror; } + if (mkdir(path, mode) < 0) { ret = -errno; - if (ret != -EACCES) { - /* in case of EACCES, the parent will retry */ - virReportSystemError(errno, _("child failed to create directory '%s'"), - path); - } + virReportSystemError(errno, _("child failed to create directory '%s'"), + path); goto childerror; } + /* check if group was set properly by creating after * setgid. If not, try doing it with chown */ if (stat(path, &st) == -1) { @@ -2417,6 +2439,7 @@ virDirCreate(const char *path, _("stat of '%s' failed"), path); goto childerror; } + if ((st.st_gid != gid) && (chown(path, (uid_t) -1, gid) < 0)) { ret = -errno; virReportSystemError(errno, @@ -2424,13 +2447,20 @@ virDirCreate(const char *path, path, (unsigned int) gid); goto childerror; } + if (mode != (mode_t) -1 && chmod(path, mode) < 0) { virReportSystemError(errno, _("cannot set mode of '%s' to %04o"), path, mode); goto childerror; } + childerror: + ret = -ret; + if ((ret & 0xff) != ret) { + VIR_WARN("unable to pass desired return value %d", ret); + ret = 0xff; + } _exit(ret); } -- 1.9.3

2 1

[libvirt] [PATCH] qemu: Do not support 'serial' scsi-block 'lun' devices
by John Ferlan 15 Jun '15

15 Jun '15

https://bugzilla.redhat.com/show_bug.cgi?id=1021480 Seems the property has been deprecated for qemu, although seemingly ignored. This patch enforces from a libvirt perspective that a scsi-block 'lun' device should not provide the 'serial' property. Signed-off-by: John Ferlan <jferlan(a)redhat.com> --- docs/formatdomain.html.in | 3 +++ src/qemu/qemu_command.c | 7 +++++++ 2 files changed, 10 insertions(+) diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in index 1781996..4eb907d 100644 --- a/docs/formatdomain.html.in +++ b/docs/formatdomain.html.in @@ -2502,6 +2502,9 @@ <dd>If present, this specify serial number of virtual hard drive. For example, it may look like <code><serial>WD-WMAP9A966149</serial></code>. + Not supported for scsi-block devices, that is those using + disk <code>type</code> 'block' using <code>device</code> 'lun' + on <code>bus</code> 'scsi'. <span class="since">Since 0.7.1</span> </dd> <dt><code>wwn</code></dt> diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index 0a6d92f..cbea0d5 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -3731,6 +3731,13 @@ qemuBuildDriveStr(virConnectPtr conn, virQEMUCapsGet(qemuCaps, QEMU_CAPS_DRIVE_SERIAL)) { if (qemuSafeSerialParamValue(disk->serial) < 0) goto error; + if (disk->bus == VIR_DOMAIN_DISK_BUS_SCSI && + disk->device == VIR_DOMAIN_DISK_DEVICE_LUN) { + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", + _("scsi-block 'lun' devices do not support the " + "serial property")); + goto error; + } virBufferAddLit(&opt, ",serial="); virBufferEscape(&opt, '\\', " ", "%s", disk->serial); } -- 2.1.0

2 1

[libvirt] [PATCH] qemu: fix cannot attach a virtio channel
by Luyao Huang 15 Jun '15

15 Jun '15

https://bugzilla.redhat.com/show_bug.cgi?id=1230039 When attach a channel which target type is virtio, we will get an error: error: Failed to attach device from channel-file.xml error: internal error: virtio serial device has invalid address type This issue was introduced in commit 9807c4. We didn't check the chr device type is serial then check if the device target type is pci-serial, but not all the Chr device is a serial type so we should check the device type before check the target type to avoid assign wrong address to other device type chr device. Also most of chr device do not need {pci, virtio-serial} address in qemu, we just get the address for the device which needed. Signed-off-by: Luyao Huang <lhuang(a)redhat.com> --- src/qemu/qemu_hotplug.c | 72 +++++++++++++++++++++++++++++++------------------ 1 file changed, 46 insertions(+), 26 deletions(-) diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c index 3562de6..4d60513 100644 --- a/src/qemu/qemu_hotplug.c +++ b/src/qemu/qemu_hotplug.c @@ -1531,6 +1531,48 @@ qemuDomainChrRemove(virDomainDefPtr vmdef, return ret; } +static int +qemuDomainAttachChrDeviceAssignAddr(qemuDomainObjPrivatePtr priv, + virDomainChrDefPtr chr) +{ + if (chr->deviceType == VIR_DOMAIN_CHR_DEVICE_TYPE_CONSOLE && + chr->targetType == VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_VIRTIO && + virDomainVirtioSerialAddrAutoAssign(NULL, priv->vioserialaddrs, + &chr->info, true) < 0) + return -1; + + if (chr->deviceType == VIR_DOMAIN_CHR_DEVICE_TYPE_SERIAL && + chr->targetType == VIR_DOMAIN_CHR_SERIAL_TARGET_TYPE_PCI && + (chr->info.type == VIR_DOMAIN_DEVICE_ADDRESS_TYPE_NONE || + chr->info.type == VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI) && + virDomainPCIAddressEnsureAddr(priv->pciaddrs, &chr->info) < 0) + return -1; + + if (chr->deviceType == VIR_DOMAIN_CHR_DEVICE_TYPE_CHANNEL && + chr->targetType == VIR_DOMAIN_CHR_CHANNEL_TARGET_TYPE_VIRTIO && + virDomainVirtioSerialAddrAutoAssign(NULL, priv->vioserialaddrs, + &chr->info, false) < 0) + return -1; + + return 0; +} + +static void +qemuDomainAttachChrDeviceReleaseAddr(qemuDomainObjPrivatePtr priv, + virDomainObjPtr vm, + virDomainChrDefPtr chr) +{ + if ((chr->deviceType == VIR_DOMAIN_CHR_DEVICE_TYPE_CONSOLE && + chr->targetType == VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_VIRTIO) || + (chr->deviceType == VIR_DOMAIN_CHR_DEVICE_TYPE_CHANNEL && + chr->targetType == VIR_DOMAIN_CHR_CHANNEL_TARGET_TYPE_VIRTIO)) + virDomainVirtioSerialAddrRelease(priv->vioserialaddrs, &chr->info); + + if (chr->deviceType == VIR_DOMAIN_CHR_DEVICE_TYPE_SERIAL && + chr->targetType == VIR_DOMAIN_CHR_SERIAL_TARGET_TYPE_PCI) + qemuDomainReleaseDeviceAddress(vm, &chr->info, NULL); +} + int qemuDomainAttachChrDevice(virQEMUDriverPtr driver, virDomainObjPtr vm, virDomainChrDefPtr chr) @@ -1541,7 +1583,6 @@ int qemuDomainAttachChrDevice(virQEMUDriverPtr driver, char *devstr = NULL; char *charAlias = NULL; bool need_release = false; - bool allowZero = false; if (!virQEMUCapsGet(priv->qemuCaps, QEMU_CAPS_DEVICE)) { virReportError(VIR_ERR_OPERATION_INVALID, "%s", @@ -1552,22 +1593,8 @@ int qemuDomainAttachChrDevice(virQEMUDriverPtr driver, if (qemuAssignDeviceChrAlias(vmdef, chr, -1) < 0) goto cleanup; - if (chr->deviceType == VIR_DOMAIN_CHR_DEVICE_TYPE_CONSOLE && - chr->targetType == VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_VIRTIO) - allowZero = true; - - if (chr->targetType == VIR_DOMAIN_CHR_SERIAL_TARGET_TYPE_PCI) { - if (virDomainPCIAddressEnsureAddr(priv->pciaddrs, &chr->info) < 0) - goto cleanup; - } else if (chr->targetType == VIR_DOMAIN_CHR_SERIAL_TARGET_TYPE_USB) { - /* XXX */ - } else { - if (virDomainVirtioSerialAddrAutoAssign(NULL, - priv->vioserialaddrs, - &chr->info, - allowZero) < 0) - goto cleanup; - } + if (qemuDomainAttachChrDeviceAssignAddr(priv, chr) < 0) + goto cleanup; need_release = true; if (qemuBuildChrDeviceStr(&devstr, vm->def, chr, priv->qemuCaps) < 0) @@ -1601,15 +1628,8 @@ int qemuDomainAttachChrDevice(virQEMUDriverPtr driver, cleanup: if (ret < 0 && virDomainObjIsActive(vm)) qemuDomainChrInsertPreAllocCleanup(vm->def, chr); - if (ret < 0 && need_release) { - if (chr->targetType == VIR_DOMAIN_CHR_SERIAL_TARGET_TYPE_PCI) { - qemuDomainReleaseDeviceAddress(vm, &chr->info, NULL); - } else if (chr->targetType == VIR_DOMAIN_CHR_SERIAL_TARGET_TYPE_USB) { - /* XXX */ - } else { - virDomainVirtioSerialAddrRelease(priv->vioserialaddrs, &chr->info); - } - } + if (ret < 0 && need_release) + qemuDomainAttachChrDeviceReleaseAddr(priv, vm, chr); VIR_FREE(charAlias); VIR_FREE(devstr); return ret; -- 1.8.3.1

3 2

[libvirt] [PATCH] qemu caps: spell queue
by Ján Tomko 15 Jun '15

15 Jun '15

--- src/qemu/qemu_capabilities.c | 4 ++-- src/qemu/qemu_capabilities.h | 2 +- src/qemu/qemu_command.c | 2 +- tests/qemuxml2argvtest.c | 2 +- 4 files changed, 5 insertions(+), 5 deletions(-) diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c index 8a64422..27a632a 100644 --- a/src/qemu/qemu_capabilities.c +++ b/src/qemu/qemu_capabilities.c @@ -286,7 +286,7 @@ VIR_ENUM_IMPL(virQEMUCaps, QEMU_CAPS_LAST, "pci-serial", "aarch64-off", - "vhost-user-multiq", /* 190 */ + "vhost-user-multiqueue", /* 190 */ ); @@ -3317,7 +3317,7 @@ virQEMUCapsInitQMPMonitor(virQEMUCapsPtr qemuCaps, /* vhost-user supports multi-queue from v2.4.0 onwards, * but there is no way to query for that capability */ if (qemuCaps->version >= 2004000) - virQEMUCapsSet(qemuCaps, QEMU_CAPS_VHOSTUSER_MULTIQ); + virQEMUCapsSet(qemuCaps, QEMU_CAPS_VHOSTUSER_MULTIQUEUE); if (virQEMUCapsProbeQMPCommands(qemuCaps, mon) < 0) goto cleanup; diff --git a/src/qemu/qemu_capabilities.h b/src/qemu/qemu_capabilities.h index 3c166b6..30aa504 100644 --- a/src/qemu/qemu_capabilities.h +++ b/src/qemu/qemu_capabilities.h @@ -229,7 +229,7 @@ typedef enum { QEMU_CAPS_DEA_KEY_WRAP = 187, /* -machine dea_key_wrap */ QEMU_CAPS_DEVICE_PCI_SERIAL = 188, /* -device pci-serial */ QEMU_CAPS_CPU_AARCH64_OFF = 189, /* -cpu ...,aarch64=off */ - QEMU_CAPS_VHOSTUSER_MULTIQ = 190, /* vhost-user with -netdev queues= */ + QEMU_CAPS_VHOSTUSER_MULTIQUEUE = 190, /* vhost-user with -netdev queues= */ QEMU_CAPS_LAST, /* this must always be the last item */ } virQEMUCapsFlags; diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index 89f775d..9f247de 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -8141,7 +8141,7 @@ qemuBuildVhostuserCommandLine(virCommandPtr cmd, net->info.alias, net->info.alias); if (queues > 1) { - if (!virQEMUCapsGet(qemuCaps, QEMU_CAPS_VHOSTUSER_MULTIQ)) { + if (!virQEMUCapsGet(qemuCaps, QEMU_CAPS_VHOSTUSER_MULTIQUEUE)) { virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", _("multi-queue is not supported for vhost-user " "with this QEMU binary")); diff --git a/tests/qemuxml2argvtest.c b/tests/qemuxml2argvtest.c index 35bfd29..a90f9a6 100644 --- a/tests/qemuxml2argvtest.c +++ b/tests/qemuxml2argvtest.c @@ -981,7 +981,7 @@ mymain(void) DO_TEST_PARSE_ERROR("vhost_queues-invalid", NONE); DO_TEST("net-vhostuser", QEMU_CAPS_DEVICE, QEMU_CAPS_NETDEV); DO_TEST("net-vhostuser-multiq", - QEMU_CAPS_DEVICE, QEMU_CAPS_NETDEV, QEMU_CAPS_VHOSTUSER_MULTIQ); + QEMU_CAPS_DEVICE, QEMU_CAPS_NETDEV, QEMU_CAPS_VHOSTUSER_MULTIQUEUE); DO_TEST_FAILURE("net-vhostuser-multiq", QEMU_CAPS_DEVICE, QEMU_CAPS_NETDEV); DO_TEST("net-user", NONE); DO_TEST("net-virtio", NONE); -- 2.3.6

3 2

[libvirt] [PATCH] virCapabilitiesDomainDataLookup: Produce saner error message
by Michal Privoznik 15 Jun '15

15 Jun '15

During a review, I've noticed this error message that was eventually produced when I was trying to define a domain: error: invalid argument: could not find capabilities for arch=mips64el domaintype=(null) Look at the (null). Why is it there? Well, during XML parsing, we try to look up the default emulator for given OS type and possibly virt type too. And this is the problem, because if we don't want to look up by virt type, a -1 is passed to note this fact. Later, the code handles -1 just right. Except for error message. When it is constructed (in a very fabulous way I must say), the value is compared to zero, not -1. And since we don't have any translation from -1 to a virt type string, we just print (null). Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- src/conf/capabilities.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/conf/capabilities.c b/src/conf/capabilities.c index 6decde8..9c2c6b4 100644 --- a/src/conf/capabilities.c +++ b/src/conf/capabilities.c @@ -678,7 +678,7 @@ virCapabilitiesDomainDataLookupInternal(virCapsPtr caps, virDomainOSTypeToString(ostype)); if (arch) virBufferAsprintf(&buf, "arch=%s ", virArchToString(arch)); - if (domaintype) + if (domaintype != -1) virBufferAsprintf(&buf, "domaintype=%s ", virDomainVirtTypeToString(domaintype)); if (emulator) -- 2.3.6

2 2

[libvirt] Deleted all setting after reboot
by Amir Azemati 15 Jun '15

15 Jun '15

Hello all great, We had a question, We use OpenStack IceHouse on CentOS 6.5. We use libvirt for create network, attach interface to our VMs and ... There is a problem. When our server restart (reboot), all settings are deleted. We have to go back and do all the setting (create network, attach an interface and ...) from the beginning. How can we solve our problem. our command we enterd: virsh list virsh domiflist ID virsh attach-interface --domain ID --type bridge --source br100 virsh managedsave ID

2 1

[libvirt] [PATCH] qemu: update netdevs of the same mac addrs correctly
by zhang bo 15 Jun '15

15 Jun '15

If a guest has multiple network devices with the same MAC address, when we online update the second device, libvirtd always updates the first one. commit def31e4c forgot to fix the online updating scenario. We need to use virDomainNetFindIdx() to find the correct network device. Signed-off-by: Zhou Yimin <zhouyimin(a)huawei.com> Signed-off-by: Zhang Bo <oscar.zhangbo(a)huawei.com> --- src/qemu/qemu_hotplug.c | 23 +++++++---------------- 1 file changed, 7 insertions(+), 16 deletions(-) diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c index 94ebe35..d455bd6 100644 --- a/src/qemu/qemu_hotplug.c +++ b/src/qemu/qemu_hotplug.c @@ -2052,20 +2052,6 @@ int qemuDomainAttachHostDevice(virConnectPtr conn, return -1; } -static virDomainNetDefPtr *qemuDomainFindNet(virDomainObjPtr vm, - virDomainNetDefPtr dev) -{ - size_t i; - - for (i = 0; i < vm->def->nnets; i++) { - if (virMacAddrCmp(&vm->def->nets[i]->mac, &dev->mac) == 0) - return &vm->def->nets[i]; - } - - return NULL; -} - - static int qemuDomainChangeNetBridge(virDomainObjPtr vm, virDomainNetDefPtr olddev, @@ -2195,7 +2181,7 @@ qemuDomainChangeNet(virQEMUDriverPtr driver, virDomainDeviceDefPtr dev) { virDomainNetDefPtr newdev = dev->data.net; - virDomainNetDefPtr *devslot = qemuDomainFindNet(vm, newdev); + virDomainNetDefPtr *devslot = NULL; virDomainNetDefPtr olddev; int oldType, newType; bool needReconnect = false; @@ -2205,8 +2191,13 @@ qemuDomainChangeNet(virQEMUDriverPtr driver, bool needReplaceDevDef = false; bool needBandwidthSet = false; int ret = -1; + int changeidx = -1; + + if ((changeidx = virDomainNetFindIdx(vm->def, newdev)) < 0) + goto cleanup; + devslot = &vm->def->nets[changeidx]; - if (!devslot || !(olddev = *devslot)) { + if (!(olddev = *devslot)) { virReportError(VIR_ERR_OPERATION_FAILED, "%s", _("cannot find existing network device to modify")); goto cleanup; -- 1.7.12.4 -- Oscar oscar.zhangbo(a)huawei.com

2 3