January 2021 - Devel - libvirt List Archives

[PATCH] spec: Add the man pages of split daemons
by Han Han 16 Jan '21

16 Jan '21

Fix the errors from commit a7cafa7bc2 when build RPMs from spec file: error: Installed (but unpackaged) file(s) found: /usr/share/man/man8/virtinterfaced.8.gz /usr/share/man/man8/virtlxcd.8.gz /usr/share/man/man8/virtnetworkd.8.gz /usr/share/man/man8/virtnodedevd.8.gz /usr/share/man/man8/virtnwfilterd.8.gz /usr/share/man/man8/virtproxyd.8.gz /usr/share/man/man8/virtqemud.8.gz /usr/share/man/man8/virtsecretd.8.gz /usr/share/man/man8/virtstoraged.8.gz /usr/share/man/man8/virtvboxd.8.gz /usr/share/man/man8/virtxend.8.gz Signed-off-by: Han Han <hhan(a)redhat.com> --- libvirt.spec.in | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/libvirt.spec.in b/libvirt.spec.in index b5892987cf..4389bef406 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -1581,6 +1581,18 @@ exit 0 %{_mandir}/man8/virtlogd.8* %{_mandir}/man8/virtlockd.8* %{_mandir}/man8/virtproxyd.8* +%{_mandir}/man8/virtxend.8* +%{_mandir}/man8/virtvzd.8* +%{_mandir}/man8/virtvboxd.8* +%{_mandir}/man8/virtstoraged.8* +%{_mandir}/man8/virtsecretd.8* +%{_mandir}/man8/virtqemud.8* +%{_mandir}/man8/virtnwfilterd.8* +%{_mandir}/man8/virtnodedevd.8* +%{_mandir}/man8/virtnetworkd.8* +%{_mandir}/man8/virtlxcd.8* +%{_mandir}/man8/virtinterfaced.8* +%{_mandir}/man8/virtbhyved.8* %{_mandir}/man7/virkey*.7* %files daemon-config-network -- 2.29.2

1 0

[PATCH] network: explicitly set the MTU of the bridge device.
by Laine Stump 15 Jan '21

15 Jan '21

In the past, the MTU of libvirt virtual network bridge devices was implicitly set by setting the MTU of the "dummy tap device" (which was being added in order to force a particular MAC address from the bridge). But the dummy tap device was removed in commit ee6c936fbb (libvirt-6.8.0), and so the mtu setting in the network is ignored. The solution is, of course, to explicitly set the bridge device MTU when it is created. Note that any guest interface with a larger MTU that is attached will cause the bridge to (temporarily) assume the larger MTU, but it will revert to the bridge's own MTU when that device is deleted (this is not due to anything libvirt does; it's just how Linux host bridges work). Resolves: https://bugzilla.redhat.com/1913561 Signed-off-by: Laine Stump <laine(a)redhat.com> ee6c936fbbo-set-mtu Signed-off-by: Laine Stump <laine(a)redhat.com> --- src/network/bridge_driver.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/network/bridge_driver.c b/src/network/bridge_driver.c index b7c604eaea..519a473995 100644 --- a/src/network/bridge_driver.c +++ b/src/network/bridge_driver.c @@ -2336,6 +2336,9 @@ networkStartNetworkVirtual(virNetworkDriverStatePtr driver, /* Set bridge options */ + if (def->mtu && virNetDevSetMTU(def->bridge, def->mtu) < 0) + goto error; + /* delay is configured in seconds, but virNetDevBridgeSetSTPDelay * expects milliseconds */ -- 2.29.2

2 2

[PATCH 00/20] handle AWOL SR-IOV VF hostdevs during domain lifetime
by Daniel Henrique Barboza 15 Jan '21

15 Jan '21

