- Devel - libvirt List Archives

[libvirt] [PATCH v2] tests: fix segfault in objecteventtest
by Roman Bogorodskiy 29 Aug '16

29 Aug '16

Test 12 from objecteventtest (createXML add event) segaults on FreeBSD with bus error. At some point it calls testNodeDeviceDestroy() from the test driver. And it fails when it tries to unlock the device in the "out:" label of this function. Unlocking fails because the previous step was a call to virNodeDeviceObjRemove from conf/node_device_conf.c. This function removes the given device from the device list and cleans up the object, including destroying of its mutex. However, it does not nullify the pointer that was given to it. As a result, we end up in testNodeDeviceDestroy() here: out: if (obj) virNodeDeviceObjUnlock(obj); And instead of skipping this, we try to do Unlock and fail because of malformed mutex. Change virNodeDeviceObjRemove to use double pointer and set pointer to NULL. --- src/conf/node_device_conf.c | 13 +++++++------ src/conf/node_device_conf.h | 2 +- src/node_device/node_device_hal.c | 4 ++-- src/test/test_driver.c | 2 +- 4 files changed, 11 insertions(+), 10 deletions(-) diff --git a/src/conf/node_device_conf.c b/src/conf/node_device_conf.c index a23d8ef..719abcd 100644 --- a/src/conf/node_device_conf.c +++ b/src/conf/node_device_conf.c @@ -207,22 +207,23 @@ virNodeDeviceObjPtr virNodeDeviceAssignDef(virNodeDeviceObjListPtr devs, } void virNodeDeviceObjRemove(virNodeDeviceObjListPtr devs, - virNodeDeviceObjPtr dev) + virNodeDeviceObjPtr *dev) { size_t i; - virNodeDeviceObjUnlock(dev); + virNodeDeviceObjUnlock(*dev); for (i = 0; i < devs->count; i++) { - virNodeDeviceObjLock(dev); - if (devs->objs[i] == dev) { - virNodeDeviceObjUnlock(dev); + virNodeDeviceObjLock(*dev); + if (devs->objs[i] == *dev) { + virNodeDeviceObjUnlock(*dev); virNodeDeviceObjFree(devs->objs[i]); + *dev = NULL; VIR_DELETE_ELEMENT(devs->objs, i, devs->count); break; } - virNodeDeviceObjUnlock(dev); + virNodeDeviceObjUnlock(*dev); } } diff --git a/src/conf/node_device_conf.h b/src/conf/node_device_conf.h index 8f23a98..9f00500 100644 --- a/src/conf/node_device_conf.h +++ b/src/conf/node_device_conf.h @@ -249,7 +249,7 @@ virNodeDeviceObjPtr virNodeDeviceAssignDef(virNodeDeviceObjListPtr devs, virNodeDeviceDefPtr def); void virNodeDeviceObjRemove(virNodeDeviceObjListPtr devs, - virNodeDeviceObjPtr dev); + virNodeDeviceObjPtr *dev); char *virNodeDeviceDefFormat(const virNodeDeviceDef *def); diff --git a/src/node_device/node_device_hal.c b/src/node_device/node_device_hal.c index ef0cd9c..fb7bf25 100644 --- a/src/node_device/node_device_hal.c +++ b/src/node_device/node_device_hal.c @@ -530,7 +530,7 @@ dev_refresh(const char *udi) /* Simply "rediscover" device -- incrementally handling changes * to sub-capabilities (like net.80203) is nasty ... so avoid it. */ - virNodeDeviceObjRemove(&driver->devs, dev); + virNodeDeviceObjRemove(&driver->devs, &dev); } else { VIR_DEBUG("no device named %s", name); } @@ -560,7 +560,7 @@ device_removed(LibHalContext *ctx ATTRIBUTE_UNUSED, dev = virNodeDeviceFindByName(&driver->devs, name); VIR_DEBUG("%s", name); if (dev) - virNodeDeviceObjRemove(&driver->devs, dev); + virNodeDeviceObjRemove(&driver->devs, &dev); else VIR_DEBUG("no device named %s", name); nodeDeviceUnlock(); diff --git a/src/test/test_driver.c b/src/test/test_driver.c index bc1f93d..53cfa3c 100644 --- a/src/test/test_driver.c +++ b/src/test/test_driver.c @@ -5534,7 +5534,7 @@ testNodeDeviceDestroy(virNodeDevicePtr dev) 0); virNodeDeviceObjLock(obj); - virNodeDeviceObjRemove(&driver->devs, obj); + virNodeDeviceObjRemove(&driver->devs, &obj); out: if (obj) -- 2.7.4

2 2

[libvirt] RFC: Limited dynamic ownership
by Martin Kletzander 29 Aug '16

29 Aug '16

Hi everyone, so there was an idea about limiting the relabelling of images that libvirt does. And I'm taking the liberty of pitching my idea how to approach this. I feel like it's pretty simple thing and there's not much to talk about, but a) I could've missed something and b) you might hate the way I approach it. The idea is to extend the seclabel XML, for example: <seclabel type='dynamic' model='dac' relabel='whitelist'> <path>/var/lib/libvirt/images</path> <path>/data/virt-stuff</path> </seclabel> Either we allow 'relabel' to be set to 'whitelist' or add a new attribute with a name like 'mode' or something, which will control how we relabel the files (actually relabel='no' can mean 'whitelist' and relabel='yes' can mean blacklist without adding anything there). After that you can specify what paths are (dis)allowed to be labelled. Actually thinking about it I like the following the most: <seclabel type='dynamic' model='dac' relabel='no'> <whitelist path='/data'/> <blacklist path='/data/private/non-virt/stuff'/> </seclabel> which I believe is pretty explanatory. Feel free to ask if it's not. And let me know what you think. And have a nice day!!! Martin

2 4

[libvirt] RFC: Qemu/SeaBIOS/VGA/PXE upgrades vs. longterm-snapshot/migration
by Philipp Hahn 29 Aug '16

29 Aug '16

Hello, If my understanding of migration/snapshots is correct, the target/loading VM must be a clone of the source/saving VM, that is have the same devices, RAM/PCI layout, etc. In the past I have had several issues with Qemu, when the distribution (Debian) updates their packaging of SeaBIOS/iPXE/VgaROM, which changes the the next/previous power-of-2 size and thus changes the PCI layout, preventing me from loading old snapshots. As the BIOS file is provided externally, it is prone to such (accidental) updates. As (AFAIK) libvirt does not track the Qemu version, BIOS files inside its XML data, there's always the danger of making snapshots invalid by updating Qemu and the BIOS files. Some questions: 1. Does Qemu use ROM shadowing, that is copying the ROM to RAM? This makes sense on real HW as ROMs are a low slower than RAM. In that case the content of the "ROM" would already be contained inside the VM-State and it would be enough to provide an "empty ROM file of the right size". 2. If Qemu does no ROM shadowing, what happens if I suspend a VM while executing ROM or SMM code and then doing an SeaBIOS update? (my DOS-assembler knowledge is quiet old nowadays) 3. How do others handle long-term snapshots? Just say "good-bye" to your old snapshots when upgrading to a newer Qemu version or keeping the old, probably unmaintained and vulnerable Qemu/BIOS binaries until the end-of-time? Thanks in advance Philipp -- Philipp Hahn Open Source Software Engineer Univention GmbH be open. Mary-Somerville-Str. 1 D-28359 Bremen Tel.: +49 421 22232-0 Fax : +49 421 22232-99 hahn(a)univention.de http://www.univention.de/ Geschäftsführer: Peter H. Ganten HRB 20755 Amtsgericht Bremen Steuer-Nr.: 71-597-02876

