qemu no-shutdown feature in libvirt
by Luna Xu
Hi developers,
Thanks for developing and maintaining such a great tool. I'm new and
I'm trying to use the no-shutdown feature of qemu with libvirt. I've
confirmed with the user list that currently there's no such feature in
libvirt that supports what I want to do, so I'm posting here and see
if anyone is aware of any existing project that can achieve this or
anything under development to avoid re-implementing the wheel. Here is
what I'm doing on qemu:
When I start a VM with the qemu command I can specify the -no-shutdown
flag so that my qemu process doesn't quit even if I shutdown the VM
from the inside (issue shutdown or halt command inside VM). The VM is
shutdown but the qemu process is not killed so that the jobs I
submitted before for example backup (drive-backup) can continue to run
even after VM gets shutdown by the user, and I'm able to check the
status of the job through qmp commands (by communicating with the qemu
process).
Is anyone aware of any project that is currently implementing this
functionality? Thanks for reading.
Thanks,
Luna
4 years
[PATCH] qemu_conf: Fix double free problem for cfg->firmwares
by Tuguoyi
cfg->firmwares still points to the original memory address after being
freed by virFirmwareFreeList(). As cfg get freed, it will be freed again
even if cfg->nfirmwares=0 which eventually lead to crash.
The patch fix it by setting cfg->firmwares to NULL explicitly after
virFirmwareFreeList() returns
Signed-off-by: Tuguoyi <tu.guoyi(a)h3c.com>
---
src/qemu/qemu_conf.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c
index 83de26a..98593b5 100644
--- a/src/qemu/qemu_conf.c
+++ b/src/qemu/qemu_conf.c
@@ -832,6 +832,7 @@ virQEMUDriverConfigLoadNVRAMEntry(virQEMUDriverConfigPtr cfg,
VIR_AUTOSTRINGLIST fwList = NULL;
virFirmwareFreeList(cfg->firmwares, cfg->nfirmwares);
+ cfg->firmwares = NULL;
if (qemuFirmwareFetchConfigs(&fwList, privileged) < 0)
return -1;
--
2.7.4
--
Best regards,
Guoyi
4 years
[libvirt][PATCH v1 0/1] support system default memory policy with numatune
by Luyao Zhong
Hi libvirt experts,
---------- what does this patch support ----------
This patch seeks the support of system default memory policy
when numatune is configured. Before this patch, numatune only
has three memory modes: static, interleave and prefered.
These memory policies are ultimately set by mbind() system call.
Memory policy could be 'hard coded' into the kernel, but none of
above policies fit our requirment under this case. mbind() support
default memory policy, but it requires a NULL nodemask. So obviously
setting allowed memory nodes is cgroups' mission. That means if
'default' mode is specified in numatune, numatune config will be
completely cgroups setting, which restricting the memory
nodes allowed for each vcpu thread in different cells.
<numatune>
<memory mode="default" nodeset="1-4,^3" migratable="yes" />
<memnode cellid="0" mode="default" nodeset="1"/>
<memnode cellid="2" mode="default" nodeset="2"/>
</numatune>
Above is current design, we introduce a new "migratable" attribute and
a new option "default" for "mode" attribute in numatune.
---------- summary of discussion ----------
But at the beginning in RFC[1], Martin Kletzander and I got a consensus,
just introducing a new "migratable" attribute to indicates that we rely
on operating system to operate memory policy.
<numatune>
<memory mode="strict" nodeset="1-4,^3" migratable="yes" />
<memnode cellid="0" mode="strict" nodeset="1"/>
<memnode cellid="2" mode="preferred" nodeset="2"/>
</numatune>
the mode will be ignored, and libvirt will not set those memory policy
related configs in qemu command line.
Then initial patch got Peter Krempa's comments[2], if I understood it
correctly, that means config should not be ignored directly (I just stated
in document it will be ignored), it should be rejected in code and output
log to lead user correct the config.
But when I updated the patch, I found I had to add a new option 'default'
for mode attribute since its default value is "strict", if not setting
mode it will still be formatted to "strict" at the end. So I sent a RFC[3]
again, but unfortunately it sunk into the mail sea.
(sorry for the RFC/PATCH title changing)
[1] https://www.redhat.com/archives/libvir-list/2020-August/msg00960.html
[2] https://www.redhat.com/archives/libvir-list/2020-October/msg00396.html
[3] https://www.redhat.com/archives/libvir-list/2020-October/msg01033.html
mbind(): https://man7.org/linux/man-pages/man2/mbind.2.html
Though we have "migratable" in current implementation, actually we can
support this feauture without it since we have "default" mode, so is
"migratable" still neccessary?
Thanks for your patience to read this. Appreciate if you could give comments.
Regards,
Luyao
Luyao Zhong (1):
support system default memory policy with numatune
docs/formatdomain.rst | 12 ++++-
docs/schemas/domaincommon.rng | 7 +++
include/libvirt/libvirt-domain.h | 1 +
src/conf/numa_conf.c | 50 ++++++++++++++++++-
src/conf/numa_conf.h | 2 +
src/libvirt_private.syms | 1 +
src/qemu/qemu_command.c | 7 ++-
src/qemu/qemu_process.c | 25 ++++++++++
src/util/virnuma.c | 3 ++
.../numatune-memory-migratable.args | 34 +++++++++++++
...atune-memory-migratable.x86_64-latest.args | 35 +++++++++++++
.../numatune-memory-migratable.xml | 33 ++++++++++++
tests/qemuxml2argvtest.c | 2 +
...matune-memory-migratable.x86_64-latest.xml | 40 +++++++++++++++
.../numatune-memory-migratable.xml | 39 +++++++++++++++
tests/qemuxml2xmltest.c | 1 +
16 files changed, 288 insertions(+), 4 deletions(-)
create mode 100644 tests/qemuxml2argvdata/numatune-memory-migratable.args
create mode 100644 tests/qemuxml2argvdata/numatune-memory-migratable.x86_64-latest.args
create mode 100644 tests/qemuxml2argvdata/numatune-memory-migratable.xml
create mode 100644 tests/qemuxml2xmloutdata/numatune-memory-migratable.x86_64-latest.xml
create mode 100644 tests/qemuxml2xmloutdata/numatune-memory-migratable.xml
--
2.25.4
4 years
[PATCH] coding-style: Document 80 chars limit for line length
by Michal Privoznik
The idea is to have it like a soft limit: if possible then break
lines, if not then have a long line instead of some creative
approach.
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
docs/coding-style.rst | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/docs/coding-style.rst b/docs/coding-style.rst
index cfd7b16638..813128bfb6 100644
--- a/docs/coding-style.rst
+++ b/docs/coding-style.rst
@@ -131,7 +131,7 @@ around operators and keywords:
indent-libvirt()
{
- indent -bad -bap -bbb -bli4 -br -ce -brs -cs -i4 -l75 -lc75 \
+ indent -bad -bap -bbb -bli4 -br -ce -brs -cs -i4 -l80 -lc80 \
-sbi4 -psl -saf -sai -saw -sbi4 -ss -sc -cdw -cli4 -npcs -nbc \
--no-tabs "$@"
}
@@ -141,6 +141,18 @@ further, by piping it through ``expand -i``, since some leading
TABs can get through. Usually they're in macro definitions or
strings, and should be converted anyhow.
+The recommended length for lines is 80 characters, but common sense
+should prevail. It may get tricky around some names (because of how
+Libvirt constructs names for functions/enums/etc.)
+
+::
+
+ foo(
+ arg1, arg2
+ ); // Bad
+ foo(arg1,
+ arg2); // Good
+
Libvirt requires a C99 compiler for various reasons. However, most
of the code base prefers to stick to C89 syntax unless there is a
compelling reason otherwise. For example, it is preferable to use
--
2.26.2
4 years
regression in meson build, AC_PATH_PROG lost
by Olaf Hering
autoconf allows to specify the path to a runtime binary that is not required during build via an environment variable:
AC_PATH_PROG([PARTED], [parted], [], [$LIBVIRT_SBIN_PATH])
meson lacks such essential feature. As a result the package build environment needs to have more packages than necessary installed. This excessive list also pushes libvirt closer to the end of the build dependency chain.
Was this considered while the buildsystem was switched to meson?
Since meson does not support environment variables it seems the only way to address this is to introduce an option in meson_options.txt for each runtime executable.
Will such change be accepted?
Olaf
4 years
[PATCH for 7.0.0 v1 00/26] Introduce virtio memory support
by Michal Privoznik
Available also here:
https://gitlab.com/MichalPrivoznik/libvirt/-/commits/virtio_mem/
There are new virtio variants of pc-dimm and nvdimm devices. This is the
first attempt to impalement support for them in libvirt.
Thanks to David Hildenbrand for his valuable input!
Michal Prívozník (26):
viruuid: Rework virUUIDIsValid()
internal.h: Introduce VIR_IS_POW2()
docs: Fix nvdimm example wrt to <uuid/>
domain_conf: Check NVDIMM UUID in ABI stability
qemu_domain_address: Reformat qemuDomainAssignS390Addresses()
conf: Require nvdimm path in validate step
domain_conf: Fix virDomainMemoryModel type
virDomainMemorySourceDefFormat: Utilize virXMLFormatElement()
virDomainMemoryTargetDefFormat: Utilize virXMLFormatElement()
qemu: Move mem validation into post parse validator
conf: Move some of virDomainMemoryDef members into a union
conf: Introduce virtio-pmem <memory/> model
qemu_capabilities: Introduce QEMU_CAPS_DEVICE_VIRTIO_{P}MEM_PCI
qemu_validate: Require virtio-mem device for mem model virtio
security: Relabel virtio mem
qemu: Allow virtio-pmem in CGroups
qemu: Create virtio-pmem in domain namespace
qemu_command: Move dimm into qemuBuildDeviceAddressStr()
qemu: Build command line for virtio-pmem
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
qemu: Refresh the actual size of virtio-mem on monitor reconnect
virsh: Simplify @flags handing in cmdSetmem() and cmdSetmaxmem()
virsh: Introduce --virtio to setmem
docs/formatdomain.rst | 70 +++-
docs/schemas/domaincommon.rng | 16 +
src/conf/domain_conf.c | 372 ++++++++++++++----
src/conf/domain_conf.h | 38 +-
src/internal.h | 10 +
src/libvirt_private.syms | 2 +
src/qemu/qemu_alias.c | 59 ++-
src/qemu/qemu_capabilities.c | 4 +
src/qemu/qemu_capabilities.h | 2 +
src/qemu/qemu_cgroup.c | 43 +-
src/qemu/qemu_command.c | 172 +++++---
src/qemu/qemu_command.h | 5 +-
src/qemu/qemu_domain.c | 99 +++--
src/qemu/qemu_domain.h | 1 +
src/qemu/qemu_domain_address.c | 98 +++--
src/qemu/qemu_domain_address.h | 3 +-
src/qemu/qemu_driver.c | 198 +++++++++-
src/qemu/qemu_hotplug.c | 22 +-
src/qemu/qemu_hotplug.h | 5 +
src/qemu/qemu_monitor.c | 37 ++
src/qemu/qemu_monitor.h | 27 ++
src/qemu/qemu_monitor_json.c | 94 +++--
src/qemu/qemu_monitor_json.h | 5 +
src/qemu/qemu_namespace.c | 19 +-
src/qemu/qemu_process.c | 52 ++-
src/qemu/qemu_validate.c | 78 ++--
src/security/security_apparmor.c | 35 +-
src/security/security_dac.c | 48 ++-
src/security/security_selinux.c | 48 ++-
src/security/virt-aa-helper.c | 22 +-
src/util/virrandom.c | 2 +-
src/util/viruuid.c | 17 +-
src/util/viruuid.h | 2 +-
.../caps_4.1.0.x86_64.xml | 1 +
.../caps_4.2.0.x86_64.xml | 1 +
.../caps_5.0.0.x86_64.xml | 1 +
.../caps_5.1.0.x86_64.xml | 2 +
.../caps_5.2.0.x86_64.xml | 2 +
...mory-hotplug-virtio-mem.x86_64-latest.args | 53 +++
.../memory-hotplug-virtio-mem.xml | 78 ++++
...ory-hotplug-virtio-pmem.x86_64-latest.args | 45 +++
.../memory-hotplug-virtio-pmem.xml | 54 +++
tests/qemuxml2argvtest.c | 2 +
...emory-hotplug-virtio-mem.x86_64-latest.xml | 1 +
...mory-hotplug-virtio-pmem.x86_64-latest.xml | 1 +
tests/qemuxml2xmltest.c | 3 +
tools/virsh-domain.c | 138 ++++++-
47 files changed, 1703 insertions(+), 384 deletions(-)
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 100644 tests/qemuxml2argvdata/memory-hotplug-virtio-pmem.x86_64-latest.args
create mode 100644 tests/qemuxml2argvdata/memory-hotplug-virtio-pmem.xml
create mode 120000 tests/qemuxml2xmloutdata/memory-hotplug-virtio-mem.x86_64-latest.xml
create mode 120000 tests/qemuxml2xmloutdata/memory-hotplug-virtio-pmem.x86_64-latest.xml
--
2.26.2
4 years
[PATCH 00/21] move checks from parse functions to post parse
by Daniel Henrique Barboza
Hi,
This started as a simple NVDIMM change, then I realized there
is a Gitlab work item for it [1], so I took the extra
mile and did a bit more. I'll copy/paste here the motivation
for this kind of change, provided by Cole in [1]:
-----
The code that handles domain/VM XML parsing (virDomainDefParseXML in
src/domain/domain_conf.c) has various validation checks sprinkled
within it. Many of these checks should be moved out of the parse step
and into virDomainDefPostParse, so they can be shared by various
places in the code that build a domain definition without XML, such
as converting from native vmware/virtualbox/xen formats.
-----
There are still checks to be moved after this work. If this is
accepted I'll update [1] with more details/tips about how to proceed
with the remaining checks.
Some g_auto* cleanups were done along the way.
[1] https://gitlab.com/libvirt/libvirt/-/issues/7
Daniel Henrique Barboza (21):
domain_conf.c: move NVDIMM 'labelsize' check to post parse
domain_conf.c: use g_autofree in 'dev' in virDomainDefParseBootXML()
domain_conf.c: modernize virDomainDefBootOrderPostParse()
domain_conf.c: move boot related timeouts check to post parse
domain_conf.c: do not leak 'video' in virDomainDefParseXML()
domain_conf.c: move primary video check to
virDomainDefPostParseVideo()
domain_conf.c: use g_autoptr() with virDomainVideoDefPtr
domain_conf.c: move QXL attributes check to
virDomainVideoDefPostParse()
virstorageencryption.h: add AUTOPTR_CLEANUP_FUNC for
virStorageEncryptionPtr
domain_conf: modernize virDomainDiskDefParseXML()
domain_conf.c: move vendor, product and tray checks to post parse
domain_conf.c: move smartcard address check to post parse
domain_conf.c: modernize virDomainSmartcardDefParseXML
domain_conf.c: remove 'error' label in virDomainDefTunablesParse()
domain_conf.c: move duplicate blkio path check to post parse
domain_conf.c: move virDomainPCIControllerOpts checks to post parse
domain_conf.c: move pci-root/pcie-root address check to post parse
domain_conf.c: modernize virDomainControllerDefParseXML()
domain_conf.c: modernize virDomainDefControllersParse()
domain_conf.c: use VIR_ERR_CONFIG_UNSUPPORTED in post parse
domain_conf.c: move idmapEntry checks to post parse
src/conf/domain_conf.c | 762 ++++++++++--------
src/conf/domain_conf.h | 4 +
src/util/virstorageencryption.h | 1 +
tests/qemuxml2argvdata/pci-root-address.err | 2 +-
.../pseries-default-phb-numa-node.err | 2 +-
.../video-multiple-primaries.err | 1 +
.../video-multiple-primaries.xml | 32 +
tests/qemuxml2argvtest.c | 5 +
8 files changed, 451 insertions(+), 358 deletions(-)
create mode 100644 tests/qemuxml2argvdata/video-multiple-primaries.err
create mode 100644 tests/qemuxml2argvdata/video-multiple-primaries.xml
--
2.26.2
4 years
[PATCH v2] lxc: Cleanup after failed startup
by Michal Privoznik
If starting an container fails, the virLXCProcessStop() is
called. But since vm->def->id is not set until libvirt_lxc is
spawned (the domain's ID is PID of that process),
virLXCProcessStop() returns early as virDomainObjIsActive()
returns false. But doing so leaves behind resources reserved for
the containers during the startup process. Most notably, hostdevs
are not re-attached to the host, the domain's transient XML is
not removed, etc.
To resolve this, virLXCProcessCleanup() is called in this case.
However, it is modified to accept @flags which allows caller to
run only specific cleanups (depending how far in container
creation the failure occurred). There is plenty of cleanups which
don't need this guard because either they detect a NULL pointer
or try to release an unique resource.
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
v2 of:
https://www.redhat.com/archives/libvir-list/2020-November/msg00317.html
diff to v1:
- Run some cleanups selectively
src/lxc/lxc_process.c | 52 ++++++++++++++++++++++++++++++++++---------
1 file changed, 41 insertions(+), 11 deletions(-)
diff --git a/src/lxc/lxc_process.c b/src/lxc/lxc_process.c
index c5a710fc3f..5763052e99 100644
--- a/src/lxc/lxc_process.c
+++ b/src/lxc/lxc_process.c
@@ -145,18 +145,27 @@ lxcProcessRemoveDomainStatus(virLXCDriverConfigPtr cfg,
}
+typedef enum {
+ VIR_LXC_PROCESS_CLEANUP_RELEASE_SECLABEL = (1 << 0),
+ VIR_LXC_PROCESS_CLEANUP_RESTORE_SECLABEL = (1 << 1),
+ VIR_LXC_PROCESS_CLEANUP_REMOVE_TRANSIENT = (1 << 2),
+} virLXCProcessCleanupFlags;
+
/**
* virLXCProcessCleanup:
* @driver: pointer to driver structure
* @vm: pointer to VM to clean up
* @reason: reason for switching the VM to shutoff state
+ * @flags: allows to run selective cleanups only
*
- * Cleanout resources associated with the now dead VM
- *
+ * Clean out resources associated with the now dead VM.
+ * If @flags is zero then whole cleanup process is done,
+ * otherwise only selected sections are run.
*/
static void virLXCProcessCleanup(virLXCDriverPtr driver,
virDomainObjPtr vm,
- virDomainShutoffReason reason)
+ virDomainShutoffReason reason,
+ unsigned int flags)
{
size_t i;
virLXCDomainObjPrivatePtr priv = vm->privateData;
@@ -164,8 +173,11 @@ static void virLXCProcessCleanup(virLXCDriverPtr driver,
virLXCDriverConfigPtr cfg = virLXCDriverGetConfig(driver);
virConnectPtr conn = NULL;
- VIR_DEBUG("Cleanup VM name=%s pid=%d reason=%d",
- vm->def->name, (int)vm->pid, (int)reason);
+ VIR_DEBUG("Cleanup VM name=%s pid=%d reason=%d flags=0x%x",
+ vm->def->name, (int)vm->pid, (int)reason, flags);
+
+ if (flags == 0)
+ flags = ~0;
/* now that we know it's stopped call the hook if present */
if (virHookPresent(VIR_HOOK_DRIVER_LXC)) {
@@ -177,9 +189,15 @@ static void virLXCProcessCleanup(virLXCDriverPtr driver,
NULL, xml, NULL);
}
- virSecurityManagerRestoreAllLabel(driver->securityManager,
- vm->def, false, false);
- virSecurityManagerReleaseLabel(driver->securityManager, vm->def);
+ if (flags & VIR_LXC_PROCESS_CLEANUP_RESTORE_SECLABEL) {
+ virSecurityManagerRestoreAllLabel(driver->securityManager,
+ vm->def, false, false);
+ }
+
+ if (flags & VIR_LXC_PROCESS_CLEANUP_RELEASE_SECLABEL) {
+ virSecurityManagerReleaseLabel(driver->securityManager, vm->def);
+ }
+
/* Clear out dynamically assigned labels */
if (vm->def->nseclabels &&
vm->def->seclabels[0]->type == VIR_DOMAIN_SECLABEL_DYNAMIC) {
@@ -258,7 +276,9 @@ static void virLXCProcessCleanup(virLXCDriverPtr driver,
NULL, xml, NULL);
}
- virDomainObjRemoveTransientDef(vm);
+ if (flags & VIR_LXC_PROCESS_CLEANUP_REMOVE_TRANSIENT)
+ virDomainObjRemoveTransientDef(vm);
+
virObjectUnref(cfg);
virObjectUnref(conn);
}
@@ -904,7 +924,7 @@ int virLXCProcessStop(virLXCDriverPtr driver,
}
cleanup:
- virLXCProcessCleanup(driver, vm, reason);
+ virLXCProcessCleanup(driver, vm, reason, 0);
return 0;
}
@@ -1198,6 +1218,7 @@ int virLXCProcessStart(virConnectPtr conn,
g_autoptr(virCgroup) selfcgroup = NULL;
int status;
g_autofree char *pidfile = NULL;
+ unsigned int stopFlags = 0;
if (virCgroupNewSelf(&selfcgroup) < 0)
return -1;
@@ -1265,6 +1286,7 @@ int virLXCProcessStart(virConnectPtr conn,
VIR_DEBUG("Setting current domain def as transient");
if (virDomainObjSetDefTransient(driver->xmlopt, vm, NULL) < 0)
goto cleanup;
+ stopFlags |= VIR_LXC_PROCESS_CLEANUP_REMOVE_TRANSIENT;
/* Run an early hook to set-up missing devices */
if (virHookPresent(VIR_HOOK_DRIVER_LXC)) {
@@ -1312,11 +1334,13 @@ int virLXCProcessStart(virConnectPtr conn,
goto cleanup;
}
virDomainAuditSecurityLabel(vm, true);
+ stopFlags |= VIR_LXC_PROCESS_CLEANUP_RELEASE_SECLABEL;
VIR_DEBUG("Setting domain security labels");
if (virSecurityManagerSetAllLabel(driver->securityManager,
vm->def, NULL, false, false) < 0)
goto cleanup;
+ stopFlags |= VIR_LXC_PROCESS_CLEANUP_RESTORE_SECLABEL;
VIR_DEBUG("Setting up consoles");
for (i = 0; i < vm->def->nconsoles; i++) {
@@ -1525,7 +1549,13 @@ int virLXCProcessStart(virConnectPtr conn,
}
if (rc != 0) {
virErrorPreserveLast(&err);
- virLXCProcessStop(driver, vm, VIR_DOMAIN_SHUTOFF_FAILED);
+ if (virDomainObjIsActive(vm)) {
+ virLXCProcessStop(driver, vm, VIR_DOMAIN_SHUTOFF_FAILED);
+ } else {
+ /* virLXCProcessStop() is NOP if the container is not active.
+ * If there was a failure whilst creating it, cleanup manually. */
+ virLXCProcessCleanup(driver, vm, VIR_DOMAIN_SHUTOFF_FAILED, stopFlags);
+ }
}
virCommandFree(cmd);
for (i = 0; i < nttyFDs; i++)
--
2.26.2
4 years
[libvirt PATCH 0/9] qemu: report guest disks informations
by marcandre.lureau＠redhat.com
From: Marc-André Lureau <marcandre.lureau(a)redhat.com>
Hi,
The following series extends virDomainGetGuestInfo to report disk informations
provided by the new QGA "guest-get-disks" command in QEMU 5.2.
Please review,
Fixes:
https://bugzilla.redhat.com/show_bug.cgi?id=1899527
Marc-André Lureau (9):
qemu_agent: rename qemuAgentDiskInfo->qemuAgentDiskAddress
qemu_agent: export qemuAgentDiskAddressFree & add g_auto
qemu_agent: factor out qemuAgentGetDiskAddress
util: json: add virJSONValueObjectGetStringArray convenience
qemu: use virJSONValueObjectGetStringArray
qemu_agent: add qemuAgentGetDisks
domain: add disk informations to virDomainGetGuestInfo
qemu_driver: report guest disk informations
virsh: add --disk informations to guestinfo command
include/libvirt/libvirt-domain.h | 1 +
src/libvirt-domain.c | 17 +++
src/libvirt_private.syms | 1 +
src/qemu/qemu_agent.c | 182 +++++++++++++++++++++++--------
src/qemu/qemu_agent.h | 25 ++++-
src/qemu/qemu_driver.c | 103 ++++++++++++++++-
src/qemu/qemu_monitor_json.c | 34 +-----
src/util/virjson.c | 30 +++++
src/util/virjson.h | 1 +
tests/qemuagenttest.c | 111 +++++++++++++++++++
tools/virsh-domain.c | 6 +
11 files changed, 430 insertions(+), 81 deletions(-)
--
2.29.0
4 years
[PATCH 00/24] qemu: Prepare for QAPIfied 'object-add'
by Peter Krempa
Prepare libvirt for the changes proposed for qemu:
https://www.redhat.com/archives/libvir-list/2020-November/msg01580.html
Patches 1-12/24 are pure refactors and can be merged right away.
Patches 13-15/24 can be merged, but the justification will be weak
without the rest.
Patches 16-22/24 are RFC until the qemu bits are merged.
Patch 23/24 adds capabilities and needs to be udpated later
Patch 24/24 is not to be merged!
Note that patch 23/24 is intentionally missing from the mailing list
posting as it's just a dump of QEMU capabilities from newest qemu. No
need to litter the list with it.
Also note that after the last patch tests will fail. See that patch for
the reason.
Fetch the full series at:
git fetch https://gitlab.com/pipo.sk/libvirt.git object-add-qapi-3
Peter Krempa (24):
qemuMonitorJSONSetMigrationParams: Take double pointer for @params
qemuMonitorSetMigrationCapabilities: Take double pointer for @caps
qemuMonitorJSONSetMigrationCapabilities: Refactor cleanup
testQemuMonitorJSONqemuMonitorJSONGetMigrationCapabilities: refactor
cleanup
qemuMonitorJSONAddObject: Take double pointer for @props
qemuMonitorJSONMakeCommandInternal: Clear @arguments when stolen
qemuMonitorAddObject: Fix semantics of @alias
qemuMonitorAddObject: Refactor cleanup
util: json: Replace virJSONValueObjectSteal by
virJSONValueObjectRemoveKey
tests: qemuxml2argv: Don't check whether -netdev was QAPIfied
repeatedly
qemuBuildChrChardevStr: Rename 'flags' to 'cdevflags'
testCompareXMLToArgvValidateSchema: Populate autoNodeset
qemu: command: Generate commandline of 'masterKey0' secret via JSON
qemu: command: Generate commandline of 'sev0' sev-guest object via
JSON
qemu: command: Generate commandline of iothread objects JSON
qemu: capabilities: Introduce QEMU_CAPS_OBJECT_QAPIFIED
tests: qemuxml2argv: Validate generation of JSON props for object-add
qemu: command: Introduce raw JSON passthrough for '-object' for
testing
qemu: monitor: Make wrapping of 'props' of 'object-add' optional
qemuMonitorCreateObjectPropsWrap: Open-code in
qemuBuildMemoryBackendProps
qemu: monitor: Don't add 'props' wrapper if qemu has
QEMU_CAPS_OBJECT_QAPIFIED
qemumonitorjsontest: Remove bomb guarding object-add
qemu: capabilities: Add 6.0 capabilities with qapified object-add
[DONTMERGE] qemuxml2argvtest: Force QMP validation with latest caps
src/qemu/qemu_capabilities.c | 2 +
src/qemu/qemu_capabilities.h | 1 +
src/qemu/qemu_command.c | 332 +-
src/qemu/qemu_migration_params.c | 22 +-
src/qemu/qemu_monitor.c | 121 +-
src/qemu/qemu_monitor.h | 8 +-
src/qemu/qemu_monitor_json.c | 57 +-
src/qemu/qemu_monitor_json.h | 6 +-
src/util/virjson.c | 29 +-
src/util/virqemu.c | 48 +-
src/util/virqemu.h | 3 +-
.../domaincapsdata/qemu_6.0.0-q35.x86_64.xml | 197 +
.../domaincapsdata/qemu_6.0.0-tcg.x86_64.xml | 203 +
tests/domaincapsdata/qemu_6.0.0.x86_64.xml | 197 +
.../caps_6.0.0.x86_64.replies | 32021 ++++++++++++++++
.../caps_6.0.0.x86_64.xml | 3205 ++
tests/qemumonitorjsontest.c | 40 +-
...v-missing-platform-info.x86_64-2.12.0.args | 2 +-
.../launch-security-sev.x86_64-2.12.0.args | 2 +-
tests/qemuxml2argvtest.c | 44 +-
20 files changed, 36202 insertions(+), 338 deletions(-)
create mode 100644 tests/domaincapsdata/qemu_6.0.0-q35.x86_64.xml
create mode 100644 tests/domaincapsdata/qemu_6.0.0-tcg.x86_64.xml
create mode 100644 tests/domaincapsdata/qemu_6.0.0.x86_64.xml
create mode 100644 tests/qemucapabilitiesdata/caps_6.0.0.x86_64.replies
create mode 100644 tests/qemucapabilitiesdata/caps_6.0.0.x86_64.xml
--
2.28.0
4 years