Hi, This series is an attempt to fix https://gitlab.com/libvirt/libvirt/-/issues/72. The root issue is that, for obvious reasons, virPCIDeviceNew() requires the device to exist in the host (i.e. the config file must be present in sysfs). The unexpected absence of the device (e.g. removing the VFs from the host while a domain was using them) will make virPCIDeviceNew() return -1 in several code paths, and the effects in Libvirt can be bothersome. Patch 20 will explain it in greater detail. Changing virPCIDeviceNew() internals to not fail in this scenario would be a herculean refactor of innocent code that doesn't have anything to do with the problem. My approach here is to check if the device exists in the sysfs in key places, keeping the default virPCIDeviceNew() behavior intact. I mentioned this is patch 20 but to emphasize: this is NOT an attempt to implement surprise hostdev hotunplug support in Libvirt. Removing SR-IOVs VFs used by any domain is still not cool and should be avoided. But after this series, Libvirt can at least fall on its feet if this situation happens. The series was tested using a Mellanox MT28800 card in a Power 9 server. Daniel Henrique Barboza (20): virpci, domain_audit: use virPCIDeviceAddressAsString() qemu, lxc: move NodeDeviceGetPCIInfo() function to domain_driver.c domain_driver.c: use PCI address with virDomainDriverNodeDeviceGetPCIInfo() virpci.c: simplify virPCIDeviceNew() signature virpci: introduce virPCIDeviceExists() virhostdev.c: virHostdevGetPCIHostDevice() now reports missing device security_selinux.c: modernize set/restore hostdev subsys label functions security_dac.c: modernize hostdev label set/restore functions dac, selinux: skip setting/restoring label for absent PCI devices libvirt-nodedev.c: remove return value from virNodeDeviceFree() qemu_driver.c: modernize qemuNodeDeviceReAttach() libxl_driver.c: modernize libxlNodeDeviceReAttach() virsh-domain.c: modernize cmdDetachDevice() virhostdev.c: add virHostdevIsPCIDevice() helper qemu_cgroup.c: skip absent PCI devices in qemuTeardownHostdevCgroup() virpci.c: use virPCIDeviceAddressPtr in virPCIDeviceListFindIndex() virpci.c: use virPCIDeviceAddressPtr in virPCIDeviceListFind() virpci.c: use virPCIDeviceAddressPtr in virPCIDeviceListSteal() virpci.c: use virPCIDeviceAddressPtr in virPCIDeviceListDel() virhostdev.c: remove missing PCI devs from hostdev manager include/libvirt/libvirt-nodedev.h | 2 +- src/conf/domain_audit.c | 6 +- src/datatypes.h | 2 + src/hypervisor/domain_driver.c | 30 ++++++++++ src/hypervisor/domain_driver.h | 4 ++ src/hypervisor/virhostdev.c | 88 ++++++++++++++++++++++------ src/hypervisor/virhostdev.h | 2 + src/libvirt-nodedev.c | 15 +++-- src/libvirt_private.syms | 3 + src/libxl/libxl_driver.c | 87 ++++++++-------------------- src/node_device/node_device_udev.c | 11 ++-- src/qemu/qemu_cgroup.c | 10 ++++ src/qemu/qemu_domain_address.c | 5 +- src/qemu/qemu_driver.c | 81 +++++++------------------- src/security/security_apparmor.c | 3 +- src/security/security_dac.c | 61 ++++++++------------ src/security/security_selinux.c | 66 +++++++++------------ src/security/virt-aa-helper.c | 6 +- src/util/virnetdev.c | 3 +- src/util/virnvme.c | 5 +- src/util/virpci.c | 93 ++++++++++++++---------------- src/util/virpci.h | 14 ++--- tests/virhostdevtest.c | 3 +- tests/virpcitest.c | 35 ++++++++--- tools/virsh-domain.c | 18 ++---- 25 files changed, 325 insertions(+), 328 deletions(-) -- 2.26.2

1 21

[PATCHv3 0/4] netlink: Extract common code to simplify netlink functions
by Shi Lei 15 Jan '21

15 Jan '21

