November 2017 - Devel - libvirt List Archives

[libvirt] [PATCH v3 0/5] Predictable file names for memory-backend-file
by Michal Privoznik 08 Nov '17

08 Nov '17

v3 of: https://www.redhat.com/archives/libvir-list/2017-October/msg01091.html diff to v2: - Pushed 1/4 and 2/4 from the original series - Split 3/4 into smaller patches Michal Privoznik (5): qemu: Set alias for memory cell in qemuBuildMemoryCellBackendStr qemu: Rename qemuProcessBuildDestroyHugepagesPath qemu: Destroy whole memory tree qemu: Use predictable file names for memory-backend-file news: Document predictable file names for memory-backend-file docs/news.xml | 11 ++ src/qemu/qemu_command.c | 9 +- src/qemu/qemu_conf.c | 55 ++++++++- src/qemu/qemu_conf.h | 9 +- src/qemu/qemu_driver.c | 17 +++ src/qemu/qemu_hotplug.c | 2 +- src/qemu/qemu_process.c | 137 +++++++++++++++------ src/qemu/qemu_process.h | 8 +- .../qemuxml2argv-cpu-numa-memshared.args | 6 +- .../qemuxml2argv-fd-memory-numa-topology.args | 3 +- .../qemuxml2argv-fd-memory-numa-topology2.args | 6 +- .../qemuxml2argv-fd-memory-numa-topology3.args | 9 +- .../qemuxml2argv-hugepages-memaccess2.args | 9 +- 13 files changed, 218 insertions(+), 63 deletions(-) -- 2.13.6

4 14

[libvirt] Libvirt config converter can't handle file not ending with new line
by Wei Liu 07 Nov '17

07 Nov '17

Hi Jim I discover a problem when using xen_xl converter. When the file in question doesn't end with a new line, I get the following error: error: configuration file syntax error: memory conf:53: expecting a value After digging a bit (but haven't read libvirt code), it appears that the file didn't end with a new line. I have worked around this, but I think this is an issue that should be fixed. Thanks, Wei.

3 4

[libvirt] [PATCH 0/3] cputest: Add more CPU data files
by Jiri Denemark 07 Nov '17

07 Nov '17

