December 2016 - Devel - libvirt List Archives

[libvirt] [PATCH 00/11] Adjust build/start format checking for fs, disk, and logical backends
by John Ferlan 11 Jan '17

11 Jan '17

Two of these patches (2 and 10) are followups to no-overwrite patches previously posted (I left links in the patches for reference). Essentially this series works to unify the probing code from the file system backend using blkid and the parted format reading code from the disk backend in one common set of functions. In doing so, the disk backend will now pick up the ability to use the blkid 'partitions' APIs in order to "probe" the target device for a valid/known partition format type. Additionally, the file system probe will pick up a fallback to the parted mechanism from the disk backend if the 'blkid' APIs are not built into the system. A few extra bells/whistles were added for fs pool startup to ensure that the format in the startup XML matches the format on the target disk, which is essentially the mechanism the disk backend used (although it was slightly broken). Then in order to really pile on, the overwrite logic was added to the logical pool which didn't have any such checking (both build and start). Testing was done locally using an iSCSI device and laying down different formats and seeing what would happen on various usages of the format (with --overwrite and --no-overwrite). John Ferlan (11): storage: Introduce virStorageBackendDeviceProbeEmpty storage: Fix implementation of no-overwrite for file system backend storage: Add partition type checks for BLKID probing storage: Add writelabel bool for virStorageBackendDeviceProbe storage: For FS pool check for properly formatted target volume storage: Move and rename disk backend label checking storage: Adjust disk label found to match labels storage: Clean up logical pool devices on build failure storage: Extract logical device initialize into a helper storage: Add overwrite flag checking for logical pool storage: Validate the device formats at logical startup src/libvirt_private.syms | 1 + src/storage/storage_backend.c | 396 ++++++++++++++++++++++++++++++++++ src/storage/storage_backend.h | 4 + src/storage/storage_backend_disk.c | 150 ++----------- src/storage/storage_backend_fs.c | 118 ++-------- src/storage/storage_backend_fs.h | 5 - src/storage/storage_backend_logical.c | 180 ++++++++++------ tools/virsh-pool.c | 2 +- tools/virsh.pod | 42 ++-- 9 files changed, 585 insertions(+), 313 deletions(-) -- 2.7.4

3 22

[libvirt] [PATCH 00/11] tests: qemu: Add cpu hotplug testing
by Peter Krempa 11 Jan '17

11 Jan '17

Add some useful monitor infrastructure to simplify testing and add testing for the cpu hotplug code. The code has some complex logic which was not covered by current test suite. Peter Krempa (11): qemu: monitor: More strict checking of 'query-cpus' if hotplug is supported util: json: Add helper to reformat JSON strings tests: qemu: Document qemuMonitorTestNewFromFile qemu: Prepare for reuse of qemuDomainSetVcpusLive qemu: Move cpu hotplug code into qemu_hotplug.c tests: qemumonitor: Propagate better error messages tests: qemu: monitor: Add helpers to test full command syntax tests: qemu: Add helper to load full monitor conversation from file tests: hotplug: Add test infrastructure for testing qemu CPU hotplug code tests: hotplug: Add test data for legacy cpu hotplug tests: hotplug: Test CPU hotplug with ppc64 data src/libvirt_private.syms | 1 + src/qemu/qemu_driver.c | 319 ----------- src/qemu/qemu_hotplug.c | 328 ++++++++++++ src/qemu/qemu_hotplug.h | 7 + src/qemu/qemu_monitor.c | 6 +- src/qemu/qemu_monitor_json.c | 6 +- src/qemu/qemu_monitor_json.h | 3 +- src/util/virjson.c | 29 + src/util/virjson.h | 2 + tests/qemuagenttest.c | 3 +- tests/qemuhotplugtest.c | 194 +++++++ tests/qemuhotplugtestcpus/ppc64-bulk-domain.xml | 20 + tests/qemuhotplugtestcpus/ppc64-bulk-monitor.json | 593 +++++++++++++++++++++ .../qemuhotplugtestcpus/ppc64-bulk-result-conf.xml | 64 +++ .../qemuhotplugtestcpus/ppc64-bulk-result-live.xml | 72 +++ .../qemuhotplugtestcpus/x86-modern-bulk-domain.xml | 21 + .../x86-modern-bulk-monitor.json | 471 ++++++++++++++++ .../x86-modern-bulk-result-conf.xml | 40 ++ .../x86-modern-bulk-result-live.xml | 48 ++ tests/qemuhotplugtestcpus/x86-old-bulk-domain.xml | 21 + .../qemuhotplugtestcpus/x86-old-bulk-monitor.json | 193 +++++++ .../x86-old-bulk-result-conf.xml | 30 ++ .../x86-old-bulk-result-live.xml | 38 ++ tests/qemumonitorjsontest.c | 2 +- tests/qemumonitortestutils.c | 322 ++++++++++- tests/qemumonitortestutils.h | 12 +- 26 files changed, 2505 insertions(+), 340 deletions(-) create mode 100644 tests/qemuhotplugtestcpus/ppc64-bulk-domain.xml create mode 100644 tests/qemuhotplugtestcpus/ppc64-bulk-monitor.json create mode 100644 tests/qemuhotplugtestcpus/ppc64-bulk-result-conf.xml create mode 100644 tests/qemuhotplugtestcpus/ppc64-bulk-result-live.xml create mode 100644 tests/qemuhotplugtestcpus/x86-modern-bulk-domain.xml create mode 100644 tests/qemuhotplugtestcpus/x86-modern-bulk-monitor.json create mode 100644 tests/qemuhotplugtestcpus/x86-modern-bulk-result-conf.xml create mode 100644 tests/qemuhotplugtestcpus/x86-modern-bulk-result-live.xml create mode 100644 tests/qemuhotplugtestcpus/x86-old-bulk-domain.xml create mode 100644 tests/qemuhotplugtestcpus/x86-old-bulk-monitor.json create mode 100644 tests/qemuhotplugtestcpus/x86-old-bulk-result-conf.xml create mode 100644 tests/qemuhotplugtestcpus/x86-old-bulk-result-live.xml -- 2.10.2

1 13

[libvirt] [PATCH v3 0/8] aggregate multiple pcie-root-ports onto a single slot
by Laine Stump 11 Jan '17

11 Jan '17

Another rebase of the series with no other changes Laine Stump (8): conf: use struct instead of int for each slot in virDomainPCIAddressBus conf: eliminate concept of "reserveEntireSlot" conf: eliminate repetitive code in virDomainPCIAddressGetNextSlot() conf: start search for next unused PCI address at same slot as previous find conf: new function virDomainPCIAddressIsMulti() qemu: use virDomainPCIAddressIsMulti() to determine multifunction setting conf: aggregate multiple devices on a slot when assigning PCI addresses conf: aggregate multiple pcie-root-ports onto a single slot src/conf/domain_addr.c | 290 ++++++++++++++------- src/conf/domain_addr.h | 48 +++- src/libvirt_private.syms | 1 + src/qemu/qemu_command.c | 16 +- src/qemu/qemu_domain_address.c | 35 ++- .../qemuxml2argv-pcie-root-port.args | 5 +- .../qemuxml2argv-pcie-switch-upstream-port.args | 5 +- .../qemuxml2argv-q35-default-devices-only.args | 7 +- .../qemuxml2argv-q35-multifunction.args | 43 +++ .../qemuxml2argv-q35-multifunction.xml | 51 ++++ .../qemuxml2argv-q35-pcie-autoadd.args | 30 ++- tests/qemuxml2argvdata/qemuxml2argv-q35-pcie.args | 28 +- .../qemuxml2argv-q35-virt-manager-basic.args | 13 +- .../qemuxml2argv-q35-virtio-pci.args | 28 +- tests/qemuxml2argvtest.c | 25 ++ .../qemuxml2xmlout-pcie-root-port.xml | 2 +- .../qemuxml2xmlout-pcie-switch-upstream-port.xml | 4 +- .../qemuxml2xmlout-q35-default-devices-only.xml | 8 +- .../qemuxml2xmlout-q35-multifunction.xml | 120 +++++++++ .../qemuxml2xmlout-q35-pcie-autoadd.xml | 52 ++-- .../qemuxml2xmloutdata/qemuxml2xmlout-q35-pcie.xml | 48 ++-- .../qemuxml2xmlout-q35-virt-manager-basic.xml | 20 +- .../qemuxml2xmlout-q35-virtio-pci.xml | 48 ++-- tests/qemuxml2xmltest.c | 25 ++ 24 files changed, 676 insertions(+), 276 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-q35-multifunction.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-q35-multifunction.xml create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-q35-multifunction.xml -- 2.7.4

4 26

[libvirt] Do different Virgil3D users running have the same CANVAS fingerprint?
by bancfc＠openmailbox.org 11 Jan '17

11 Jan '17

Background: Canvas fingerprinting is a technique to track users based on their GPUs. https://en.wikipedia.org/wiki/Canvas_fingerprinting Someone did some testing and the good news is the fingerprint is common for all users of the same OS across all KVM users because it presents the same virtual GPU/drivers for everybody. What I need your help to find out is whether this holds for Virgil3D users that enable graphics acceleration. (I am running on Debian and the libvirt version in the repos is too old to have this included also I don't have multiple machines) To test this you need: To run plain FireFox on a virtualized distro (with GL acceleration enabled in libvirt) of your choice and visit https://browserleaks.com/canvas . Then repeat the same steps with that same distro (in a VM) on another physical machine and compare values. A good result is if you see the same numbers for both machines. That means the virtual device fingerprint is uniform for all virtual users.