2 1

[libvirt] [PATCH] bhyve: fix disks address allocation
by Roman Bogorodskiy 29 Aug '16

29 Aug '16

As bhyve currently doesn't use controller addressing and simply uses 1 implicit controller for 1 disk device, the scheme looks the following: pci addrees -> (implicit controller) -> disk device So in fact we identify disk devices by pci address of implicit controller and just pass it this way to bhyve in a form: -s pci_addr,ahci-(cd|hd),/path/to/disk Therefore, we cannot use virDeviceInfoPCIAddressWanted() because it does not expect that disk devices might need PCI address assignment. As a result, if a disk was specified without address, it will not be generated and domain will to start. Until proper controller addressing is not implemented in the bhyve driver, force each disk to have PCI address generated if it was not specified by user. --- src/bhyve/bhyve_device.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/bhyve/bhyve_device.c b/src/bhyve/bhyve_device.c index 8373a5f..ca30e9f 100644 --- a/src/bhyve/bhyve_device.c +++ b/src/bhyve/bhyve_device.c @@ -107,7 +107,8 @@ bhyveAssignDevicePCISlots(virDomainDefPtr def, } for (i = 0; i < def->ndisks; i++) { - if (!virDeviceInfoPCIAddressWanted(&def->disks[i]->info)) + if (def->disks[i]->info.type == VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI && + !virPCIDeviceAddressIsEmpty(&def->disks[i]->info.addr.pci)) continue; if (virDomainPCIAddressReserveNextSlot(addrs, &def->disks[i]->info, -- 2.9.2

2 2

[libvirt] [PATCH 0/6] auto-assign addresses when <address type='pci'/> is specified
by Laine Stump 28 Aug '16

28 Aug '16

This is an alternative to Cole's series that permits <address type='pci'/> to force assignment of a PCI address, which is particularly useful on platforms that could connect the same device in different ways (e.g. aarch64/virt). Here is Cole's last iteration of the series: https://www.redhat.com/archives/libvir-list/2016-May/msg01088.html I had expressed a dislike of the "auto_allocate" flag that his series temporarily adds to the address (while simultaneously changing the address type to NONE) and suggested just changing all the necessary places to check for a valid PCI address instead of just checking the address type. He replied that this wasn't as simple as it looked, so I decided to try it; turns out he's right. But I still like this method better because it's not playing tricks with the address type, or adding a temporary private attribute to what should be pure config data. Your opinion may vary though :-) Note that patch 5/6 incorporates the same test case that Cole used in his penultimate patch, and I've added his patch to check the case of aarch64 at the end as well. Cole Robinson (1): tests: qemu: test <address type='pci'/> with aarch64 Laine Stump (5): conf: move virDomainDeviceInfo definition from domain_conf.h to device_conf.h conf: new functions to check if PCI address is wanted/present conf: allow type='pci' addresses with no address attributes specified bhyve: auto-assign addresses when <address type='pci'/> is specified qemu: auto-assign addresses when <address type='pci'/> is specified docs/schemas/basictypes.rng | 8 +- src/bhyve/bhyve_device.c | 10 +- src/conf/device_conf.c | 6 +- src/conf/device_conf.h | 132 ++++++++++++++++++++- src/conf/domain_addr.c | 2 +- src/conf/domain_conf.c | 13 +- src/conf/domain_conf.h | 129 -------------------- src/qemu/qemu_domain_address.c | 64 +++++----- ...l2argv-aarch64-virtio-pci-manual-addresses.args | 4 +- ...ml2argv-aarch64-virtio-pci-manual-addresses.xml | 5 + .../qemuxml2argv-pci-autofill-addr.args | 25 ++++ .../qemuxml2argv-pci-autofill-addr.xml | 35 ++++++ tests/qemuxml2argvtest.c | 1 + ...2xmlout-aarch64-virtio-pci-manual-addresses.xml | 5 + .../qemuxml2xmlout-pci-autofill-addr.xml | 41 +++++++ tests/qemuxml2xmltest.c | 1 + 16 files changed, 298 insertions(+), 183 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pci-autofill-addr.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pci-autofill-addr.xml create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-pci-autofill-addr.xml -- 2.5.5

4 21

[libvirt] [PATCH] docs: Add missing / to closing tag
by Christophe Fergeau 26 Aug '16

26 Aug '16

The iothread example for virtio-scsi should be <driver iothread='4'/> rather than <driver iothread='4'> for the XML to be valid. --- I've already pushed this under the docs/trivial rule. Christophe docs/formatdomain.html.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in index f1dadc6..8c15a73 100644 --- a/docs/formatdomain.html.in +++ b/docs/formatdomain.html.in @@ -3166,7 +3166,7 @@ <address type='pci' domain='0x0000' bus='0x00' slot='0x0a' function='0x0'/> </controller> <controller type='scsi' index='0' model='virtio-scsi'> - <driver iothread='4'> + <driver iothread='4'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x0b' function='0x0'/> </controller> ... -- 2.7.4

1 0

[libvirt] [PATCH 0/6] Fix a few issues introduced by adding vcpu hotplug
by Peter Krempa 26 Aug '16

26 Aug '16

Peter Krempa (6): virsh: vcpuinfo: Report vcpu number from the structure rather than it's position qemu: driver: Fix qemuDomainHelperGetVcpus for sparse vcpu topologies doc: clarify documentation for vcpu order conf: Don't validate vcpu count in XML parser qemu: driver: Validate configuration when setting maximum vcpu count conf: Fix build with picky GCC docs/formatdomain.html.in | 7 ++++--- src/conf/domain_conf.c | 13 ++++--------- src/qemu/qemu_driver.c | 23 ++++++++++++++++++----- tools/virsh-domain.c | 3 ++- 4 files changed, 28 insertions(+), 18 deletions(-) -- 2.8.2

2 12

[libvirt] [PATCH] vz: update domain cache after device updates
by Nikolay Shirokovskiy 26 Aug '16

26 Aug '16