Jiri Denemark (3): cputest: Do not drop v[0-9] from CPU names cputest: Add data for Intel(R) Xeon(R) CPU E5-2650 v4 cputest: Add data for Intel(R) Core(TM) i7-7700 CPU tests/cputest.c | 10 +- tests/cputestdata/cpu-parse.sh | 2 +- .../x86_64-cpuid-Core-i7-7700-disabled.xml | 6 + .../x86_64-cpuid-Core-i7-7700-enabled.xml | 9 + ...est.xml => x86_64-cpuid-Core-i7-7700-guest.xml} | 0 ...host.xml => x86_64-cpuid-Core-i7-7700-host.xml} | 0 .../cputestdata/x86_64-cpuid-Core-i7-7700-json.xml | 9 + tests/cputestdata/x86_64-cpuid-Core-i7-7700.json | 499 ++++++++++++++++++++ tests/cputestdata/x86_64-cpuid-Core-i7-7700.xml | 47 ++ ...l => x86_64-cpuid-Xeon-E3-1245-v5-disabled.xml} | 0 ...ml => x86_64-cpuid-Xeon-E3-1245-v5-enabled.xml} | 0 .../x86_64-cpuid-Xeon-E3-1245-v5-guest.xml | 25 + .../x86_64-cpuid-Xeon-E3-1245-v5-host.xml | 26 ++ ...n.xml => x86_64-cpuid-Xeon-E3-1245-v5-json.xml} | 0 ...1245.json => x86_64-cpuid-Xeon-E3-1245-v5.json} | 0 ...3-1245.xml => x86_64-cpuid-Xeon-E3-1245-v5.xml} | 0 ...l => x86_64-cpuid-Xeon-E5-2630-v3-disabled.xml} | 0 ...ml => x86_64-cpuid-Xeon-E5-2630-v3-enabled.xml} | 0 ....xml => x86_64-cpuid-Xeon-E5-2630-v3-guest.xml} | 0 ...t.xml => x86_64-cpuid-Xeon-E5-2630-v3-host.xml} | 0 ...n.xml => x86_64-cpuid-Xeon-E5-2630-v3-json.xml} | 0 ...2630.json => x86_64-cpuid-Xeon-E5-2630-v3.json} | 0 ...5-2630.xml => x86_64-cpuid-Xeon-E5-2630-v3.xml} | 0 ...l => x86_64-cpuid-Xeon-E5-2650-v3-disabled.xml} | 0 ...ml => x86_64-cpuid-Xeon-E5-2650-v3-enabled.xml} | 0 ....xml => x86_64-cpuid-Xeon-E5-2650-v3-guest.xml} | 0 ...t.xml => x86_64-cpuid-Xeon-E5-2650-v3-host.xml} | 0 ...n.xml => x86_64-cpuid-Xeon-E5-2650-v3-json.xml} | 0 ...2650.json => x86_64-cpuid-Xeon-E5-2650-v3.json} | 0 ...5-2650.xml => x86_64-cpuid-Xeon-E5-2650-v3.xml} | 0 ...l => x86_64-cpuid-Xeon-E5-2650-v4-disabled.xml} | 0 .../x86_64-cpuid-Xeon-E5-2650-v4-enabled.xml | 9 + .../x86_64-cpuid-Xeon-E5-2650-v4-guest.xml | 30 ++ .../x86_64-cpuid-Xeon-E5-2650-v4-host.xml | 34 ++ .../x86_64-cpuid-Xeon-E5-2650-v4-json.xml | 11 + .../cputestdata/x86_64-cpuid-Xeon-E5-2650-v4.json | 505 +++++++++++++++++++++ tests/cputestdata/x86_64-cpuid-Xeon-E5-2650-v4.xml | 43 ++ .../x86_64-cpuid-Xeon-E7-8890-v3-disabled.xml | 6 + ...ml => x86_64-cpuid-Xeon-E7-8890-v3-enabled.xml} | 0 ....xml => x86_64-cpuid-Xeon-E7-8890-v3-guest.xml} | 0 ...t.xml => x86_64-cpuid-Xeon-E7-8890-v3-host.xml} | 0 ...n.xml => x86_64-cpuid-Xeon-E7-8890-v3-json.xml} | 0 ...8890.json => x86_64-cpuid-Xeon-E7-8890-v3.json} | 0 ...7-8890.xml => x86_64-cpuid-Xeon-E7-8890-v3.xml} | 0 44 files changed, 1266 insertions(+), 5 deletions(-) create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i7-7700-disabled.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i7-7700-enabled.xml rename tests/cputestdata/{x86_64-cpuid-Xeon-E3-1245-guest.xml => x86_64-cpuid-Core-i7-7700-guest.xml} (100%) rename tests/cputestdata/{x86_64-cpuid-Xeon-E3-1245-host.xml => x86_64-cpuid-Core-i7-7700-host.xml} (100%) create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i7-7700-json.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i7-7700.json create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i7-7700.xml rename tests/cputestdata/{x86_64-cpuid-Xeon-E3-1245-disabled.xml => x86_64-cpuid-Xeon-E3-1245-v5-disabled.xml} (100%) rename tests/cputestdata/{x86_64-cpuid-Xeon-E3-1245-enabled.xml => x86_64-cpuid-Xeon-E3-1245-v5-enabled.xml} (100%) create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E3-1245-v5-guest.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E3-1245-v5-host.xml rename tests/cputestdata/{x86_64-cpuid-Xeon-E3-1245-json.xml => x86_64-cpuid-Xeon-E3-1245-v5-json.xml} (100%) rename tests/cputestdata/{x86_64-cpuid-Xeon-E3-1245.json => x86_64-cpuid-Xeon-E3-1245-v5.json} (100%) rename tests/cputestdata/{x86_64-cpuid-Xeon-E3-1245.xml => x86_64-cpuid-Xeon-E3-1245-v5.xml} (100%) rename tests/cputestdata/{x86_64-cpuid-Xeon-E5-2630-disabled.xml => x86_64-cpuid-Xeon-E5-2630-v3-disabled.xml} (100%) rename tests/cputestdata/{x86_64-cpuid-Xeon-E5-2630-enabled.xml => x86_64-cpuid-Xeon-E5-2630-v3-enabled.xml} (100%) rename tests/cputestdata/{x86_64-cpuid-Xeon-E5-2630-guest.xml => x86_64-cpuid-Xeon-E5-2630-v3-guest.xml} (100%) rename tests/cputestdata/{x86_64-cpuid-Xeon-E5-2630-host.xml => x86_64-cpuid-Xeon-E5-2630-v3-host.xml} (100%) rename tests/cputestdata/{x86_64-cpuid-Xeon-E5-2630-json.xml => x86_64-cpuid-Xeon-E5-2630-v3-json.xml} (100%) rename tests/cputestdata/{x86_64-cpuid-Xeon-E5-2630.json => x86_64-cpuid-Xeon-E5-2630-v3.json} (100%) rename tests/cputestdata/{x86_64-cpuid-Xeon-E5-2630.xml => x86_64-cpuid-Xeon-E5-2630-v3.xml} (100%) rename tests/cputestdata/{x86_64-cpuid-Xeon-E5-2650-disabled.xml => x86_64-cpuid-Xeon-E5-2650-v3-disabled.xml} (100%) rename tests/cputestdata/{x86_64-cpuid-Xeon-E5-2650-enabled.xml => x86_64-cpuid-Xeon-E5-2650-v3-enabled.xml} (100%) rename tests/cputestdata/{x86_64-cpuid-Xeon-E5-2650-guest.xml => x86_64-cpuid-Xeon-E5-2650-v3-guest.xml} (100%) rename tests/cputestdata/{x86_64-cpuid-Xeon-E5-2650-host.xml => x86_64-cpuid-Xeon-E5-2650-v3-host.xml} (100%) rename tests/cputestdata/{x86_64-cpuid-Xeon-E5-2650-json.xml => x86_64-cpuid-Xeon-E5-2650-v3-json.xml} (100%) rename tests/cputestdata/{x86_64-cpuid-Xeon-E5-2650.json => x86_64-cpuid-Xeon-E5-2650-v3.json} (100%) rename tests/cputestdata/{x86_64-cpuid-Xeon-E5-2650.xml => x86_64-cpuid-Xeon-E5-2650-v3.xml} (100%) rename tests/cputestdata/{x86_64-cpuid-Xeon-E7-8890-disabled.xml => x86_64-cpuid-Xeon-E5-2650-v4-disabled.xml} (100%) create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E5-2650-v4-enabled.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E5-2650-v4-guest.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E5-2650-v4-host.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E5-2650-v4-json.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E5-2650-v4.json create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E5-2650-v4.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E7-8890-v3-disabled.xml rename tests/cputestdata/{x86_64-cpuid-Xeon-E7-8890-enabled.xml => x86_64-cpuid-Xeon-E7-8890-v3-enabled.xml} (100%) rename tests/cputestdata/{x86_64-cpuid-Xeon-E7-8890-guest.xml => x86_64-cpuid-Xeon-E7-8890-v3-guest.xml} (100%) rename tests/cputestdata/{x86_64-cpuid-Xeon-E7-8890-host.xml => x86_64-cpuid-Xeon-E7-8890-v3-host.xml} (100%) rename tests/cputestdata/{x86_64-cpuid-Xeon-E7-8890-json.xml => x86_64-cpuid-Xeon-E7-8890-v3-json.xml} (100%) rename tests/cputestdata/{x86_64-cpuid-Xeon-E7-8890.json => x86_64-cpuid-Xeon-E7-8890-v3.json} (100%) rename tests/cputestdata/{x86_64-cpuid-Xeon-E7-8890.xml => x86_64-cpuid-Xeon-E7-8890-v3.xml} (100%) -- 2.14.3

