April 2020 - Devel - libvirt List Archives

[PATCH] bhyve: add missing param to virDomainPCIAddressBusSetModel
by Daniel P. Berrangé 16 Apr '20

16 Apr '20

Fixes build error introduced in commit aa15e9259f1f246e69fb9742581ced720c88695d Author: Laine Stump <laine(a)redhat.com> Date: Sun Apr 5 22:40:37 2020 -0400 qemu/conf: set HOTPLUGGABLE connect flag during PCI address set init Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- Pushed as a CI fix src/bhyve/bhyve_device.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/bhyve/bhyve_device.c b/src/bhyve/bhyve_device.c index 13261e9935..fc52280361 100644 --- a/src/bhyve/bhyve_device.c +++ b/src/bhyve/bhyve_device.c @@ -71,7 +71,8 @@ bhyveDomainPCIAddressSetCreate(virDomainDefPtr def, unsigned int nbuses) return NULL; if (virDomainPCIAddressBusSetModel(&addrs->buses[0], - VIR_DOMAIN_CONTROLLER_MODEL_PCI_ROOT) < 0) + VIR_DOMAIN_CONTROLLER_MODEL_PCI_ROOT, + true) < 0) goto error; if (virDomainDeviceInfoIterate(def, bhyveCollectPCIAddress, addrs) < 0) -- 2.24.1

1 0

[PATCH] docs: add zpci information to pci-addresses.rst
by Cornelia Huck 16 Apr '20

16 Apr '20

Add some information on how pci address work on s390x. Signed-off-by: Cornelia Huck <cohuck(a)redhat.com> --- docs/pci-addresses.rst | 63 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 63 insertions(+) diff --git a/docs/pci-addresses.rst b/docs/pci-addresses.rst index 923783a151b0..9e241a24fcfb 100644 --- a/docs/pci-addresses.rst +++ b/docs/pci-addresses.rst @@ -184,3 +184,66 @@ guest OS rather than as ``0001:08:00.1``, which is the address of the device on the host. Of course, all the rules and behaviors described above still apply. + +zPCI addresses +============== + +For s390x machines, PCI addresses are handled yet differently. No +topology information is relayed in the PCI addresses; instead, the +``fid`` and ``uid`` elements of the ``zpci`` device convey information. +In the simplest case, the following XML snippet + +:: + + <controller type='pci' index='0' model='pci-root'/> + <controller type='pci' index='1' model='pci-bridge'> + <model name='pci-bridge'/> + <target chassisNr='1'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'> + <zpci uid='0x0002' fid='0x00000001'/> + </address> + </controller> + <interface type='bridge'> + <mac address='02:ca:fe:fa:ce:04'/> + <source bridge='virbr0'/> + <model type='virtio'/> + <address type='pci' domain='0x0000' bus='0x01' slot='0x01' function='0x0'> + <zpci uid='0x0001' fid='0x00000000'/> + </address> + </interface> + +will result in the following in a Linux guest:: + + 0001:00:00.0 Ethernet controller: Red Hat, Inc. Virtio network device + +Note that the PCI bridge is not visible in the guest; s390x always has a flat +topology. + +Neither are any changes in the PCI address visible in the guest; replacing +the PCI address for the virtio-net device with + +:: + + <address type='pci' domain='0x0000' bus='0x01' slot='0x07' function='0x3'> + +will result in the exactly same view in the guest, as the addresses there +are generated from the information provided via the ``zpci`` element (in +fact, from the ``uid``). + +Therefore, replacing the virtio-net device definition with the following XML +snippet + +:: + + <interface type='bridge'> + <mac address='02:ca:fe:fa:ce:04'/> + <source bridge='virbr0'/> + <model type='virtio'/> + <address type='pci' domain='0x0000' bus='0x01' slot='0x07' function='0x3'> + <zpci uid='0x0007' fid='0x00000003'/> + </address> + </interface> + +will yield the following result in a Linux guest:: + + 0007:00:00.0 Ethernet controller: Red Hat, Inc. Virtio network device -- 2.21.1