--- src/vz/vz_driver.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/vz/vz_driver.c b/src/vz/vz_driver.c index b34fe33..f223794 100644 --- a/src/vz/vz_driver.c +++ b/src/vz/vz_driver.c @@ -1694,6 +1694,9 @@ static int vzDomainUpdateDeviceFlags(virDomainPtr domain, if (prlsdkUpdateDevice(driver, dom, dev) < 0) goto cleanup; + if (prlsdkUpdateDomain(driver, dom) < 0) + goto cleanup; + ret = 0; cleanup: -- 1.8.3.1

3 2

[libvirt] [PATCH] vz: fixed race in vzDomainAttach/DettachDevice
by Olga Krishtal 26 Aug '16

26 Aug '16

While dettaching/attaching device in OpenStack, nova calls vzDomainDettachDevice twice, because the update of the internal configuration of the ct comes a bit latter than the update event. As the result, we suffer from the second call to dettach the same device. Signed-off-by: Olga Krishtal <okrishtal(a)virtuozzo.com> --- src/vz/vz_sdk.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/src/vz/vz_sdk.c b/src/vz/vz_sdk.c index 68dd5b5..9fbf968 100644 --- a/src/vz/vz_sdk.c +++ b/src/vz/vz_sdk.c @@ -3594,6 +3594,12 @@ prlsdkAttachDevice(vzDriverPtr driver, return -1; } + if (prlsdkUpdateDomain(driver, dom) < 0) { + virReportError(VIR_ERR_INTERNAL_ERROR, "%s", + _("Failed to save new config")); + return -1; + } + job = PrlVm_CommitEx(privdom->sdkdom, PVCF_DETACH_HDD_BUNDLE); if (PRL_FAILED(waitDomainJob(job, dom))) return -1; @@ -3661,6 +3667,12 @@ prlsdkDetachDevice(vzDriverPtr driver, goto cleanup; } + if (prlsdkUpdateDomain(driver, dom) < 0) { + virReportError(VIR_ERR_INTERNAL_ERROR, "%s", + _("Failed to save new config")); + goto cleanup; + } + job = PrlVm_CommitEx(privdom->sdkdom, PVCF_DETACH_HDD_BUNDLE); if (PRL_FAILED(waitDomainJob(job, dom))) goto cleanup; -- 1.8.3.1

3 2

[libvirt] [PATCH] vz: getting bus type for containers
by Mikhail Feoktistov 26 Aug '16

26 Aug '16

We should query bus type for containers too, like for VM. In openstack we add volume disk like SCSI, so we can't hardcode SATA bus. --- src/vz/vz_sdk.c | 32 +++++++++++++------------------- 1 file changed, 13 insertions(+), 19 deletions(-) diff --git a/src/vz/vz_sdk.c b/src/vz/vz_sdk.c index f81b320..c4a1c3d 100644 --- a/src/vz/vz_sdk.c +++ b/src/vz/vz_sdk.c @@ -47,7 +47,7 @@ VIR_LOG_INIT("parallels.sdk"); static PRL_HANDLE prlsdkFindNetByMAC(PRL_HANDLE sdkdom, virMacAddrPtr mac); static PRL_HANDLE -prlsdkGetDisk(PRL_HANDLE sdkdom, virDomainDiskDefPtr disk, bool isCt); +prlsdkGetDisk(PRL_HANDLE sdkdom, virDomainDiskDefPtr disk); /* * Log error description @@ -547,7 +547,7 @@ prlsdkAddDomainVideoInfoVm(PRL_HANDLE sdkdom, virDomainDefPtr def) } static int -prlsdkGetDiskId(PRL_HANDLE disk, bool isCt, int *bus, char **dst) +prlsdkGetDiskId(PRL_HANDLE disk, int *bus, char **dst) { PRL_RESULT pret; PRL_UINT32 pos, ifType; @@ -555,13 +555,8 @@ prlsdkGetDiskId(PRL_HANDLE disk, bool isCt, int *bus, char **dst) pret = PrlVmDev_GetStackIndex(disk, &pos); prlsdkCheckRetExit(pret, -1); - /* Let physical devices added to CT look like SATA disks */ - if (isCt) { - ifType = PMS_SATA_DEVICE; - } else { - pret = PrlVmDev_GetIfaceType(disk, &ifType); - prlsdkCheckRetExit(pret, -1); - } + pret = PrlVmDev_GetIfaceType(disk, &ifType); + prlsdkCheckRetExit(pret, -1); switch (ifType) { case PMS_IDE_DEVICE: @@ -632,7 +627,7 @@ prlsdkGetDiskInfo(vzDriverPtr driver, if (*buf != '\0' && virDomainDiskSetSource(disk, buf) < 0) goto cleanup; - if (prlsdkGetDiskId(prldisk, isCt, &disk->bus, &disk->dst) < 0) + if (prlsdkGetDiskId(prldisk, &disk->bus, &disk->dst) < 0) goto cleanup; if (virDiskNameToBusDeviceIndex(disk, &busIdx, &devIdx) < 0) @@ -1598,7 +1593,7 @@ prlsdkBootOrderCheck(PRL_HANDLE sdkdom, PRL_DEVICE_TYPE sdkType, int sdkIndex, goto cleanup; } - if (prlsdkGetDiskId(dev, false, &bus, &dst) < 0) + if (prlsdkGetDiskId(dev, &bus, &dst) < 0) goto cleanup; if (!(bus == disk->bus && STREQ(disk->dst, dst))) @@ -3409,7 +3404,6 @@ prlsdkFindNetByMAC(PRL_HANDLE sdkdom, virMacAddrPtr mac) static int prlsdkConfigureDisk(vzDriverPtr driver, PRL_HANDLE sdkdom, virDomainDiskDefPtr disk, - bool isCt, bool create) { PRL_RESULT pret; @@ -3432,7 +3426,7 @@ static int prlsdkConfigureDisk(vzDriverPtr driver, pret = PrlVmCfg_CreateVmDev(sdkdom, devType, &sdkdisk); prlsdkCheckRetGoto(pret, cleanup); } else { - sdkdisk = prlsdkGetDisk(sdkdom, disk, isCt); + sdkdisk = prlsdkGetDisk(sdkdom, disk); if (sdkdisk == PRL_INVALID_HANDLE) return -1; } @@ -3499,7 +3493,7 @@ static int prlsdkConfigureDisk(vzDriverPtr driver, } static PRL_HANDLE -prlsdkGetDisk(PRL_HANDLE sdkdom, virDomainDiskDefPtr disk, bool isCt) +prlsdkGetDisk(PRL_HANDLE sdkdom, virDomainDiskDefPtr disk) { PRL_RESULT pret; PRL_UINT32 num; @@ -3521,7 +3515,7 @@ prlsdkGetDisk(PRL_HANDLE sdkdom, virDomainDiskDefPtr disk, bool isCt) pret = PrlVmCfg_GetDevByType(sdkdom, devType, i, &sdkdisk); prlsdkCheckRetGoto(pret, error); - if (prlsdkGetDiskId(sdkdisk, isCt, &bus, &dst) < 0) + if (prlsdkGetDiskId(sdkdisk, &bus, &dst) < 0) goto error; if (disk->bus == bus && STREQ(disk->dst, dst)) { @@ -3560,7 +3554,7 @@ prlsdkAttachDevice(vzDriverPtr driver, switch (dev->type) { case VIR_DOMAIN_DEVICE_DISK: if (prlsdkConfigureDisk(driver, privdom->sdkdom, - dev->data.disk, IS_CT(dom->def), true) < 0) + dev->data.disk, true) < 0) return -1; break; @@ -3618,7 +3612,7 @@ prlsdkDetachDevice(vzDriverPtr driver, switch (dev->type) { case VIR_DOMAIN_DEVICE_DISK: - sdkdev = prlsdkGetDisk(privdom->sdkdom, dev->data.disk, IS_CT(dom->def)); + sdkdev = prlsdkGetDisk(privdom->sdkdom, dev->data.disk); if (sdkdev == PRL_INVALID_HANDLE) goto cleanup; @@ -3688,7 +3682,7 @@ prlsdkUpdateDevice(vzDriverPtr driver, switch (dev->type) { case VIR_DOMAIN_DEVICE_DISK: if (prlsdkConfigureDisk(driver, privdom->sdkdom, dev->data.disk, - IS_CT(dom->def), false) < 0) + false) < 0) return -1; break; @@ -3981,7 +3975,7 @@ prlsdkDoApplyConfig(vzDriverPtr driver, for (i = 0; i < def->ndisks; i++) { if (prlsdkConfigureDisk(driver, sdkdom, def->disks[i], - IS_CT(def), true) < 0) + true) < 0) goto error; } -- 1.8.3.1

3 2

[libvirt] [PATCH 1/2] vz: implicitly support additional migration flags
by Pavel Glushchak 26 Aug '16

26 Aug '16

* Added VIR_MIGRATE_LIVE, VIR_MIGRATE_UNDEFINE_SOURCE and VIR_MIGRATE_PERSIST_DEST to supported migration flags Signed-off-by: Pavel Glushchak <pglushchak(a)virtuozzo.com> --- src/vz/vz_driver.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/src/vz/vz_driver.c b/src/vz/vz_driver.c index b34fe33..7a12632 100644 --- a/src/vz/vz_driver.c +++ b/src/vz/vz_driver.c @@ -2887,8 +2887,11 @@ vzEatCookie(const char *cookiein, int cookieinlen, unsigned int flags) goto cleanup; } -#define VZ_MIGRATION_FLAGS (VIR_MIGRATE_PAUSED | \ - VIR_MIGRATE_PEER2PEER) +#define VZ_MIGRATION_FLAGS (VIR_MIGRATE_PAUSED | \ + VIR_MIGRATE_PEER2PEER | \ + VIR_MIGRATE_LIVE | \ + VIR_MIGRATE_UNDEFINE_SOURCE | \ + VIR_MIGRATE_PERSIST_DEST) #define VZ_MIGRATION_PARAMETERS \ VIR_MIGRATE_PARAM_DEST_XML, VIR_TYPED_PARAM_STRING, \ -- 2.7.4