2 4

[libvirt] [PATCH 0/2] Update documentation for latest vbox changes.
by Dawid Zamirski 07 Nov '17

07 Nov '17

* update docs/drvvbox.html.in to show support for <controller> * update docs/fomatdomain.html.in to describe autoport behavior in the vbox driver Dawid Zamirski (2): docs: Update vbox driver documentation. docs: Document autoport behavior in the vbox driver docs/drvvbox.html.in | 28 +++++++++++++++++++++++++++- docs/formatdomain.html.in | 5 ++++- 2 files changed, 31 insertions(+), 2 deletions(-) -- 2.14.2

2 5

[libvirt] [PATCH v3 00/13] vbox: Improve handling of storage devices
by Dawid Zamirski 07 Nov '17

07 Nov '17

v2: https://www.redhat.com/archives/libvir-list/2017-October/msg01108.html Changes since v2: * Rebase on master * Do not segfault in 'Cleanup partially-defined VM on failure' when code jumps to cleanup and machine is NULL * Take out SAS controller handling code into a separate patch * Split up the snapshot function cleanup code into separate patches * Fixed code formatting as pointed out in review * Rename vboxDumpIDEHDDs -> vboxDumpDisks into a separate patch * Add docs/news.xml patch to describe improvements/fixes in the series Dawid Zamirski (13): vbox: Cleanup partially-defined VM on failure vbox: Process <controller> element in domain XML vbox: Add vboxDumpStorageControllers vbox: Rename vboxDumpIDEHDDs to vboxDumpDisks vbox: Cleanup/prepare snasphot dumpxml functions vbox: Do not free disk definitions on cleanup vbox: Swap vboxSnapshotGetReadOnlyDisks arguments vbox: Correctly generate drive name in dumpxml vbox: Cleanup vboxDumpDisks implementation vbox: Process empty removable disks in dumpxml vbox: Generate disk address element in dumpxml vbox: Add SAS controller support docs: Update news.xml with vbox changes. docs/news.xml | 74 ++++ src/vbox/vbox_common.c | 1105 +++++++++++++++++++++++++++++++----------------- src/vbox/vbox_common.h | 8 + 3 files changed, 792 insertions(+), 395 deletions(-) -- 2.14.3