2 3

[libvirt] [PATCH 00/12] vbox: remove support for vbox 3.x and older.
by Dawid Zamirski 10 Jan '17

10 Jan '17

Hello, This series removes support for legacy VirtualBox versions (3.x and older) that did not have upstream support for a while and won't even work on any relatively recent distro. The idea for doing this was first mentioned here [1] and this makes the driver code cleaner as the APIs for those old versions were quite different from v4.0+ and required abstractions to handle the differences. Please note that the first patch in the series is sent to ML as a compressed attachment because it deletes VirtualBox SDK header files for those old verions which are large and the patch would not pass ML message size limit. [1] https://www.redhat.com/archives/libvir-list/2016-November/msg01133.html Regards, Dawid Dawid Zamirski (12): vbox: remove SDK header files for vbox 3 and older. vbox: remove calls to *InstallUniformedAPI macros. vbox: remove code for old API versions. vbox: remove _vboxAttachDrivesOld vbox: do not use IHardDisk anymore. vbox: remove getMachineForSession flag. vbox: remove domain events support. vbox: remove code dealing with oldMediumInterface vbox: IVRDxServer to IVRDEServer. vbox: fix _displayTakeScreenShotPNGToArray vbox: consolidate vbox IID structures. docs: add news entry in improvements section. docs/news.html.in | 8 + src/Makefile.am | 4 - src/vbox/vbox_CAPI_v2_2.h | 4869 ----------------------------------- src/vbox/vbox_CAPI_v3_0.h | 5396 --------------------------------------- src/vbox/vbox_CAPI_v3_1.h | 5297 -------------------------------------- src/vbox/vbox_CAPI_v3_2.h | 5625 ----------------------------------------- src/vbox/vbox_V2_2.c | 37 - src/vbox/vbox_V3_0.c | 37 - src/vbox/vbox_V3_1.c | 37 - src/vbox/vbox_V3_2.c | 37 - src/vbox/vbox_XPCOMCGlue.h | 2 +- src/vbox/vbox_common.c | 402 +-- src/vbox/vbox_common.h | 13 +- src/vbox/vbox_network.c | 12 +- src/vbox/vbox_storage.c | 76 +- src/vbox/vbox_tmpl.c | 3006 ++-------------------- src/vbox/vbox_uniformed_api.h | 171 +- 17 files changed, 438 insertions(+), 24591 deletions(-) delete mode 100644 src/vbox/vbox_CAPI_v2_2.h delete mode 100644 src/vbox/vbox_CAPI_v3_0.h delete mode 100644 src/vbox/vbox_CAPI_v3_1.h delete mode 100644 src/vbox/vbox_CAPI_v3_2.h delete mode 100644 src/vbox/vbox_V2_2.c delete mode 100644 src/vbox/vbox_V3_0.c delete mode 100644 src/vbox/vbox_V3_1.c delete mode 100644 src/vbox/vbox_V3_2.c -- 2.9.3

2 14

[libvirt] qemu-kvm blocked for more than 120 seconds when "libvirt-guests" is enabled
by Oscar Segarra 10 Jan '17

10 Jan '17

Hi, I just have two virtual machines in my environment, I want them to gracefully stop when host is powered off gracefully. Nevertheless, system hangs on shutdown: [root@vdicnode01 ~]# virsh list Id Name State ---------------------------------------------------- 1 vdicdb01 running 2 vdicone01 running The configuration: /usr/libexec/libvirt-guests.sh URIS=default ON_BOOT=ignore ON_SHUTDOWN=shutdown SHUTDOWN_TIMEOUT=60 PARALLEL_SHUTDOWN=5 START_DELAY=0 BYPASS_CACHE=0 CONNECT_RETRIES=10 RETRIES_SLEEP=1 SYNC_TIME=0 [root@vdicnode01 ~]# cat /etc/libvirt/qemu.conf user = "oneadmin" group = "oneadmin" dynamic_ownership = 0 spice_tls = 0 With libvirt-guests service started: [root@vdicnode01 ~]# service libvirt-guests status Redirecting to /bin/systemctl status libvirt-guests.service ● libvirt-guests.service - Suspend Active Libvirt Guests Loaded: loaded (/usr/lib/systemd/system/libvirt-guests.service; disabled; vendor preset: disabled) Active: active (exited) since Sat 2016-12-31 17:13:34 CET; 5s ago Docs: man:libvirtd(8) http://libvirt.org Process: 6619 ExecStart=/usr/libexec/libvirt-guests.sh start (code=exited, status=0/SUCCESS) Main PID: 6619 (code=exited, status=0/SUCCESS) Dec 31 17:13:34 vdicnode01.vdicube.com systemd[1]: Starting Suspend Active Libvirt Guests... Dec 31 17:13:34 vdicnode01.vdicube.com libvirt-guests.sh[6619]: libvirt-guests is configured not to start any guests on boot Dec 31 17:13:34 vdicnode01.vdicube.com systemd[1]: Started Suspend Active Libvirt Guests. [root@vdicnode01 ~]# If I stop locally libvirt-guests (as root) Looks work perfectly: [root@vdicnode01 ~]# virsh list Id Name State ---------------------------------------------------- [root@vdicnode01 ~]# --> Now I start again the virtual machines and the libvirt-guests service <-- [root@vdicnode01 ~]# service libvirtd restart Redirecting to /bin/systemctl restart libvirtd.service [root@vdicnode01 ~]# service libvirt-guests start Redirecting to /bin/systemctl start libvirt-guests.service [root@vdicnode01 ~]# virsh list Id Name State ---------------------------------------------------- 1 vdicone01 running 2 vdicdb01 running [root@vdicnode01 ~]# But If I shutdown the host it look not work properly (I attack screenshots of the shutdown process). Any help will be welcome. Thanks a lot.

3 11

[libvirt] [PATCH 0/6] qemu: blockjob: make automatic disk locking less useless
by Peter Krempa 10 Jan '17

10 Jan '17

If automatic disk locking would be enabled with either lock manager the operations would most probably fail. This was mostly as libvirt did not bother to release images that were no longer written to by qemu, or tried re-lock the same image. This fixes the locking code for creation of external snapshots (both disk-only and with memory), block copy and active block commit. This series also kills the horrible "rollback" code in the external disk snapshot code. Regular block commit work will be tracked by: https://bugzilla.redhat.com/show_bug.cgi?id=1405537 Peter Krempa (6): qemu: blockcopy: Save monitor error prior to calling into lock manager locking: Fix documentation on how automatic sanlock leases are stored qemu: snapshot: Don't redetect backing chain after snapshot qemu: snapshot: Refactor snapshot rollback on failure qemu: snapshot: Properly handle image locking qemu: blockjob: Fix locking of block copy/active block commit src/locking/sanlock.conf | 2 +- src/qemu/qemu_blockjob.c | 26 ++-- src/qemu/qemu_driver.c | 389 +++++++++++++++++++++++++++-------------------- 3 files changed, 242 insertions(+), 175 deletions(-) -- 2.11.0

3 14

[libvirt] [PATCH v3 0/3] qemu: Use virtio-pci by default for mach-virt guests
by Andrea Bolognani 10 Jan '17

10 Jan '17

Changes from [v2]: * rename qemuDomainCountVirtioMMIODevices() to qemuDomainHasVirtioMMIODevices() and make it exit as soon as the first virtio-mmio device is encountered, as suggested by Laine * tweak test suite and note no new test cases are needed * add comments and user documentation * add release notes entry * can actually be merged now that all patches it builds on have been merged :) Changes from [v1]: * use virDomainDeviceInfoIterate(), as suggested by Martin and Laine, which results in cleaner and more robust code [v1] https://www.redhat.com/archives/libvir-list/2016-October/msg00988.html [v2] https://www.redhat.com/archives/libvir-list/2016-October/msg01042.html Andrea Bolognani (3): qemu: Use virtio-pci by default for mach-virt guests docs: Document virtio-mmio by default for mach-virt guests NEWS: Update for virtio-pci by default for mach-virt guests docs/formatdomain.html.in | 8 +++- docs/news.html.in | 6 +++ src/qemu/qemu_domain_address.c | 51 ++++++++++++++++++++-- ...l2argv-aarch64-virt-2.6-virtio-pci-default.args | 14 +++--- .../qemuxml2argv-aarch64-virtio-pci-default.args | 17 +++++--- .../qemuxml2argv-aarch64-virtio-pci-default.xml | 3 -- tests/qemuxml2argvtest.c | 1 + .../qemuxml2xmlout-aarch64-virtio-pci-default.xml | 40 ++++++++++++++--- tests/qemuxml2xmltest.c | 1 + 9 files changed, 119 insertions(+), 22 deletions(-) -- 2.7.4

2 8

[libvirt] [V2]RFC for support cache tune in libvirt
by Qiao, Liyong 10 Jan '17

10 Jan '17