V2 here: https://www.redhat.com/archives/libvir-list/2021-January/msg00174.html Since V2: - Fix the post process of virNetlinkTalk(). If virNetlinkTalk() succeeds and we got an NLMSG_ERROR packet with the zero-value error, it should be regarded as a success. - Several fixes for the pointer of resp in virNetlinkTalk(). - Minor fixes according to coding style. Shi Lei (4): netlink: Remove invalid flags(NLM_F_CREATE and NLM_F_EXCL) for RTM_DELLINK netlink: Minor changes for macros NETLINK_MSG_[NEST_START|NEST_END|PUT] netlink: Introduce macro NETLINK_MSG_APPEND to wrap nlmsg_append netlink: Introduce a helper function to simplify netlink functions src/util/virnetlink.c | 321 +++++++++++++++++++----------------------- src/util/virnetlink.h | 27 +--- 2 files changed, 149 insertions(+), 199 deletions(-) -- 2.25.1

2 8

Release of libvirt-7.0.0
by Jiri Denemark 15 Jan '21

15 Jan '21

The 7.0.0 release of both libvirt and libvirt-python is tagged and signed tarballs and source RPMs are available at https://libvirt.org/sources/ https://libvirt.org/sources/python/ Thanks everybody who helped with this release by sending patches, reviewing, testing, or providing any other feedback. Your work is greatly appreciated. * Project governance * Formal handover of release tarball signing Starting from libvirt-6.6 the release tarballs are signed by Jiří Denemark. Releases starting with 7.0 contain a note from the previous maintainer Daniel Veillard offically handing over the signing of packages so that the transition can be verified. * New features * nodedev: Add node device driver support for AP devices Add support for detecting and listing Adjunct Processor(AP) cards, AP queues and AP matrix devices (which are capable of MDEV) of a KVM host system in libvirt node device driver with correct object relationships. * qemu: Allow control of ``qcow2`` metadata cache In specific usecases such as when massive storage images are used it's possible to achieve better performance by increasing the metadata cache size. The new knob allows advanced users setting the size according to qemu's documentation to suit their image. * conf: Add support for keeping TPM emulator state Currently, swtpm TPM state file is removed when a transient domain is powered off or undefined. Add per-TPM emulator option ``persistent_state`` for keeping TPM state. * Improvements * qemu: Discourage users from polling ``virDomainGetBlockJobInfo`` for block job completion Document that waiting for events is a more robust solution. * secret: Relax XML schema for the ``usage`` name of a ``secret`` Various bits of documentation of how to use libvirt with RBD volumes used an usage name which would not pass the XML validation. Relax the requirement to make such XMLs valid. * virnetdevopenvswitch: Various improvements The code that handles ``<interface type='vhostuser'/>`` was given various improvements. So far, libvirt assumed vhostuser interfaces are handled exclusively by OpenVSwitch and refused to start a guest if it was not so. Now a guest can be started successfully even if the interface is created by some other tool (e.g. ``dpdk-testpmd``). Also, the code that detects the interface name was adapted to new versions of OpenVSwitch and thus can detect name more reliably. * qemu: Report guest disks informations in ``virDomainGetGuestInfo`` Libvirt is now able to report disks and filesystems from the guest's perspective (using guest agent). And with sufficiently new guest agent (5.3.0 or newer) the API also handles disks on CCW bus. * Bug fixes * qemu: Fix logic bug in inactive snapshot deletion This release fixes a bug introduced in libvirt-6.9 where libvirt's snapshot metadata would not be deleted on successful snapshot deletion. * qemu: Fix VMs with ``<iotune>`` on an empty cdrom Specifying ``<iotune>`` for an empty cdrom would prevent the VM from starting as qemu doesn't accept the tuning for an empty drive. We now postpone setting the parameters until a new media is inserted. * Avoid taking extra host memory when launching pSeries guests Under certain conditions, pSeries guests were being launched with more RAM than it was specified in the domain XML by the user. New pSeries domains created with libvirt 7.0.0 will always launch with the right amount of initial memory. Existing guests that migrate from an older libvirt version to 7.0.0 will not be affected by this change. * qemu: Don't cache NUMA caps ``virsh capabilities`` contains ``<topology/>`` section which reports NUMA topology among with amount of free hugepages per each NUMA node. However, these amounts were not updated between calls. * networkGetDHCPLeases: Handle leases with infinite expiry time Since libvirt-6.3.0 it is possible to configure expiry time for DHCP leases. If the expiry time was infinite then ``virsh net-dhcp-leases`` and NSS plugins refused to work. * qemu: Don't prealloc mem for real NVDIMMs If a real life NVDIMM is assigned to a guest via ``<memory model='nvdimm'/>`` then QEMU is no longer instructed to preallocate memory for it. This prevents unnecessary wear on the NVDIMM. * network: Introduce mutex for bridge name generation When new libvirt network is defined or created and the input XML does not contain any bridge name, libvirt generates one. However, it might have happened that the same name would be generated for different networks if two or more networks were defined/created at once. Enjoy. Jirka