2 16

[libvirt] [PATCH v2 00/15] vbox: Improve handling of storage devices
by Dawid Zamirski 07 Nov '17

07 Nov '17

From: Dawid Zamirski <dzrudy(a)gmail.com> v1: https://www.redhat.com/archives/libvir-list/2017-October/msg00381.html Changes since v1: * split out the original patches into smaller ones, with each bugfix or cleanup task is in its own isolated and compilable patch * make sure switch statements are type casted and all cases are handled * fixed implementation of partial VM cleanup code and isolated into separate patch (patch #3) * squashed doc and rng updates into a single patch (#9), updated doc wording as suggested * addressed other minor issues (add debug statements, code formatting, better comments, commit message spelling etc) Dawid Zamirski (15): vbox: Update ATTRIBUTE_UNUSED usage vbox: Close media when undefining domains vbox: Cleanup partially-defined VM on failure vbox: vboxAttachDrives now relies on address info vbox: Cleanup vboxAttachDrives implementation vbox: Errors in vboxAttachDrives are now critical vbox: Support empty removable drives. vbox: Add more IStorageController API mappings domain: Allow 'model' attribute for ide controller vbox: Process <controller> element in domain XML vbox: Add vboxDumpStorageControllers vbox: Correctly generate drive name in dumpxml vbox: Cleanup vboxDumpDisks implementation vbox: Process empty removable disks in dumpxml vbox: Generate disk address element in dumpxml docs/formatdomain.html.in | 4 + docs/schemas/domaincommon.rng | 18 +- src/conf/domain_conf.c | 9 + src/conf/domain_conf.h | 9 + src/libvirt_private.syms | 2 + src/vbox/vbox_common.c | 1422 +++++++++++++++++++++++++---------------- src/vbox/vbox_common.h | 21 + src/vbox/vbox_tmpl.c | 93 ++- src/vbox/vbox_uniformed_api.h | 3 + 9 files changed, 983 insertions(+), 598 deletions(-) -- 2.14.2

2 36

[libvirt] [PATCH 0/2] Misc apparmor fixes
by Christian Ehrhardt 07 Nov '17

07 Nov '17

Hi, here a few more apparmor fixes for your review. One is for an Ubuntu bug [1] which is non fatal, but denies a qemu fix to fully work. The other one I was carried in Ubuntu for some time and is related to ipv6 only setups where virt-aa-helper can fail if not permitted inet6. [1]: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1729626 Christian Ehrhardt (2): apparmor: allow qemu to read max_segments apparmor, virt-aa-helper: allow ipv6 examples/apparmor/libvirt-qemu | 3 +++ examples/apparmor/usr.lib.libvirt.virt-aa-helper | 1 + 2 files changed, 4 insertions(+) -- 2.7.4

