- Devel - libvirt List Archives

[libvirt] [PATCH] virt-aa-helper: fix libusb access to udev usb descriptions
by Christian Ehrhardt 26 Oct '17

26 Oct '17

In bf3a4140 "virt-aa-helper: fix libusb access to udev usb data" the libusb access to properly detect the device/bus ids was fixed. The path /run/udev/data/+usb* contains a subset of that information we already allow to be read and are currently not needed for the function qemu needs libusb for. But on the init of libusb all those files are still read so a lot of apparmor denials can be seen when using usb host devices, like: apparmor="DENIED" operation="open" name="/run/udev/data/+usb:2-1.2:1.0" comm="qemu-system-x86" requested_mask="r" denied_mask="r" Today we could silence the warnings with a deny rule without breaking current use cases. But since the data in there is only a subset of those it can read already it is no additional information exposure. And on the other hand a future udev/libusb/qemu combination might need it so allow the access in the default apparmor profile. Signed-off-by: Christian Ehrhardt <christian.ehrhardt(a)canonical.com> --- examples/apparmor/libvirt-qemu | 1 + 1 file changed, 1 insertion(+) diff --git a/examples/apparmor/libvirt-qemu b/examples/apparmor/libvirt-qemu index b341e31..97dd2d4 100644 --- a/examples/apparmor/libvirt-qemu +++ b/examples/apparmor/libvirt-qemu @@ -32,6 +32,7 @@ # libusb needs udev data about usb devices (~equal to content of lsusb -v) /run/udev/data/c16[6,7]* r, /run/udev/data/c18[0,8,9]* r, + /run/udev/data/+usb* r, # WARNING: this gives the guest direct access to host hardware and specific # portions of shared memory. This is required for sound using ALSA with kvm, -- 2.7.4

3 2

[libvirt] Libvirt xl to xml converter only picks up first occurrence of an option
by Wei Liu 26 Oct '17

26 Oct '17

Hi Jim I discovered that libvirt's native config file to xml converter for libxl only pick up the first occurrence of an option. For example in a xl cfg file: extra = "abc" ... extra = "def" xl will pick up "def" because that shows up later and takes precedence, while the converter picks up "abc". I think this is a bug in the converter and should be fixed. Thanks Wei.

2 2

[libvirt] [PATCH] conf: Avoid leaking blockers from virDomainCapsCPUModel
by Jiri Denemark 26 Oct '17

26 Oct '17

When adding CPU usability blockers I forgot to properly free them when in virDomainCapsCPUModelsDispose. Reported-by: Marc Hartmayer <mhartmay(a)linux.vnet.ibm.com> Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com> --- src/conf/domain_capabilities.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/conf/domain_capabilities.c b/src/conf/domain_capabilities.c index 729d905e2..7f96ff386 100644 --- a/src/conf/domain_capabilities.c +++ b/src/conf/domain_capabilities.c @@ -94,8 +94,10 @@ virDomainCapsCPUModelsDispose(void *obj) virDomainCapsCPUModelsPtr cpuModels = obj; size_t i; - for (i = 0; i < cpuModels->nmodels; i++) + for (i = 0; i < cpuModels->nmodels; i++) { VIR_FREE(cpuModels->models[i].name); + virStringListFree(cpuModels->models[i].blockers); + } VIR_FREE(cpuModels->models); } -- 2.14.3

2 1

[libvirt] [PATCH 0/2] Further Increase default file handle limits
by Christian Ehrhardt 26 Oct '17

26 Oct '17

In 27cd7635 new default limits were set: Author: Daniel P. Berrange <berrange(a)redhat.com> Date: Wed Mar 15 16:51:51 2017 +0000 Increase default file handle limits for daemons But I faced some constraints with these values and think it is time to reconsider the defaults to only have to be tweaked in really uncommon cases. Christian Ehrhardt (2): Increase default file handle limits for virtlogd Increase default file handle limits for virtlockd src/locking/virtlockd.service.in | 4 ++-- src/logging/virtlogd.service.in | 6 ++++-- 2 files changed, 6 insertions(+), 4 deletions(-) -- 2.7.4

2 3

[libvirt] [PATCH] docs: Drop mention that WWN for disks must be unique
by Peter Krempa 26 Oct '17

26 Oct '17

For multipath disks it might be useful to have the same WWN for multiple disks. It's the users choice to do so. Since we dropped the check that disallows using duplicate WWNs drop the docs as well. https://bugzilla.redhat.com/show_bug.cgi?id=1464975 --- Pushed as trivial. docs/formatdomain.html.in | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in index 4609e2ec2..4f28dce35 100644 --- a/docs/formatdomain.html.in +++ b/docs/formatdomain.html.in @@ -3184,8 +3184,7 @@ <dt><code>wwn</code></dt> <dd>If present, this element specifies the WWN (World Wide Name) of a virtual hard disk or CD-ROM drive. It must be composed - of 16 hexadecimal digits and must be unique (at least among - disks of a single domain) + of 16 hexadecimal digits. <span class='since'>Since 0.10.1</span> </dd> <dt><code>vendor</code></dt> -- 2.13.6

1 0

[libvirt] Plans for next release
by Daniel Veillard 26 Oct '17

26 Oct '17