1 0

[PATCH 0/6] authz: support authz device and vnc authz
by Zihao Chang 15 Jan '21

15 Jan '21

This patchset aims to support authz device, pass authz device to qemu cmd and support vnc authz. authz device example: <authz mode="simple" index='1' identity='test'/> vnc authz example: <graphics ...> <authz type='sasl' index='1'/> </graphics> Zihao Chang (6): authz: support parsing authz devices authz: support passing authz device to qemu cmd authz: support formating authz to xml authz: support parsing the authz element in vnc authz: support passing sasl acl in vnc to qemu cmd vnc: support authz ACL xml format src/conf/domain_conf.c | 248 +++++++++++++++++++++++++++++++-- src/conf/domain_conf.h | 35 +++++ src/conf/domain_validate.c | 1 + src/conf/virconftypes.h | 6 + src/libvirt_private.syms | 2 + src/qemu/qemu_command.c | 60 +++++++- src/qemu/qemu_domain.c | 1 + src/qemu/qemu_domain_address.c | 2 + src/qemu/qemu_driver.c | 5 + src/qemu/qemu_hotplug.c | 3 + src/qemu/qemu_validate.c | 1 + 11 files changed, 353 insertions(+), 11 deletions(-) -- 2.28.0

2 8

[PATCH 0/2] qemu: Do not Use canonical path for system memory
by Michal Privoznik 15 Jan '21

15 Jan '21

Patch 2/2 is where the actual logic is happening. It is also depending on the following QEMU patch: https://lists.nongnu.org/archive/html/qemu-devel/2021-01/msg01979.html Once merged I'll replace those two occurrences of 'QEMU commit XXX' with proper commit hash. Michal Prívozník (2): qemu_capabilities: Introduce QEMU_CAPS_X_USE_CANONICAL_PATH_FOR_RAMBLOCK_ID qemu: Do not Use canonical path for system memory src/qemu/qemu_capabilities.c | 2 ++ src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 30 ++++++++++++++++--- src/qemu/qemu_command.h | 3 +- src/qemu/qemu_hotplug.c | 2 +- .../caps_4.0.0.aarch64.xml | 1 + .../qemucapabilitiesdata/caps_4.0.0.ppc64.xml | 1 + .../caps_4.0.0.riscv32.xml | 1 + .../caps_4.0.0.riscv64.xml | 1 + .../qemucapabilitiesdata/caps_4.0.0.s390x.xml | 1 + .../caps_4.0.0.x86_64.xml | 1 + .../caps_4.1.0.x86_64.xml | 1 + .../caps_4.2.0.aarch64.xml | 1 + .../qemucapabilitiesdata/caps_4.2.0.ppc64.xml | 1 + .../qemucapabilitiesdata/caps_4.2.0.s390x.xml | 1 + .../caps_4.2.0.x86_64.xml | 1 + .../caps_5.0.0.aarch64.xml | 1 + .../qemucapabilitiesdata/caps_5.0.0.ppc64.xml | 1 + .../caps_5.0.0.riscv64.xml | 1 + .../caps_5.0.0.x86_64.xml | 1 + .../qemucapabilitiesdata/caps_5.1.0.sparc.xml | 1 + .../caps_5.1.0.x86_64.xml | 1 + .../caps_5.2.0.aarch64.xml | 1 + .../qemucapabilitiesdata/caps_5.2.0.ppc64.xml | 1 + .../caps_5.2.0.riscv64.xml | 1 + .../qemucapabilitiesdata/caps_5.2.0.s390x.xml | 1 + .../caps_5.2.0.x86_64.xml | 1 + .../hugepages-memaccess3.x86_64-latest.args | 4 +-- 28 files changed, 56 insertions(+), 8 deletions(-) -- 2.26.2