2 4

[libvirt] [PATCH 0/3] Fix qemu's <interface type='ethernet'> tap device online status
by Laine Stump 26 Aug '16

26 Aug '16

These patches are all closely related, but each fixes a different problem, so they each should be in a separate patch. These all came out of Vasiliy's report that type='ethernet tap devices were all offline and didn't have their IP address or routes added. He sent a patch (which was an expanded version of 1/1), and the modification to that patch, along with the other two patches, came out of my review of his patch. Laine Stump (2): qemu: remove unnecessary setting of tap device online state qemu: set tap device online for type='ethernet' Vasiliy Tolstov (1): qemu: fix ethernet network type ip/route assign src/qemu/qemu_hotplug.c | 15 --------------- src/qemu/qemu_interface.c | 14 +++++++++----- 2 files changed, 9 insertions(+), 20 deletions(-) -- 2.7.4

3 16

[libvirt] [PATCH v2] qemu: fix ip/route assigning on ethernet device
by Vasiliy Tolstov 25 Aug '16

25 Aug '16

After investigation, i found that ips and routes incorrectly assigning on device deletion. Also after libvirt create tap device it does not up. Vasiliy Tolstov (1): qemu: fix ethernet network type ip/route assign src/qemu/qemu_interface.c | 23 ++++++++++++++++++----- 1 file changed, 18 insertions(+), 5 deletions(-) -- 2.7.4

2 8

[libvirt] [RFC] libvirt vGPU QEMU integration
by Neo Jia 25 Aug '16

25 Aug '16

