July 2022 - Devel - libvirt List Archives

[libvirt PATCH v2 0/5] Ask qemu about migration blockers
by Eugenio Pérez 20 Jul '22

20 Jul '22

There are some hardcoded migration blockers in libvirt, like having a net vhost-vdpa device. While it's true that they cannot be migrated at the moment, there are plans to be able to migrate them soon. They'll put a migration blockers in the cases where you cannot migrate them. Ask qemu about then before rejecting the migration. In case the question is not possible, assume they're not migratable. Eugenio Pérez (4): qemu_monitor_json: Add qemuMonitorJSONGetMigrationBlockers qemu_monitor: add support for get qemu migration blockers qemu_migration: get migration blockers before hardcoded checks qemu_migrate: Do not forbif vDPA devices if can query blockers Jonathon Jongsma (1): qemu: introduce capability QEMU_MIGRATION_BLOCKED_REASONS src/qemu/qemu_capabilities.c | 2 + src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_migration.c | 38 ++++++++++++++++++- src/qemu/qemu_monitor.c | 11 ++++++ src/qemu/qemu_monitor.h | 4 ++ src/qemu/qemu_monitor_json.c | 35 +++++++++++++++++ src/qemu/qemu_monitor_json.h | 3 ++ .../caps_6.0.0.aarch64.xml | 1 + .../qemucapabilitiesdata/caps_6.0.0.s390x.xml | 1 + .../caps_6.0.0.x86_64.xml | 1 + .../caps_6.1.0.x86_64.xml | 1 + .../caps_6.2.0.aarch64.xml | 1 + .../qemucapabilitiesdata/caps_6.2.0.ppc64.xml | 1 + .../caps_6.2.0.x86_64.xml | 1 + .../caps_7.0.0.aarch64.xml | 1 + .../qemucapabilitiesdata/caps_7.0.0.ppc64.xml | 1 + .../caps_7.0.0.x86_64.xml | 1 + .../caps_7.1.0.x86_64.xml | 1 + 18 files changed, 104 insertions(+), 1 deletion(-) -- 2.31.1

4 21

[PATCH 0/2] schemas: Drop <interleave/> from capabilities schemas
by Michal Privoznik 20 Jul '22

20 Jul '22

*** BLURB HERE *** Michal Prívozník (2): capabilityschemadata: Fix order of <features/> in caps-test2.xml schemas: Drop <interleave/> from capabilities schemas src/conf/schemas/capability.rng | 160 +++++++++++----------- src/conf/schemas/domaincaps.rng | 80 +++++------ tests/capabilityschemadata/caps-test2.xml | 8 +- 3 files changed, 119 insertions(+), 129 deletions(-) -- 2.35.1

3 4

[PATCH] spec: Restart sockets even when libvirtd is inactive
by Jim Fehlig 20 Jul '22

20 Jul '22

By default libvirtd will terminate itself after 120 seconds, so it is likely that the daemon will not be running at package upgrade. Try restarting sockets even if the daemon is inactive. Signed-off-by: Jim Fehlig <jfehlig(a)suse.com> --- Assuming sockets need restarted on package update? libvirt.spec.in | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/libvirt.spec.in b/libvirt.spec.in index 9d788b790f..5201a14431 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -1365,16 +1365,19 @@ then # own the sockets again when it comes back up. Thus we must # do this particular ordering, so that we get libvirtd # running with socket activation in use + is_active=no /bin/systemctl is-active libvirtd.service 1>/dev/null 2>&1 if test $? = 0 then + is_active=yes /bin/systemctl stop libvirtd.service >/dev/null 2>&1 || : - - /bin/systemctl try-restart \ - libvirtd.socket \ - libvirtd-ro.socket \ - libvirtd-admin.socket >/dev/null 2>&1 || : - + fi + /bin/systemctl try-restart \ + libvirtd.socket \ + libvirtd-ro.socket \ + libvirtd-admin.socket >/dev/null 2>&1 || : + if test "$is_active" = yes + then /bin/systemctl start libvirtd.service >/dev/null 2>&1 || : fi fi -- 2.36.1

2 1

[libvirt PATCH] qemu_migration: Delete vDPA check
by Eugenio Pérez 20 Jul '22

20 Jul '22

