- Devel - libvirt List Archives

[PATCH 0/7] qemu: snapshot: Fix removal of output files on failure
by Peter Krempa 17 Jun '21

17 Jun '21

Peter Krempa (7): qemuSnapshotPrepareDiskExternal: Move temp variables into the block using them qemuSnapshotPrepareDiskExternal: Avoid condition squashing qemuSnapshotPrepareDiskExternal: Reject creation of block devices sooner qemuSnapshotPrepareDiskExternal: Enforce match between snapshot type and existing file type qemuSnapshotPrepareDiskExternal: Refactor existing file check conf: snapshot: rename variable holding memory snapshot file location qemuSnapshotCreateActiveExternal: Don't unlink memory snapshot image if it was existing before src/conf/snapshot_conf.c | 10 +++---- src/conf/snapshot_conf.h | 2 +- src/qemu/qemu_snapshot.c | 56 +++++++++++++++++++++++++++++----------- 3 files changed, 47 insertions(+), 21 deletions(-) -- 2.31.1

2 8

[PATCH 0/8] security_dac: Couple of cleanups
by Michal Privoznik 17 Jun '21

17 Jun '21

I've started looking at how we could fix the following bug: https://bugzilla.redhat.com/show_bug.cgi?id=1786222 Long story short, we are not using just async signal safe functions in a forked off thread that runs chown() from within the domain's private namespace. Hence, we ran into a deadlock (although the case of the bug the deadlock is in glibc not gluster). So far I don't have any fix, but I have couple of cleanups. Michal Prívozník (8): security_dac: Use g_autofree security_dac: Introduce virSecurityDACChownItemFree() security_dac: Introduce g_autoptr for virSecurityDACChownList security_dac: Don't check for !priv in virSecurityDACSetOwnershipInternal() virSecurityDACSetOwnershipInternal: Drop dead code virSecurityDACSetOwnershipInternal: Don't overwrite @path argument virSecurityDACSetOwnershipInternal: Fix WIN32 code qemu: Deduplicate code in qemuSecurityChownCallback() src/qemu/qemu_driver.c | 22 +--- src/security/security_dac.c | 201 ++++++++++++++------------------ src/security/security_manager.h | 13 ++- 3 files changed, 98 insertions(+), 138 deletions(-) -- 2.31.1

2 10

Libvirt hit a issue when do VM migration
by 梁朝军 17 Jun '21

17 Jun '21

Hi All, Who can give me a help? I hit another issue when do vm migration? Libvirt throw out the error like below "libvirt: Domain Config error : unsupported configuration: vcpu enable order of vCPU '0' differs between source and destination definitions” The cup information is defined VM domain on source host is like: <vcpu placement='static'>2</vcpu> <vcpus> <vcpu id='0' enabled='yes' hotpluggable='no' order='1'/> <vcpu id='1' enabled='yes' hotpluggable='no' order='2'/> </vcpus> <cputune> <vcpupin vcpu='0' cpuset='42'/> <vcpupin vcpu='1' cpuset='43'/> </cputune> The distinction host previews generate xml for VM like: <vcpu placement='static'>2</vcpu> <vcpus> <vcpu id='0' enabled='yes' hotpluggable='no' order='1'/> <vcpu id='1' enabled='yes' hotpluggable='no' order='2'/> </vcpus> <cputune> <vcpupin vcpu='0' cpuset='42'/> <vcpupin vcpu='1' cpuset='43'/> </cputune> What’t wrong with it? Or I missing some actions in configurations regarding the migration Thanks a lot !

2 1

[PATCH 1/1] domain_validate.c: fix virDomainDefFSValidate() when fs->dst is NULL
by Daniel Henrique Barboza 17 Jun '21

17 Jun '21

Commit 56dcdec1ac81 ("conf: reject duplicate virtiofs tags") added validation code to reject duplicated virtiofs tags. But the <target> element is not always present, meaning that fs->dst can be NULL at that point. If there is no "<target>" tag then the validation will fail in virHashAddEntry() because fs->dst will be NULL. This is tested in qemuxml2xml vhost-user-fs-sock, which is since then not passing: 1020) QEMU XML-2-XML-inactive vhost-user-fs-sock ... Expected result code=0 but received code=1 FAILED 1021) QEMU XML-2-XML-active vhost-user-fs-sock ... Expected result code=0 but received code=1 FAILED The '<target>' tag is not mandatory, so let's consider that fs->dst being NULL is a feasible scenario an adapt virDomainDefFSValidate() accordingly. Signed-off-by: Daniel Henrique Barboza <danielhb413(a)gmail.com> --- src/conf/domain_validate.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/conf/domain_validate.c b/src/conf/domain_validate.c index 9422b00964..cf8b43b845 100644 --- a/src/conf/domain_validate.c +++ b/src/conf/domain_validate.c @@ -1504,7 +1504,7 @@ virDomainDefFSValidate(const virDomainDef *def) for (i = 0; i < def->nfss; i++) { const virDomainFSDef *fs = def->fss[i]; - if (fs->fsdriver != VIR_DOMAIN_FS_DRIVER_TYPE_VIRTIOFS) + if (fs->fsdriver != VIR_DOMAIN_FS_DRIVER_TYPE_VIRTIOFS || !fs->dst) continue; if (virHashHasEntry(dsts, fs->dst)) { -- 2.31.1