Hi libvirt experts, I am starting this email thread to discuss the potential solution / proposal of integrating vGPU support into libvirt for QEMU. Some quick background, NVIDIA is implementing a VFIO based mediated device framework to allow people to virtualize their devices without SR-IOV, for example NVIDIA vGPU, and Intel KVMGT. Within this framework, we are reusing the VFIO API to process the memory / interrupt as what QEMU does today with passthru device. The difference here is that we are introducing a set of new sysfs file for virtual device discovery and life cycle management due to its virtual nature. Here is the summary of the sysfs, when they will be created and how they should be used: 1. Discover mediated device As part of physical device initialization process, vendor driver will register their physical devices, which will be used to create virtual device (mediated device, aka mdev) to the mediated framework. Then, the sysfs file "mdev_supported_types" will be available under the physical device sysfs, and it will indicate the supported mdev and configuration for this particular physical device, and the content may change dynamically based on the system's current configurations, so libvirt needs to query this file every time before create a mdev. Note: different vendors might have their own specific configuration sysfs as well, if they don't have pre-defined types. For example, we have a NVIDIA Tesla M60 on 86:00.0 here registered, and here is NVIDIA specific configuration on an idle system. For example, to query the "mdev_supported_types" on this Tesla M60: cat /sys/bus/pci/devices/0000:86:00.0/mdev_supported_types # vgpu_type_id, vgpu_type, max_instance, num_heads, frl_config, framebuffer, max_resolution 11 ,"GRID M60-0B", 16, 2, 45, 512M, 2560x1600 12 ,"GRID M60-0Q", 16, 2, 60, 512M, 2560x1600 13 ,"GRID M60-1B", 8, 2, 45, 1024M, 2560x1600 14 ,"GRID M60-1Q", 8, 2, 60, 1024M, 2560x1600 15 ,"GRID M60-2B", 4, 2, 45, 2048M, 2560x1600 16 ,"GRID M60-2Q", 4, 4, 60, 2048M, 2560x1600 17 ,"GRID M60-4Q", 2, 4, 60, 4096M, 3840x2160 18 ,"GRID M60-8Q", 1, 4, 60, 8192M, 3840x2160 2. Create/destroy mediated device Two sysfs files are available under the physical device sysfs path : mdev_create and mdev_destroy The syntax of creating a mdev is: echo "$mdev_UUID:vendor_specific_argument_list" > /sys/bus/pci/devices/.../mdev_create The syntax of destroying a mdev is: echo "$mdev_UUID:vendor_specific_argument_list" > /sys/bus/pci/devices/.../mdev_destroy The $mdev_UUID is a unique identifier for this mdev device to be created, and it is unique per system. For NVIDIA vGPU, we require a vGPU type identifier (shown as vgpu_type_id in above Tesla M60 output), and a VM UUID to be passed as "vendor_specific_argument_list". If there is no vendor specific arguments required, either "$mdev_UUID" or "$mdev_UUID:" will be acceptable as input syntax for the above two commands. To create a M60-4Q device, libvirt needs to do: echo "$mdev_UUID:vgpu_type_id=20,vm_uuid=$VM_UUID" > /sys/bus/pci/devices/0000\:86\:00.0/mdev_create Then, you will see a virtual device shows up at: /sys/bus/mdev/devices/$mdev_UUID/ For NVIDIA, to create multiple virtual devices per VM, it has to be created upfront before bringing any of them online. Regarding error reporting and detection, on failure, write() to sysfs using fd returns error code, and write to sysfs file through command prompt shows the string corresponding to error code. 3. Start/stop mediated device Under the virtual device sysfs, you will see a new "online" sysfs file. you can do cat /sys/bus/mdev/devices/$mdev_UUID/online to get the current status of this virtual device (0 or 1), and to start a virtual device or stop a virtual device you can do: echo "1|0" > /sys/bus/mdev/devices/$mdev_UUID/online libvirt needs to query the current state before changing state. Note: if you have multiple devices, you need to write to the "online" file individually. For NVIDIA, if there are multiple mdev per VM, libvirt needs to bring all of them "online" before starting QEMU. 4. Launch QEMU/VM Pass the mdev sysfs path to QEMU as vfio-pci device: -device vfio-pci,sysfsdev=/sys/bus/mdev/devices/$mdev_UUID,id=vgpu0 5. Shutdown sequence libvirt needs to shutdown the qemu, bring the virtual device offline, then destroy the virtual device 6. VM Reset No change or requirement for libvirt as this will be handled via VFIO reset API and QEMU process will keep running as before. 7. Hot-plug It optional for vendors to support hot-plug. And it is same syntax to create a virtual device for hot-plug. For hot-unplug, after executing QEMU monitor "device del" command, libvirt needs to write to "destroy" sysfs to complete hot-unplug process. Since hot-plug is optional, then mdev_create or mdev_destroy operations may return an error if it is not supported. Thanks, Neo

5 6

[libvirt] [PATCH v1] qemu-migration: Disallow migration of read only disk
by Corey S. McQuay 25 Aug '16

25 Aug '16

From: "Corey S. McQuay" <csmcquay(a)linux.vnet.ibm.com> Currently Libvirt allows attempts to migrate read only disks. Qemu cannot handle this as read only disks cannot be written to on the destination system. The end result is a cryptic error message and a failed migration. This patch causes migration to fail earlier and provides a meaningful error message stating that migrating read only disks is not supported. Signed-off-by: Corey S. McQuay <csmcquay(a)linux.vnet.ibm.com> Reviewed-by: Jason J. Herne <jjherne(a)linux.vnet.ibm.com> Reviewed-by: Boris Fiuczynski <fiuczy(a)linux.vnet.ibm.com> --- src/qemu/qemu_migration.c | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c index d018add..7d0a78f 100644 --- a/src/qemu/qemu_migration.c +++ b/src/qemu/qemu_migration.c @@ -2387,6 +2387,28 @@ qemuMigrationIsSafe(virDomainDefPtr def, return true; } +static bool +qemuMigrationAreAllDisksRW(virDomainDefPtr def, + size_t nmigrate_disks, + const char **migrate_disks) +{ + size_t i; + + for (i = 0; i < def->ndisks; i++) { + virDomainDiskDefPtr disk = def->disks[i]; + + if (qemuMigrateDisk(disk, nmigrate_disks, migrate_disks) && + disk->src->readonly) { + virReportError(VIR_ERR_OPERATION_UNSUPPORTED, + _("Cannot migrate read-only disk %s"), + disk->dst); + return false; + } + } + + return true; +} + /** qemuMigrationSetOffline * Pause domain for non-live migration. */ @@ -3132,6 +3154,9 @@ qemuMigrationBeginPhase(virQEMUDriverPtr driver, !qemuMigrationIsSafe(vm->def, nmigrate_disks, migrate_disks)) goto cleanup; + if (!qemuMigrationAreAllDisksRW(vm->def, nmigrate_disks, migrate_disks)) + goto cleanup; + if (flags & VIR_MIGRATE_POSTCOPY && (!(flags & VIR_MIGRATE_LIVE) || flags & VIR_MIGRATE_PAUSED)) { -- 1.8.3.1

4 5

[libvirt] [PATCH 1/2] vz: implicitly support additional migration flags
by Pavel Glushchak 25 Aug '16

25 Aug '16

* Added VIR_MIGRATE_LIVE, VIR_MIGRATE_UNDEFINE_SOURCE and VIR_MIGRATE_PERSIST_DEST to supported migration flags Signed-off-by: Pavel Glushchak <pglushchak(a)virtuozzo.com> --- src/vz/vz_driver.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/src/vz/vz_driver.c b/src/vz/vz_driver.c index b34fe33..7a12632 100644 --- a/src/vz/vz_driver.c +++ b/src/vz/vz_driver.c @@ -2887,8 +2887,11 @@ vzEatCookie(const char *cookiein, int cookieinlen, unsigned int flags) goto cleanup; } -#define VZ_MIGRATION_FLAGS (VIR_MIGRATE_PAUSED | \ - VIR_MIGRATE_PEER2PEER) +#define VZ_MIGRATION_FLAGS (VIR_MIGRATE_PAUSED | \ + VIR_MIGRATE_PEER2PEER | \ + VIR_MIGRATE_LIVE | \ + VIR_MIGRATE_UNDEFINE_SOURCE | \ + VIR_MIGRATE_PERSIST_DEST) #define VZ_MIGRATION_PARAMETERS \ VIR_MIGRATE_PARAM_DEST_XML, VIR_TYPED_PARAM_STRING, \ -- 2.7.4

1 1

[libvirt] [PATCH] Bypass caching in saving VM memory upon external memory snapshot.
by fuweiwei 25 Aug '16

25 Aug '16