Currently, the migration code denies migration as long as the VM has a vhost-vDPA device. While it's true that vhost-vDPA devices cannot be migrated at the moment, there are plans to be able to migrate them soon. Libvirt must treat it equal to vhost-kernel devices: Not all of them can be migrated (the ones that do not expose the feature VHOST_F_LOG_ALL cannot be migrated). So checks like this one should work for all vhost devices equally. A more accurate solution is to ask qemu if it has an active migration blocker at that moment. Hoever, that require synchronization to avoid qemu to add one between the query and the actual migration command. Signed-off-by: Eugenio Pérez <eperezma(a)redhat.com> --- src/qemu/qemu_migration.c | 6 ------ 1 file changed, 6 deletions(-) diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c index 9c3fd41761..4ddf027c83 100644 --- a/src/qemu/qemu_migration.c +++ b/src/qemu/qemu_migration.c @@ -1546,12 +1546,6 @@ qemuMigrationSrcIsAllowed(virQEMUDriver *driver, virDomainNetDef *net = vm->def->nets[i]; qemuSlirp *slirp; - if (net->type == VIR_DOMAIN_NET_TYPE_VDPA) { - virReportError(VIR_ERR_OPERATION_INVALID, "%s", - _("vDPA devices cannot be migrated")); - return false; - } - slirp = QEMU_DOMAIN_NETWORK_PRIVATE(net)->slirp; if (slirp && !qemuSlirpHasFeature(slirp, QEMU_SLIRP_FEATURE_MIGRATE)) { -- 2.31.1

4 11

[libvirt PATCH] conf: add missing break on a switch case
by Jonathon Jongsma 19 Jul '22

19 Jul '22

This was not causing any problems because all cases below were empty, but in order to avoid future misbehavior, add a break to this case. Signed-off-by: Jonathon Jongsma <jjongsma(a)redhat.com> --- src/conf/node_device_conf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/conf/node_device_conf.c b/src/conf/node_device_conf.c index 51746229fc..364bb489bd 100644 --- a/src/conf/node_device_conf.c +++ b/src/conf/node_device_conf.c @@ -770,7 +770,7 @@ virNodeDeviceDefFormat(const virNodeDeviceDef *def) virNodeDeviceCapMdevTypesFormat(&buf, data->ap_matrix.mdev_types, data->ap_matrix.nmdev_types); - + break; case VIR_NODE_DEV_CAP_MDEV_TYPES: case VIR_NODE_DEV_CAP_FC_HOST: case VIR_NODE_DEV_CAP_VPORTS: -- 2.35.3

2 1

[PATCH 0/7] Refactor closecallback use in LXC
by Peter Krempa 19 Jul '22

19 Jul '22

The end-goal is to remove 'virCloseCallbacksGetConn'. Peter Krempa (7): virLXCProcessStop: Add 'cleanupFlags' parameter virLXCProcessStart: Pass in virConnect object only when registering autodestroy virLXCProcessReboot: Simplify cleanup virLXCProcessAutostartAll: Remove unused 'conn' virLXCProcessAutostartDomain: Refactor control flow and variable use virLXCProcessReboot: Remove the need to re-register autodestroy callback virclosecallbacks: Remove unused virCloseCallbacksGetConn src/hypervisor/virclosecallbacks.c | 24 ----- src/hypervisor/virclosecallbacks.h | 3 - src/libvirt_private.syms | 1 - src/lxc/lxc_driver.c | 17 ++-- src/lxc/lxc_process.c | 141 +++++++++++------------------ src/lxc/lxc_process.h | 8 +- 6 files changed, 69 insertions(+), 125 deletions(-) -- 2.36.1

2 8

[PATCH 0/2] Two simple virBuffer*() usage fixes
by Michal Privoznik 19 Jul '22

19 Jul '22

*** BLURB HERE *** Michal Prívozník (2): qemu_capabilities: Indent <cpudata/> properly domain_conf: Switch to virBufferAddLit for literal strings src/conf/domain_conf.c | 4 ++-- src/qemu/qemu_capabilities.c | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) -- 2.35.1

2 3

Plans for the next release
by Jiri Denemark 19 Jul '22

19 Jul '22

We are getting close to the next release of libvirt. To aim for the release on Aug 01 I suggest entering the freeze on Tuesday Jul 26 and tagging RC2 on Friday Jul 29. I hope this works for everyone. Jirka

1 0

[PATCH 0/2] Fix build with glib-2.73.2
by Michal Privoznik 18 Jul '22

18 Jul '22

3 6

[libvirt PATCH 0/9] [RFC] Dynamic CPU models
by Tim Wiederhake 18 Jul '22

18 Jul '22