3 3

[libvirt PATCH] qemu_hotplug: don't forget to add hostdev interfaces to the interface list
by Laine Stump 17 Jun '21

17 Jun '21

Originally qemuDomainAttachNetDevice() would wait until the cleanup at the very end of the function to add newly hotplugged interfaces to the domain's nets list. commit 7b8bec4560 modified it to add the new interface to the nets list earlier (but not all the way at the beginning of the function either, because there are some operations (PCI address assignment in particular) that need the new device to not yet be visible in the domaindef). But hostdev interfaces short-circuit past most of the body of qemuDomainAttachNetDevice() (since none of it applies to hostdev interfaces). In the past that was okay, but since the line that adds the new interface to the domaindef's nets list is in that "most of the body", after that commit hotplugged hostdev interfaces are no longer being properly added to the domaindef nets list, so they don't show up in the status XML or the virsh domiflist output. It really *is* important to add interfaces to the nets list earlier, so we can't revert commit 7b8bec4560, and we also can't move the insert to common code *earlier* in the function, so instead this patch duplicates the VIR_APPEND_ELEMENT_COPY() just before the code path for hostdev interfaces jumps to cleanup. Resolves: https://bugzilla.redhat.com/1972991 Fixes: 7b8bec45601b6570f6a7413e94d291986d2663f1 (any other tags I should add?) Signed-off-by: Laine Stump <laine(a)redhat.com> --- src/qemu/qemu_hotplug.c | 17 ++++++++++++++--- 1 file changed, 14 insertions(+), 3 deletions(-) diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c index 0640cdd9f7..e323edc2e8 100644 --- a/src/qemu/qemu_hotplug.c +++ b/src/qemu/qemu_hotplug.c @@ -1230,10 +1230,21 @@ qemuDomainAttachNetDevice(virQEMUDriver *driver, /* This is really a "smart hostdev", so it should be attached * as a hostdev (the hostdev code will reach over into the * netdev-specific code as appropriate), then also added to - * the nets list (see cleanup:) if successful. + * the nets list if successful. */ - ret = qemuDomainAttachHostDevice(driver, vm, - virDomainNetGetActualHostdev(net)); + if (qemuDomainAttachHostDevice(driver, vm, + virDomainNetGetActualHostdev(net)) < 0) { + goto cleanup; + } + if (VIR_APPEND_ELEMENT_COPY(vm->def->nets, vm->def->nnets, net) < 0) + goto cleanup; + + /* the rest of the setup doesn't apply to hostdev interfaces, so + * we can skip straight to the cleanup (nothing there applies to + * hostdev interfaces either, but it might in the future, so we + * may as well be consistent) + */ + ret = 0; goto cleanup; } -- 2.31.1

2 1

[libvirt PATCHv2 0/2] Small virtiofs fixes (virtio-fs epopee)
by Ján Tomko 17 Jun '21

17 Jun '21

Ján Tomko (2): conf: move filesystem target validation conf: require target for external virtiofsd docs/formatdomain.rst | 1 + docs/kbase/virtiofs.rst | 1 + src/conf/domain_conf.c | 6 ------ src/conf/domain_validate.c | 10 ++++++++++ tests/qemuxml2argvdata/vhost-user-fs-sock.xml | 1 + 5 files changed, 13 insertions(+), 6 deletions(-) -- 2.31.1

3 6

[PATCH] qemu: Don't set NVRAM label when creating it
by Michal Privoznik 16 Jun '21

16 Jun '21

The NVRAM label is set in qemuSecuritySetAllLabel(). There's no need to set its label upfront. In fact, setting it twice creates an imbalance because it's unset only once which mangles seclabel remembering. However, plain removal of the qemuSecurityDomainSetPathLabel() undoes the fix for the original bug (when dynamic ownership is off then the NVRAM is not created with cfg->user and cfg->group but as root:root). Therefore, we have to switch to virFileOpenAs() and pass cfg->user and cfg->group and VIR_FILE_OPEN_FORCE_OWNER flag. There's no need to pass VIR_FILE_OPEN_FORCE_MODE because the file will be created with the proper mode. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1969347 Fixes: bcdaa91a27b5b2d103535270a6a287efe6cd8bfb Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- src/qemu/qemu_process.c | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c index c37687f249..2b03b0ab98 100644 --- a/src/qemu/qemu_process.c +++ b/src/qemu/qemu_process.c @@ -4538,16 +4538,19 @@ qemuPrepareNVRAM(virQEMUDriver *driver, goto cleanup; } - if ((dstFD = qemuDomainOpenFile(driver, vm, loader->nvram, - O_WRONLY | O_CREAT | O_EXCL, - NULL)) < 0) + if ((dstFD = virFileOpenAs(loader->nvram, + O_WRONLY | O_CREAT | O_EXCL, + S_IRUSR | S_IWUSR, + cfg->user, cfg->group, + VIR_FILE_OPEN_FORCE_OWNER)) < 0) { + virReportSystemError(-dstFD, + _("Failed to create file '%s'"), + loader->nvram); goto cleanup; + } created = true; - if (qemuSecurityDomainSetPathLabel(driver, vm, loader->nvram, false) < 0) - goto cleanup; - do { char buf[1024]; -- 2.31.1