Hi folks I’v send the V1 version RFC early this week, but no reply yet. Thanks Qiaowei for the comment, I’v change the RFC much more libvirt specify, please help to comments on. ##Propose Changes #Libvirtd configure changes Add a new configure option cache_allocation_ratio to libvirtd, which let libvirt to allocate how many cache to domains. Default is 0.5 Eg. On a host which has 55M cache, libvirt can allocate 55M * cache_allocation_ratio cache to domains ## Virsh command line changes: NAME cachetune - control or query domain cache allocation SYNOPSIS cachetune <domain> [--enabled true/false] [--type <type>][--size <number>] [--config] [--live] [--current] DESCRIPTION Allocate cache usage for domain. OPTIONS [--domain] <string> domain name, id or uuid --enabled <true/false> enable cache allocation --type <string> cache allocations type, support l3/l2 etc --size <number> the cache size in KB --config affect next boot --live affect running domain --current affect current domain This will allow libvirt to allocate specify type l3 cache for a domain Domain xml changes: <cachetune> <enabled=’yes’, size=4096, actual_size=4680,type=’l3’> <enabled=’no’, size=256, actual_size=0, type=’l2’> </cachetune> For more information about the detail design, please refer https://www.redhat.com/archives/libvir-list/2016-December/msg01011.html CAT intro: https://software.intel.com/en-us/articles/software-enabling-for-cache-alloc… Best Regards Eli Qiao(乔立勇）OpenStack Core team OTC Intel. --

2 2

[libvirt] [PATCH] util: fix domain object leaks on closecallbacks
by Wang King 10 Jan '17

10 Jan '17