4 12

[libvirt PATCH] docs: fix mistaken description of the read-only socket units
by Daniel P. Berrangé 16 Apr '20

16 Apr '20

Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- docs/daemons.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/daemons.rst b/docs/daemons.rst index 13c244de7b..e0b95105e4 100644 --- a/docs/daemons.rst +++ b/docs/daemons.rst @@ -145,7 +145,7 @@ Libvirt ships a number of unit files for controlling ``libvirtd``: UNIX socket ``/var/run/libvirt/libvirt-sock``. This socket is recommended to be started on boot by default. -* ``libvirtd-ro.socket`` - the unit file corresponding to the main read-write +* ``libvirtd-ro.socket`` - the unit file corresponding to the main read-only UNIX socket ``/var/run/libvirt/libvirt-sock-ro``. This socket is recommended to be started on boot by default. @@ -316,7 +316,7 @@ Libvirt ships a number of unit files for controlling ``virt${DRIVER}d``: recommended to be started on boot by default. * ``virt${DRIVER}d-ro.socket`` - the unit file corresponding to the main - read-write UNIX socket ``/var/run/libvirt/virt${DRIVER}d-sock-ro``. This + read-only UNIX socket ``/var/run/libvirt/virt${DRIVER}d-sock-ro``. This socket is recommended to be started on boot by default. * ``virt${DRIVER}d-admin.socket`` - the unit file corresponding to the @@ -471,7 +471,7 @@ Libvirt ships a number of unit files for controlling ``virtproxyd``: UNIX socket ``/var/run/libvirt/libvirt-sock``. This socket is recommended to be started on boot by default. -* ``virtproxyd-ro.socket`` - the unit file corresponding to the main read-write +* ``virtproxyd-ro.socket`` - the unit file corresponding to the main read-only UNIX socket ``/var/run/libvirt/libvirt-sock-ro``. This socket is recommended to be started on boot by default. -- 2.25.2

2 1

[RFC] Adding docker driver to libvirt
by nshirokovskiy 16 Apr '20

16 Apr '20

Hi, all. Does it make sense to add such a driver? I can't say I have a big picture of docker functionality in mind but at least container lifecycle management and container networking are common to both. Nikolay

7 10

[PATCH] qemuDomainDefPostParse: Fail if unable to fill machine type
by Michal Privoznik 16 Apr '20

16 Apr '20

