[PATCH 0/4] Implement virsh hypervisor-cpu-models
by Boris Fiuczynski
Allows for the query of hypervisor-known CPU models via the simple
command: virsh hypervisor-cpu-models. For the QEMU driver, the models
are queried via the capabilities file. Each model is printed to the
terminal on its own line similar to the cpu-models command, and there
is no order to the listing.
There is a related libvirt-python merge request at
https://gitlab.com/libvirt/libvirt-python/-/merge_requests/159
David Judkovics (4):
libvirt: Introduce virConnectGetHypervisorCPUModelNames public API
remote: Implement virConnectGetHypervisorCPUModelNames
qemu_driver: Implement qemuConnectGetHypervisorCPUModelNames
virsh: Introduce new hypervisor-cpu-models command
docs/manpages/virsh.rst | 20 ++++++++
include/libvirt/libvirt-host.h | 7 +++
src/driver-hypervisor.h | 10 ++++
src/libvirt-host.c | 65 +++++++++++++++++++++++++
src/libvirt_public.syms | 5 ++
src/qemu/qemu_driver.c | 59 +++++++++++++++++++++++
src/remote/remote_daemon_dispatch.c | 62 ++++++++++++++++++++++++
src/remote/remote_driver.c | 52 ++++++++++++++++++++
src/remote/remote_protocol.x | 26 +++++++++-
src/remote_protocol-structs | 16 +++++++
tools/virsh-host.c | 74 +++++++++++++++++++++++++++++
11 files changed, 395 insertions(+), 1 deletion(-)
--
2.47.0
4 months, 3 weeks
[PATCH 0/3] Remove deprecated machines pc-i440fx-2.4 up to pc-i440fx-2.12
by Thomas Huth
While our new auto-disablement of old machine types will only kick
in with the next (v10.1) release, the pc-i440fx-2.* machine types
have been explicitly marked as deprecated via our old deprecation
policy mechanism before (two releases ago), so it should be fine to
remove them now already.
Note that we can not do much additional clean ups on top yet since
the corresponding q35 machines (which share the same compatibility knobs)
are still around and only will be removed for the 10.1 release instead.
So the bigger clean-up can only be done for 10.1, but removing the i440fx
machine types now will still have at least a small benefit of accelerating
our CI a little bit (since we don't have to run tests for these old machine
types anymore).
Thomas Huth (3):
tests/qtest/test-x86-cpuid-compat: Remove tests related to
pc-i440fx-2.3
hw/i386/pc_piix: Remove pc-i440fx-2.4 up to pc-i440fx-2.12
tests/qtest/test-x86-cpuid-compat: Replaced the removed pc-i440fx-2.*
machines
docs/about/deprecated.rst | 7 ---
docs/about/removed-features.rst | 4 +-
docs/interop/firmware.json | 2 +-
hw/i386/pc_piix.c | 95 -----------------------------
tests/qtest/test-x86-cpuid-compat.c | 52 ++++++----------
qemu-options.hx | 10 +--
6 files changed, 25 insertions(+), 145 deletions(-)
--
2.47.1
4 months, 3 weeks
[PATCH 0/1] Support cloning saved VMs
by Felipe Franciosi
Hello!
I have a use case which I'm struggling to support with libvirt:
saving a VM to a file, cloning it (which renames the VM), and restoring it.
My search revealed a number of tutorials for using virt-clone [1], but that
doesn't seem to cover VMs which are _saved_ (only running or paused).
[1] https://github.com/virt-manager/virt-manager/blob/main/virtinst/virtclone.py
In a nutshell, I want to power on a VM and do some setup, then save its full
state to disk (e.g., with virsh save). Finally I want to modify the XML to:
- rename the VM
- change which bridge its NICs are on (while maintaining mac addresses)
- change the disk image to a copy (done while the VM is saved)
But the restore operation fails because of a target domain name check
implemented in virDomainDefCheckABIStabilityFlags(). I've debated how to best
address this and I'm looking for your views.
I suspect this call is there for a reason (which may still be relevant),
although the name is clearly not part of the ABI; it's the host identifier for
that domain and not guest-visible. My first stab at this is therefore just to
drop this check (patch attached).
I'm open to suggestions, for example by plumbing through a flag which makes the
check optional. Please let me know how you prefer that I take this forward.
Thanks,
F.
Felipe Franciosi (1):
conf: remove domain name change check on CheckABI
src/conf/domain_conf.c | 11 -----------
1 file changed, 11 deletions(-)
--
2.39.5
4 months, 3 weeks
[PATCH] cpu_x86: Probe host CPU for all MSR features
by Jiri Denemark
The list of CPU features we probe from various MSR grew significantly
over time and the CPU map currently mentions 11 distinct MSR indexes.
But the code for directly probing host CPU features was still reading
only the original 0x10a index. Thus the CPU model in host capabilities
was missing a lot of features.
Instead of specifying a static list of indexes to read (which we would
forget to update in the future), let's just read all indexes found in
the CPU map.
Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com>
---
src/cpu/cpu_x86.c | 62 ++++++++++++++++++++++++++++++++++++++++-------
1 file changed, 53 insertions(+), 9 deletions(-)
diff --git a/src/cpu/cpu_x86.c b/src/cpu/cpu_x86.c
index 6d72d446c9..1ce97d9dcf 100644
--- a/src/cpu/cpu_x86.c
+++ b/src/cpu/cpu_x86.c
@@ -2836,15 +2836,61 @@ cpuidSet(uint32_t base, virCPUData *data)
}
+static size_t
+virCPUx86ListMSRs(virCPUx86Map *map,
+ unsigned long **msrs)
+{
+ size_t n = 0;
+ size_t i, j, k;
+
+ /* These three nested loops look horrible, but data->len is always 1 here
+ * and thanks to grouping features in the CPU map by their MSR index the
+ * third loop will run more than one iteration only once for each distinct
+ * index.
+ */
+ for (i = 0; i < map->nfeatures; i++) {
+ virCPUx86Data *data = &map->features[i]->data;
+
+ for (j = 0; j < data->len; j++) {
+ virCPUx86DataItem *item = &data->items[j];
+ bool found = false;
+ unsigned long msr;
+
+ if (item->type != VIR_CPU_X86_DATA_MSR)
+ continue;
+
+ msr = item->data.msr.index;
+
+ for (k = n; k > 0; k--) {
+ if ((*msrs)[k - 1] == msr) {
+ found = true;
+ break;
+ }
+ }
+
+ if (!found)
+ VIR_APPEND_ELEMENT(*msrs, n, msr);
+ }
+ }
+
+ return n;
+}
+
+
static int
virCPUx86GetHost(virCPUDef *cpu,
virDomainCapsCPUModels *models)
{
g_autoptr(virCPUData) cpuData = NULL;
unsigned int addrsz;
+ virCPUx86Map *map;
+ g_autofree unsigned long *msrs = NULL;
+ size_t nmsrs;
+ uint64_t msr;
+ size_t i;
int ret;
- if (virCPUx86DriverInitialize() < 0)
+ if (!(map = virCPUx86GetMap()))
return -1;
if (!(cpuData = virCPUDataNew(archs[0])))
@@ -2854,18 +2900,16 @@ virCPUx86GetHost(virCPUDef *cpu,
cpuidSet(CPUX86_EXTENDED, cpuData) < 0)
return -1;
- /* Read the IA32_ARCH_CAPABILITIES MSR (0x10a) if supported.
- * This is best effort since there might be no way to read the MSR
- * when we are not running as root. */
- if (virCPUx86DataCheckFeature(cpuData, "arch-capabilities") == 1) {
- uint64_t msr;
- unsigned long index = 0x10a;
+ nmsrs = virCPUx86ListMSRs(map, &msrs);
- if (virHostCPUGetMSR(index, &msr) == 0) {
+ /* This is best effort since there might be no way to read the MSR
+ * when we are not running as root. */
+ for (i = 0; i < nmsrs; i++) {
+ if (virHostCPUGetMSR(msrs[i], &msr) == 0) {
virCPUx86DataItem item = {
.type = VIR_CPU_X86_DATA_MSR,
.data.msr = {
- .index = index,
+ .index = msrs[i],
.eax = msr & 0xffffffff,
.edx = msr >> 32,
},
--
2.47.1
4 months, 3 weeks
[PATCH v3 0/4] fix AppArmor policy restore for runtime rules
by Georgia Garcia
Some rules are generated dynamically during boot and added to the
AppArmor policy. An example of that is macvtap devices that call the
AppArmorSetFDLabel hook to add a rule for the tap device path.
Since this information is dynamic, it is not available in the xml
config, therefore whenever a "Restore" hook is called, the entire
profile is regenerated by virt-aa-helper based only the information
from the VM definition, so the dynamic/runtime information is lost.
This patchset fixes that by storing these rules in a different file
called libvirt-uuid.runtime_files, which is included by
libvirt-uuid.files that already exists. It also includes other fixes
like memory leaks, adoption of the GLib API in the apparmor files and
a fix on the AppArmor policy that incorrectly applies apparmor policy
syntax.
Georgia Garcia (4):
security_apparmor: fix memleaks in AppArmorSetFDLabel
security: replace uses of label and VIR_FREE by g_autofree
apparmor: fix UUID specification
virt-aa-helper: store dynamically generated rules
.../usr.lib.libvirt.virt-aa-helper.in | 5 +-
src/security/apparmor/usr.sbin.libvirtd.in | 7 +-
src/security/apparmor/usr.sbin.virtqemud.in | 6 +-
src/security/security_apparmor.c | 84 +++++-----
src/security/virt-aa-helper.c | 145 +++++++++---------
5 files changed, 125 insertions(+), 122 deletions(-)
--
2.43.0
4 months, 4 weeks
[PATCH] qemu: Report error from both sides of migration
by Jiri Denemark
When migration fails in Perform phase, we call Finish on the destination
host with cancelled=1 and get the error from there and report it to the
user. This works well if the error on the destination caused the
migration to fail. But in other cases the main error may reported by the
source and the destination would just be complaining about broken
migration stream.
In other words, we don't really know which error caused the migration to
fail and we have no way of detecting that. So instead of choosing one
error, this patch will combine the error messages from both sides of
migration into a single message and report it to the user. The result
would be, for example:
operation failed: migration failed. Message from the source host:
operation failed: job 'migration out' failed: Certificate does not
match the hostname ble.bla. Message from the destination host:
operation failed: job 'migration in' failed: load of migration
failed: Invalid argument
And yes, this is ugly, but I wasn't able to come up with a better way of
fixing this issue.
https://issues.redhat.com/browse/RHEL-58933
Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com>
---
src/libvirt-domain.c | 26 +++++++++++++-------------
src/qemu/qemu_migration.c | 26 +++++++++++++-------------
2 files changed, 26 insertions(+), 26 deletions(-)
diff --git a/src/libvirt-domain.c b/src/libvirt-domain.c
index e8e5379672..efccafc4d2 100644
--- a/src/libvirt-domain.c
+++ b/src/libvirt-domain.c
@@ -3430,26 +3430,26 @@ virDomainMigrateVersion3Full(virDomainPtr domain,
if (ddomain) {
VIR_ERROR(_("finish step ignored that migration was cancelled"));
} else {
- /* If Finish reported a useful error, use it instead of the
- * original "migration unexpectedly failed" error.
+ virErrorPtr err = virGetLastError();
+ /* When both Confirm and Finish reported an error in QEMU driver,
+ * we don't really know which error is the root cause. Let's report
+ * both errors to the user.
*
* This is ugly but we can't do better with the APIs we have. We
* only replace the error if Finish was called with cancelled == 1
* and reported a real error (old libvirt would report an error
- * from RPC instead of MIGRATE_FINISH_OK), which only happens when
- * the domain died on destination. To further reduce a possibility
- * of false positives we also check that Perform returned
- * VIR_ERR_OPERATION_FAILED.
+ * from RPC instead of MIGRATE_FINISH_OK).
*/
if (orig_err &&
orig_err->domain == VIR_FROM_QEMU &&
- orig_err->code == VIR_ERR_OPERATION_FAILED) {
- virErrorPtr err = virGetLastError();
- if (err &&
- err->domain == VIR_FROM_QEMU &&
- err->code != VIR_ERR_MIGRATE_FINISH_OK) {
- g_clear_pointer(&orig_err, virFreeError);
- }
+ orig_err->code == VIR_ERR_OPERATION_FAILED &&
+ err &&
+ err->domain == VIR_FROM_QEMU &&
+ err->code != VIR_ERR_MIGRATE_FINISH_OK) {
+ virReportError(VIR_ERR_OPERATION_FAILED,
+ _("migration failed. Message from the source host: %1$s. Message from the destination host: %2$s"),
+ orig_err->message, err->message);
+ g_clear_pointer(&orig_err, virFreeError);
}
}
}
diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c
index 1582a738a3..8c0e522828 100644
--- a/src/qemu/qemu_migration.c
+++ b/src/qemu/qemu_migration.c
@@ -5904,26 +5904,26 @@ qemuMigrationSrcPerformPeer2Peer3(virQEMUDriver *driver,
if (ddomain) {
VIR_ERROR(_("finish step ignored that migration was cancelled"));
} else {
- /* If Finish reported a useful error, use it instead of the
- * original "migration unexpectedly failed" error.
+ virErrorPtr err = virGetLastError();
+ /* When both Confirm and Finish reported an error in QEMU driver,
+ * we don't really know which error is the root cause. Let's report
+ * both errors to the user.
*
* This is ugly but we can't do better with the APIs we have. We
* only replace the error if Finish was called with cancelled == 1
* and reported a real error (old libvirt would report an error
- * from RPC instead of MIGRATE_FINISH_OK), which only happens when
- * the domain died on destination. To further reduce a possibility
- * of false positives we also check that Perform returned
- * VIR_ERR_OPERATION_FAILED.
+ * from RPC instead of MIGRATE_FINISH_OK).
*/
if (orig_err &&
orig_err->domain == VIR_FROM_QEMU &&
- orig_err->code == VIR_ERR_OPERATION_FAILED) {
- virErrorPtr err = virGetLastError();
- if (err &&
- err->domain == VIR_FROM_QEMU &&
- err->code != VIR_ERR_MIGRATE_FINISH_OK) {
- g_clear_pointer(&orig_err, virFreeError);
- }
+ orig_err->code == VIR_ERR_OPERATION_FAILED &&
+ err &&
+ err->domain == VIR_FROM_QEMU &&
+ err->code != VIR_ERR_MIGRATE_FINISH_OK) {
+ virReportError(VIR_ERR_OPERATION_FAILED,
+ _("migration failed. Message from the source host: %1$s. Message from the destination host: %2$s"),
+ orig_err->message, err->message);
+ g_clear_pointer(&orig_err, virFreeError);
}
}
}
--
2.47.1
4 months, 4 weeks
[PATCH 0/2] tests: Add qemu-9.2 dev cycle caps on s390x
by Michal Privoznik
NB, the capabilities were captured in a VM running on an actual s390x
machine so there might be some CPU features (incorrectly) missing. But
it's the best I can do.
Michal Prívozník (2):
qemuxmlconftest: Switch s390-default-cpu-...-virtio-2.7 to virtio-2.9
tests: qemucapabilities: Add test data for the qemu-9.2 dev cycle on
s390x
tests/domaincapsdata/qemu_9.3.0.s390x.xml | 436 +
.../caps_9.3.0_s390x.replies | 38101 ++++++++++++++++
.../qemucapabilitiesdata/caps_9.3.0_s390x.xml | 4268 ++
...-deprecated-features-off.s390x-latest.args | 2 +-
...default-video-type-s390x.s390x-latest.args | 2 +-
...vfio-zpci-ccw-memballoon.s390x-latest.args | 2 +-
.../launch-security-s390-pv.s390x-latest.args | 2 +-
...-cpu-kvm-ccw-virtio-2.9.s390x-latest.args} | 4 +-
...t-cpu-kvm-ccw-virtio-2.9.s390x-latest.xml} | 4 +-
...> s390-default-cpu-kvm-ccw-virtio-2.9.xml} | 2 +-
...t-cpu-kvm-ccw-virtio-4.2.s390x-latest.args | 2 +-
...-cpu-tcg-ccw-virtio-2.9.s390x-latest.args} | 2 +-
...t-cpu-tcg-ccw-virtio-2.9.s390x-latest.xml} | 2 +-
...> s390-default-cpu-tcg-ccw-virtio-2.9.xml} | 2 +-
.../s390-defaultconsole.s390x-latest.args | 2 +-
.../s390-panic.s390x-latest.args | 2 +-
tests/qemuxmlconftest.c | 4 +-
17 files changed, 42822 insertions(+), 17 deletions(-)
create mode 100644 tests/domaincapsdata/qemu_9.3.0.s390x.xml
create mode 100644 tests/qemucapabilitiesdata/caps_9.3.0_s390x.replies
create mode 100644 tests/qemucapabilitiesdata/caps_9.3.0_s390x.xml
rename tests/qemuxmlconfdata/{s390-default-cpu-kvm-ccw-virtio-2.7.s390x-latest.args => s390-default-cpu-kvm-ccw-virtio-2.9.s390x-latest.args} (70%)
rename tests/qemuxmlconfdata/{s390-default-cpu-kvm-ccw-virtio-2.7.s390x-latest.xml => s390-default-cpu-kvm-ccw-virtio-2.9.s390x-latest.xml} (86%)
rename tests/qemuxmlconfdata/{s390-default-cpu-kvm-ccw-virtio-2.7.xml => s390-default-cpu-kvm-ccw-virtio-2.9.xml} (85%)
rename tests/qemuxmlconfdata/{s390-default-cpu-tcg-ccw-virtio-2.7.s390x-latest.args => s390-default-cpu-tcg-ccw-virtio-2.9.s390x-latest.args} (94%)
rename tests/qemuxmlconfdata/{s390-default-cpu-tcg-ccw-virtio-2.7.s390x-latest.xml => s390-default-cpu-tcg-ccw-virtio-2.9.s390x-latest.xml} (92%)
rename tests/qemuxmlconfdata/{s390-default-cpu-tcg-ccw-virtio-2.7.xml => s390-default-cpu-tcg-ccw-virtio-2.9.xml} (85%)
--
2.45.2
4 months, 4 weeks
Release of libvirt-11.0.0
by Jiri Denemark
The 11.0.0 release of both libvirt and libvirt-python is tagged and
signed tarballs are available at
https://download.libvirt.org/
https://download.libvirt.org/python/
Thanks everybody who helped with this release by sending patches,
reviewing, testing, or providing feedback. Your work is greatly
appreciated.
* New features
* network/qemu/lxc: support vlans on standard Linux host bridges
The network, qemu, and lxc drivers now support (using the
``<vlan>`` subelement) vlan tagging and trunking on network
interfaces connected to a standard Linux host bridge.
* qemu: Add support for direct and extended tlbflush features
Domains can now utilise more tlbflush hyperv features.
* Improvements
* ch: Enable user aliases
User can now specify custom aliases for devices in domain XML
* qemu: Grab a QUERY job when formatting domain XML
Under some specific conditions it might have happened that domain XML did
not contain runtime information or returned an XML that's in process of
changing (e.g. by a thread that's hotplugging a device). Formatting domain
XML now serializes properly with other threads.
* virtiofs: Allow read only mode
The ``<filesystem/>`` with `virtiofsd` backend can now use ``<readonly/>``
tag to export underlying filesystem in read only mode.
* qemu: allow migration of vGPU from mdev device <-> SRIOV VF device
Some GPU vendors are switching from using vGPUs creating using
mdev and identified with a uuid, to vGPUs created as SRIOV VFs and
identified by their PCI address, and want to support live
migration from a host using one type of vGPU to the other
type. This is now possible.
* Bug fixes
* qemu: tpm: do not update profile name for transient domains
Fix a possible crash when starting a transient domain which was
introduced in the previous release.
* qemu: Fix snapshot to not delete disk image with internal snapshot
When a VM has internal snapshot that is parent to external snapshot and user
reverts to the internal snapshot and deletes the external snapshot libvirt
would delete the disk image containing the internal snapshot. This would
result in data loss.
* qemu: Do not format invalid XML with hyperv features in passthrough mode
When hyperv features were specified together with ``mode="passthrough"``
libvirt parsed and formatted such features in the domain XML even though
they were not used at all, resulting in XML that is not valid based on our
schema. This is now fixed by not parsing any specified features when the
passthrough mode is used.
* qemu: Fix a crash when starting a domain with ovs bridge and QOS
* cpu: Add missing -v1 variants for CPU models
Some CPU models (mostly old ones) were missed when versioned CPU model
names were introduced in the previous release.
* qemu: Fix false error when recovering failed post-copy migration
In some cases libvirt would report a failure to recover post-copy migration
even though the recovery started just fine and migration would eventually
successfully finish.
Enjoy.
Jirka
5 months
[PATCH 00/20] qemu: support mapped-ram+directio+mulitfd
by Jim Fehlig
This series is essentially V1 of a prior RFC [1] to support QEMU's
mapped-ram stream format [2] and migration capability. Along with
supporting mapped-ram, it implements a design approach we discussed
for supporting parallel save/restore [3]. In summary, the approach is
1. Add mapped-ram migration capability
2. Steal an element from save header 'unused' for a 'features' variable
and bump save version to 3.
3. Add /etc/libvirt/qemu.conf knob for the save format version,
defaulting to latest v3
4. Use v3 (aka mapped-ram) by default
5. Use mapped-ram with BYPASS_CACHE for v3, old approach for v2
6. include: Define constants for parallel save/restore
7. qemu: Add support for parallel save. Implies mapped-ram, reject if v2
8. qemu: Add support for parallel restore. Implies mapped-ram.
Reject if v2
9. tools: add parallel parameter to virsh save command
10. tools: add parallel parameter to virsh restore command
With this series, saving and restoring using mapped-ram is enabled by
default if the underlying QEMU advertises the mapped-ram migration
capability. It can be disabled by changing the 'save_image_version'
setting in qemu.conf.
To use mapped-ram with QEMU:
- The 'mapped-ram' migration capability must be set to true
- The 'multifd' migration capability must be set to true and
the 'multifd-channels' migration parameter must set to a
value >= 1
- QEMU must be provided an fdset containing the migration fd(s)
- The 'migrate' qmp command is invoked with a URI referencing the fdset
and an offset where to start reading or writing the data stream, e.g.
{"execute":"migrate",
"arguments":{"detach":true,"resume":false,
"uri":"file:/dev/fdset/0,offset=0x11921"}}
The mapped-ram stream, in conjunction with direct IO and multifd, can
significantly improve the time required to save VM memory state. The
following tables compare mapped-ram with the existing, sequential save
stream. In all cases, the save and restore operations are to/from a
block device comprised of two NVMe disks in RAID0 configuration with
xfs (~8600MiB/s). The values in the 'save time' and 'restore time'
columns were scraped from the 'real' time reported by time(1). The
'Size' and 'Blocks' columns were provided by the corresponding
outputs of stat(1).
VM: 32G RAM, 1 vcpu, idle (shortly after boot)
| save | restore |
| time | time | Size | Blocks
-----------------------+---------+---------+--------------+--------
legacy | 6.193s | 4.399s | 985744812 | 1925288
-----------------------+---------+---------+--------------+--------
mapped-ram | 5.109s | 1.176s | 34368554354 | 1774472
-----------------------+---------+---------+--------------+--------
legacy + direct IO | 5.725s | 4.512s | 985765251 | 1925328
-----------------------+---------+---------+--------------+--------
mapped-ram + direct IO | 4.627s | 1.490s | 34368554354 | 1774304
-----------------------+---------+---------+--------------+--------
mapped-ram + direct IO | | | |
+ multifd-channels=8 | 4.421s | 0.845s | 34368554318 | 1774312
-------------------------------------------------------------------
VM: 32G RAM, 30G dirty, 1 vcpu in tight loop dirtying memory
| save | restore |
| time | time | Size | Blocks
-----------------------+---------+---------+--------------+---------
legacy | 25.800s | 14.332s | 33154309983 | 64754512
-----------------------+---------+---------+--------------+---------
mapped-ram | 18.742s | 15.027s | 34368559228 | 64617160
-----------------------+---------+---------+--------------+---------
legacy + direct IO | 13.115s | 18.050s | 33154310496 | 64754520
-----------------------+---------+---------+--------------+---------
mapped-ram + direct IO | 13.623s | 15.959s | 34368557392 | 64662040
-----------------------+-------- +---------+--------------+---------
mapped-ram + direct IO | | | |
+ multifd-channels=8 | 6.994s | 6.470s | 34368554980 | 64665776
--------------------------------------------------------------------
As can be seen from the tables, one caveat of mapped-ram is the logical file
size of a saved image is basically equivalent to the VM memory size. Note
however that mapped-ram typically uses fewer blocks on disk.
Support for mapped-ram+direct-io only recently landed in upstream QEMU
and will first appear in the 9.1 release, which may complicate merging
support in libvirt. Specifically, I'm not sure how to detect if the
combination is supported by QEMU. Suggestions welcomed.
Similar to the RFC, V1 ignores compression. libvirt currently supports
compression by connecting the output of QEMU's save stream to the specified
compression program via a pipe. This approach is incompatible with mapped-ram
since the fd provided to QEMU must be seekable. In general, we can consider
mapped-ram and compression incompatible and document they cannot be used
together.
[1] https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/message/E...
[2] https://gitlab.com/qemu-project/qemu/-/blob/master/docs/devel/migration/m...
[3] https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/message/K...
Claudio Fontana (2):
include: Define constants for parallel save/restore
tools: add parallel parameter to virsh restore command
Jim Fehlig (17):
lib: virDomainSaveParams: Ensure absolute save path
qemu_fd: Add function to retrieve fdset ID
qemu: Add function to check capability in migration params
qemu: Add function to get bool value from migration params
qemu: Add mapped-ram migration capability
qemu: Add function to get migration params for save
qemu: QEMU_SAVE_VERSION: Bump to version 3
qemu: conf: Add setting for save image version
qemu: Add helper function for creating save image fd
qemu: Add support for mapped-ram on save
qemu: Decompose qemuSaveImageOpen
qemu: Move creation of qemuProcessIncomingDef struct
qemu: Apply migration parameters in qemuMigrationDstRun
qemu: Add support for mapped-ram on restore
qemu: Support O_DIRECT with mapped-ram on save
qemu: Support O_DIRECT with mapped-ram on restore
qemu: Add support for parallel save and restore
Li Zhang (1):
tools: add parallel parameter to virsh save command
docs/manpages/virsh.rst | 9 +-
include/libvirt/libvirt-domain.h | 13 ++
src/libvirt-domain.c | 52 +++++--
src/qemu/libvirtd_qemu.aug | 1 +
src/qemu/qemu.conf.in | 6 +
src/qemu/qemu_conf.c | 16 +++
src/qemu/qemu_conf.h | 5 +
src/qemu/qemu_driver.c | 104 +++++++++-----
src/qemu/qemu_fd.c | 18 +++
src/qemu/qemu_fd.h | 3 +
src/qemu/qemu_migration.c | 192 +++++++++++++++++--------
src/qemu/qemu_migration.h | 9 +-
src/qemu/qemu_migration_params.c | 86 ++++++++++++
src/qemu/qemu_migration_params.h | 17 +++
src/qemu/qemu_monitor.c | 39 ++++++
src/qemu/qemu_monitor.h | 5 +
src/qemu/qemu_process.c | 120 +++++++++++-----
src/qemu/qemu_process.h | 19 ++-
src/qemu/qemu_saveimage.c | 216 ++++++++++++++++++++---------
src/qemu/qemu_saveimage.h | 35 +++--
src/qemu/qemu_snapshot.c | 26 ++--
src/qemu/test_libvirtd_qemu.aug.in | 1 +
tools/virsh-domain.c | 79 +++++++++--
23 files changed, 827 insertions(+), 244 deletions(-)
--
2.35.3
5 months