5 16

[libvirt PATCH v3 0/3] Propose a simple mechanism on how to disable pipeline jobs
by Erik Skultety 14 Jan '21

14 Jan '21

>From time to time it happens that some of the distros for which we run our pipelines break (or the images we pull break). Because we don't have dedicated maintainers for the jobs/runners, we can only employ the best effort approach wrt to making the pipeline green again when we're positive the problem doesn't lie in libvirt. For jobs that are broken for quite some time we should opt to disable them unconditionally unless a volunteer dedicates the time to either fix it or the matter gets fixed on its own in time (e.g. updated container images). v1: https://www.redhat.com/archives/libvir-list/2021-January/msg00573.html v2: https://www.redhat.com/archives/libvir-list/2021-January/msg00672.html Since v2: - renamed all the template jobs according to the review comments - added 'rules' for container jobs as well - fixed the env variable naming inconsistency that somehow made it to the v1 patches Erik Skultety (3): gitlab-ci.yml: Replace template anchors with extends gitlab-ci.yml: Convert only/except to the rules syntax gitlab-ci.yml: Add an explicit env variable to mark a job as broken .gitlab-ci.yml | 164 ++++++++++++++++++++++++++----------------------- 1 file changed, 86 insertions(+), 78 deletions(-) -- 2.29.2

2 4

Re: qmp-shell TUI (was: Re: Call for Google Summer of Code 2021 project ideas)
by Stefan Hajnoczi 14 Jan '21

14 Jan '21