From: Fuweiwei <fuweiwei2(a)huawei.com> Currently in qemu-kvm platform, the process of making an external memory snapshot is based on the "migration-to-file" sheme. It will use the system cache to speed up dumping. However, it will make external disk snapshots afterwards, which must wait for the completion of flushing the dirty pages to the snapshot file. i.e. In virFileWrapperFdClose() after qemuMigrationToFile(), it should wait until the libvirt_iohelper thread finishes fdatasync and exits. During this time, the VM is paused (since it is suspended from the last iteration of migration-to-file, to the completion of disk snapshots). Assuming saving 4GB dirty memory at 200MB/s fdatasync speed, the VM will pause for up to 20s, which is unfriendly to guests. So I propose that it may be better to bypass caching upon external memory snapshot, via the VIR_DOMAIN_SAVE_BYPASS_CACHE flag. As a result, it may avoid long-term fdatasync in libvirt_iohelper thread and achieve seemless VM suspend. Signed-off-by: Fuweiwei <fuweiwei2(a)huawei.com> --- src/qemu/qemu_driver.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 2089359..f954c23 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -14117,7 +14117,8 @@ qemuDomainSnapshotCreateActiveExternal(virConnectPtr conn, goto cleanup; if ((ret = qemuDomainSaveMemory(driver, vm, snap->def->file, - xml, compressed, resume, 0, + xml, compressed, resume, + VIR_DOMAIN_SAVE_BYPASS_CACHE, QEMU_ASYNC_JOB_SNAPSHOT)) < 0) goto cleanup; -- 1.8.3.1

2 1

[libvirt] [PATCH 0/7] fspool: backend directory
by Olga Krishtal 25 Aug '16

25 Aug '16

Hi everyone, we would like to propose the first implementation of fspool with directory backend. Filesystem pools is a facility to manage filesystems resources similar to how storage pools manages volume resources. Furthermore new API follows storage API closely where it makes sense. Uploading/downloading operations are not defined yet as it is not obvious how to make it properly. I guess we can use some kind of tar to make a stream from a filesystem. Please share you thoughts on this particular issue. The patchset provides 'dir' backend which simply expose directories in some directory in host filesystem. The virsh commands are provided too. So it is ready to play with, just replace 'pool' in xml descriptions and virsh commands to 'fspool' and 'volume' to 'item'. Examle and usage: Define: virsh -c qemu:///system fspool-define-as fs_pool_name dir --target /path/on/host Build virsh -c qemu:///system fspool-build fs_pool_name Start virsh -c qemu:///system fspool-start fs_pool_name Look inside virsh -c qemu:///system fspool-list (--all) fspool_name Fspool called POOL, on the host fs uses /fs_driver to hold items. virsh -c qemu:///system fspool-dumpxml POOL <fspool type='dir'> <name>POOL</name> <uuid>c57c9d7c-b1d5-4c45-ba9c-67f03d4da160</uuid> <capacity unit='bytes'>733722615808</capacity> <allocation unit='bytes'>1331486720</allocation> <available unit='bytes'>534810800128</available> <source> </source> <target> <path>/fs_driver</path> <permissions> <mode>0755</mode> <owner>0</owner> <group>0</group> </permissions> </target> </fspool> virsh -c qemu:///system fspool-info POOL Name: POOL UUID: c57c9d7c-b1d5-4c45-ba9c-67f03d4da160 State: running Persistent: yes Autostart: no autostart Capacity: 683.33 GiB Allocation: 1.24 GiB Available: 498.08 GiB virsh -c qemu+unix:///system item-list POOL Name Path ------------------------------------------------------------------------------ item1 /fs_driver/item1 item10 /fs_driver/item10 item11 /fs_driver/item11 item12 /fs_driver/item12 item15 /fs_driver/item15 Fspool of directory type is some directory on host fs that holds items (subdirs). Example of usage for items: virsh -c vz+unix:///system item-create-as POOL item1 1g - create item virsh -c qemu+unix:///system item-dumpxml item1 POOL <fsitem> <name>item1</name> <key>/fs_driver/item1</key> <source> fspoo ='POOL' </source> <capacity unit='bytes'>0</capacity> <allocation unit='bytes'>0</allocation> <target> <format type='dir'/> </target> </fsitem> virsh -c qemu+unix:///system item-info item1 POOL Name: item1 Type: dir Capacity: 683.33 GiB Allocation: 634.87 MiB Autostart: no autostart Capacity: 683.33 GiB Allocation: 1.24 GiB Available: 498.08 GiB virsh -c qemu+unix:///system item-list POOL Name Path ------------------------------------------------------------------------------ item1 /fs_driver/item1 item10 /fs_driver/item10 item11 /fs_driver/item11 item12 /fs_driver/item12 item15 /fs_driver/item15 Olga Krishtal (7): fspool: introduce filesystem pools API fspool: usual driver based implementation of filesystem pools API fspools: configuration and internal representation fspools: acl support for filesystem pools remote: filesystem pools driver implementation fspool: default implementation of filesystem pools virsh: filesystem pools commands configure.ac | 33 + daemon/Makefile.am | 4 + daemon/libvirtd.c | 10 + daemon/remote.c | 35 + include/libvirt/libvirt-fs.h | 273 +++++ include/libvirt/libvirt.h | 1 + include/libvirt/virterror.h | 8 + po/POTFILES.in | 6 + src/Makefile.am | 46 + src/access/viraccessdriver.h | 12 + src/access/viraccessdrivernop.c | 19 + src/access/viraccessdriverpolkit.c | 47 + src/access/viraccessdriverstack.c | 49 + src/access/viraccessmanager.c | 31 + src/access/viraccessmanager.h | 11 + src/access/viraccessperm.c | 15 +- src/access/viraccessperm.h | 124 +++ src/conf/fs_conf.c | 1624 +++++++++++++++++++++++++++ src/conf/fs_conf.h | 310 ++++++ src/datatypes.c | 154 +++ src/datatypes.h | 94 ++ src/driver-fs.h | 210 ++++ src/driver.h | 3 + src/fs/fs_backend.h | 85 ++ src/fs/fs_backend_dir.c | 334 ++++++ src/fs/fs_backend_dir.h | 8 + src/fs/fs_driver.c | 2164 ++++++++++++++++++++++++++++++++++++ src/fs/fs_driver.h | 10 + src/libvirt-fs.c | 1715 ++++++++++++++++++++++++++++ src/libvirt.c | 28 + src/libvirt_private.syms | 53 + src/libvirt_public.syms | 46 + src/remote/remote_driver.c | 72 +- src/remote/remote_protocol.x | 522 ++++++++- src/rpc/gendispatch.pl | 19 +- src/util/virerror.c | 37 + tools/Makefile.am | 4 + tools/virsh-fspool.c | 1728 ++++++++++++++++++++++++++++ tools/virsh-fspool.h | 36 + tools/virsh-item.c | 1274 +++++++++++++++++++++ tools/virsh-item.h | 37 + tools/virsh.c | 4 + tools/virsh.h | 9 + 43 files changed, 11294 insertions(+), 10 deletions(-) create mode 100644 include/libvirt/libvirt-fs.h create mode 100644 src/conf/fs_conf.c create mode 100644 src/conf/fs_conf.h create mode 100644 src/driver-fs.h create mode 100644 src/fs/fs_backend.h create mode 100644 src/fs/fs_backend_dir.c create mode 100644 src/fs/fs_backend_dir.h create mode 100644 src/fs/fs_driver.c create mode 100644 src/fs/fs_driver.h create mode 100644 src/libvirt-fs.c create mode 100644 tools/virsh-fspool.c create mode 100644 tools/virsh-fspool.h create mode 100644 tools/virsh-item.c create mode 100644 tools/virsh-item.h -- 1.8.3.1

2 20

[libvirt] [PATCH] remove the dead code this patch is to remove the dead code Signed-off-by: JieWang <wangjie88@huawei.com>
by JieWang 25 Aug '16

25 Aug '16

Signed-off-by: JieWang <wangjie88(a)huawei.com> --- src/qemu/qemu_migration.c | 1 - 1 file changed, 1 deletion(-) diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c index 6a683f7..759e15a 100644 --- a/src/qemu/qemu_migration.c +++ b/src/qemu/qemu_migration.c @@ -1602,7 +1602,6 @@ qemuMigrationPrecreateDisk(virConnectPtr conn, _("cannot precreate storage for disk type '%s'"), virStorageTypeToString(disk->src->type)); goto cleanup; - break; } if ((vol = virStorageVolLookupByName(pool, volName))) { -- 1.9.5.msysgit.1

4 3

[libvirt] [PATCH v3 00/24] qemu: Add support for new vcpu hotplug and unplug
by Peter Krempa 24 Aug '16

24 Aug '16

v3 fixes stuff pointed out in reviews for v2: - more than 10 vcpus problem (patch 8 and new patch 10 adding tests) - few typos and other problems and stuff found while testing: - ordering function for qsort being broken (patch 21) You can fetch the changes at: git fetch git://pipo.sk/pipo/libvirt.git vcpu-unplug-3 Peter Krempa (24): qemu: monitor: Return structures from qemuMonitorGetCPUInfo qemu: monitor: Return struct from qemuMonitor(Text|Json)QueryCPUs qemu: caps: Add capability for query-hotpluggable-cpus command qemu: Forbid config when topology based cpu count doesn't match the config qemu: capabilities: Extract availability of new cpu hotplug for machine types qemu: monitor: Extract QOM path from query-cpus reply qemu: monitor: Add support for calling query-hotpluggable-cpus qemu: monitor: Add algorithm for combining query-(hotpluggable-)-cpus data tests: Add test infrastructure for qemuMonitorGetCPUInfo tests: cpu-hotplug: Add data for x86 hotplug with 11+ vcpus tests: cpu-hotplug: Add data for ppc64 platform including hotplug tests: cpu-hotplug: Add data for ppc64 out-of-order hotplug tests: cpu-hotplug: Add data for ppc64 without threads enabled qemu: domain: Extract cpu-hotplug related data qemu: domain: Prepare for VCPUs vanishing while libvirt is not running util: Extract and rename qemuDomainDelCgroupForThread to virCgroupDelThread conf: Add XML for individual vCPU hotplug qemu: migration: Prepare for non-contiguous vcpu configurations qemu: command: Add helper to convert vcpu definition to JSON props qemu: process: Copy final vcpu order information into the vcpu definition qemu: command: Add support for sparse vcpu topologies qemu: Use modern vcpu hotplug approach if possible qemu: hotplug: Allow marking unplugged devices by alias qemu: hotplug: Add support for VCPU unplug docs/formatdomain.html.in | 45 +++ docs/schemas/domaincommon.rng | 25 ++ src/conf/domain_conf.c | 154 +++++++++- src/conf/domain_conf.h | 6 + src/libvirt_private.syms | 1 + src/qemu/qemu_capabilities.c | 31 +- src/qemu/qemu_capabilities.h | 3 + src/qemu/qemu_command.c | 50 +++- src/qemu/qemu_command.h | 3 + src/qemu/qemu_domain.c | 312 +++++++++++++++++---- src/qemu/qemu_domain.h | 19 +- src/qemu/qemu_driver.c | 247 +++++++++------- src/qemu/qemu_hotplug.c | 124 +++++++- src/qemu/qemu_hotplug.h | 7 + src/qemu/qemu_migration.c | 16 +- src/qemu/qemu_monitor.c | 268 +++++++++++++++++- src/qemu/qemu_monitor.h | 58 +++- src/qemu/qemu_monitor_json.c | 266 +++++++++++++++--- src/qemu/qemu_monitor_json.h | 8 +- src/qemu/qemu_monitor_text.c | 41 +-- src/qemu/qemu_monitor_text.h | 3 +- src/qemu/qemu_process.c | 187 +++++++++++- src/util/vircgroup.c | 20 ++ src/util/vircgroup.h | 4 + .../generic-vcpus-individual.xml | 23 ++ tests/genericxml2xmltest.c | 2 + tests/qemucapabilitiesdata/caps_2.7.0.x86_64.xml | 55 ++-- .../qemumonitorjson-cpuinfo-ppc64-basic-cpus.json | 77 +++++ ...emumonitorjson-cpuinfo-ppc64-basic-hotplug.json | 27 ++ .../qemumonitorjson-cpuinfo-ppc64-basic.data | 40 +++ ...mumonitorjson-cpuinfo-ppc64-hotplug-1-cpus.json | 149 ++++++++++ ...onitorjson-cpuinfo-ppc64-hotplug-1-hotplug.json | 28 ++ .../qemumonitorjson-cpuinfo-ppc64-hotplug-1.data | 51 ++++ ...mumonitorjson-cpuinfo-ppc64-hotplug-2-cpus.json | 221 +++++++++++++++ ...onitorjson-cpuinfo-ppc64-hotplug-2-hotplug.json | 29 ++ .../qemumonitorjson-cpuinfo-ppc64-hotplug-2.data | 62 ++++ ...mumonitorjson-cpuinfo-ppc64-hotplug-4-cpus.json | 221 +++++++++++++++ ...onitorjson-cpuinfo-ppc64-hotplug-4-hotplug.json | 29 ++ .../qemumonitorjson-cpuinfo-ppc64-hotplug-4.data | 62 ++++ ...umonitorjson-cpuinfo-ppc64-no-threads-cpus.json | 77 +++++ ...nitorjson-cpuinfo-ppc64-no-threads-hotplug.json | 125 +++++++++ .../qemumonitorjson-cpuinfo-ppc64-no-threads.data | 72 +++++ ...nitorjson-cpuinfo-x86-basic-pluggable-cpus.json | 50 ++++ ...orjson-cpuinfo-x86-basic-pluggable-hotplug.json | 82 ++++++ ...emumonitorjson-cpuinfo-x86-basic-pluggable.data | 39 +++ .../qemumonitorjson-cpuinfo-x86-full-cpus.json | 104 +++++++ .../qemumonitorjson-cpuinfo-x86-full-hotplug.json | 115 ++++++++ .../qemumonitorjson-cpuinfo-x86-full.data | 76 +++++ tests/qemumonitorjsontest.c | 184 +++++++++++- .../qemuxml2argv-cpu-hotplug-startup.args | 20 ++ .../qemuxml2argv-cpu-hotplug-startup.xml | 29 ++ tests/qemuxml2argvtest.c | 2 + tests/testutils.c | 4 +- 53 files changed, 3677 insertions(+), 276 deletions(-) create mode 100644 tests/genericxml2xmlindata/generic-vcpus-individual.xml create mode 100644 tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-ppc64-basic-cpus.json create mode 100644 tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-ppc64-basic-hotplug.json create mode 100644 tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-ppc64-basic.data create mode 100644 tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-ppc64-hotplug-1-cpus.json create mode 100644 tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-ppc64-hotplug-1-hotplug.json create mode 100644 tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-ppc64-hotplug-1.data create mode 100644 tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-ppc64-hotplug-2-cpus.json create mode 100644 tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-ppc64-hotplug-2-hotplug.json create mode 100644 tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-ppc64-hotplug-2.data create mode 100644 tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-ppc64-hotplug-4-cpus.json create mode 100644 tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-ppc64-hotplug-4-hotplug.json create mode 100644 tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-ppc64-hotplug-4.data create mode 100644 tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-ppc64-no-threads-cpus.json create mode 100644 tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-ppc64-no-threads-hotplug.json create mode 100644 tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-ppc64-no-threads.data create mode 100644 tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-x86-basic-pluggable-cpus.json create mode 100644 tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-x86-basic-pluggable-hotplug.json create mode 100644 tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-x86-basic-pluggable.data create mode 100644 tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-x86-full-cpus.json create mode 100644 tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-x86-full-hotplug.json create mode 100644 tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-x86-full.data create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-hotplug-startup.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-hotplug-startup.xml -- 2.8.2

3 38

[libvirt] [PATCH] storage_backend_rbd: fix typos
by Chen Hanxiao 24 Aug '16

24 Aug '16

From: Chen Hanxiao <chenhanxiao(a)gmail.com> s/failed/failed to Signed-off-by: Chen Hanxiao <chenhanxiao(a)gmail.com> --- src/storage/storage_backend_rbd.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/storage/storage_backend_rbd.c b/src/storage/storage_backend_rbd.c index 9665fbc..4dd4b24 100644 --- a/src/storage/storage_backend_rbd.c +++ b/src/storage/storage_backend_rbd.c @@ -894,7 +894,7 @@ virStorageBackendRBDSnapshotProtect(rbd_image_t image, VIR_DEBUG("Querying if RBD snapshot %s@%s is protected", imgname, snapname); if ((r = rbd_snap_is_protected(image, snapname, &protected)) < 0) { - virReportSystemError(-r, _("failed verify if RBD snapshot %s@%s " + virReportSystemError(-r, _("failed to verify if RBD snapshot %s@%s " "is protected"), imgname, snapname); goto cleanup; } @@ -904,7 +904,7 @@ virStorageBackendRBDSnapshotProtect(rbd_image_t image, imgname, snapname); if ((r = rbd_snap_protect(image, snapname)) < 0) { - virReportSystemError(-r, _("failed protect RBD snapshot %s@%s"), + virReportSystemError(-r, _("failed to protect RBD snapshot %s@%s"), imgname, snapname); goto cleanup; } -- 1.8.3.1

2 1

[libvirt] Plans for next release
by Daniel Veillard 24 Aug '16

24 Aug '16

So if we want a 2.2.0 release around Sep 1st, I suggest entering freeze this Friday probably at the end of the day (european time), then push the rc2 next Tuesday for a release on Thursday, hope this works for everybody, Daniel -- Daniel Veillard | Open Source and Standards, Red Hat veillard(a)redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/

3 3

[libvirt] [PATCH 0/3] virsh: Option completers and small improvements/fixes for autocomplete
by Nishith Shah 24 Aug '16

24 Aug '16

This series introduces option completers and adds some minor improvements and fixes(not bugs per se, just better/sane behavior) in vshReadlineParse. The first patch introduces the usage of option completers to auto-complete arguments for a particular option. The second and third patches provide small improvements like completing the options of type VSH_OT_ARGV or VSH_OT_DATA, and to complete multiple options as well, if a previous option requires an argument, and that argument has been provided. Nishith Shah (3): virsh: Introduce usage of option completers to auto-complete arguments virsh: Allow data or argument options to be completed as well virsh: Complete multiple options when any one option requires data tools/vsh.c | 75 ++++++++++++++++++++++++++++++++++++++++--------------------- 1 file changed, 49 insertions(+), 26 deletions(-) -- 2.1.4

2 5

[libvirt] [PATCH 0/3] Misc virsh improvements
by Pino Toscano 24 Aug '16

24 Aug '16

Hi, this series provides small improvements for virsh. The patches are sent as single series as some of the changes would conflict if sent as different patches. Thanks, Pino Toscano (3): virsh: respect -q/--quiet more virsh: avoid i18n puzzle virsh: use vshError consistently after virBufferError checks tests/virsh-undefine | 4 -- tools/virsh-domain.c | 130 ++++++++++++++++++++++++------------------------ tools/virsh-interface.c | 16 +++--- tools/virsh-network.c | 36 +++++++------- tools/virsh-nodedev.c | 12 ++--- tools/virsh-nwfilter.c | 6 +-- tools/virsh-pool.c | 30 +++++------ tools/virsh-secret.c | 6 +-- tools/virsh-snapshot.c | 16 +++--- tools/virsh-volume.c | 20 ++++---- 10 files changed, 137 insertions(+), 139 deletions(-) -- 2.7.4

3 5

[libvirt] [PATCH] tests: fix segault in objecteventtest
by Roman Bogorodskiy 24 Aug '16

24 Aug '16

Test 12 from objecteventtest (createXML add event) segaults on FreeBSD with bus error. At some point it calls testNodeDeviceDestroy() from the test driver. And it fails when it tries to unlock the device in the "out:" label of this function. Unlocking fails because the previous step was a call to virNodeDeviceObjRemove from conf/node_device_conf.c. This function removes the given device from the device list and cleans up the object, including destroying of its mutex. However, it does not nullify the pointer that was given to it. As a result, we end up in testNodeDeviceDestroy() here: out: if (obj) virNodeDeviceObjUnlock(obj); And instead of skipping this, we try to do Unlock and fail because of malformed mutex. Fix this by nullifying obj passed to virNodeDeviceObjRemove. --- src/conf/node_device_conf.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/conf/node_device_conf.c b/src/conf/node_device_conf.c index a23d8ef..16b9d93 100644 --- a/src/conf/node_device_conf.c +++ b/src/conf/node_device_conf.c @@ -218,6 +218,7 @@ void virNodeDeviceObjRemove(virNodeDeviceObjListPtr devs, if (devs->objs[i] == dev) { virNodeDeviceObjUnlock(dev); virNodeDeviceObjFree(devs->objs[i]); + *(void**)dev = NULL; VIR_DELETE_ELEMENT(devs->objs, i, devs->count); break; -- 2.7.4

2 2