[PATCH v3 00/15] Introduce virtio-mem <memory/> model
by Michal Privoznik
v3 of:
https://listman.redhat.com/archives/libvir-list/2021-February/msg00961.html
diff to v2:
- Dropped code that forbade use of virtio-mem and memballoon at the same
time;
- This meant that I had to adjust memory accounting,
qemuDomainSetMemoryFlags() - see patches 11/15 and 12/15 which are new.
- Fixed small nits raised by Peter in his review of v2
Michal Prívozník (15):
virhostmem: Introduce virHostMemGetTHPSize()
qemu_process: Deduplicate code in qemuProcessNeedHugepagesPath()
qemu_process: Drop needless check in
qemuProcessNeedMemoryBackingPath()
qemu_capabilities: Introduce QEMU_CAPS_DEVICE_VIRTIO_MEM_PCI
conf: Introduce virtio-mem <memory/> model
qemu: Build command line for virtio-mem
qemu: Wire up <memory/> live update
qemu: Wire up MEMORY_DEVICE_SIZE_CHANGE event
Introduce MEMORY_DEVICE_SIZE_CHANGE event
qemu: Refresh the actual size of virtio-mem on monitor reconnect
qemu: Account for both memballoon and virtio-mem
qemuDomainSetMemoryFlags: Take virtio-mem into consideration
virsh: Introduce update-memory-device command
news: document recent virtio memory addition
kbase: Document virtio-mem
NEWS.rst | 7 +
docs/formatdomain.rst | 45 +++-
docs/kbase/index.rst | 4 +
docs/kbase/memorydevices.rst | 150 +++++++++++
docs/kbase/meson.build | 1 +
docs/manpages/virsh.rst | 30 +++
docs/schemas/domaincommon.rng | 16 ++
examples/c/misc/event-test.c | 17 ++
include/libvirt/libvirt-domain.h | 23 ++
src/conf/domain_conf.c | 115 ++++++++-
src/conf/domain_conf.h | 15 ++
src/conf/domain_event.c | 84 +++++++
src/conf/domain_event.h | 10 +
src/conf/domain_validate.c | 39 +++
src/libvirt_private.syms | 5 +
src/qemu/qemu_alias.c | 10 +-
src/qemu/qemu_capabilities.c | 2 +
src/qemu/qemu_capabilities.h | 1 +
src/qemu/qemu_command.c | 13 +-
src/qemu/qemu_domain.c | 50 +++-
src/qemu/qemu_domain.h | 1 +
src/qemu/qemu_domain_address.c | 38 ++-
src/qemu/qemu_driver.c | 233 +++++++++++++++++-
src/qemu/qemu_hotplug.c | 18 ++
src/qemu/qemu_hotplug.h | 5 +
src/qemu/qemu_monitor.c | 37 +++
src/qemu/qemu_monitor.h | 27 ++
src/qemu/qemu_monitor_json.c | 97 ++++++--
src/qemu/qemu_monitor_json.h | 5 +
src/qemu/qemu_process.c | 118 ++++++++-
src/qemu/qemu_validate.c | 8 +
src/remote/remote_daemon_dispatch.c | 30 +++
src/remote/remote_driver.c | 32 +++
src/remote/remote_protocol.x | 15 +-
src/remote_protocol-structs | 7 +
src/security/security_apparmor.c | 1 +
src/security/security_dac.c | 2 +
src/security/security_selinux.c | 2 +
src/util/virhostmem.c | 63 +++++
src/util/virhostmem.h | 3 +
tests/domaincapsmock.c | 9 +
.../caps_5.1.0.x86_64.xml | 1 +
.../caps_5.2.0.x86_64.xml | 1 +
.../caps_6.0.0.x86_64.xml | 1 +
...mory-hotplug-virtio-mem.x86_64-latest.args | 49 ++++
.../memory-hotplug-virtio-mem.xml | 67 +++++
tests/qemuxml2argvtest.c | 1 +
...emory-hotplug-virtio-mem.x86_64-latest.xml | 1 +
tests/qemuxml2xmltest.c | 1 +
tools/virsh-domain.c | 169 +++++++++++++
50 files changed, 1612 insertions(+), 67 deletions(-)
create mode 100644 docs/kbase/memorydevices.rst
create mode 100644 tests/qemuxml2argvdata/memory-hotplug-virtio-mem.x86_64-latest.args
create mode 100644 tests/qemuxml2argvdata/memory-hotplug-virtio-mem.xml
create mode 120000 tests/qemuxml2xmloutdata/memory-hotplug-virtio-mem.x86_64-latest.xml
--
2.26.2
3 years, 5 months
[PATCH 0/7] qemu: snapshot: Fix removal of output files on failure
by Peter Krempa
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
3 years, 5 months
[PATCH 0/8] security_dac: Couple of cleanups
by Michal Privoznik
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
3 years, 5 months
Libvirt hit a issue when do VM migration
by 梁朝军
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 !
3 years, 5 months
[PATCH 1/1] domain_validate.c: fix virDomainDefFSValidate() when fs->dst is NULL
by Daniel Henrique Barboza
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 years, 5 months
[libvirt PATCH] qemu_hotplug: don't forget to add hostdev interfaces to the interface list
by Laine Stump
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
3 years, 5 months
[libvirt PATCHv2 0/2] Small virtiofs fixes (virtio-fs epopee)
by Ján Tomko
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 years, 5 months
[PATCH] qemu: Don't set NVRAM label when creating it
by Michal Privoznik
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
3 years, 5 months
[PATCH 0/3] Apparmor: Add profiles for hypervisor daemons
by Jim Fehlig
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
3 years, 5 months
Migration capabilities is not reset after the libvirtd service restart
by Huangzhichao
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=a1dec315c9ad87a1982...
When we roll back this patch, "CAP A" would be the same as "CAP B".
Do you have any suggestion ?
Thanks.
3 years, 5 months