From: wangjing <king.wang(a)huawei.com> The virCloseCallbacksSet method increase object reference for VM, and decrease object reference in virCloseCallbacksUnset. But VM UUID will be deleted from closecallbacks list in virCloseCallbacksRun when connection disconnected, and then object reference cannot be decreased by virCloseCallbacksUnset in callback functions. Signed-off-by: Wang King <king.wang(a)huawei.com> --- src/util/virclosecallbacks.c | 29 +++++++++++++++++------------ 1 file changed, 17 insertions(+), 12 deletions(-) diff --git a/src/util/virclosecallbacks.c b/src/util/virclosecallbacks.c index 891a92b..26d5075 100644 --- a/src/util/virclosecallbacks.c +++ b/src/util/virclosecallbacks.c @@ -300,7 +300,9 @@ virCloseCallbacksGetForConn(virCloseCallbacksPtr closeCallbacks, data.list = list; data.oom = false; + virObjectLock(closeCallbacks); virHashForEach(closeCallbacks->list, virCloseCallbacksGetOne, &data); + virObjectUnlock(closeCallbacks); if (data.oom) { VIR_FREE(list->entries); @@ -329,22 +331,15 @@ virCloseCallbacksRun(virCloseCallbacksPtr closeCallbacks, * them all from the hash. At that point we can release * the lock and run the callbacks safely. */ - virObjectLock(closeCallbacks); list = virCloseCallbacksGetForConn(closeCallbacks, conn); if (!list) return; for (i = 0; i < list->nentries; i++) { - char uuidstr[VIR_UUID_STRING_BUFLEN]; - virUUIDFormat(list->entries[i].uuid, uuidstr); - virHashRemoveEntry(closeCallbacks->list, uuidstr); - } - virObjectUnlock(closeCallbacks); - - for (i = 0; i < list->nentries; i++) { virDomainObjPtr vm; + virDomainObjPtr dom; - if (!(vm = virDomainObjListFindByUUID(domains, + if (!(vm = virDomainObjListFindByUUIDRef(domains, list->entries[i].uuid))) { char uuidstr[VIR_UUID_STRING_BUFLEN]; virUUIDFormat(list->entries[i].uuid, uuidstr); @@ -352,10 +347,20 @@ virCloseCallbacksRun(virCloseCallbacksPtr closeCallbacks, continue; } - vm = list->entries[i].callback(vm, conn, opaque); - if (vm) - virObjectUnlock(vm); + dom = list->entries[i].callback(vm, conn, opaque); + if (dom) + virObjectUnlock(dom); + virObjectUnref(vm); } + + virObjectLock(closeCallbacks); + for (i = 0; i < list->nentries; i++) { + char uuidstr[VIR_UUID_STRING_BUFLEN]; + virUUIDFormat(list->entries[i].uuid, uuidstr); + virHashRemoveEntry(closeCallbacks->list, uuidstr); + } + virObjectUnlock(closeCallbacks); + VIR_FREE(list->entries); VIR_FREE(list); } -- 2.8.3

2 2

[libvirt] [PATCH v2] cmdPerf: Display enabled/disabled message on perf event enable/disable
by Nitesh Konkar 09 Jan '17

09 Jan '17

Currently no message is displayed on successful perf event enable or disable. This patch gives the enabled/disabled status message on successful enabling/disabling of the perf event. Eg:virsh perf Domain --enable instructions --disable cache_misses instructions : enabled cache_misses : disabled Signed-off-by: Nitesh Konkar <nitkon12(a)linux.vnet.ibm.com> --- tools/virsh-domain.c | 27 ++++++++++++++++++--------- 1 file changed, 18 insertions(+), 9 deletions(-) diff --git a/tools/virsh-domain.c b/tools/virsh-domain.c index 3a6fa5c..287ca28 100644 --- a/tools/virsh-domain.c +++ b/tools/virsh-domain.c @@ -8848,13 +8848,27 @@ virshParseEventStr(const char *event, return ret; } +static void +virshPrintPerfStatus(vshControl *ctl, virTypedParameterPtr params, int nparams) +{ + size_t i; + + for (i = 0; i < nparams; i++) { + if (params[i].type == VIR_TYPED_PARAM_BOOLEAN && + params[i].value.b) { + vshPrint(ctl, "%-15s: %s\n", params[i].field, _("enabled")); + } else { + vshPrint(ctl, "%-15s: %s\n", params[i].field, _("disabled")); + } + } +} + static bool cmdPerf(vshControl *ctl, const vshCmd *cmd) { virDomainPtr dom; int nparams = 0; int maxparams = 0; - size_t i; virTypedParameterPtr params = NULL; bool ret = false; const char *enable = NULL, *disable = NULL; @@ -8891,18 +8905,13 @@ cmdPerf(vshControl *ctl, const vshCmd *cmd) vshError(ctl, "%s", _("Unable to get perf events")); goto cleanup; } - for (i = 0; i < nparams; i++) { - if (params[i].type == VIR_TYPED_PARAM_BOOLEAN && - params[i].value.b) { - vshPrint(ctl, "%-15s: %s\n", params[i].field, _("enabled")); - } else { - vshPrint(ctl, "%-15s: %s\n", params[i].field, _("disabled")); - } - } + virshPrintPerfStatus(ctl, params, nparams); } else { if (virDomainSetPerfEvents(dom, params, nparams, flags) != 0) { vshError(ctl, "%s", _("Unable to enable/disable perf events")); goto cleanup; + } else { + virshPrintPerfStatus(ctl, params, nparams); } } -- 1.9.3

2 1

[libvirt] [PATCH 1/2] perf: Refactor perf code
by Nitesh Konkar 09 Jan '17

09 Jan '17

Avoid unnecessary calling of function vshCommandOptStringReq. In the current code the function vshCommandOptStringReq is called irrespective of whether --enable and/or --disable is present in the command line. Eg: 'virsh perf domainName' also results in calling this function twice. This patch fixes this. Signed-off-by: Nitesh Konkar <nitkon12(a)linux.vnet.ibm.com> --- tools/virsh-domain.c | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/tools/virsh-domain.c b/tools/virsh-domain.c index 3a6fa5c..91de532 100644 --- a/tools/virsh-domain.c +++ b/tools/virsh-domain.c @@ -8862,6 +8862,8 @@ cmdPerf(vshControl *ctl, const vshCmd *cmd) bool current = vshCommandOptBool(cmd, "current"); bool config = vshCommandOptBool(cmd, "config"); bool live = vshCommandOptBool(cmd, "live"); + bool shouldEnable = vshCommandOptBool(cmd, "enable"); + bool shouldDisable = vshCommandOptBool(cmd, "disable"); VSH_EXCLUSIVE_OPTIONS_VAR(current, live); VSH_EXCLUSIVE_OPTIONS_VAR(current, config); @@ -8871,9 +8873,15 @@ cmdPerf(vshControl *ctl, const vshCmd *cmd) if (live) flags |= VIR_DOMAIN_AFFECT_LIVE; - if (vshCommandOptStringReq(ctl, cmd, "enable", &enable) < 0 || - vshCommandOptStringReq(ctl, cmd, "disable", &disable) < 0) - return false; + if (shouldEnable) { + if (vshCommandOptStringReq(ctl, cmd, "enable", &enable) < 0) + return false; + } + + if (shouldDisable) { + if (vshCommandOptStringReq(ctl, cmd, "disable", &disable) < 0) + return false; + } if (!(dom = virshCommandOptDomain(ctl, cmd, NULL))) return false; -- 1.9.3

3 3

[libvirt] [PATCH v2 0/2] Detect misconfiguration between disk bus and disk address
by Marc Hartmayer 09 Jan '17

09 Jan '17

This patch series adds the functionality to detect a misconfiguration between disk bus type and disk address type for disks that are using the address type virDomainDeviceDriveAddress. It also adds a test for it. A check for other bus types may be needed. This may require a driver specific function, as it is already implemented in virDomainDeviceDefPostParse(), for example. Changelog: - v1 -> v2: + Use full enumeration of the bus types + Add warning for unexpected bus type Marc Hartmayer (2): conf: Detect misconfiguration between disk bus and disk address tests: Add tests for disk configuration validation src/conf/domain_conf.c | 56 ++++++++++++++++++++++ .../qemuxml2argv-disk-fdc-incompatible-address.xml | 22 +++++++++ .../qemuxml2argv-disk-ide-incompatible-address.xml | 23 +++++++++ ...qemuxml2argv-disk-sata-incompatible-address.xml | 23 +++++++++ ...qemuxml2argv-disk-scsi-incompatible-address.xml | 24 ++++++++++ tests/qemuxml2argvtest.c | 8 ++++ 6 files changed, 156 insertions(+) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-disk-fdc-incompatible-address.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-disk-ide-incompatible-address.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-disk-sata-incompatible-address.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-disk-scsi-incompatible-address.xml -- 2.5.5

4 7

[libvirt] RFC for support Intel RDT/CAT in libvirt
by Qiao, Liyong 09 Jan '17

09 Jan '17

Hi folks I would like to start a discussion about how to support a new cpu feature in libvirt. CAT support is not fully merged into linux kernel yet, the target release is 4.10, and all patches has been merged into linux tip branch. So there won’t be interface/design changes. ## Background Intel RDT is a toolkit to do resource Qos for cpu such as llc(l3) cache, memory bandwidth usage, these fine granularity resource control features are very useful in a cloud environment which will run logs of noisy instances. Currently, Libvirt has supported CAT/MBMT/MBML already, they are only for resource usage monitor, propose to supporting CAT to control VM’s l3 cache quota. ## CAT interface in kernel In kernel, a new resource interface has been introduced under /sys/fs/resctrl, it’s used for resource control, for more information, refer Intel_rdt_ui [ https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/tree/Documentation… ] Kernel requires to provide schemata for l3 cache before add a task to a new partition, these interface is too much detail for a virtual machine user, so propose to let Libvirt manage schemata on the host. ## What will libvirt do? ### Questions: To enable CAT support in libvirt, we need to think about follow questions 1. Only set CAT when an VM has CPU pin, which is to say, l3 cache is per cpu socket resources. On a host which has 2 cpu sockets, each cpu socket has it own cache, and can not be shared.. 2. What the cache allocation policy should be used, this will be looks like: a. VM has it’s own dedicated l3 cache and also can share other l3 cache. b. VM can only use the caches which allocated to it. c. Has some pre-defined policies and priority for a VM Like COB [1] 1. Should reserve some l3 cache for host’s system usage (related to 2) 2. What’s the unit for l3 cache allocation? (related to 2) ### Propose Changes XML domain user interface changes: Option 1: explicit specify cache allocation for a VM 1 work with numa node Some cloud orchestration software use numa + vcpu pin together, so we can enable cat supporting with numa infra. Expose how many l3 cache a VM want to reserved and we require that the l3 cache should be bind on some specify cpu socket, just like what we did for numa node. This is an domain xml example which is generated by OpenStack Nova for allocate llc(l3 cache) when booting a new VM <domain> … <cputune> <vcpupin vcpu='0' cpuset='19'/> <vcpupin vcpu='1' cpuset='63'/> <vcpupin vcpu='2' cpuset='83'/> <vcpupin vcpu='3' cpuset='39'/> <vcpupin vcpu='4' cpuset='40'/> <vcpupin vcpu='5' cpuset='84'/> <emulatorpin cpuset='19,39-40,63,83-84'/> </cputune> ... <cpu mode='host-model'> <model fallback='allow'/> <topology sockets='3' cores='1' threads='2'/> <numa> <cell id='0' cpus='0-1' memory='2097152' l3cache='1408' unit='KiB'/> <cell id='1' cpus='2-5' memory='4194304' l3cache='5632' unit='KiB'/> </numa> </cpu> ... </domain> Refer to [http://libvirt.org/formatdomain.html#elementsCPUTuning] So finally we can calculate on which CPU socket(cell) we need to allocate how may l3cache for a VM. 2. work with vcpu pin Forget numa part, CAT setting should have relationship with cpu core setting, we can apply CAT policy if VM has set cpu pin setting (only VM won’t be schedule to another CPU sockets) Cache allocation on which CPU socket can be calculate as just as 1. We may need to enable both 1 and 2. There are several policy for cache allocation: Let’ take some examples: For intel e5 v4 2699(Signal socket), there are 55M l3 cache on the chip , the default of L3 schemata is L3:0=ffffff , it represents to use 20 bit to control l3 cache, each bit will represent 2.75M, which will be the minimal unit on this host. The allocation policy could be 3 policies : 1. One priority VM: A priority import VM can be allocated a dedicated amount l3 cache (let’s say 2.75 * 4 = 11M) and it can also reach the left 44 M cache which will be shared with other process and VM on the same host. So that we need to create a new ‘Partition’ n-20371 root@s2600wt:/sys/fs/resctrl# ls cpus info n-20371 schemata tasks Inside of n-20371 directory: root@s2600wt:/sys/fs/resctrl# ls n-20371/ cpus schemata tasks The schemata content will be L3:0=fffff The tasks content will be the pids of that VM Along we need to change the default schemata of system: root@s2600wt:/sys/fs/resctrl# cat schemata L3:0=ffff # which can not use the highest 4 bits, only tasks in n-20371 can reach that. In this design , we can only get 1 priority VM. Let’s change it a bit to have 2 VMs The schemata of the 2 VMs could be: 1. L3:0=ffff0 # could not use the 4 low bits 11M l3 cache 2. L3:0=0ffff # could not use the 4 high bits 11M l3 cache Default schemata changes to L3:0=0fff0 # default system process could only use the middle 33M l3 cache 2. Isolated l3 cache dedicated allocation for each VM(if required) A VM can only use the cache allocated to it. For example VM 1 requires to allocate 11 M It’s schemata will be L3:0=f0000 # VM 2 requires to allocate 11M It’s schemata will be L3:0=f000 And default schemata will be L3:0=fff In this case, we can create multiple VMs which each of them can have dedicated l3 cache. The disadvantage is that we the allocated cache could be not be shared efficiently. 3. Isolated l3 cache shared allocation for each VM(if required by user) In this case, we will put some VMs (which consider as noisy neighbors) to a ‘Partition’, restrict them to use the only caches allocated to them, by do this, other much more priority VM can be ensure to have enough l3 cache Then we should decide how much cache the noisy group should have, and put all of their pids in that tasks file. Option 2: set cache priority and apply policies Don’t specify cache amount at all, only define cache usage priority when define a VM domain XML. Cache priority will decide how much the VM can use l3 cache on a host, it’s not a quantized. So user don’t need to think about how much cache it should have when define a domain XML. Libvirt will decide cache allocation by the priority of VM defined and policies using. Disadvantage is that caches ability on different host may be different. Same VM domain XML on different host may have vary caches allocation amount. # Support CAT in libvirt itself or leverage other software COB COB is Intel Cache Orchestrator Balancer (COB). please refer http://clrgitlab.intel.com/rdt/cob/tree/master COB supports some pre-defined policies, it will monitor cpu/cache/cache missing and do cache allocation based on policy using. If COB support monitor some specified process (VM process) and accept priority defined, it will be good to reuse. At last the question came out: * Support a fine-grained llc cache control , let user specify cache allocation * Support pre-defined policies and user specify llc allocation priority. Reference [1] COB http://clrgitlab.intel.com/rdt/cob/tree/master [2] CAT intro: https://software.intel.com/en-us/articles/software-enabling-for-cache-alloc… [3] kernel Intel_rdt_ui [ https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/tree/Documentation… ] Best Regards Eli Qiao(乔立勇）OpenStack Core team OTC Intel. --

2 1

[libvirt] [PATCH 0/6] Don't run whole sec driver in namespace
by Michal Privoznik 09 Jan '17

09 Jan '17

In eadaa97548 I've tried to solve the issue of setting seclabels on private /dev/* entries. While my approach works, it has tiny flaw - anything that happens in the namespace stays in the namespace. I mean, if there's a internal state change occurring on relabel operation (it should not, and it doesn't nowadays, but it's no guarantee), this change is not reflected in the daemon. This is because when entering the namespace, the daemon forks, enters the namespace and then executes the RelabelAll() function. This imperfection is: a) very easy to forget b) very hard to debug Therefore, we may have transaction APIs as suggested here [1]. On transactionBegin() the sec driver will record [path. seclabel] somewhere instead of applying the label. Then on transactionCommit() new process is forked, enters the namespace and perform previously recorded changes. This way it is only the minimal code that runs in the namespace. Moreover, it runs over constant data thus there can be no internal state transition. 1: https://www.redhat.com/archives/libvir-list/2016-December/msg00254.html Michal Privoznik (6): security_selinux: s/virSecuritySELinuxSecurity/virSecuritySELinux/ security_dac: Resolve virSecurityDACSetOwnershipInternal const correctness security driver: Introduce transaction APIs security_dac: Implement transaction APIs security_selinux: Implement transaction APIs qemu: Use transactions from security driver src/libvirt_private.syms | 3 + src/qemu/qemu_driver.c | 28 +++-- src/qemu/qemu_security.c | 98 +++++---------- src/security/security_dac.c | 197 +++++++++++++++++++++++++++++- src/security/security_driver.h | 9 ++ src/security/security_manager.c | 38 ++++++ src/security/security_manager.h | 7 +- src/security/security_selinux.c | 219 +++++++++++++++++++++++++++++++--- src/security/security_stack.c | 49 ++++++++ src/storage/storage_backend.h | 2 +- src/storage/storage_backend_fs.c | 2 +- src/storage/storage_backend_gluster.c | 2 +- src/storage/storage_driver.c | 6 +- src/storage/storage_driver.h | 4 +- src/util/virstoragefile.c | 2 +- src/util/virstoragefile.h | 2 +- 16 files changed, 561 insertions(+), 107 deletions(-) -- 2.11.0

2 12

[libvirt] memory-ballooning side-channel attack
by bancfc＠openmailbox.org 08 Jan '17

08 Jan '17

Hello and Happy Holidays, In the past few years many serious attacks against the memory deduplication (KSM) feature of all hypervisors have been shown. [1] Even allowing attackers to modify/steal APT keys and source lists on the host. [2] Since its not enabled by default the fall out is relatively low and easily mitigated. New side-channel attacks against memory-ballon enabled VMs are beginning to surface. Please consider documenting this and disabling this feature for newly created VMs to have safe defaults. [1] https://staff.aist.go.jp/c.artho/papers/EuroSec2011-suzaki.pdf [2] https://www.usenix.org/system/files/conference/usenixsecurity16/sec16_paper… [3] http://ieeexplore.ieee.org/document/7562068/ *Hint: If you can't see the IEEE paper use sci-hub.

1 1

[libvirt] [PATCH 0/9] Qemu: s390: Cpu Model Support
by Jason J. Herne 06 Jan '17

06 Jan '17

This patch set enables cpu model support for s390. The user can now set exact cpu models, query supported models via virsh domcapabilities, and use host-model and host-passthrough modes. The end result is that migration is safer because Qemu will perform runnability checking on the destination host and quit with an error if the guest's cpu model is not supported. Note: Some test data has been separated from corresponding test case updates for ease of review. Changelog --------- [v3] s390: Cpu driver support for update and compare - Fixed indentation of error message in virCPUs390Update test-data: Qemu caps replies and xml for s390x qemu 2.7 and 2.8 - Moved this patch before introduction of query-cpu-model-expansion - Regenerated all test data tests: domain capabilities: qemu 2.7 and 2.8 on s390x - Added Qemu 2.7 test - Removed fake host model name - Moved this patch before introduction of query-cpu-model-expansion tests: qemu capabilites: qemu 2.7 and 2.8 on s390x - Moved this patch before introduction of query-cpu-model-expansion - Stop using fake host cpu qemu: qmp query-cpu-model-expansion command - Moved query-cpu-model-expansion capability to this patch - changed label "cleanup" to "error" in qemuMonitorCPUModelInfoCopy - qemuMonitorJSONParseCPUModelProperty is now static, and also made appropriate changes when passing a boolean to virJSONValueGetBoolean - removed unnecessary error checking when assigning "data" variable in qemuMonitorJSONGetCPUModelExpansion - Fix up capabilities test data to reflect changes from this commit - fixed query-cpu-model-expansion's enumeration formatting qemu-caps: Get host model directly from Qemu when available - Moved query-cpu-model-expansion capability from this patch - virQEMUCapsCopyCPUModelFromQEMU is now static and type void - check for native guest is done before attempting to set host CPU - s390x no longer falls back to getting host CPU model from the host if it cannot be retrieved from QEMU - fixed unnecessary intialization of some variables that were introduced in v2 of these patches - virQEMUCapsLoadHostCPUModelInfo now first allocates data into a qemuMonitorCPUModelInfoPtr before assigning it to appropriate qemuCaps field - if we do not have QEMU_CAPS_QUERY_CPU_MODEL_EXPANSION available, skip trying to read the hostCPU portion of the qemu cache file - all hostCPU element parsing is handled in its entirety within function virQEMUCapsLoadHostCPUModelInfo - Fix up capabilities test data to reflect changes from this commit qemu: command: Support new cpu feature argument syntax - Add error message for case where s390 guest attempts to use cpu features on older qemu. - Combined the tests into this commit - Now tests s390 cpu features both with and without query-cpu-model-expansion [v2] * Added s390x cpu and capabilities tests * Added cpu feature syntax tests * Dropped patch: Warn when migrating host-passthrough * Added patch: Document migrating host-passthrough is dangerous s390: Cpu driver support for update and compare - Compare: Added comment explaining why s390 bypasses the cpuCompare operation - Update: Added error message explaining minimum match mode is not supported - Update: Ensure user is not using unsupported optional feature policy - Update: Use virCPUDefUpdateFeature to update/create user requested features - Other minor fixes s390-cpu: Remove nodeData and decode - Completely remove nodeData and decode functions qemu: qmp query-cpu-model-expansion command - Cleaned up debug print - Restructured qemuMonitorJSONGetCPUModelExpansion - Added more JSON parsing error handling - CPU model features now parsed via an iterator - qemuMonitorJSONGetCPUModelExpansion: Fixed double free of model ptr - Restructure qemuMonitorCPUModelInfoFree - Other minor fixes qemu-caps: Get host model directly from Qemu when available - virQEMUCapsProbeQMPHostCPU: indentation fix - Fixed rebase error involving a missing 'goto cleanup;'. - Fix indentation in virQEMUCapsProbeQMPHostCPU - virQEMUCapsInitHostCPUModel now routes to virQEMUCapsCopyModelFromQEMU or virQEMUCapsCopyModelFromHost, depending on architecture. - Restructure hostCpu data in qemu caps cache xml - Other minor fixes Collin L. Walling (5): test-data: Qemu caps replies and xml for s390x qemu 2.7 and 2.8 tests: domain capabilities: qemu 2.7 and 2.8 on s390x tests: qemu capabilites: qemu 2.7 and 2.8 on s390x qemu: qmp query-cpu-model-expansion command qemu: command: Support new cpu feature argument syntax Jason J. Herne (4): s390: Cpu driver support for update and compare s390-cpu: Remove nodeData and decode qemu-caps: Get host model directly from Qemu when available tests: qemuxml2argv s390x cpu model po/POTFILES.in | 1 + src/cpu/cpu_s390.c | 103 +- src/qemu/qemu_capabilities.c | 190 +- src/qemu/qemu_capabilities.h | 3 + src/qemu/qemu_command.c | 18 +- src/qemu/qemu_monitor.c | 62 + src/qemu/qemu_monitor.h | 22 + src/qemu/qemu_monitor_json.c | 117 + src/qemu/qemu_monitor_json.h | 6 + tests/domaincapsschemadata/qemu_2.7.0.s390x.xml | 78 + tests/domaincapsschemadata/qemu_2.8.0.s390x.xml | 159 + tests/domaincapstest.c | 18 + .../qemucapabilitiesdata/caps_2.7.0.s390x.replies | 11999 +++++++++++++++++ tests/qemucapabilitiesdata/caps_2.7.0.s390x.xml | 140 + .../qemucapabilitiesdata/caps_2.8.0.s390x.replies | 13380 +++++++++++++++++++ tests/qemucapabilitiesdata/caps_2.8.0.s390x.xml | 286 + tests/qemucapabilitiestest.c | 2 + .../qemuxml2argv-cpu-s390-features.args | 19 + .../qemuxml2argv-cpu-s390-features.xml | 23 + .../qemuxml2argv-cpu-s390-zEC12.args | 19 + .../qemuxml2argv-cpu-s390-zEC12.xml | 21 + tests/qemuxml2argvtest.c | 14 + 22 files changed, 26638 insertions(+), 42 deletions(-) create mode 100644 tests/domaincapsschemadata/qemu_2.7.0.s390x.xml create mode 100644 tests/domaincapsschemadata/qemu_2.8.0.s390x.xml create mode 100644 tests/qemucapabilitiesdata/caps_2.7.0.s390x.replies create mode 100644 tests/qemucapabilitiesdata/caps_2.7.0.s390x.xml create mode 100644 tests/qemucapabilitiesdata/caps_2.8.0.s390x.replies create mode 100644 tests/qemucapabilitiesdata/caps_2.8.0.s390x.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-s390-features.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-s390-features.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-s390-zEC12.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-s390-zEC12.xml -- 2.7.4

2 20

Re: [libvirt] [RFC] phi support in libvirt
by He Chen 06 Jan '17

06 Jan '17

> On Mon, Dec 05, 2016 at 04:12:22PM +0000, Feng, Shaohe wrote: > > Hi all: > > > > As we are know Intel® Xeon phi targets high-performance computing and > > other parallel workloads. > > Now qemu has supported phi virtualization，it is time for libvirt to > > support phi. > > Can you provide pointer to the relevant QEMU changes. > Xeon Phi Knights Landing (KNL) contains 2 primary hardware features, one is up to 288 CPUs which needs patches to support and we are pushing it, the other is Multi-Channel DRAM (MCDRAM) which does not need any changes currently. Let me introduce more about MCDRAM, MCDRAM is on-package high-bandwidth memory (~500GB/s). On KNL platform, hardware expose MCDRAM as a seperate, CPUless and remote NUMA node to OS so that MCDRAM will not be allocated by default (since MCDRAM node has no CPU, every CPU regards MCDRAM node as remote node). In this way, MCDRAM can be reserved for certain specific applications. > > Different from the traditional X86 server, There is a special numa > > node with Multi-Channel DRAM (MCDRAM) on Phi, but without any CPU . > > > > Now libvirt requires nonempty cpus argument for NUMA node, such as. > > <numa> > > <cell id='0' cpus='0-239' memory='80' unit='GiB'/> > > <cell id='1' cpus='240-243' memory='16' unit='GiB'/> </numa> > > > > In order to support phi virtualization, libvirt needs to allow a numa > > cell definition without 'cpu' attribution. > > > > Such as: > > <numa> > > <cell id='0' cpus='0-239' memory='80' unit='GiB'/> > > <cell id='1' memory='16' unit='GiB'/> </numa> > > > > When a cell without 'cpu', qemu will allocate memory by default MCDRAM instead of DDR. > > There's separate concepts at play which your description here is mixing up. > > First is the question of whether the guest NUMA node can be created with only RAM or CPUs, or a mix of both. > > Second is the question of what kind of host RAM (MCDRAM vs DDR) is used as the backing store for the guest > Guest NUMA node shoulde be created with memory only (keep the same as host's) and the more important things is the memory should bind to (come from) host MCDRAM node. > These are separate configuration items which don't need to be conflated in libvirt. ie we should be able to create a guest with a node containing only memory, and back that by DDR on the host. Conversely we should be able to create a guest with a node containing memory + cpus and back that by MCDRAM on the host (even if that means the vCPUs will end up on a different host node from its RAM) > > On the first point, there still appears to be some brokness in either QEMU or Linux wrt configuration of virtual NUMA where either cpus or memory are absent from nodes. > > eg if I launch QEMU with > > -numa node,nodeid=0,cpus=0-3,mem=512 > -numa node,nodeid=1,mem=512 > -numa node,nodeid=2,cpus=4-7 > -numa node,nodeid=3,mem=512 > -numa node,nodeid=4,mem=512 > -numa node,nodeid=5,cpus=8-11 > -numa node,nodeid=6,mem=1024 > -numa node,nodeid=7,cpus=12-15,mem=1024 > > then the guest reports > > # numactl --hardware > available: 6 nodes (0,3-7) > node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 > node 0 size: 487 MB > node 0 free: 230 MB > node 3 cpus: 12 13 14 15 > node 3 size: 1006 MB > node 3 free: 764 MB > node 4 cpus: > node 4 size: 503 MB > node 4 free: 498 MB > node 5 cpus: > node 5 size: 503 MB > node 5 free: 499 MB > node 6 cpus: > node 6 size: 503 MB > node 6 free: 498 MB > node 7 cpus: > node 7 size: 943 MB > node 7 free: 939 MB > > so its pushed all the CPUs from nodes without RAM into the first node, and moved CPUs from the 7th node into the 3rd node. > I am not sure why this happens, but basically, I lauch QEMU like: -object memory-backend-ram,size=20G,prealloc=yes,host-nodes=0,policy=bind,id=node0 \ -numa node,nodeid=0,cpus=0-14,cpus=60-74,cpus=120-134,cpus=180-194,memdev=node0 \ -object memory-backend-ram,size=20G,prealloc=yes,host-nodes=1,policy=bind,id=node1 \ -numa node,nodeid=1,cpus=15-29,cpus=75-89,cpus=135-149,cpus=195-209,memdev=node1 \ -object memory-backend-ram,size=20G,prealloc=yes,host-nodes=2,policy=bind,id=node2 \ -numa node,nodeid=2,cpus=30-44,cpus=90-104,cpus=150-164,cpus=210-224,memdev=node2 \ -object memory-backend-ram,size=20G,prealloc=yes,host-nodes=3,policy=bind,id=node3 \ -numa node,nodeid=3,cpus=45-59,cpus=105-119,cpus=165-179,cpus=225-239,memdev=node3 \ -object memory-backend-ram,size=3G,prealloc=yes,host-nodes=4,policy=bind,id=node4 \ -numa node,nodeid=4,memdev=node4 \ -object memory-backend-ram,size=3G,prealloc=yes,host-nodes=5,policy=bind,id=node5 \ -numa node,nodeid=5,memdev=node5 \ -object memory-backend-ram,size=3G,prealloc=yes,host-nodes=6,policy=bind,id=node6 \ -numa node,nodeid=6,memdev=node6 \ -object memory-backend-ram,size=3G,prealloc=yes,host-nodes=7,policy=bind,id=node7 \ -numa node,nodeid=7,memdev=node7 \ (Please ignore the complex cpus parameters...) As you can see, the pair of `-object memory-backend-ram` and `-numa` is used to specify where the memory of the guest NUMA node is allocated from. It works well for me :-) > So before considering MCDRAM / Phi, we need to fix this more basic NUMA topology setup. > > > Now here I'd like to discuss these questions: > > 1. This feature is only for Phi at present, but we > > will check Phi platform for CPU-less NUMA node. > > The NUMA node without CPU indicates MCDRAM node. > > We should not assume such semantics - it is a concept that is specific to particular Intel x86_64 CPUs. We need to consider that other architectures may have nodes without CPUs that are backed by normal DDR. > IOW, we shoud be explicit about presence of MCDRAM in the host. > Agreed, but for KNL, that is how we detect MCDRAM on host: 1. detect CPU family is Xeon Phi X200 (means KNL) 2. enumerate all NUMA nodes and regard the nodes that contain memory only as MCDRAM nodes. ... Thanks, -He

4 6

[libvirt] [PATCH 0/3] qemu: fix pit timer tick policy
by Maxim Nestratov 05 Jan '17

05 Jan '17

Maxim Nestratov (3): qemu: fix pit timer tick policy=delay qemu: allow to specify pit timer tick policy=discard qemu: tests: add "no-kvm-pit-device" testcase src/qemu/qemu_command.c | 10 ++++++-- .../qemuxml2argv-kvm-pit-delay.args | 2 +- .../qemuxml2argv-kvm-pit-device.xml | 2 +- .../qemuxml2argv-no-kvm-pit-device.args | 23 +++++++++++++++++ .../qemuxml2argv-no-kvm-pit-device.xml | 29 ++++++++++++++++++++++ tests/qemuxml2argvtest.c | 5 ++-- 6 files changed, 64 insertions(+), 7 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-no-kvm-pit-device.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-no-kvm-pit-device.xml -- 2.4.11

2 9

[libvirt] [libivrt] storage: Two iSCSI node records may cause refreshing iscsi pool failed
by Shichangkuo 05 Jan '17

05 Jan '17

Hi, John When starting an iscsi storage pool, libvirt will execute “iscsiadm --mode node --portal 192.168.0.42 --targetname iqn.2003-10.com.xxxx --op new”, which is called by virISCSINodeNew. This will add an iSCSI node record. The record file is /etc/iscsi/nodes/iqn.2003-10.com.xxxx/192.168.0.42,3260. When we already executed "iscsiadm --mode discovery --type sendtargets --portal 192.168.0.42 --op new", another iSCSI node record will be produced in /etc/iscsi/nodes/iqn.2003-10.com.xxxx/192.168.0.42,3260,1/default. Then two iscsi sessions, as [2] and [3], will be logged in when we start the pool. Device of session [2] is /dev/sde, and device of session [3] is /dev/sdf. But there is only one path in /dev/disk/by-path, let's assume it is /dev/sdf. Refreshing storage pool will choose first session, like [2], and libvirt will find sde NOT sdf in /dev/disk/by-path. We will not find sde, then no volumes is found in the pool. I think the root reason is we have two iSCSI node records. Can we use "iscsiadm --mode discovery --type sendtargets --portal 192.168.0.42 --op new" in virISCSINodeNew? diff --git a/src/util/viriscsi.c b/src/util/viriscsi.c index 504ffbd..a8a8644 100644 --- a/src/util/viriscsi.c +++ b/src/util/viriscsi.c @@ -469,9 +469,9 @@ virISCSINodeNew(const char *portal, int ret = -1; cmd = virCommandNewArgList(ISCSIADM, - "--mode", "node", + "--mode", "discovery", + "--type", "sendtargets", "--portal", portal, - "--targetname", target, "--op", "new", NULL); Thanks, Changkuo. ------------------------------------------------------------------------------------------------------------------------------------- 本邮件及其附件含有杭州华三通信技术有限公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ This e-mail and its attachments contain confidential information from H3C, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!

2 1

[libvirt] [PATCH] internal: Simplify STREQ_NULLABLE
by Michal Privoznik 05 Jan '17

05 Jan '17

Our STREQ_NULLABLE and STRNEQ_NULLABLE macros are too complicated. This was a result of some broken version of gcc. However, that is long gone and therefore we can simplify the macros. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- src/internal.h | 4 ++-- tests/virstringtest.c | 61 +++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 63 insertions(+), 2 deletions(-) diff --git a/src/internal.h b/src/internal.h index d8cc5adc3..334659d32 100644 --- a/src/internal.h +++ b/src/internal.h @@ -92,9 +92,9 @@ # define STRSKIP(a, b) (STRPREFIX(a, b) ? (a) + strlen(b) : NULL) # define STREQ_NULLABLE(a, b) \ - ((a) ? (b) && STREQ((a) ? (a) : "", (b) ? (b) : "") : !(b)) + ((a) ? (b) && STREQ((a), (b)) : !(b)) # define STRNEQ_NULLABLE(a, b) \ - ((a) ? !(b) || STRNEQ((a) ? (a) : "", (b) ? (b) : "") : !!(b)) + ((a) ? !(b) || STRNEQ((a), (b)) : !!(b)) # define NUL_TERMINATE(buf) do { (buf)[sizeof(buf)-1] = '\0'; } while (0) # define ARRAY_CARDINALITY(Array) (sizeof(Array) / sizeof(*(Array))) diff --git a/tests/virstringtest.c b/tests/virstringtest.c index 1d660b798..db1731f96 100644 --- a/tests/virstringtest.c +++ b/tests/virstringtest.c @@ -34,6 +34,53 @@ VIR_LOG_INIT("tests.stringtest"); +struct testStreqData { + const char *a; + const char *b; +}; + +static int testStreq(const void *args) +{ + const struct testStreqData *data = args; + int ret = -1; + bool equal = true; + bool streq_rv, strneq_rv; + size_t i; + + if ((size_t) data->a ^ (size_t) data->b) + equal = false; + if (data->a && data->b) { + for (i = 0; data->a[i] != '\0'; i++) { + if (data->b[i] == '\0' || + data->a[i] != data->b[i]) { + equal = false; + break; + } + } + } + + streq_rv = STREQ_NULLABLE(data->a, data->b); + strneq_rv = STRNEQ_NULLABLE(data->a, data->b); + + if (streq_rv != equal) { + virFilePrintf(stderr, + "STREQ not working correctly. Expected %d got %d", + (int) equal, (int) streq_rv); + goto cleanup; + } + + if (strneq_rv == equal) { + virFilePrintf(stderr, + "STRNEQ not working correctly. Expected %d got %d", + (int) equal, (int) strneq_rv); + goto cleanup; + } + + ret = 0; + cleanup: + return ret; +} + struct testSplitData { const char *string; const char *delim; @@ -651,6 +698,20 @@ mymain(void) { int ret = 0; +#define TEST_STREQ(aa, bb) \ + do { \ + struct testStreqData streqData = {.a = aa, .b = bb}; \ + if (virTestRun("Streq", testStreq, &streqData) < 0) \ + ret = -1; \ + } while (0) + + TEST_STREQ("hello", "world"); + TEST_STREQ(NULL, NULL); + TEST_STREQ(NULL, ""); + TEST_STREQ("", NULL); + TEST_STREQ("", ""); + TEST_STREQ("hello", "hello"); + #define TEST_SPLIT(str, del, max, toks) \ do { \ struct testSplitData splitData = { \ -- 2.11.0

2 2

[libvirt] Loosing lxc guests when restarting libvirt
by Christian Ehrhardt 05 Jan '17

05 Jan '17

Hi, I found an issue in libvirt related to libvirt-lxc, but fail to find the root cause. The TL;DR is: libvirt-lxc guests get killed on libvirt restart due to "internal error: No valid cgroup for machine" It was able to reproduce libvirt 1.3.1, 2.4 and 2.5 as packages in Ubuntu and Debian. I wanted to ask for two things: - wider coverage where this does reproduce - your expertise on the case itself. Steps to reproduce: 1. Spawn new KVM Guest of your choice 2. install test dependencies $ apt-get install libvirt-daemon-system libvirt-clients libxml2-utils # or package managers / package names of your chosen os 3. run the following sequence as root export LIBVIRT_DEFAULT_URI=lxc:/// cat << EOF > /tmp/smoke-lxc.xml <domain type='lxc'> <name>sl</name> <memory unit='KiB'>256000</memory> <currentMemory unit='KiB'>256000</currentMemory> <vcpu placement='static'>1</vcpu> <os> <type>exe</type> <init>/bin/bash</init> </os> <features> <privnet/> </features> <clock offset='utc'/> <devices> <emulator>/usr/lib/libvirt/libvirt_lxc</emulator> <filesystem type='mount' accessmode='passthrough'> <source dir='/'/> <target dir='/'/> </filesystem> <console type='pty'> <target type='lxc' port='0'/> </console> </devices> </domain> EOF virsh define /tmp/smoke-lxc.xml virsh start sl virsh list --all # is running now /etc/init.d/libvirtd restart virsh list --all # is no more running, but it should Way more background and detail can be found at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=848317 -- Christian Ehrhardt Software Engineer, Ubuntu Server Canonical Ltd

4 5

[libvirt] [PATCH] Changes to support Veritas HyperScale (VxHS) block device protocol with qemu-kvm
by Ashish Mittal 05 Jan '17

05 Jan '17

Sample XML for a vxhs vdisk is as follows: <disk type='network' device='disk'> <driver name='qemu' type='raw' cache='none'/> <source protocol='vxhs' name='eb90327c-8302-4725-9e1b-4e85ed4dc251'> <host name='192.168.0.1' port='9999'/> </source> <backingStore/> <target dev='vda' bus='virtio'/> <serial>eb90327c-8302-4725-9e1b-4e85ed4dc251</serial> <alias name='virtio-disk0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </disk> Signed-off-by: Ashish Mittal <Ashish.Mittal(a)veritas.com> --- docs/formatdomain.html.in | 12 ++++++-- docs/schemas/domaincommon.rng | 1 + src/qemu/qemu_command.c | 4 +++ src/qemu/qemu_driver.c | 3 ++ src/qemu/qemu_parse_command.c | 25 ++++++++++++++++ src/util/virstoragefile.c | 4 ++- src/util/virstoragefile.h | 1 + .../qemuxml2argv-disk-drive-network-vxhs.args | 23 +++++++++++++++ .../qemuxml2argv-disk-drive-network-vxhs.xml | 34 ++++++++++++++++++++++ tests/qemuxml2argvtest.c | 1 + 10 files changed, 104 insertions(+), 4 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-vxhs.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-vxhs.xml diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in index 11b3330..ade35a3 100644 --- a/docs/formatdomain.html.in +++ b/docs/formatdomain.html.in @@ -2276,9 +2276,9 @@ <dd> The <code>protocol</code> attribute specifies the protocol to access to the requested image. Possible values are "nbd", - "iscsi", "rbd", "sheepdog" or "gluster". If the - <code>protocol</code> attribute is "rbd", "sheepdog" or - "gluster", an additional attribute <code>name</code> is + "iscsi", "rbd", "sheepdog", "gluster" or "vxhs". If the + <code>protocol</code> attribute is "rbd", "sheepdog", "gluster" + or "vxhs", an additional attribute <code>name</code> is mandatory to specify which volume/image will be used. For "nbd", the <code>name</code> attribute is optional. For "iscsi" (<span class="since">since 1.0.4</span>), the <code>name</code> @@ -2388,6 +2388,12 @@ <td> one or more (<span class="since">Since 2.1.0</span>), just one prior to that </td> <td> 24007 </td> </tr> + <tr> + <td> vxhs </td> + <td> a server running Veritas HyperScale daemon </td> + <td> only one </td> + <td> 9999 </td> + </tr> </table> <p> gluster supports "tcp", "rdma", "unix" as valid values for the diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng index 19d45fd..e569e0a 100644 --- a/docs/schemas/domaincommon.rng +++ b/docs/schemas/domaincommon.rng @@ -1464,6 +1464,7 @@ <value>ftp</value> <value>ftps</value> <value>tftp</value> + <value>vxhs</value> </choice> </attribute> <optional> diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index 4a5fce3..c7b95aa 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -491,6 +491,9 @@ qemuNetworkDriveGetPort(int protocol, /* no default port specified */ return 0; + case VIR_STORAGE_NET_PROTOCOL_VXHS: + return 9999; + case VIR_STORAGE_NET_PROTOCOL_RBD: case VIR_STORAGE_NET_PROTOCOL_LAST: case VIR_STORAGE_NET_PROTOCOL_NONE: @@ -1034,6 +1037,7 @@ qemuBuildNetworkDriveStr(virStorageSourcePtr src, case VIR_STORAGE_NET_PROTOCOL_TFTP: case VIR_STORAGE_NET_PROTOCOL_ISCSI: case VIR_STORAGE_NET_PROTOCOL_GLUSTER: + case VIR_STORAGE_NET_PROTOCOL_VXHS: ret = qemuBuildNetworkDriveURI(src, secinfo); break; diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index a82e58b..4910004 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -13724,6 +13724,7 @@ qemuDomainSnapshotPrepareDiskExternalBackingInactive(virDomainDiskDefPtr disk) case VIR_STORAGE_NET_PROTOCOL_FTPS: case VIR_STORAGE_NET_PROTOCOL_TFTP: case VIR_STORAGE_NET_PROTOCOL_SSH: + case VIR_STORAGE_NET_PROTOCOL_VXHS: case VIR_STORAGE_NET_PROTOCOL_LAST: virReportError(VIR_ERR_INTERNAL_ERROR, _("external inactive snapshots are not supported on " @@ -13787,6 +13788,7 @@ qemuDomainSnapshotPrepareDiskExternalOverlayActive(virDomainSnapshotDiskDefPtr d case VIR_STORAGE_NET_PROTOCOL_FTPS: case VIR_STORAGE_NET_PROTOCOL_TFTP: case VIR_STORAGE_NET_PROTOCOL_SSH: + case VIR_STORAGE_NET_PROTOCOL_VXHS: case VIR_STORAGE_NET_PROTOCOL_LAST: virReportError(VIR_ERR_INTERNAL_ERROR, _("external active snapshots are not supported on " @@ -13932,6 +13934,7 @@ qemuDomainSnapshotPrepareDiskInternal(virConnectPtr conn, case VIR_STORAGE_NET_PROTOCOL_FTPS: case VIR_STORAGE_NET_PROTOCOL_TFTP: case VIR_STORAGE_NET_PROTOCOL_SSH: + case VIR_STORAGE_NET_PROTOCOL_VXHS: case VIR_STORAGE_NET_PROTOCOL_LAST: virReportError(VIR_ERR_INTERNAL_ERROR, _("internal inactive snapshots are not supported on " diff --git a/src/qemu/qemu_parse_command.c b/src/qemu/qemu_parse_command.c index c3b27aa..f2edc28 100644 --- a/src/qemu/qemu_parse_command.c +++ b/src/qemu/qemu_parse_command.c @@ -263,6 +263,16 @@ qemuParseNBDString(virDomainDiskDefPtr disk) return -1; } +static int +qemuParseVxHSString(virDomainDiskDefPtr def) +{ + virURIPtr uri = NULL; + + if (!(uri = virURIParse(def->src->path))) + return -1; + + return qemuParseDriveURIString(def, uri, "vxhs"); +} /* * This method takes a string representing a QEMU command line ARGV set @@ -737,6 +747,12 @@ qemuParseCommandLineDisk(virDomainXMLOptionPtr xmlopt, if (VIR_STRDUP(def->src->path, vdi) < 0) goto error; } + } else if (STRPREFIX(def->src->path, "vxhs:")) { + def->src->type = VIR_STORAGE_TYPE_NETWORK; + def->src->protocol = VIR_STORAGE_NET_PROTOCOL_VXHS; + + if (qemuParseVxHSString(def) < 0) + goto error; } else { def->src->type = VIR_STORAGE_TYPE_FILE; } @@ -1933,6 +1949,10 @@ qemuParseCommandLine(virCapsPtr caps, disk->src->type = VIR_STORAGE_TYPE_NETWORK; disk->src->protocol = VIR_STORAGE_NET_PROTOCOL_SHEEPDOG; val += strlen("sheepdog:"); + } else if (STRPREFIX(val, "vxhs:")) { + disk->src->type = VIR_STORAGE_TYPE_NETWORK; + disk->src->protocol = VIR_STORAGE_NET_PROTOCOL_VXHS; + val += strlen("vxhs:"); } else { disk->src->type = VIR_STORAGE_TYPE_FILE; } @@ -2009,6 +2029,11 @@ qemuParseCommandLine(virCapsPtr caps, goto error; break; + case VIR_STORAGE_NET_PROTOCOL_VXHS: + if (qemuParseVxHSString(disk) < 0) + goto error; + + break; case VIR_STORAGE_NET_PROTOCOL_HTTP: case VIR_STORAGE_NET_PROTOCOL_HTTPS: case VIR_STORAGE_NET_PROTOCOL_FTP: diff --git a/src/util/virstoragefile.c b/src/util/virstoragefile.c index 272db67..a730a01 100644 --- a/src/util/virstoragefile.c +++ b/src/util/virstoragefile.c @@ -86,7 +86,8 @@ VIR_ENUM_IMPL(virStorageNetProtocol, VIR_STORAGE_NET_PROTOCOL_LAST, "ftp", "ftps", "tftp", - "ssh") + "ssh", + "vxhs") VIR_ENUM_IMPL(virStorageNetHostTransport, VIR_STORAGE_NET_HOST_TRANS_LAST, "tcp", @@ -2634,6 +2635,7 @@ virStorageSourceParseBackingColon(virStorageSourcePtr src, case VIR_STORAGE_NET_PROTOCOL_ISCSI: case VIR_STORAGE_NET_PROTOCOL_GLUSTER: case VIR_STORAGE_NET_PROTOCOL_SSH: + case VIR_STORAGE_NET_PROTOCOL_VXHS: virReportError(VIR_ERR_INTERNAL_ERROR, _("malformed backing store path for protocol %s"), protocol); diff --git a/src/util/virstoragefile.h b/src/util/virstoragefile.h index 3d09468..88dff36 100644 --- a/src/util/virstoragefile.h +++ b/src/util/virstoragefile.h @@ -132,6 +132,7 @@ typedef enum { VIR_STORAGE_NET_PROTOCOL_FTPS, VIR_STORAGE_NET_PROTOCOL_TFTP, VIR_STORAGE_NET_PROTOCOL_SSH, + VIR_STORAGE_NET_PROTOCOL_VXHS, VIR_STORAGE_NET_PROTOCOL_LAST } virStorageNetProtocol; diff --git a/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-vxhs.args b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-vxhs.args new file mode 100644 index 0000000..3d37b00 --- /dev/null +++ b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-vxhs.args @@ -0,0 +1,23 @@ +LC_ALL=C \ +PATH=/bin \ +HOME=/home/test \ +USER=test \ +LOGNAME=test \ +QEMU_AUDIO_DRV=none \ +/usr/libexec/qemu-kvm \ +-name QEMUGuest1 \ +-S \ +-M pc \ +-cpu qemu32 \ +-m 214 \ +-smp 1,sockets=1,cores=1,threads=1 \ +-uuid c7a5fdbd-edaf-9455-926a-d65c16db1809 \ +-nographic \ +-nodefaults \ +-monitor unix:/tmp/lib/domain--1-QEMUGuest1/monitor.sock,server,nowait \ +-no-acpi \ +-boot c \ +-usb \ +-drive file=vxhs://192.168.0.1:9999/eb90327c-8302-4725-9e1b-4e85ed4dc251,\ +format=raw,if=none,id=drive-virtio-disk0,cache=none \ +-device virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0 diff --git a/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-vxhs.xml b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-vxhs.xml new file mode 100644 index 0000000..45c807f --- /dev/null +++ b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-vxhs.xml @@ -0,0 +1,34 @@ +<domain type='qemu'> + <name>QEMUGuest1</name> + <uuid>c7a5fdbd-edaf-9455-926a-d65c16db1809</uuid> + <memory unit='KiB'>219136</memory> + <currentMemory unit='KiB'>219136</currentMemory> + <vcpu placement='static'>1</vcpu> + <os> + <type arch='i686' machine='pc'>hvm</type> + <boot dev='hd'/> + </os> + <clock offset='utc'/> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>destroy</on_crash> + <devices> + <emulator>/usr/libexec/qemu-kvm</emulator> + <disk type='network' device='disk'> + <driver name='qemu' type='raw' cache='none'/> + <source protocol='vxhs' name='eb90327c-8302-4725-9e1b-4e85ed4dc251'> + <host name='192.168.0.1' port='9999'/> + </source> + <backingStore/> + <target dev='vda' bus='virtio'/> + <serial>eb90327c-8302-4725-9e1b-4e85ed4dc251</serial> + <alias name='virtio-disk0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> + </disk> + <controller type='usb' index='0'/> + <controller type='pci' index='0' model='pci-root'/> + <input type='mouse' bus='ps2'/> + <input type='keyboard' bus='ps2'/> + <memballoon model='none'/> + </devices> +</domain> diff --git a/tests/qemuxml2argvtest.c b/tests/qemuxml2argvtest.c index 1ee8402..d94e3f2 100644 --- a/tests/qemuxml2argvtest.c +++ b/tests/qemuxml2argvtest.c @@ -869,6 +869,7 @@ mymain(void) # endif DO_TEST("disk-drive-network-rbd-ipv6", NONE); DO_TEST_FAILURE("disk-drive-network-rbd-no-colon", NONE); + DO_TEST("disk-drive-network-vxhs", NONE); DO_TEST("disk-drive-no-boot", QEMU_CAPS_BOOTINDEX); DO_TEST_PARSE_ERROR("disk-device-lun-type-invalid", -- 2.5.5

4 8

[libvirt] [PATCH] NEWS: Update after qemu namespace fix
by Michal Privoznik 04 Jan '17

04 Jan '17

Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- Pushed under my-christmas-gift-to-libvirt rule. docs/news.html.in | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/docs/news.html.in b/docs/news.html.in index 36c7d3d66..e544cfa38 100644 --- a/docs/news.html.in +++ b/docs/news.html.in @@ -67,6 +67,10 @@ The chardev detection code has been improved and can now handle this configuration properly </li> + <li>qemu: Enable mount namespace<br/> + To avoid funny races with udev relabelling devices under our hands and + to enhance security, libvirt now spawns each qemu process with its own + <code>/dev</code>.</li> </ul> </li> </ul> -- 2.11.0

4 3

[libvirt] Issue with libvirtd
by Faysal Ali 04 Jan '17

04 Jan '17

Hi I have a CentOS 7.3 server where I am running KVM with few virtual machines. I noticed this being repeated regularly in /var/log/messages *libvirtd[1956]: End of file while reading data: Input/output error* Anyone have seen that happening ?? Any idea where should I dig more ?? Br. Umar

2 1