libvirt and qemu cpu models are out of sync. libvirt cpu models are considered static and never changing, whereas qemu cpu models have changed over time. This leads to problems and confusion for users, as the cpu models they specify may have different features than what they expect. This series introduces two new APIs to enumerate and retrieve cpu models dynamically from the hypervisor at runtime, allowing the user to make use of cpu models from newer hypervisor versions even if libvirt is not aware of them. These two new functions are intended as building blocks onto which higher-level functionality can be build, e.g. the ability to specify a hypervisor cpu model directly in a domain xml. With these two functions alone this has to be done manually for now, i.e. enumerate the available cpu models, retrieve the cpu description and manually insert it into the domain xml accordingly: $ virsh hypervisor-cpu-models --arch x86_64 Name Alias ---------------------------------------------------- max host base qemu64-v1 qemu64 qemu64-v1 qemu32-v1 qemu32 qemu32-v1 phenom-v1 phenom phenom-v1 (...) $ virsh hypervisor-cpu-definition --machine pc --arch x86_64 qemu64 <cpu> <model>qemu64</model> <feature name='cmov'/> <feature name='mmx'/> <feature name='xd'/> <feature name='x-intel-pt-auto-level'/> <feature name='kvm_asyncpf'/> <feature name='kvm-asyncpf'/> <feature name='legacy-cache'/> <feature name='vmware-cpuid-freq'/> <feature name='mce'/> <feature name='mca'/> <feature name='msr'/> <feature name='fxsr'/> <feature name='cpuid-0xb'/> <feature name='kvm_pv_eoi'/> <feature name='pni'/> <feature name='x2apic'/> <feature name='i64'/> <feature name='pae'/> <feature name='pat'/> <feature name='sse'/> <feature name='kvm_nopiodelay'/> <feature name='kvm-nopiodelay'/> <feature name='kvmclock-stable-bit'/> <feature name='hypervisor'/> <feature name='syscall'/> <feature name='x-migrate-smi-count'/> <feature name='full-cpuid-auto-level'/> <feature name='sse3'/> <feature name='sse2'/> <feature name='kvm-pv-eoi'/> <feature name='cx8'/> <feature name='pge'/> <feature name='fill-mtrr-mask'/> <feature name='cx16'/> <feature name='de'/> <feature name='clflush'/> <feature name='tsc'/> <feature name='fpu'/> <feature name='check'/> <feature name='apic'/> <feature name='kvm-steal-time'/> <feature name='kvm_steal_time'/> <feature name='kvmclock'/> <feature name='l3-cache'/> <feature name='nx'/> <feature name='tcg-cpuid'/> <feature name='lm'/> <feature name='pse'/> <feature name='sep'/> <feature name='kvm'/> <feature name='lahf-lm'/> <feature name='lahf_lm'/> <feature name='mtrr'/> <feature name='pse36'/> </cpu> The returned cpu description is currently completely unfiltered, as can be seen by the duplicate entries differing only in "-" vs. "_" usage, inclusion of experimental feature flags and generally, flags that are not recognized by libvirt. One possibility to adress this would be to extend virQEMUCapsCPUFeatureTranslate. Before I continue with this, I would love to hear other people's thoughts, comments and potential use cases. Cheers, Tim Tim Wiederhake (9): qemuMonitorCPUDefInfo: Add alias libvirt: introduce virConnectGetHypervisorCPUModelNames public API remote: Add RPC support for the virConnectGetHypervisorCPUModelNames API qemu: implement virConnectGetHypervisorCPUModelNames API tools: Report hypervisor cpu model names libvirt: introduce virConnectGetHypervisorCPUModelDefinition public API remote: Add support for the virConnectGetHypervisorCPUModelDefinition API qemu: Implement virConnectGetHypervisorCPUModelDefinition API tools: Report hypervisor cpu model definitions docs/manpages/virsh.rst | 27 ++++++ include/libvirt/libvirt-host.h | 13 +++ src/driver-hypervisor.h | 17 ++++ src/libvirt-host.c | 109 +++++++++++++++++++++++ src/libvirt_public.syms | 2 + src/qemu/qemu_driver.c | 105 ++++++++++++++++++++++ src/qemu/qemu_monitor.c | 2 + src/qemu/qemu_monitor.h | 1 + src/qemu/qemu_monitor_json.c | 3 + src/remote/remote_daemon_dispatch.c | 76 ++++++++++++++++ src/remote/remote_driver.c | 100 +++++++++++++++++++++ src/remote/remote_protocol.x | 37 +++++++- src/remote_protocol-structs | 27 ++++++ tools/virsh-host.c | 132 ++++++++++++++++++++++++++++ 14 files changed, 650 insertions(+), 1 deletion(-) -- 2.31.1

2 22