Hi all, we are getting close to the end of the month, and I think we should enter freeze over the week-end. Then I can try to push an RC2 on Tuesday and make the GA release on the 2nd Nov (I'm travelling ATM and Nov 1st is closed, not sure I could do this that day). Hope this works for everyone, thanks, Daniel -- Daniel Veillard | Red Hat Developers Tools http://developer.redhat.com/ veillard(a)redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/

1 0

[libvirt] [PATCH v2 0/3] Update VRDE server port handling.
by Dawid Zamirski 26 Oct '17

26 Oct '17

v1: https://www.redhat.com/archives/libvir-list/2017-October/msg00421.html Changes since v1: * separate out the patch that drops VBOX_SESSION_OPEN/CLOSE macros. * reverse logic to check for rdp.autoport instead of rdp.port to avoid handling port = -1 * do not set rdp.port = -1 if vboxGetActiveRdpPort returns -1 and add more verbose code comments to clarify the logic Dawid Zamirski (3): vbox: Remove old unflexible macros vbox: Make autoport set RDP port range. vbox: Read runtime RDP port and handle autoport src/vbox/vbox_common.c | 3 +- src/vbox/vbox_tmpl.c | 159 ++++++++++++++++++++++++++++++------------ src/vbox/vbox_uniformed_api.h | 2 +- 3 files changed, 118 insertions(+), 46 deletions(-) -- 2.14.2

2 8

[libvirt] [PATCH go-xml] Add bootp option to NetworkDHCP
by Michal Rostecki 24 Oct '17

24 Oct '17

From: Michal Rostecki <michal.rostecki(a)gmail.com> Support specyfing concrete file and TFTP server for PXE boot. Signed-off-by: Michal Rostecki <michal.rostecki(a)gmail.com> --- network.go | 6 ++++++ network_test.go | 7 +++++++ 2 files changed, 13 insertions(+) diff --git a/network.go b/network.go index 32f125a..10c4dfc 100644 --- a/network.go +++ b/network.go @@ -78,9 +78,15 @@ type NetworkDHCPHost struct { IP string `xml:"ip,attr,omitempty"` } +type NetworkBootp struct { + File string `xml:"file,attr,omitempty"` + Server string `xml:"server,attr,omitempty"` +} + type NetworkDHCP struct { Ranges []NetworkDHCPRange `xml:"range"` Hosts []NetworkDHCPHost `xml:"host"` + Bootp []NetworkBootp `xml:"bootp"` } type NetworkIP struct { diff --git a/network_test.go b/network_test.go index b1bd168..3efb278 100644 --- a/network_test.go +++ b/network_test.go @@ -100,6 +100,12 @@ var networkTestData = []struct { IP: "192.168.122.10", }, }, + Bootp: []NetworkBootp{ + NetworkBootp{ + File: "pxelinux.0", + Server: "192.168.122.1", + }, + }, }, }, NetworkIP{ @@ -179,6 +185,7 @@ var networkTestData = []struct { ` <dhcp>`, ` <range start="192.168.122.2" end="192.168.122.254"></range>`, ` <host mac="00:16:3e:77:e2:ed" name="foo.example.com" ip="192.168.122.10"></host>`, + ` <bootp file="pxelinux.0" server="192.168.122.1"></bootp>`, ` </dhcp>`, ` </ip>`, ` <ip address="2001:db8:ca2:2::1" family="ipv6" prefix="64">`, -- 2.13.6

1 0

[libvirt] [PATCH v2 0/2] daemon: fix termination/reload issues
by Nikolay Shirokovskiy 24 Oct '17

24 Oct '17

v1: https://www.redhat.com/archives/libvir-list/2017-September/msg01006.html Changes from v1: 1. Patches that fixes qemu driver termination are moved out of this series 2. New version of [1] now fixes issue in a way that suggested by reviewer 3. [2] fixes another issue that was discovered in the process of review Nikolay Shirokovskiy (2): libvirtd: fix crash on termination [1] virtlogd: add missing netserver refcount increment on reload [2] src/locking/lock_daemon.c | 1 + src/rpc/virnetdaemon.c | 6 +++++- 2 files changed, 6 insertions(+), 1 deletion(-) -- 1.8.3.1

1 3

[libvirt] [PATCH] spec: Restart libvirtd in posttrans
by Jiri Denemark 24 Oct '17

24 Oct '17

When upgrading libvirt packages, there's no strict ordering for the installation or removal of the individual libvirt sub packages. Thus libvirt-daemon may be upgraded (and its %postun scriptlet) started before all sub packages with driver libraries are upgraded. When libvirt-daemon's %postun scriptlet restarts the daemon old drivers may still be laying around and the daemon may crash when it tries to use them. Let's restart the daemon in %posttrans to make sure libvirtd is restarted only after all sub packages are at the same version. https://bugzilla.redhat.com/show_bug.cgi?id=1464300 Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com> --- libvirt.spec.in | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/libvirt.spec.in b/libvirt.spec.in index 0123d0655..73e647cb5 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -1554,13 +1554,11 @@ fi if [ $1 -ge 1 ] ; then /bin/systemctl reload-or-try-restart virtlockd.service >/dev/null 2>&1 || : /bin/systemctl reload-or-try-restart virtlogd.service >/dev/null 2>&1 || : - /bin/systemctl try-restart libvirtd.service >/dev/null 2>&1 || : fi %else if [ $1 -ge 1 ]; then /sbin/service virtlockd reload > /dev/null 2>&1 || : /sbin/service virtlogd reload > /dev/null 2>&1 || : - /sbin/service libvirtd condrestart > /dev/null 2>&1 fi %endif @@ -1570,10 +1568,16 @@ fi if [ "$1" -ge "1" ]; then /sbin/service virtlockd reload > /dev/null 2>&1 || : /sbin/service virtlogd reload > /dev/null 2>&1 || : - /sbin/service libvirtd condrestart > /dev/null 2>&1 fi %endif +%posttrans daemon +%if %{with_systemd} +/bin/systemctl try-restart libvirtd.service >/dev/null 2>&1 || : +%else +/sbin/service libvirtd condrestart > /dev/null 2>&1 || : +%endif + # In upgrade scenario we must explicitly enable virtlockd/virtlogd # sockets, if libvirtd is already enabled and start them if # libvirtd is running, otherwise you'll get failures to start @@ -1642,11 +1646,13 @@ fi %post daemon-config-nwfilter cp %{_datadir}/libvirt/nwfilter/*.xml %{_sysconfdir}/libvirt/nwfilter/ + +%posttrans daemon-config-nwfilter # Make sure libvirt picks up the new nwfilter defininitons %if %{with_systemd} - /bin/systemctl try-restart libvirtd.service >/dev/null 2>&1 ||: +/bin/systemctl try-restart libvirtd.service >/dev/null 2>&1 || : %else - /sbin/service libvirtd condrestart > /dev/null 2>&1 || : +/sbin/service libvirtd condrestart > /dev/null 2>&1 || : %endif -- 2.14.2

2 2

[libvirt] [PATCH] virsh: domain: Fix option handling in domxml-to-native
by Peter Krempa 24 Oct '17

24 Oct '17

Commit fdeac7a05fdf85458d72e89efcfa0f444525aaad tried to fix the output of 'virsh --help domxml-to-native' by switching types around. One of the changes broke the option parser. VSH_OT_ARGV should be used only for variable argument count, not to make the help generator look pretty. The correct option type in this case is VSH_OT_STRING as it's not mandatory now since it can be substituted by using --domain. This makes --help for this command look incorrect, but the parser works as it should. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1494400 --- tools/virsh-domain.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/virsh-domain.c b/tools/virsh-domain.c index e1a312a6a..1e33e8295 100644 --- a/tools/virsh-domain.c +++ b/tools/virsh-domain.c @@ -10152,7 +10152,7 @@ static const vshCmdOptDef opts_domxmltonative[] = { .help = N_("domain name, id or uuid") }, {.name = "xml", - .type = VSH_OT_ARGV, + .type = VSH_OT_STRING, .help = N_("xml data file to export from") }, {.name = NULL} -- 2.13.6

2 1

[libvirt] [PATCH] qemu: Reset hasManagedSave after removing a corrupted image
by Jiri Denemark 24 Oct '17

24 Oct '17

When starting a domain with managed save image, we try to restore it first. If the image is corrupted, we silently unlink it and just normally start the domain. At this point the domain has no managed save image, yet we did not reset the hasManagedSave flag. https://bugzilla.redhat.com/show_bug.cgi?id=1460962 Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com> --- src/qemu/qemu_driver.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 32a416f9e..74fdfdb0f 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -7256,6 +7256,7 @@ qemuDomainObjStart(virConnectPtr conn, } else { VIR_WARN("Ignoring incomplete managed state %s", managed_save); priv->job.current->operation = op; + vm->hasManagedSave = false; } } } -- 2.14.2

2 1

[libvirt] [PATCH] iohelper: use saferead if later write with O_DIRECT
by Nikolay Shirokovskiy 24 Oct '17

24 Oct '17

One of the usecases of iohelper is to read from pipe and write to file with O_DIRECT. As we read from pipe we can have partial read and then we fail to write this data because output file is open with O_DIRECT and buffer size is not aligned. --- src/util/iohelper.c | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/src/util/iohelper.c b/src/util/iohelper.c index 5416d45..bb8a8dd 100644 --- a/src/util/iohelper.c +++ b/src/util/iohelper.c @@ -109,9 +109,21 @@ runIO(const char *path, int fd, int oflags) while (1) { ssize_t got; - if ((got = read(fdin, buf, buflen)) < 0) { - if (errno == EINTR) + /* If we read with O_DIRECT from file we can't use saferead as + * it can lead to unaligned read after reading last bytes. + * If we write with O_DIRECT use should use saferead so that + * writes will be aligned. + * In other cases using saferead reduces number of syscalls. + */ + if (fdin == fd && direct) { + if ((got = read(fdin, buf, buflen)) < 0 && + errno == EINTR) continue; + } else { + got = saferead(fdin, buf, buflen); + } + + if (got < 0) { virReportSystemError(errno, _("Unable to read %s"), fdinname); goto cleanup; } -- 1.8.3.1

2 2

[libvirt] [PATCH v1 0/5] Predictable file names for memory-backend-file
by Michal Privoznik 24 Oct '17

24 Oct '17

As discussed here [1], for some types of environment it's important to allocate memory upfront. In such cases libvirt needs to reuse the paths. However, since we don't want to expose the paths anywhere, reversed approach is implemented. If enabled in config file, libvirt builds predictable paths for memory-backend-file. 1: https://www.redhat.com/archives/libvir-list/2017-October/msg01036.html As usual, you can also find all the patches on my github: https://github.com/zippy2/libvirt/tree/aliases_from_user_v2 (Why v2? Don't ask.) Michal Privoznik (5): conf: s/virDomainObjGetShortName/virDomainDefGetShortName/ qemu: Move memPath generation from memoryBackingDir to a separate function qemu.conf: Introduce memory_predictable_file_names qemuxml2argvtest: Test memory_predictable_file_names news: Document memory_predictable_file_names docs/news.xml | 10 ++ src/conf/domain_conf.c | 4 +- src/conf/domain_conf.h | 2 +- src/libvirt_private.syms | 2 +- src/qemu/libvirtd_qemu.aug | 1 + src/qemu/qemu.conf | 5 + src/qemu/qemu_command.c | 9 +- src/qemu/qemu_conf.c | 92 +++++++++++++- src/qemu/qemu_conf.h | 11 ++ src/qemu/qemu_domain.c | 4 +- src/qemu/qemu_driver.c | 21 ++- src/qemu/qemu_hotplug.c | 2 +- src/qemu/qemu_process.c | 141 +++++++++++++++------ src/qemu/qemu_process.h | 8 +- src/qemu/test_libvirtd_qemu.aug.in | 1 + .../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 +- tests/qemuxml2argvtest.c | 1 + 21 files changed, 279 insertions(+), 68 deletions(-) -- 2.13.6

2 8

[libvirt] libvirt not wanting to read back its own interface XML
by Marc Haber 24 Oct '17

24 Oct '17

Hi, I'm trying to give libvirt knowlegde of a VLAN interface that is configured by a different means and not by libvirt. To figure out the syntax, I created a VLAN interface through virt-manager and dumped out the XML: <interface type='vlan' name='ens3.180'> <protocol family='ipv6'> <ip address='2a01:4f8:150:436c::55:100' prefix='64'/> <ip address='fe80::5054:ff:fe30:e0d1' prefix='64'/> </protocol> <link speed='4294967295' state='up'/> <vlan tag='180'> <interface name='ens3'/> </vlan> </interface> I then removed the Interface in virt-manager and tried to have libvirt read back its own XML. [12/784]mh@testsid85:~ $ virsh iface-dumpxml ens3.180 > ens3.180.xml [13/785]mh@testsid85:~ $ virsh iface-define ens3.180.xml error: Failed to define interface from ens3.180.xml error: XML error: could not get interface XML description: XML invalid - Expecting an element start, got nothing What is going on here? How do I define a VLAN interface via XML? Greetings Marc -- ----------------------------------------------------------------------------- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421

4 9

[libvirt] [jenkins-ci PATCH v2 0/5] guests: Fixes for development releases
by Andrea Bolognani 23 Oct '17

23 Oct '17

Changes from [v1]: * rebase on top of current master; * perform pure code motions in a separate patch; * clean up non-CI guests. [v1] https://www.redhat.com/archives/libvir-list/2017-October/msg01045.html Andrea Bolognani (5): guests: Shuffle base steps around guests: Use non-debug kernel on Fedora Rawhide guests: Clean up non-CI guests ansible: Use ansible_distribution_release on FreeBSD guests: Add Debian sid and FreeBSD -CURRENT guests/files/fedora-rawhide-kernel-nodebug.repo | 8 ++ guests/host_vars/libvirt-debian-sid/install.yml | 3 + .../main.yml | 2 +- .../main.yml | 11 ++- guests/host_vars/libvirt-ubuntu-12/main.yml | 1 - guests/host_vars/libvirt-ubuntu-14/main.yml | 1 - guests/host_vars/libvirt-ubuntu-16/main.yml | 1 - guests/tasks/base.yml | 61 +++++++++----- guests/vars/mappings.yml | 3 +- guests/vars/vault.yml | 98 ++++++++++------------ 10 files changed, 107 insertions(+), 82 deletions(-) create mode 100644 guests/files/fedora-rawhide-kernel-nodebug.repo create mode 100644 guests/host_vars/libvirt-debian-sid/install.yml copy guests/host_vars/{libvirt-ubuntu-16 => libvirt-debian-sid}/main.yml (94%) copy guests/host_vars/{libvirt-ubuntu-16 => libvirt-freebsd-current}/main.yml (51%) -- 2.13.6

2 6

[libvirt] [jenkins-ci PATCH] guests: disable sendmail on FreeBSD to speedup booting
by Pavel Hrdina 23 Oct '17

23 Oct '17

You can notice it by looking for this message while booting: "Oct 23 08:31:19 libvirt-freebsd-10 sm-mta[667]: My unqualified host name (libvirt-freebsd-10) unknown; sleeping for retry" Signed-off-by: Pavel Hrdina <phrdina(a)redhat.com> --- guests/tasks/base.yml | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/guests/tasks/base.yml b/guests/tasks/base.yml index a71e66d..48455dd 100644 --- a/guests/tasks/base.yml +++ b/guests/tasks/base.yml @@ -118,6 +118,19 @@ hostname: name: '{{ inventory_hostname }}' +# On FreeBSD sendmail is enabled by default and it expects fully qualified +# hostname. By disabling sendmail we will avoid sendmail to trying to resolve +# the hostname while booting which takes several seconds. +- name: Disable sendmail + lineinfile: + path: /etc/rc.conf + create: yes + backup: yes + regexp: '^sendmail_enable.*' + line: 'sendmail_enable="NONE"' + when: + - os_name == 'FreeBSD' + - name: Configure ssh access for the root user authorized_key: user: root -- 2.13.6

2 3

[libvirt] Build fails on Debian unstable: libssh's ssh_get_publickey() is deprecated
by Andrea Bolognani 23 Oct '17

23 Oct '17

I ran into a failure trying to compile libvirt on Debian unstable today: rpc/virnetlibsshsession.c: In function 'virLibsshServerKeyAsString': rpc/virnetlibsshsession.c:220:5: error: 'ssh_get_publickey' is deprecated [-Werror=deprecated-declarations] if (ssh_get_publickey(sess->session, &key) != SSH_OK) { ^~ In file included from rpc/virnetlibsshsession.c:24:0: /usr/include/libssh/libssh.h:489:31: note: declared here SSH_DEPRECATED LIBSSH_API int ssh_get_publickey(ssh_session session, ssh_key *key); ^~~~~~~~~~~~~~~~~ CC libvirt_lxc_la-libvirt-lxc.lo cc1: all warnings being treated as errors Makefile:8092: recipe for target 'rpc/libvirt_net_rpc_la-virnetlibsshsession.lo' failed Looks like Debian decided to start shipping a development snapshot instead of the latest stable release: $ dpkg -l | grep libssh- ii libssh-gcrypt-4:amd64 0.8.0~20170825.94fa1e38-1 ii libssh-gcrypt-dev 0.8.0~20170825.94fa1e38-1 That means we're not in a hurry; still, it probably makes sense to try and figure out a way to keep it compiling (and working!) sooner rather than later :) -- Andrea Bolognani / Red Hat / Virtualization

2 1

[libvirt] [libvirt-jenkins-ci PATCH 0/6] Implement developer flavor
by Andrea Bolognani 23 Oct '17

23 Oct '17

Make lcitool useful outside of the libvirt CI context, even though doing so openly contradicts its name. We're just savage like that. Andrea Bolognani (6): guests: Open vault on demand guests: Move configuration handling to load_config() guests: Implement flavors guests: Implement developer flavor guests: Hand root password location over to Ansible guests: Update documentation guests/README.markdown | 45 ++++++------ guests/group_vars/all/main.yml | 4 +- guests/host_vars/libvirt-centos-6/main.yml | 2 - guests/host_vars/libvirt-centos-6/vault.yml | 10 --- guests/host_vars/libvirt-centos-7/main.yml | 2 - guests/host_vars/libvirt-centos-7/vault.yml | 10 --- guests/host_vars/libvirt-debian-8/main.yml | 2 - guests/host_vars/libvirt-debian-8/vault.yml | 10 --- guests/host_vars/libvirt-debian-9/main.yml | 2 - guests/host_vars/libvirt-debian-9/vault.yml | 10 --- guests/host_vars/libvirt-fedora-25/main.yml | 2 - guests/host_vars/libvirt-fedora-25/vault.yml | 10 --- guests/host_vars/libvirt-fedora-26/main.yml | 2 - guests/host_vars/libvirt-fedora-26/vault.yml | 10 --- guests/host_vars/libvirt-fedora-rawhide/main.yml | 2 - guests/host_vars/libvirt-fedora-rawhide/vault.yml | 10 --- guests/host_vars/libvirt-freebsd-10/main.yml | 3 +- guests/host_vars/libvirt-freebsd-10/vault.yml | 10 --- guests/host_vars/libvirt-freebsd-11/main.yml | 3 +- guests/host_vars/libvirt-freebsd-11/vault.yml | 10 --- guests/host_vars/libvirt-ubuntu-12/main.yml | 2 - guests/host_vars/libvirt-ubuntu-12/vault.yml | 8 -- guests/host_vars/libvirt-ubuntu-14/main.yml | 2 - guests/host_vars/libvirt-ubuntu-14/vault.yml | 8 -- guests/host_vars/libvirt-ubuntu-16/main.yml | 2 - guests/host_vars/libvirt-ubuntu-16/vault.yml | 8 -- guests/lcitool | 90 +++++++++++++++++------ guests/site.yml | 6 ++ guests/tasks/base.yml | 2 +- guests/tasks/developer.yml | 21 ++++++ guests/tasks/jenkins.yml | 8 ++ guests/vars/vault.yml | 54 ++++++++++++++ 32 files changed, 186 insertions(+), 184 deletions(-) delete mode 100644 guests/host_vars/libvirt-centos-6/vault.yml delete mode 100644 guests/host_vars/libvirt-centos-7/vault.yml delete mode 100644 guests/host_vars/libvirt-debian-8/vault.yml delete mode 100644 guests/host_vars/libvirt-debian-9/vault.yml delete mode 100644 guests/host_vars/libvirt-fedora-25/vault.yml delete mode 100644 guests/host_vars/libvirt-fedora-26/vault.yml delete mode 100644 guests/host_vars/libvirt-fedora-rawhide/vault.yml delete mode 100644 guests/host_vars/libvirt-freebsd-10/vault.yml delete mode 100644 guests/host_vars/libvirt-freebsd-11/vault.yml delete mode 100644 guests/host_vars/libvirt-ubuntu-12/vault.yml delete mode 100644 guests/host_vars/libvirt-ubuntu-14/vault.yml delete mode 100644 guests/host_vars/libvirt-ubuntu-16/vault.yml create mode 100644 guests/tasks/developer.yml create mode 100644 guests/vars/vault.yml -- 2.13.6

2 12

[libvirt] [jenkins-ci PATCH 0/3] guests: Fixes for development releases
by Andrea Bolognani 23 Oct '17

23 Oct '17

Andrea Bolognani (3): guests: Use non-debug kernel on Fedora Rawhide ansible: Use ansible_distribution_release on FreeBSD guests: Add Debian sid and FreeBSD -CURRENT guests/files/fedora-rawhide-kernel-nodebug.repo | 8 +++ guests/host_vars/libvirt-debian-sid/install.yml | 3 ++ guests/host_vars/libvirt-debian-sid/main.yml | 19 +++++++ guests/host_vars/libvirt-debian-sid/vault.yml | 8 +++ guests/host_vars/libvirt-freebsd-current/main.yml | 25 +++++++++ guests/host_vars/libvirt-freebsd-current/vault.yml | 8 +++ guests/tasks/base.yml | 61 ++++++++++++++-------- 7 files changed, 111 insertions(+), 21 deletions(-) create mode 100644 guests/files/fedora-rawhide-kernel-nodebug.repo create mode 100644 guests/host_vars/libvirt-debian-sid/install.yml create mode 100644 guests/host_vars/libvirt-debian-sid/main.yml create mode 100644 guests/host_vars/libvirt-debian-sid/vault.yml create mode 100644 guests/host_vars/libvirt-freebsd-current/main.yml create mode 100644 guests/host_vars/libvirt-freebsd-current/vault.yml -- 2.13.6

2 4

Re: [libvirt] [Qemu-devel] [RFC 0/6] enable numa configuration before machine_init() from HMP/QMP
by Eduardo Habkost 23 Oct '17

23 Oct '17

On Thu, Oct 19, 2017 at 04:28:59PM +0100, Daniel P. Berrange wrote: > On Thu, Oct 19, 2017 at 11:21:22AM -0400, Igor Mammedov wrote: > > ----- Original Message ----- > > > From: "Daniel P. Berrange" <berrange(a)redhat.com> > > > To: "Igor Mammedov" <imammedo(a)redhat.com> > > > Cc: "peter maydell" <peter.maydell(a)linaro.org>, pkrempa(a)redhat.com, ehabkost(a)redhat.com, cohuck(a)redhat.com, > > > qemu-devel(a)nongnu.org, armbru(a)redhat.com, pbonzini(a)redhat.com, david(a)gibson.dropbear.id.au > > > Sent: Wednesday, October 18, 2017 5:30:10 PM > > > Subject: Re: [Qemu-devel] [RFC 0/6] enable numa configuration before machine_init() from HMP/QMP > > > > > > On Tue, Oct 17, 2017 at 06:06:35PM +0200, Igor Mammedov wrote: > > > > On Tue, 17 Oct 2017 16:07:59 +0100 > > > > "Daniel P. Berrange" <berrange(a)redhat.com> wrote: > > > > > > > > > On Tue, Oct 17, 2017 at 09:27:02AM +0200, Igor Mammedov wrote: > > > > > > On Mon, 16 Oct 2017 17:36:36 +0100 > > > > > > "Daniel P. Berrange" <berrange(a)redhat.com> wrote: > > > > > > > > > > > > > On Mon, Oct 16, 2017 at 06:22:50PM +0200, Igor Mammedov wrote: > > > > > > > > Series allows to configure NUMA mapping at runtime using QMP/HMP > > > > > > > > interface. For that to happen it introduces a new '-paused' CLI > > > > > > > > option > > > > > > > > which allows to pause QEMU before machine_init() is run and > > > > > > > > adds new set-numa-node HMP/QMP commands which in conjuction with > > > > > > > > info hotpluggable-cpus/query-hotpluggable-cpus allow to configure > > > > > > > > NUMA mapping for cpus. > > > > > > > > > > > > > > What's the problem we're seeking solve here compared to what we > > > > > > > currently > > > > > > > do for NUMA configuration ? > > > > > > From RHBZ1382425 > > > > > > " > > > > > > Current -numa CLI interface is quite limited in terms that allow map > > > > > > CPUs to NUMA nodes as it requires to provide cpu_index values which > > > > > > are non obvious and depend on machine/arch. As result libvirt has to > > > > > > assume/re-implement cpu_index allocation logic to provide valid > > > > > > values for -numa cpus=... QEMU CLI option. > > > > > > > > > > In broad terms, this problem applies to every device / object libvirt > > > > > asks QEMU to create. For everything else libvirt is able to assign a > > > > > "id" string, which is can then use to identify the thing later. The > > > > > CPU stuff is different because libvirt isn't able to provide 'id' > > > > > strings for each CPU - QEMU generates a psuedo-id internally which > > > > > libvirt has to infer. The latter is the same problem we had with > > > > > devices before '-device' was introduced allowing 'id' naming. > > > > > > > > > > IMHO we should take the same approach with CPUs and start modelling > > > > > the individual CPUs as something we can explicitly create with -object > > > > > or -device. That way libvirt can assign names and does not have to > > > > > care about CPU index values, and it all works just the same way as > > > > > any other devices / object we create > > > > > > > > > > ie instead of: > > > > > > > > > > -smp 8,sockets=4,cores=2,threads=1 > > > > > -numa node,nodeid=0,cpus=0-3 > > > > > -numa node,nodeid=1,cpus=4-7 > > > > > > > > > > we could do: > > > > > > > > > > -object numa-node,id=numa0 > > > > > -object numa-node,id=numa1 > > > > > -object cpu,id=cpu0,node=numa0,socket=0,core=0,thread=0 > > > > > -object cpu,id=cpu1,node=numa0,socket=0,core=1,thread=0 > > > > > -object cpu,id=cpu2,node=numa0,socket=1,core=0,thread=0 > > > > > -object cpu,id=cpu3,node=numa0,socket=1,core=1,thread=0 > > > > > -object cpu,id=cpu4,node=numa1,socket=2,core=0,thread=0 > > > > > -object cpu,id=cpu5,node=numa1,socket=2,core=1,thread=0 > > > > > -object cpu,id=cpu6,node=numa1,socket=3,core=0,thread=0 > > > > > -object cpu,id=cpu7,node=numa1,socket=3,core=1,thread=0 > > > > the follow up question would be where do "socket=3,core=1,thread=0" > > > > come from, currently these options are the function of > > > > (-M foo -smp ...) and can be queried vi query-hotpluggble-cpus at > > > > runtime after qemu parses -M and -smp options. > > > > > > NB, I realize my example was open to mis-interpretation. The values I'm > > > illustrating here for socket=3,core=1,thread=0 and *not* ID values, they > > > are a plain enumeration of values. ie this is saying the 4th socket, the > > > 2nd core and the 1st thread. Internally QEMU might have the 2nd core > > > with a core-id of 8, or 7038 or whatever architecture specific numbering > > > scheme makes sense, but that's not what the mgmt app gives at the CLI > > > level > > Even though fixed properties/values simplicity is tempting and it might even > > work for what we have implemented in qemu currently (well, SPAPR will need > > refactoring (if possible) to meet requirements + compat stuff for current > > machines with sparse IDs). > > But I have to disagree here and try to oppose it. > > > > QEMU models concrete platforms/hw with certain non abstract properties > > and it's libvirt's domain to translate platform specific devices into > > 'spherical' devices with abstract properties. > > > > Now back to cpus and suggestion to fix the set of 'address' properties > > and their values into continuous enumeration range [0..N). That would > > 1. put a burden of hiding platform/device details on QEMU > > (which is already bad as QEMU's job is to emulate it) > > 2. with abstract 'address' properties and values, user won't have > > a clue as to where device is being attached (as qemu would magically > > remap that to fit specific machine needs) > > 2.1. if abstract 'address' properties and values we can do away with > > socket/core/thread/whatnot since they won't mean the same when considered > > from platform point of view, so we can just drop all these nonsense > > and go back to cpu-index that has all the properties you've suggested > > /abstract, [0..N]/. > > 3. we currently stopped with socket|core|thread-id properties as they are > > applicable to machines that support -device cpu, but it's up to machine > > to pick witch of these to use (x86: uses all, spar: uses core-id only), > > but current property set is open for extension if need arises without > > need to redefine interface. So fixed list of properties [even ignoring > > values impact] doesn't scale. > > Note from the libvirt POV, we don't expose socket-id/core-id/thread-id in our > guest XML, we just provide an overall count of sockets/cores/threads which is > portable. The only arch specific thing we would have todo is express constraints > about ratios of these - eg indicate in some way that ppc doesn't allow mutliple > threads per core for example. > > > We even have cpu-add command which takes cpu-index as argument and > > -numa node,cpus=0..X CLI option, good luck with figuring out which cpu goes > > where and if it makes any sense from platform point of view. > > > > That's why when designing hot plug for 'device_add cpu' interface, we ended up > > with new query-hotpluggble-cpus QMP command, which is currently used by libvirt > > for hot-plug: > > > > Approach allows > > 1: machine to publish properties/values that make sense from emulated > > platform point of view but still understandable by user of given hw. > > 2: user may use them as opaque mandatory properties to create cpu device if > > he/she doesn't care about where it's plugged. > > 3: if user cares about which cpu goes where, properties defined by machine > > provide that info from emulated hw point of view including platform specific > > details. > > 4: it's easy to extend set of properties/values if need arises without > > breaking users (provided user will put them all in -device/device_add > > options as it's supposed to) > > > > But current approach has drawback, to call query-hotpluggble-cpus, machine has to > > be started first, which is fine for hot plug but not for specifying CLI options. > > > > Currently that could be solved by starting qemu twice when 'defining domain', > > where on the first run mgmt queries board layout and caches it for all the next > > times the defined machine is started (change in machine/version/-smp/-cpu will > > invalidate, cache). > > > > This series allows to avoid this 1st time restart, when creating domain for > > the first time, mgmt can query layout and then specify numa mapping without > > restarting, it can cache defined mapping as commands exactly match corresponding > > CLI options and reuse cached options on the next domain starts. > > > > This approach could be extended further with "device_add cpu" command > > so it would be possible to start qemu with -smp 0,... and allow mgmt to > > create cpus with explicit IDs controlled by mgmt, and again mgmt may cache > > these commands and reuse them on CLI next time machine is started > > > > I think Eduardo's work on query-slots is superset of query-hotpluggble-cpus, > > but working to the same goal to allow mgmt discover which hw is provided by > > specific machine and where/which hw could be plugged (like which slot supports > > which kind of device and which 'address' should be used to attach device > > (socket|core... - for cpus, bus/function - for pic, ...) > > As mentioned elsewhere in the thread, the approach of defining the VM config > incrementally via the monitor has significant downsides, by making the config > invisible in any logs of the ARGV, and has likely performance impact when > starting up QEMU, particularly if it is used for more things going forward. To > me these downsides are enough to make the suggested approach for CPUs impractical > for libvirt to use. Those downsides do exist, but we should weight them against the downsides of not allowing any information at all to flow from QEMU to libvirt when starting a VM. I believe the code in libvirt/src/qemu/qemu_domain_address.c is a good illustration of those downsides. -- Eduardo

3 5

[libvirt] [RFC] Question regarding the validity of QEMU capabilities
by Marc Hartmayer 23 Oct '17

23 Oct '17

Hi all, the actual capabilities of QEMU are depending on the host. This includes dependencies like which kernel modules are loaded or which kernel parameters are used (e.g. kvm.nested). Therefore, after a restart we cannot be sure that the QEMU capabilities remain the same. How can we solve this problem? I have come up with two ways: - reprobe the capabilities with every host reboot - check for every possible change in virQEMUCapsIsValid... (this is already done for KVM). In my opinion this is not the way to go. Thanks. Marc

4 5

[libvirt] [PATCH 0/3] qemu: Fix race condition between block jobs and the end of migration
by Jiri Denemark 23 Oct '17

23 Oct '17

When migrating both memory and storage, we need to make sure block jobs are finished after the virtual CPUs get paused at the end of migration but before QEMU completes the migration otherwise QEMU may die with _co_do_pwritev: Assertion `!(bs->open_flags & 0x0800)' failed This is a libvirt side of the QEMU fix from Dr. David Alan Gilbert: http://lists.nongnu.org/archive/html/qemu-devel/2017-10/msg04895.html Applicable on top of my "Preparation for new QEMU migration states" series I sent yesterday. Jiri Denemark (3): qemu: Add support for migrate-continue QMP command qemu: Add pause-before-switchover migration capability qemu: Enabled pause-before-switchover migration capability src/qemu/qemu_domain.c | 1 + src/qemu/qemu_domain.h | 1 + src/qemu/qemu_migration.c | 75 +++++++++++++++++++++++++++++++++++++++++++- src/qemu/qemu_monitor.c | 18 +++++++++-- src/qemu/qemu_monitor.h | 6 ++++ src/qemu/qemu_monitor_json.c | 29 +++++++++++++++++ src/qemu/qemu_monitor_json.h | 4 +++ 7 files changed, 131 insertions(+), 3 deletions(-) -- 2.14.2

2 4

[libvirt] Exposing mem-path in domain XML
by Michal Privoznik 23 Oct '17

23 Oct '17

Dear list, there is the following bug [1] which I'm not quite sure how to grasp. So there is this application/infrastructure called Kove [2] that allows you to have memory for your application stored on a distant host in network and basically fetch needed region on pagefault. Now imagine that somebody wants to use it for backing up domain memory. However, the way that the tool works is it has some kernel module and then some userland binary that is fed with the path of the mmaped file. I don't know all the details, but the point is, in order to let users use this we need to expose the paths for mem-path for the guest memory. I know we did not want to do this in the past, but now it looks like we don't have a way around it, do we? Michal 1: https://bugzilla.redhat.com/show_bug.cgi?id=1461214 2: http://kove.net

3 15

[libvirt] Question about the host-model CPU mode
by Marc Hartmayer 23 Oct '17

23 Oct '17

Let's assume we've a z13 system with a QEMU 2.9 and we define a domain using the default s390-virtio-ccw machine together with the host-model CPU mode. The definition will have the machine expanded to s390-virtio-ccw-2.9 but retain the host-model CPU mode. In a next step we upgrade to QEMU 2.10 (first version to recognize z14). Everything is still fine, even though the machine runs in 2.9 compatibility mode. Finally we upgrade to a z14. As a consequence it is not possible to start the domain anymore as the machine type doesn't support our CPU host model (which is expanded at start time of the domain). Is this behavior expected? There are some ways to avoid this problem: - CPU model expansion is performed at domain definition time - host-model is related to the machine type of a domain Thank you in advance. Beste Grüße / Kind regards Marc Hartmayer IBM Deutschland Research & Development GmbH Vorsitzende des Aufsichtsrats: Martina Koederitz Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen Registergericht: Amtsgericht Stuttgart, HRB 243294

5 19