2 1

[PATCH 0/3] Apparmor: Add profiles for hypervisor daemons
by Jim Fehlig 16 Jun '21

16 Jun '21

This series is a first attempt at creating apparmor profiles for the modular daemons. It introduces profiles for virt{lxc,qemu,xen}d, which AFAIK are the only hypervisors supported by apparmor. The profiles are copies of the libvirtd profile, with all the non hypervisor-specific rules removed. E.g. qemu related rules removed from the virtxend profile and vice versa. Likely more rules could be trimmed from the xen and lxc profiles. I'll need to investigate how the apparmor tools can help identify such rules. So far things look okay with apparmor and modular daemons. One issue I have yet to resolve is interaction between dnsmasq and libvirt_leaseshelper. Trying to start e.g. the default network results in the following apparmor denial type=AVC msg=audit(1623791662.885:655): apparmor="DENIED" operation="exec" profile="/usr/sbin/dnsmasq" name="/usr/lib/libvirt_leaseshelper" pid=8154 comm="sh" requested_mask="x" denied_mask="x" fsuid=0 ouid=0 Perhaps some apparmor experts can make better sense of that error than me :-). It would be nice to avoid adjusting the dnsmasq profile, which is not in the libvirt project, if possible. I noticed a few more denial messages that I _think_ are unrelated to modular daemons, which also need further investigation type=AVC msg=audit(1623797296.856:593): apparmor="DENIED" operation="open" profile="virt-aa-helper" name="/etc/ssl/openssl.cnf" pid=6511 comm="virt-aa-helper" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 type=AVC msg=audit(1623797296.856:594): apparmor="DENIED" operation="open" profile="virt-aa-helper" name="/etc/libnl/classid" pid=6511 comm="virt-aa-helper" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 t type=AVC msg=audit(1623797297.732:623): apparmor="DENIED" operation="open" profile="libvirt-481c2d22-76d5-404b-a4b0-dc2069c7e19e" name="/etc/libnl/classid" pid=6539 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=107 ouid=0 Jim Fehlig (3): Apparmor: Add profile for virtqemud Apparmor: Add profile for virtlxcd Apparmor: Add profile for virtxend src/security/apparmor/libvirt-lxc | 4 +- src/security/apparmor/libvirt-qemu | 6 + src/security/apparmor/meson.build | 3 + src/security/apparmor/usr.sbin.virtlxcd.in | 89 +++++++++++++ src/security/apparmor/usr.sbin.virtqemud.in | 135 ++++++++++++++++++++ src/security/apparmor/usr.sbin.virtxend.in | 78 +++++++++++ 6 files changed, 314 insertions(+), 1 deletion(-) create mode 100644 src/security/apparmor/usr.sbin.virtlxcd.in create mode 100644 src/security/apparmor/usr.sbin.virtqemud.in create mode 100644 src/security/apparmor/usr.sbin.virtxend.in -- 2.31.1

2 7

Migration capabilities is not reset after the libvirtd service restart
by Huangzhichao 16 Jun '21

16 Jun '21

Hi Everyone, We find migration capabilities is not reset after restarting libvirtd, it would cause problem in the following scene: Version: libvirt release 7.4.0 Step 1. create a VM and query migration capabilities, mark the return content as "Cap A". Step 2. stop the source libvirtd service when executing live migration, then migration failed. Step 3. restart the source libvirtd service, then query migration capabilities, mark the return content as "Cap B". "Cap A" is different from "Cap B", because the source libvirtd service would set migration capabilities when executing live migration. We find that there is a patch may cause this problem. Link: https://libvirt.org/git/?p=libvirt.git;a=commitdiff;h=a1dec315c9ad87a198245… When we roll back this patch, "CAP A" would be the same as "CAP B". Do you have any suggestion ? Thanks.

2 1

[libvirt PATCH 0/3] Small virtiofs fixes (virtio-fs epopee)
by Ján Tomko 16 Jun '21

16 Jun '21

Today we fix a bug: https://bugzilla.redhat.com/show_bug.cgi?id=1969232 and an issue: https://gitlab.com/libvirt/libvirt/-/issues/178 Ján Tomko (3): conf: require target for external virtiofsd docs: fix filesystem schema indentation conf: reject duplicate virtiofs tags docs/formatdomain.rst | 1 + docs/kbase/virtiofs.rst | 1 + docs/schemas/domaincommon.rng | 32 +++++++++---------- src/conf/domain_conf.c | 2 +- src/conf/domain_validate.c | 30 +++++++++++++++++ tests/qemuxml2argvdata/vhost-user-fs-sock.xml | 1 + 6 files changed, 50 insertions(+), 17 deletions(-) -- 2.31.1

2 6