Previously, we used virCapabilitiesDomainDataLookup() to fill machine type in post parse callback if none was provided in the domain XML. If machine type couldn't be filled in an error was reported. After 4a4132b4625 we've changed it to virQEMUCapsGetPreferredMachine() which returns NULL, but we no longer report an error and proceed with the post parse callbacks processing. This may lead to a crash because the code later on assumes def->os.machine is not NULL. Fixes: 4a4132b4625 Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- src/qemu/qemu_domain.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c index 91e234d644..98ffd23a71 100644 --- a/src/qemu/qemu_domain.c +++ b/src/qemu/qemu_domain.c @@ -4973,6 +4973,14 @@ qemuDomainDefPostParse(virDomainDefPtr def, if (!def->os.machine) { const char *machine = virQEMUCapsGetPreferredMachine(qemuCaps, def->virtType); + if (!machine) { + virReportError(VIR_ERR_INVALID_ARG, + _("could not get preferred machine for %s type=%s"), + def->emulator, + virDomainVirtTypeToString(def->virtType)); + return -1; + } + def->os.machine = g_strdup(machine); } -- 2.25.3

2 1

Re: [libvirt-php] libvirt_domain_interface_addresses causing segfault
by Fernando Casas Schössow 16 Apr '20

16 Apr '20

I think I found the problem and it seems to affect only Windows guests. I'm not sure about the cause tough. Possible causes: 1- Network interface names containing white spaces. 2- One of the interfaces not reporting a MAC address. As an example here is the output of the equivalent virsh command for a Windows guest: Name MAC address Protocol Address ------------------------------------------------------------------------------- Ethernet 2 52:54:00:99:b5:62 ipv6 fe80::71fd:2467:8755:cb0b%13/64 Ethernet 2 52:54:00:99:b5:62 ipv4 192.168.0.77/26 Loopback Pseudo-Interface 1 ipv6 ::1/128 Loopback Pseudo-Interface 1 ipv4 127.0.0.1/8 isatap.{974B556C-9BAF-4A84-A1B1-9D1FDABEC29B} 00:00:00:00:00:00 ipv6 fe80::5efe:192.168.7.21%12/128 Please note the name containing white spaces: "Ethernet 2", "Loopback Pseudo-Interface 1". And also interface "Loopback Pseudo-Interface 1" not reporting a MAC address. Hope this additional information helps. Thanks. Fernando On mié, abr 15, 2020 at 11:41 PM, Fernando Casas Schössow <casasfernando(a)outlook.com> wrote: > Hi, > > While executing libvirt_domain_interface_addresses() with the > qemu-agent running in the guest as the source, the function causes > PHP to segfault. If I change the source to either dhcp or arp, the > function executes correctly. > > Example: > > $netdetails = libvirt_domain_interface_addresses($vmres, 0); <-- > executes correctly (dhcp source) > $netdetails = libvirt_domain_interface_addresses($vmres, 1); <-- > segfault (qemu agent source) > $netdetails = libvirt_domain_interface_addresses($vmres, 2); <-- > executes correctly (arp source) > > I tested the equivalent function using virsh against the same host > and it executes correctly with any source. > I have a php-cgi core file that I can share if that may help on > finding the problem. > > gdb output: > > GNU gdb (Debian 9.1-2) 9.1 > Copyright (C) 2020 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > <http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. > Type "show copying" and "show warranty" for details. > This GDB was configured as "x86_64-linux-gnu". > Type "show configuration" for configuration details. > For bug reporting instructions, please see: > <http://www.gnu.org/software/gdb/bugs/>. > Find the GDB manual and other documentation resources online at: > <http://www.gnu.org/software/gdb/documentation/>. > > For help, type "help". > Type "apropos word" to search for commands related to "word"... > Reading symbols from /usr/bin/php-cgi... > (No debugging symbols found in /usr/bin/php-cgi) > [New LWP 2594] > [Thread debugging using libthread_db enabled] > Using host libthread_db library > "/lib/x86_64-linux-gnu/libthread_db.so.1". > Core was generated by `php-cgi index.php'. > Program terminated with signal SIGSEGV, Segmentation fault. > #0 __strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:85 > 85 ../sysdeps/x86_64/multiarch/../strlen.S: No such file or directory. > (gdb) bt > #0 __strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:85 > #1 0x000055c6a4ceacd2 in add_assoc_string_ex () > #2 0x00007f4d36175253 in ?? () from > /usr/lib/php/20180731/libvirt-php.so > #3 0x000055c6a4d6b477 in execute_ex () > #4 0x000055c6a4d705c7 in zend_execute () > #5 0x000055c6a4ce8ed4 in zend_execute_scripts () > #6 0x000055c6a4c8be38 in php_execute_script () > #7 0x000055c6a4b53da8 in ?? () > #8 0x00007f4d39efce0b in __libc_start_main (main=0x55c6a4b51cf0, > argc=2, argv=0x7fff35718588, init=<optimized out>, fini=<optimized > out>, > rtld_fini=<optimized out>, stack_end=0x7fff35718578) at > ../csu/libc-start.c:308 > #9 0x000055c6a4b544ca in _start () > > > System information: > > OS: Debian Bullseye > PHP version (fast cgi): 7.3.15 > Libvirt PHP version: 0.5.5 > Libvirt version: 6.0.0 > > KVM host libvirt version: 5.9.0 > > If you need any other information please let me know. > > Thanks. > > Fernando

2 4

FYI: upstream bug reporting now using https://gitlab.com/libvirt
by Daniel P. Berrangé 16 Apr '20

16 Apr '20

In keeping with our general aim to consolidate libvirt project infrastructure services on GitLab, we now wish to have issues for upstream libvirt projects reported on the appropriate https://gitlab.com/libvirt/ repository issue tracker. For further details see: https://libvirt.org/bugs.html Bugs against OS distro provided binary packages should continue to be filed against the OS distros' own bug trackers unless the problem is known to also affect current upstream libvirt versions. Note that as part of this change, the "Virtualization Tools" component on bugzilla.redhat.com has been updated to remove the ability to file new bugs against libvirt related components. Existing bugs there still exist in bugzilla, but new bugs can only be filed against gitlab.com. Over time we hope to triage old bugs and close those that are either invalid, or those not likely to be addressed given current maintainer resources available. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|

1 0

Re: [libvirt-php] libvirt_domain_interface_addresses() only returns only on IP address for NICs with multiple IPs
by Fernando Casas Schössow 16 Apr '20

16 Apr '20

Forgot to add the output of the equivalent virsh command for the same VM: Name MAC address Protocol Address ------------------------------------------------------------------------------- lo 00:00:00:00:00:00 ipv4 127.0.0.1/8 lo 00:00:00:00:00:00 ipv6 ::1/128 eth0 52:54:00:12:b9:22 ipv4 192.168.7.31/26 eth0 52:54:00:12:b9:22 ipv6 fe80::5054:ff:fe12:b922/64 eth1 52:54:00:8e:b0:35 ipv4 192.168.1.34/24 eth1 52:54:00:8e:b0:35 ipv6 fe80::5054:ff:fe8e:b035/64 Thanks, Fernando On jue, abr 16, 2020 at 12:58 AM, Fernando Casas Schössow <casasfernando(a)outlook.com> wrote: > Hi, > > While using the function libvirt_domain_interface_addresses() with > qemu guest agent as the source, for interfaces with more than one IP > address, the function will only return one IP. > > Example code: > > $netdetails = libvirt_domain_interface_addresses($vmres, 2); > foreach ($netdetails as $nic) { > print_r($nic); > } > > > Example output: > > Array > ( > [name] => eth0 > [hwaddr] => 52:54:00:12:b9:22 > [naddrs] => 2 > [addrs] => Array > ( > [addr] => fe80::5054:ff:fe12:b922 > [prefix] => 64 > [type] => 1 > ) > > ) > Array > ( > [name] => eth1 > [hwaddr] => 52:54:00:8e:b0:35 > [naddrs] => 2 > [addrs] => Array > ( > [addr] => fe80::5054:ff:fe8e:b035 > [prefix] => 64 > [type] => 1 > ) > > ) > > As you can see for this guest the function returns two interfaces > (eth0 and eth1). For both interfaces naddrs => 2 which is correct > because both interfaces have an ipv4 and an ipv6 address but the > addrs array only contains the ipv6 address information while the ipv4 > address information is missing. > > System information: > > OS: Debian Bullseye > PHP version (fast cgi): 7.3.15 > Libvirt PHP version: 0.5.5 > Libvirt version: 6.0.0 > > KVM host libvirt version: 5.9.0 > > If you need any other information please let me know. > > Thanks. > > Fernando

2 1

[PATCH v2] qemu: Revoke access to mirror on failed blockcopy
by Michal Privoznik 16 Apr '20

16 Apr '20

When preparing to do a blockcopy, the mirror image is modified so that QEMU can access it. For instance, the mirror has seclabels set, if it is a NVMe disk it is detached from the host and so on. And usually, the restore is done upon successful finish of the blockcopy operation. But, if something fails then we need to explicitly revoke the access to the mirror image (and thus reattach NVMe disk back to the host). Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1822538 Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- diff to v1: - Fix call of qemuDomainStorageSourceChainAccessRevoke() so that it is called even if data = crdata = NULL. src/qemu/qemu_driver.c | 21 +++++++++++++-------- 1 file changed, 13 insertions(+), 8 deletions(-) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 31f199fdef..dfe0adaad8 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -17950,6 +17950,7 @@ qemuDomainBlockCopyCommon(virDomainObjPtr vm, virDomainDiskDefPtr disk = NULL; int ret = -1; bool need_unlink = false; + bool need_revoke = false; g_autoptr(virQEMUDriverConfig) cfg = virQEMUDriverGetConfig(driver); const char *format = NULL; bool mirror_reuse = !!(flags & VIR_DOMAIN_BLOCK_COPY_REUSE_EXT); @@ -18124,6 +18125,7 @@ qemuDomainBlockCopyCommon(virDomainObjPtr vm, if (qemuDomainStorageSourceChainAccessAllow(driver, vm, mirror) < 0) goto endjob; + need_revoke = true; if (blockdev) { if (mirror_reuse) { @@ -18232,14 +18234,17 @@ qemuDomainBlockCopyCommon(virDomainObjPtr vm, endjob: if (ret < 0 && - virDomainObjIsActive(vm) && - (data || crdata)) { - qemuDomainObjEnterMonitor(driver, vm); - if (data) - qemuBlockStorageSourceChainDetach(priv->mon, data); - if (crdata) - qemuBlockStorageSourceAttachRollback(priv->mon, crdata->srcdata[0]); - ignore_value(qemuDomainObjExitMonitor(driver, vm)); + virDomainObjIsActive(vm)) { + if (data || crdata) { + qemuDomainObjEnterMonitor(driver, vm); + if (data) + qemuBlockStorageSourceChainDetach(priv->mon, data); + if (crdata) + qemuBlockStorageSourceAttachRollback(priv->mon, crdata->srcdata[0]); + ignore_value(qemuDomainObjExitMonitor(driver, vm)); + } + if (need_revoke) + qemuDomainStorageSourceChainAccessRevoke(driver, vm, mirror); } if (need_unlink && virStorageFileUnlink(mirror) < 0) VIR_WARN("%s", _("unable to remove just-created copy target")); -- 2.25.3

2 1

[libvirt] [PATCH] qemu: fix hang in p2p + xbzrle compression + parallel migration
by Lin Ma 16 Apr '20

16 Apr '20

When we do parallel migration, The multifd-channels migration parameter needs to be set on the destination side as well before incoming migration URI, unless we accept the default number of connections(2). Usually, This can be correctly handled by libvirtd. But in this case if we use p2p + xbzrle compression without parameter '--comp-xbzrle-cache', qemuMigrationParamsDump returns too early, The corresponding migration parameter will not be set on the destination side, It results QEMU hangs. Reproducer: virsh migrate --live --p2p --comp-methods xbzrle \ --parallel --parallel-connections 3 GUEST qemu+ssh://dsthost/system or virsh migrate --live --p2p --compressed \ --parallel --parallel-connections 3 GUEST qemu+ssh://dsthost/system Signed-off-by: Lin Ma <lma(a)suse.com> --- src/qemu/qemu_migration_params.c | 1 - 1 file changed, 1 deletion(-) diff --git a/src/qemu/qemu_migration_params.c b/src/qemu/qemu_migration_params.c index dd5e2ce1b6..810199370f 100644 --- a/src/qemu/qemu_migration_params.c +++ b/src/qemu/qemu_migration_params.c @@ -630,7 +630,6 @@ qemuMigrationParamsDump(qemuMigrationParamsPtr migParams, if (migParams->compMethods == 1ULL << QEMU_MIGRATION_COMPRESS_XBZRLE && !migParams->params[QEMU_MIGRATION_PARAM_XBZRLE_CACHE_SIZE].set) { *flags |= VIR_MIGRATE_COMPRESSED; - return 0; } for (i = 0; i < QEMU_MIGRATION_COMPRESS_LAST; ++i) { -- 2.23.0

2 1