3 5

[libvirt] [PATCH REPOST 0/8] Privatize _virStoragePoolObj and _virStorageVolDefList (Batch #3)
by John Ferlan 07 Nov '17

07 Nov '17

Since the original series (19 patches): https://www.redhat.com/archives/libvir-list/2017-September/msg00594.html didn't garner any attention, I'm going with smaller patch piles to make forward progress. This is the last half of the storage backends plus one missed merge (because I broke things up <sigh>) John Ferlan (8): storage: Use virStoragePoolObjGetDef accessor for iSCSI backend storage: Use virStoragePoolObjGetDef accessor for MPATH backend storage: Use virStoragePoolObjGetDef accessor for RBD backend storage: Use virStoragePoolObjGetDef accessor for SCSI backend storage: Use virStoragePoolObjGetDef accessor for VSTORAGE backend storage: Use virStoragePoolObjGetDef accessor for ZFS backend storage: Use virStoragePoolObjGetDef accessor for new driver events storage: Privatize virStoragePoolObj and virStorageVolDefList src/conf/storage_conf.h | 4 --- src/conf/virstorageobj.c | 20 +++++++++++ src/conf/virstorageobj.h | 15 -------- src/storage/storage_backend_iscsi.c | 41 ++++++++++++---------- src/storage/storage_backend_mpath.c | 8 +++-- src/storage/storage_backend_rbd.c | 64 ++++++++++++++++++---------------- src/storage/storage_backend_scsi.c | 30 +++++++++------- src/storage/storage_backend_vstorage.c | 31 ++++++++-------- src/storage/storage_backend_zfs.c | 39 ++++++++++++--------- src/storage/storage_driver.c | 8 ++--- 10 files changed, 144 insertions(+), 116 deletions(-) -- 2.13.6

2 11

[libvirt] [PATCH v2] vz: allow to start vz driver without host cache info
by Mikhail Feoktistov 07 Nov '17

07 Nov '17

Show warning message instead of fail operation. It happens if kernel or cpu doesn't support reporting cpu cache info. In case of Virtuozzo file "id" doesn't exist. --- src/vz/vz_driver.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/vz/vz_driver.c b/src/vz/vz_driver.c index 6f4aee3..eb97e54 100644 --- a/src/vz/vz_driver.c +++ b/src/vz/vz_driver.c @@ -119,7 +119,7 @@ vzBuildCapabilities(void) goto error; if (virCapabilitiesInitCaches(caps) < 0) - goto error; + VIR_WARN("Failed to get host CPU cache info"); verify(ARRAY_CARDINALITY(archs) == ARRAY_CARDINALITY(emulators)); -- 1.8.3.1

2 5

[libvirt] Interim fix for exposing VMware firmware=bios|efi in libvirt XML
by Richard W.M. Jones 07 Nov '17

07 Nov '17

https://bugzilla.redhat.com/show_bug.cgi?id=1217444 VMware guests can use either BIOS or UEFI firmware. VMware itself exposes this information in the VMX file and it's available to the ESX driver in libvirt. virt-v2v wants to consume this information. Unfortunately after a few years and iterations we've not come up with an acceptable patch to expose “has UEFI” in the libvirt XML. (Latest patch was: https://www.redhat.com/archives/libvir-list/2016-October/msg00045.html ) Could we instead add a temporary addition to the XML generated by the ESX driver? I'm thinking something like the existing <vmware:moref> and <vmware:datacenterpath> fields: <domain type='vmware' xmlns:vmware='http://libvirt.org/schemas/domain/vmware/1.0'> <name>Fedora</name> ... <vmware:datacenterpath>ha-datacenter</vmware:datacenterpath> <vmware:moref>2</vmware:moref> <vmware:firmware>uefi</vmware:firmware>  </domain> This field would be informational, ie. the ESX driver would create it but not read it when creating new VMs. This would solve our immediate problem in virt-v2v and is pretty simple to implement. Also it doesn't close off any future general solution. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/

2 1