On Wed, Jan 13, 2021 at 01:59:43PM -0500, John Snow wrote: > On 1/13/21 3:53 AM, Stefan Hajnoczi wrote: > > On Tue, Jan 12, 2021 at 9:10 PM John Snow <jsnow(a)redhat.com> wrote: > > 2. Ability to watch QMP activity on a running QEMU process, e.g. even > > when libvirt is directly connected to the monitor. > > > > That *WOULD* be extremely cool, and moves a lot closer to how mitmproxy > works. > > (Actually, mitmproxy could theoretically be taught how to read and > understand QMP traffic, but that's not something I know how to do or would > be prepared to mentor.) > > Is this possible to do in a post-hoc fashion? Let's say you are using > production environment QEMU, how do we attach the QMP listener to it? Or > does this idea require that we start QEMU in a specific fashion with a > second debug socket that qmp-shell can connect to in order to listen? > > ... Or do we engineer qmp-shell to open its own socket that libvirt connects > to ...? Here is the QEMU command-line that libvirt uses on my F33 system: -chardev socket,id=charmonitor,fd=36,server,nowait -mon chardev=charmonitor,id=monitor,mode=control Goals for this feature: 1. No manual steps required for setup. 2. Ability to start/stop monitoring traffic at runtime without restarting QEMU. 3. Available to unprivileged users. I think the easiest way to achieve this is through a new QEMU monitor command. Approaches that come to mind: 1. Add a -mon debug-chardev property and a QMP command to set it at runtime. The debug-chardev receives both monitor input (commands) and output (responses and events). This does not allow MITM, rather it mirrors traffic. 2. Add a chardev-get-fd command that fetches the fd from a chardev and then use the existing chardev-change command to replace the monitor chardev with a chardev connected to qmp-shell. This inserts qmp-shell as a proxy between the QMP client and server. qmp-shell can remove itself again with another chardev-change command. This approach allows MITM. The downside is it assumes the QMP chardev is a file descriptor, so it won't work with all types of chardev. 3. Add a new chardev-proxy type that aggregates 3 chardevs: 1. an origin source chardev, 2. a monitoring sink chardev, and 3. a monitoring source chardev. The data flow is origin <-> monitoring sink <-> monitoring source <-> QMP monitor. qmp-shell creates the monitoring sink (for receiving incoming QMP commands) and monitoring source chardev (for forwarding QMP commands or MITM commands), and then it uses change-chardev to instantiate a chardev-proxy that directs the original libvirt chardev through the monitoring sink and source. This is the most complex but also completely contained within the QEMU chardev layer. In all these approaches qmp-shell uses virsh qemu-monitor-command or an equivalent API to start/stop monitoring a running VM without manual setup steps. Stefan

4 9

[PATCH v2 0/2] qemu: Do not Use canonical path for system memory
by Michal Privoznik 14 Jan '21

14 Jan '21

v2 of: https://www.redhat.com/archives/libvir-list/2021-January/msg00601.html diff to v1: - Added a comment to patch 1/2 per Peter's request. - Replaced 'git describe' commit IDs with just their hashes. The qemu patch is still not merged, so I couldn't replace XXX with actual QEMU commits in 2/2. I'm keeping an eye on the patch and will do that once it's merged. https://lists.nongnu.org/archive/html/qemu-devel/2021-01/msg01979.html Michal Prívozník (2): qemu_capabilities: Introduce QEMU_CAPS_X_USE_CANONICAL_PATH_FOR_RAMBLOCK_ID qemu: Do not Use canonical path for system memory src/qemu/qemu_capabilities.c | 5 ++++ src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 30 ++++++++++++++++--- src/qemu/qemu_command.h | 3 +- src/qemu/qemu_hotplug.c | 2 +- .../caps_4.0.0.aarch64.xml | 1 + .../qemucapabilitiesdata/caps_4.0.0.ppc64.xml | 1 + .../caps_4.0.0.riscv32.xml | 1 + .../caps_4.0.0.riscv64.xml | 1 + .../qemucapabilitiesdata/caps_4.0.0.s390x.xml | 1 + .../caps_4.0.0.x86_64.xml | 1 + .../caps_4.1.0.x86_64.xml | 1 + .../caps_4.2.0.aarch64.xml | 1 + .../qemucapabilitiesdata/caps_4.2.0.ppc64.xml | 1 + .../qemucapabilitiesdata/caps_4.2.0.s390x.xml | 1 + .../caps_4.2.0.x86_64.xml | 1 + .../caps_5.0.0.aarch64.xml | 1 + .../qemucapabilitiesdata/caps_5.0.0.ppc64.xml | 1 + .../caps_5.0.0.riscv64.xml | 1 + .../caps_5.0.0.x86_64.xml | 1 + .../qemucapabilitiesdata/caps_5.1.0.sparc.xml | 1 + .../caps_5.1.0.x86_64.xml | 1 + .../caps_5.2.0.aarch64.xml | 1 + .../qemucapabilitiesdata/caps_5.2.0.ppc64.xml | 1 + .../caps_5.2.0.riscv64.xml | 1 + .../qemucapabilitiesdata/caps_5.2.0.s390x.xml | 1 + .../caps_5.2.0.x86_64.xml | 1 + .../hugepages-memaccess3.x86_64-latest.args | 4 +-- 28 files changed, 59 insertions(+), 8 deletions(-) -- 2.26.2

2 7