October 2016 - Devel - libvirt List Archives

[libvirt] [OSSTEST PATCH 0/2] libvirt: Fix save/restore capability check on ARM
by Ian Jackson 11 Oct '16

11 Oct '16

Currently, osstest, the Xen Project's automated test framework, erroneously thinks that save/restore is supported with libvirt on ARM. In fact, save/restore is not supported by Xen on ARM at all. The result is that osstest then actually attempts the save/restore, and abandons the test job as a failure. This is not desirable. In these two patches I try to fix the feature detection to get this right. I'd appreciate advice about whether I have done the right thing. My code is based partly on empirical observation of the output of `virsh capabilities' on x86 and ARM. (See below.) Thanks, Ian. >From baroque0, x86. As left by 101253.test-amd64-amd64-libvirt-pair; osstest "branch" osstest <capabilities> <host> <cpu> <arch>x86_64</arch> <features> <pae/> </features> <model>Haswell-noTSX</model> <topology sockets='1' cores='4' threads='2'/> <feature name='vme'/> <feature name='ds'/> <feature name='acpi'/> <feature name='ht'/> <feature name='tm'/> <feature name='pbe'/> <feature name='dtes64'/> <feature name='monitor'/> <feature name='ds_cpl'/> <feature name='vmx'/> <feature name='smx'/> <feature name='est'/> <feature name='tm2'/> <feature name='xtpr'/> <feature name='pdcm'/> <feature name='f16c'/> <feature name='rdrand'/> <feature name='tsc_adjust'/> <feature name='xsaveopt'/> <feature name='pdpe1gb'/> <feature name='abm'/> <feature name='invtsc'/> </cpu> <power_management/> <migration_features> <live/> </migration_features> <netprefix>vif</netprefix> <topology> <cells num='1'> <cell id='0'> <memory unit='KiB'>9699328</memory> <cpus num='8'> <cpu id='0' socket_id='0' core_id='0' siblings='0-1'/> <cpu id='1' socket_id='0' core_id='0' siblings='0-1'/> <cpu id='2' socket_id='0' core_id='1' siblings='2-3'/> <cpu id='3' socket_id='0' core_id='1' siblings='2-3'/> <cpu id='4' socket_id='0' core_id='2' siblings='4-5'/> <cpu id='5' socket_id='0' core_id='2' siblings='4-5'/> <cpu id='6' socket_id='0' core_id='3' siblings='6-7'/> <cpu id='7' socket_id='0' core_id='3' siblings='6-7'/> </cpus> </cell> </cells> </topology> </host> <guest> <os_type>xen</os_type> <arch name='x86_64'> <wordsize>64</wordsize> <emulator>/usr/lib/xen/bin/qemu-system-i386</emulator> <machine>xenpv</machine> <domain type='xen'/> </arch> </guest> <guest> <os_type>xen</os_type> <arch name='i686'> <wordsize>32</wordsize> <emulator>/usr/lib/xen/bin/qemu-system-i386</emulator> <machine>xenpv</machine> <domain type='xen'/> </arch> <features> <pae/> </features> </guest> <guest> <os_type>hvm</os_type> <arch name='i686'> <wordsize>32</wordsize> <emulator>/usr/lib/xen/bin/qemu-system-i386</emulator> <loader>/usr/lib/xen/boot/hvmloader</loader> <machine>xenfv</machine> <domain type='xen'/> </arch> <features> <pae/> <nonpae/> <acpi default='on' toggle='yes'/> <apic default='on' toggle='no'/> <hap default='on' toggle='yes'/> </features> </guest> <guest> <os_type>hvm</os_type> <arch name='x86_64'> <wordsize>64</wordsize> <emulator>/usr/lib/xen/bin/qemu-system-i386</emulator> <loader>/usr/lib/xen/boot/hvmloader</loader> <machine>xenfv</machine> <domain type='xen'/> </arch> <features> <acpi default='on' toggle='yes'/> <apic default='on' toggle='no'/> <hap default='on' toggle='yes'/> </features> </guest> </capabilities> >From arndale-lakeside, ARM. As left by 101251 | test-armhf-armhf-libvirt; osstest "branch" qemu-mainline <capabilities> <host> <cpu> <arch>armv7l</arch> </cpu> <power_management/> <netprefix>vif</netprefix> <topology> <cells num='1'> <cell id='0'> <memory unit='KiB'>2097152</memory> <cpus num='2'> <cpu id='0' socket_id='0' core_id='0' siblings='0-1'/> <cpu id='1' socket_id='0' core_id='0' siblings='0-1'/> </cpus> </cell> </cells> </topology> </host> <guest> <os_type>xen</os_type> <arch name='armv7l'> <wordsize>32</wordsize> <emulator>/usr/lib/xen/bin/qemu-system-i386</emulator> <machine>xenpv</machine> <domain type='xen'/> </arch> </guest> </capabilities>

4 14

[libvirt] Recommendations for Libvirt LTS release
by Guido Günther 11 Oct '16

11 Oct '16

Hi, Debian is about to enter it's freeze for the Stretch release in November and we will support the libvirt version that is in Stretch for at least 5 years. The upstream version of libvirt at this point will likely be 2.4.0. Are any other distros about to pick a version around that time so we can possibly join forces? Are there any recommendations to rather pick another version due to planned features/fixes/refactorings that haven't made it to the list yet? As with previous versions I will feed back patches to the -maint branch and hope to cut point releases as were currently doing with 0.9.12 but if other distros (apart from Debians downstreams) would use the same version this would be a plus. Cheers, -- Guido

3 2

[libvirt] [PATCH] audit: add descriptions about audit log
by Chen Hanxiao 11 Oct '16

11 Oct '16

From: Chen Hanxiao <chenhanxiao(a)gmail.com> This patch add some descriptions on what libvirt audit will record in introduction section. Signed-off-by: Chen Hanxiao <chenhanxiao(a)gmail.com> --- docs/auditlog.html.in | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/docs/auditlog.html.in b/docs/auditlog.html.in index 45464af..d1d0f6e 100644 --- a/docs/auditlog.html.in +++ b/docs/auditlog.html.in @@ -14,7 +14,9 @@ subsystem. This provides administrators / auditors with a canonical historical record of changes to virtual machines' / containers' lifecycle states and their configuration. On hosts which are running the Linux audit daemon, - the logs will usually end up in <code>/var/log/audit/audit.log</code> + the logs will usually end up in <code>/var/log/audit/audit.log</code>. + If QEMU try to use some resources on the host, libvirt will record them + in audit log. </p> <h2><a name="config">Configuration</a></h2> -- 1.8.3.1

2 1

[libvirt] [PATCH 0/2] Sanitize vcpu topology checking
by Peter Krempa 11 Oct '16

11 Oct '16

See patch 1. Peter Krempa (2): conf: Sanitize cpu topology numbers qemu: Reuse virDomainDeGetVcpusTopology to calculate total vcpu count src/conf/domain_conf.c | 39 +++++++++++++++++++++++++++++++++++++++ src/conf/domain_conf.h | 2 ++ src/libvirt_private.syms | 1 + src/qemu/qemu_domain.c | 18 ++++++++---------- src/qemu/qemu_driver.c | 14 ++++++-------- 5 files changed, 56 insertions(+), 18 deletions(-) -- 2.10.0

2 3

[libvirt] libvirt-guest.sh bug fixes
by Stefan Bader 11 Oct '16

11 Oct '16

Two small changes, before I forget about submitting them... First one affects all environments the same. The list of UIDs which is generated has each element on a separate line. And using quotes in the echo preserves those newlines. However the processing assumes one line per URI and all UIDs separated by spaces. So without dropping the quotes only one guest will get shutdown/suspended. The second change is for Xen environments only. Domain-0 appears in the list of guests and it is a persistent one. So on shutdown, the script tries to stop Domain-0 (which is not working) and then waits the whole timeout for it to stop. -Stefan

4 11

[libvirt] [PATCH] libvirt-storage.c:Lines too long, use 80 character columns.
by Nitesh Konkar 11 Oct '16

11 Oct '16

Signed-off-by: Nitesh Konkar <nitkon12(a)linux.vnet.ibm.com> --- src/libvirt-storage.c | 24 ++++++++++++++++-------- 1 file changed, 16 insertions(+), 8 deletions(-) diff --git a/src/libvirt-storage.c b/src/libvirt-storage.c index 48996ba..c4f2a03 100644 --- a/src/libvirt-storage.c +++ b/src/libvirt-storage.c @@ -233,7 +233,8 @@ virConnectNumOfDefinedStoragePools(virConnectPtr conn) virCheckConnectReturn(conn, -1); - if (conn->storageDriver && conn->storageDriver->connectNumOfDefinedStoragePools) { + if (conn->storageDriver && + conn->storageDriver->connectNumOfDefinedStoragePools) { int ret; ret = conn->storageDriver->connectNumOfDefinedStoragePools(conn); if (ret < 0) @@ -280,7 +281,8 @@ virConnectListDefinedStoragePools(virConnectPtr conn, virCheckNonNullArgGoto(names, error); virCheckNonNegativeArgGoto(maxnames, error); - if (conn->storageDriver && conn->storageDriver->connectListDefinedStoragePools) { + if (conn->storageDriver && + conn->storageDriver->connectListDefinedStoragePools) { int ret; ret = conn->storageDriver->connectListDefinedStoragePools(conn, names, maxnames); if (ret < 0) @@ -332,7 +334,8 @@ virConnectFindStoragePoolSources(virConnectPtr conn, virCheckNonNullArgGoto(type, error); virCheckReadOnlyGoto(conn->flags, error); - if (conn->storageDriver && conn->storageDriver->connectFindStoragePoolSources) { + if (conn->storageDriver && + conn->storageDriver->connectFindStoragePoolSources) { char *ret; ret = conn->storageDriver->connectFindStoragePoolSources(conn, type, srcSpec, flags); if (!ret) @@ -485,7 +488,8 @@ virStoragePoolLookupByVolume(virStorageVolPtr vol) virCheckStorageVolReturn(vol, NULL); - if (vol->conn->storageDriver && vol->conn->storageDriver->storagePoolLookupByVolume) { + if (vol->conn->storageDriver && + vol->conn->storageDriver->storagePoolLookupByVolume) { virStoragePoolPtr ret; ret = vol->conn->storageDriver->storagePoolLookupByVolume(vol); if (!ret) @@ -1188,7 +1192,8 @@ virStoragePoolNumOfVolumes(virStoragePoolPtr pool) virCheckStoragePoolReturn(pool, -1); - if (pool->conn->storageDriver && pool->conn->storageDriver->storagePoolNumOfVolumes) { + if (pool->conn->storageDriver && + pool->conn->storageDriver->storagePoolNumOfVolumes) { int ret; ret = pool->conn->storageDriver->storagePoolNumOfVolumes(pool); if (ret < 0) @@ -1230,7 +1235,8 @@ virStoragePoolListVolumes(virStoragePoolPtr pool, virCheckNonNullArgGoto(names, error); virCheckNonNegativeArgGoto(maxnames, error); - if (pool->conn->storageDriver && pool->conn->storageDriver->storagePoolListVolumes) { + if (pool->conn->storageDriver && + pool->conn->storageDriver->storagePoolListVolumes) { int ret; ret = pool->conn->storageDriver->storagePoolListVolumes(pool, names, maxnames); if (ret < 0) @@ -1297,7 +1303,8 @@ virStorageVolLookupByName(virStoragePoolPtr pool, virCheckStoragePoolReturn(pool, NULL); virCheckNonNullArgGoto(name, error); - if (pool->conn->storageDriver && pool->conn->storageDriver->storageVolLookupByName) { + if (pool->conn->storageDriver && + pool->conn->storageDriver->storageVolLookupByName) { virStorageVolPtr ret; ret = pool->conn->storageDriver->storageVolLookupByName(pool, name); if (!ret) @@ -1471,7 +1478,8 @@ virStorageVolCreateXML(virStoragePoolPtr pool, virCheckNonNullArgGoto(xmlDesc, error); virCheckReadOnlyGoto(pool->conn->flags, error); - if (pool->conn->storageDriver && pool->conn->storageDriver->storageVolCreateXML) { + if (pool->conn->storageDriver && + pool->conn->storageDriver->storageVolCreateXML) { virStorageVolPtr ret; ret = pool->conn->storageDriver->storageVolCreateXML(pool, xmlDesc, flags); if (!ret) -- 2.1.0

3 3

[libvirt] GSoC 2017
by Michal Privoznik 11 Oct '16

11 Oct '16

Dear list, the new round of Google Summer of Code has been announced just now [1]. I believe libvirt wants to participate again, therefore I've started a new wikipage where we can collect ideas for students to work on [2]. If you have any idea just put it on the list please. If you are shy, drop me an e-mail and I'll put it there for you. Also, if you want to participate as a mentor, just add yourself to a project that has none yet (or talk to other mentors for cooperation). Please note that nothing is decided yet, the program has been just announced, we have been not selected yet. I haven't even filled out the application form yet. But in order to do so, I need a list of possible ideas and mentors. Thank you! Michal 1: https://opensource.googleblog.com/2016/10/announcing-google-code-in-2016-an… 2: http://wiki.libvirt.org/page/Google_Summer_of_Code_2017

1 0

[libvirt] [PATCH 0/2] Maybe fix a crash and some unnecessary logging
by Martin Kletzander 11 Oct '16

11 Oct '16

First patch fixes some unnecessary loging I've found out thanks to Vincent's crash reproducer. The second one is an RFC, I would like to know what others think about and can find (and maybe help). More info in that commit message. Martin Kletzander (2): Don't update timer if there's none. Purge marked callbacks before dispatching events src/conf/object_event.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) -- 2.10.1

2 6

[libvirt] [PATCH 0/7] Fixes to various different issues
by John Ferlan 10 Oct '16

10 Oct '16

All found by Coverity.... Not being so diligent lately... There are a few more, but they're all false positives so I'll keep those local. John Ferlan (7): conf: Remove incorrect check when encoding shmem audit message tests: Prefer virGetLastErrorMessage in testSELinuxLabeling qemu: Remove possibility of NULL dereference util: Resolve memory leaks in virLogParse{Output|Filter} vsh: Fix some issues in auto completion code util: Remove need for local 'nelems' tests: Need to initialize data src/conf/domain_audit.c | 4 ++-- src/qemu/qemu_capabilities.c | 7 +++++-- src/util/virlog.c | 4 ++-- src/util/virqemu.c | 3 +-- tests/qemumonitorjsontest.c | 2 +- tests/securityselinuxlabeltest.c | 6 ++---- tools/vsh.c | 7 ++++--- 7 files changed, 17 insertions(+), 16 deletions(-) -- 2.7.4

2 16

[libvirt] Analysis of the effect of adding PCIe root ports
by Richard W.M. Jones 10 Oct '16

10 Oct '16

I was asked to look at the impact on boot times of adding (empty) PCIe root ports to the device model. The proposal from Laine is to add a few of these to every guest to allow hotplugging. Last time I looked into this I found that probing any (legacy) PCI device is expensive because of the inefficient way that qemu emulates accesses to PCI config space, requiring IIRC 2 or 4 VMEXITs to access every word. (PCI slots which are not occupied are basically free, the problem is PCI devices). At that time I did not look at Q35/PCIe at all. We generally aim for boot times under 600-700ms. Probing PCI devices takes a significant fraction of this time. The detailed analysis is attached. It comes from a program called 'boot-analysis' (https://github.com/libguestfs/libguestfs/tree/master/utils/boot-analysis) It is best viewed using 'less -r' so that you can see the colours. The summary table is: Number of ports 0 1 2 3 4 bios:overhead 874 884 875 878 935 kernel:entry 159 163 165 174 491 kernel:initcalls-before-userspace 1065 1090 1110 1147 1263 /init:udev-overhead 173 187 185 193 301 insmod virtio_pci 43 41 41 41 74 TOTAL + 51 + 62 + 119 + 750 (All times are in milliseconds.) A few observations: (1) For #ports <= 3, each extra port adds around 30-40ms to the boot time, which is consistent with what I saw when I measured legacy PCI. (2) There is a sudden, unexplained and reproducible discontinuity when going from 3 to 4 ports. (Because libguestfs uses other devices, this might not actually be 3 to 4 PCIe devices, this is spare ports after all the others added for libguestfs devices.) (3) "kernel:entry" covers a lot of initialization that happens before the kernel prints its version string. This is moderately affected by adding PCIe ports until we hit the discontinuity. Based on this analysis I conclude: (a) Unless we can explain the discontinuity, avoid adding more than 3 root ports. (b) It would be nice to turn the whole thing off for people who don't care about / need hotplugging. (c) We could make PCI probing a lot faster by having the kernel handle PCI config space. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org

4 15