Exception in thread "main" java.lang.UnsatisfiedLinkError: Unable to
load library 'virt': The specified module could not be found.
by sujith.a_S1＠dell.com
trying to write a simple java program to connect to KVM, but getting the error
CODE
----------------------------------------------------------------------------------------------------
package com.poc.kvm_connection;
import org.libvirt.Connect;
import org.libvirt.ConnectAuth;
import org.libvirt.ConnectAuthDefault;
import org.libvirt.LibvirtException;
public class KvmConnectionApplication {
public static void main(String[] args) throws Exception {
KvmConnectionApplication application = new KvmConnectionApplication();
application.testConnection();
}
public void testConnection() throws LibvirtException {
ConnectAuth defaultAuth = new ConnectAuthDefault();
Connect conn = new Connect("qemu+tcp://10.230.211.237/system", defaultAuth, 0);
}
}
ERROR
--------------------------------------------------------------------------------------------------------------------
Exception in thread "main" java.lang.UnsatisfiedLinkError: Unable to load library 'virt': The specified module could not be found.
at com.sun.jna.NativeLibrary.loadLibrary(NativeLibrary.java:169)
at com.sun.jna.NativeLibrary.getInstance(NativeLibrary.java:242)
at com.sun.jna.Library$Handler.<init>(Library.java:140)
at com.sun.jna.Native.loadLibrary(Native.java:368)
at com.sun.jna.Native.loadLibrary(Native.java:353)
at org.libvirt.jna.Libvirt.<clinit>(Unknown Source)
at org.libvirt.Connect.<clinit>(Unknown Source)
3 weeks, 4 days
[PATCH 0/8] Enabling logging for ch guests
by Praveen K Paladugu
LogContext management is now moved from Qemu driver to hypervisor. After migrating Qemu to use domain_logcontext, I extended ch driver to use also use logcontext to capture early boot failures in domain specific log file.
I broke up the migration of logcontext from qemu to hypevisor into multiple patches. Due to this breakup, patches 1,2,3 fail to build. Only after applying patch4 does this patchset successfully build.
Praveen K Paladugu (8):
domain: move logcontext mgmt from qemu to hypervisor
hypervisor: drop hypervisor specific args in domainLogContextNew
qemu: Fix domainLogContextNew invocations in qemu driver
libvirt_private: export symbols from domain_logcontext
po: Update POTFILES
ch: Enable logging for ch domains
ch: move curl_data and curl_callback definitions
ch: Enable logging curl responses from ch
po/POTFILES | 2 +-
src/ch/ch_conf.h | 2 +
src/ch/ch_monitor.c | 84 ++++++++++++-------
src/ch/ch_monitor.h | 6 +-
src/ch/ch_process.c | 36 ++++++--
.../domain_logcontext.c} | 78 +++++++++--------
src/hypervisor/domain_logcontext.h | 45 ++++++++++
src/hypervisor/meson.build | 1 +
src/libvirt_private.syms | 6 ++
src/qemu/meson.build | 1 -
src/qemu/qemu_domain.c | 28 +++----
src/qemu/qemu_domain.h | 12 +--
src/qemu/qemu_logcontext.h | 41 ---------
src/qemu/qemu_nbdkit.c | 12 ++-
src/qemu/qemu_process.c | 45 +++++-----
15 files changed, 235 insertions(+), 164 deletions(-)
rename src/{qemu/qemu_logcontext.c => hypervisor/domain_logcontext.c} (79%)
create mode 100644 src/hypervisor/domain_logcontext.h
delete mode 100644 src/qemu/qemu_logcontext.h
--
2.47.0
3 weeks, 5 days
[PATCH] qemu: Grab a QUERY job when formatting domain XML
by Michal Privoznik
It may happen that, for instance after daemon restart, that one
thread is still in qemuProcessReconnect(), i.e. filling in
runtime information by talking to QEMU on monitor. If another
thread then tries to format domain XML (which is currently
guarded by plain mutex on virDomainObj) it'll produce incomplete
and misleading information (e.g. current size of virtio-mem).
This happens because the reconnecting thread talks to QEMU on
monitor and thus unlocks the domain object frequently allowing
the XML formatting thread to acquire the mutex meanwhile.
Resolves: https://issues.redhat.com/browse/RHEL-71042
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
src/qemu/qemu_driver.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index 09f7edda7d..f1a633fdd3 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -6163,6 +6163,9 @@ static char
if (virDomainGetXMLDescEnsureACL(dom->conn, vm->def, flags) < 0)
goto cleanup;
+ if (virDomainObjBeginJob(vm, VIR_JOB_QUERY) < 0)
+ goto cleanup;
+
qemuDomainUpdateCurrentMemorySize(vm);
if ((flags & VIR_DOMAIN_XML_MIGRATABLE))
@@ -6177,6 +6180,8 @@ static char
ret = qemuDomainFormatXML(driver, vm, flags);
+ virDomainObjEndJob(vm);
+
cleanup:
virDomainObjEndAPI(&vm);
return ret;
--
2.45.2
3 weeks, 5 days
[PATCH v2 00/25] cpu_map: Add missing -v1 models
by Jiri Denemark
CPU models that do not have a list of versions attached are still
advertised as aliases to corresponding -v1 variants. We should add the
missing variants to the CPU map.
Available on gitlab:
git fetch https://gitlab.com/jirkade/libvirt.git cpu-versions
Version 2:
- Add -v1 for all models including ancient ones
Jiri Denemark (25):
cpu_map: Sort data files in meson.build
sync_qemu_models_i386: Update meson.build
sync_qemu_models_i386: Generate missing -v1 variants
cpu_map: Add 486-v1 CPU model
cpu_map: Add pentium-v1 CPU model
cpu_map: Add pentium2-v1 CPU model
cpu_map: Add pentium3-v1 CPU model
cpu_map: Add coreduo-v1 CPU model
cpu_map: Add n270-v1 CPU model
cpu_map: Add core2duo-v1 CPU model
cpu_map: Add qemu32-v1 CPU model
cpu_map: Add kvm32-v1 CPU model
cpu_map: Add qemu64-v1 CPU model
cpu_map: Add kvm64-v1 CPU model
cpu_map: Add Conroe-v1 CPU model
cpu_map: Add Penryn-v1 CPU model
cpu_map: Add KnightsMill-v1 CPU model
cpu_map: Add athlon-v1 CPU model
cpu_map: Add phenom-v1 CPU model
cpu_map: Add Opteron_G1-v1 CPU model
cpu_map: Add Opteron_G2-v1 CPU model
cpu_map: Add Opteron_G3-v1 CPU model
cpu_map: Add Opteron_G4-v1 CPU model
cpu_map: Add Opteron_G5-v1 CPU model
cpu_map: Add EPYC-Genoa-v1 CPU model
src/cpu_map/index.xml | 22 +++
src/cpu_map/meson.build | 38 +++--
src/cpu_map/sync_qemu_models_i386.py | 30 ++++
src/cpu_map/x86_486-v1.xml | 6 +
src/cpu_map/x86_Conroe-v1.xml | 6 +
src/cpu_map/x86_EPYC-Genoa-v1.xml | 6 +
src/cpu_map/x86_KnightsMill-v1.xml | 6 +
src/cpu_map/x86_Opteron_G1-v1.xml | 6 +
src/cpu_map/x86_Opteron_G2-v1.xml | 6 +
src/cpu_map/x86_Opteron_G3-v1.xml | 6 +
src/cpu_map/x86_Opteron_G4-v1.xml | 6 +
src/cpu_map/x86_Opteron_G5-v1.xml | 6 +
src/cpu_map/x86_Penryn-v1.xml | 6 +
src/cpu_map/x86_athlon-v1.xml | 6 +
src/cpu_map/x86_core2duo-v1.xml | 6 +
src/cpu_map/x86_coreduo-v1.xml | 6 +
src/cpu_map/x86_kvm32-v1.xml | 6 +
src/cpu_map/x86_kvm64-v1.xml | 6 +
src/cpu_map/x86_n270-v1.xml | 6 +
src/cpu_map/x86_pentium-v1.xml | 6 +
src/cpu_map/x86_pentium2-v1.xml | 6 +
src/cpu_map/x86_pentium3-v1.xml | 6 +
src/cpu_map/x86_phenom-v1.xml | 6 +
src/cpu_map/x86_qemu32-v1.xml | 6 +
src/cpu_map/x86_qemu64-v1.xml | 6 +
.../x86_64-cpuid-A10-5800K-host.xml | 2 +-
.../x86_64-cpuid-Atom-D510-host.xml | 2 +-
.../x86_64-cpuid-Atom-N450-host.xml | 2 +-
.../x86_64-cpuid-Core2-E6850-host.xml | 2 +-
.../x86_64-cpuid-Core2-Q9500-host.xml | 2 +-
.../cputestdata/x86_64-cpuid-FX-8150-host.xml | 2 +-
.../x86_64-cpuid-Opteron-1352-host.xml | 2 +-
.../x86_64-cpuid-Opteron-2350-host.xml | 2 +-
.../x86_64-cpuid-Opteron-6234-host.xml | 2 +-
.../x86_64-cpuid-Opteron-6282-host.xml | 2 +-
.../x86_64-cpuid-Pentium-P6100-host.xml | 2 +-
.../x86_64-cpuid-Phenom-B95-host.xml | 2 +-
.../x86_64-cpuid-Xeon-5110-host.xml | 2 +-
.../x86_64-cpuid-Xeon-X5460-host.xml | 2 +-
.../domaincapsdata/qemu_5.2.0-q35.x86_64.xml | 100 ++++++++++---
.../domaincapsdata/qemu_5.2.0-tcg.x86_64.xml | 105 +++++++++++---
tests/domaincapsdata/qemu_5.2.0.x86_64.xml | 100 ++++++++++---
.../domaincapsdata/qemu_6.0.0-q35.x86_64.xml | 100 ++++++++++---
.../domaincapsdata/qemu_6.0.0-tcg.x86_64.xml | 105 +++++++++++---
tests/domaincapsdata/qemu_6.0.0.x86_64.xml | 100 ++++++++++---
.../domaincapsdata/qemu_6.1.0-q35.x86_64.xml | 100 ++++++++++---
.../domaincapsdata/qemu_6.1.0-tcg.x86_64.xml | 105 +++++++++++---
tests/domaincapsdata/qemu_6.1.0.x86_64.xml | 100 ++++++++++---
.../domaincapsdata/qemu_6.2.0-q35.x86_64.xml | 100 ++++++++++---
.../domaincapsdata/qemu_6.2.0-tcg.x86_64.xml | 105 +++++++++++---
tests/domaincapsdata/qemu_6.2.0.x86_64.xml | 100 ++++++++++---
.../domaincapsdata/qemu_7.0.0-q35.x86_64.xml | 100 ++++++++++---
.../domaincapsdata/qemu_7.0.0-tcg.x86_64.xml | 105 +++++++++++---
tests/domaincapsdata/qemu_7.0.0.x86_64.xml | 100 ++++++++++---
.../domaincapsdata/qemu_7.1.0-q35.x86_64.xml | 100 ++++++++++---
.../domaincapsdata/qemu_7.1.0-tcg.x86_64.xml | 105 +++++++++++---
tests/domaincapsdata/qemu_7.1.0.x86_64.xml | 100 ++++++++++---
.../domaincapsdata/qemu_7.2.0-q35.x86_64.xml | 100 ++++++++++---
.../qemu_7.2.0-tcg.x86_64+hvf.xml | 97 ++++++++++---
.../domaincapsdata/qemu_7.2.0-tcg.x86_64.xml | 97 ++++++++++---
tests/domaincapsdata/qemu_7.2.0.x86_64.xml | 100 ++++++++++---
.../domaincapsdata/qemu_8.0.0-q35.x86_64.xml | 100 ++++++++++---
.../domaincapsdata/qemu_8.0.0-tcg.x86_64.xml | 97 ++++++++++---
tests/domaincapsdata/qemu_8.0.0.x86_64.xml | 100 ++++++++++---
.../domaincapsdata/qemu_8.1.0-q35.x86_64.xml | 132 ++++++++++++++---
.../domaincapsdata/qemu_8.1.0-tcg.x86_64.xml | 135 +++++++++++++++---
tests/domaincapsdata/qemu_8.1.0.x86_64.xml | 132 ++++++++++++++---
.../domaincapsdata/qemu_8.2.0-q35.x86_64.xml | 132 ++++++++++++++---
.../domaincapsdata/qemu_8.2.0-tcg.x86_64.xml | 134 ++++++++++++++---
tests/domaincapsdata/qemu_8.2.0.x86_64.xml | 132 ++++++++++++++---
.../domaincapsdata/qemu_9.0.0-q35.x86_64.xml | 132 ++++++++++++++---
.../domaincapsdata/qemu_9.0.0-tcg.x86_64.xml | 133 ++++++++++++++---
tests/domaincapsdata/qemu_9.0.0.x86_64.xml | 132 ++++++++++++++---
.../domaincapsdata/qemu_9.1.0-q35.x86_64.xml | 132 ++++++++++++++---
.../domaincapsdata/qemu_9.1.0-tcg.x86_64.xml | 133 ++++++++++++++---
tests/domaincapsdata/qemu_9.1.0.x86_64.xml | 132 ++++++++++++++---
.../domaincapsdata/qemu_9.2.0-q35.x86_64.xml | 132 ++++++++++++++---
.../domaincapsdata/qemu_9.2.0-tcg.x86_64.xml | 133 ++++++++++++++---
tests/domaincapsdata/qemu_9.2.0.x86_64.xml | 132 ++++++++++++++---
79 files changed, 3882 insertions(+), 877 deletions(-)
create mode 100644 src/cpu_map/x86_486-v1.xml
create mode 100644 src/cpu_map/x86_Conroe-v1.xml
create mode 100644 src/cpu_map/x86_EPYC-Genoa-v1.xml
create mode 100644 src/cpu_map/x86_KnightsMill-v1.xml
create mode 100644 src/cpu_map/x86_Opteron_G1-v1.xml
create mode 100644 src/cpu_map/x86_Opteron_G2-v1.xml
create mode 100644 src/cpu_map/x86_Opteron_G3-v1.xml
create mode 100644 src/cpu_map/x86_Opteron_G4-v1.xml
create mode 100644 src/cpu_map/x86_Opteron_G5-v1.xml
create mode 100644 src/cpu_map/x86_Penryn-v1.xml
create mode 100644 src/cpu_map/x86_athlon-v1.xml
create mode 100644 src/cpu_map/x86_core2duo-v1.xml
create mode 100644 src/cpu_map/x86_coreduo-v1.xml
create mode 100644 src/cpu_map/x86_kvm32-v1.xml
create mode 100644 src/cpu_map/x86_kvm64-v1.xml
create mode 100644 src/cpu_map/x86_n270-v1.xml
create mode 100644 src/cpu_map/x86_pentium-v1.xml
create mode 100644 src/cpu_map/x86_pentium2-v1.xml
create mode 100644 src/cpu_map/x86_pentium3-v1.xml
create mode 100644 src/cpu_map/x86_phenom-v1.xml
create mode 100644 src/cpu_map/x86_qemu32-v1.xml
create mode 100644 src/cpu_map/x86_qemu64-v1.xml
--
2.47.0
3 weeks, 5 days
[PATCH] virsh: Fix --timeout option of migrate command
by Jiri Denemark
When starting a migration with --timeout, we create a thread to call the
migration API and in parallel setup a timer for the timeout. The
description of --timeout says: "run action specified by --timeout-*
option (suspend by default) if live migration exceeds timeout", which is
not really the way this feature was implemented. Before live migration
starts we first need to contact the source to get the domain definition
and send it to the destination where a new QEMU process has to be
started. This can take some (unpredictably long) time while the timeout
timer is already running. If a very short timeout is set (which doesn't
really make sense, but it's allowed), we may even end up taking the
timeout action before the actual migration had a chance to start.
With this patch the timeout is started only after we get non-zero
dataTotal from virDomainGetJobInfo, which means the migration (of either
storage or memory) really started.
https://issues.redhat.com/browse/RHEL-41264
Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com>
---
tools/virsh-domain.c | 55 ++++++++++++++++++++++++++++----------------
1 file changed, 35 insertions(+), 20 deletions(-)
diff --git a/tools/virsh-domain.c b/tools/virsh-domain.c
index e4923284af..546db955a9 100644
--- a/tools/virsh-domain.c
+++ b/tools/virsh-domain.c
@@ -4237,7 +4237,10 @@ typedef void (*jobWatchTimeoutFunc)(vshControl *ctl, virDomainPtr dom,
struct virshWatchData {
vshControl *ctl;
virDomainPtr dom;
+ GMainContext *context;
jobWatchTimeoutFunc timeout_func;
+ int timeout_secs;
+ GSource *timeout_src;
void *opaque;
const char *label;
GIOChannel *stdin_ioc;
@@ -4259,6 +4262,20 @@ virshWatchTimeout(gpointer opaque)
}
+static void
+virshWatchSetTimeout(struct virshWatchData *data)
+{
+ vshDebug(data->ctl, VSH_ERR_DEBUG,
+ "watchJob: setting timeout of %d secs\n", data->timeout_secs);
+
+ data->timeout_src = g_timeout_source_new_seconds(data->timeout_secs);
+ g_source_set_callback(data->timeout_src,
+ virshWatchTimeout,
+ data, NULL);
+ g_source_attach(data->timeout_src, data->context);
+}
+
+
static gboolean
virshWatchProgress(gpointer opaque)
{
@@ -4290,10 +4307,17 @@ virshWatchProgress(gpointer opaque)
jobinfo.type == VIR_DOMAIN_JOB_UNBOUNDED)) {
vshTTYDisableInterrupt(data->ctl);
data->jobStarted = true;
+ vshDebug(data->ctl, VSH_ERR_DEBUG,
+ "watchJob: job started\n");
+ }
- if (!data->verbose) {
+ if (data->jobStarted) {
+ if (data->timeout_secs > 0 && !data->timeout_src) {
+ if (jobinfo.dataTotal > 0)
+ virshWatchSetTimeout(data);
+ } else if (!data->verbose) {
vshDebug(data->ctl, VSH_ERR_DEBUG,
- "watchJob: job started, disabling callback\n");
+ "watchJob: disabling callback\n");
return G_SOURCE_REMOVE;
}
}
@@ -4356,13 +4380,15 @@ virshWatchJob(vshControl *ctl,
struct sigaction sig_action;
struct sigaction old_sig_action;
#endif /* !WIN32 */
- g_autoptr(GSource) timeout_src = NULL;
g_autoptr(GSource) progress_src = NULL;
g_autoptr(GSource) stdin_src = NULL;
struct virshWatchData data = {
.ctl = ctl,
.dom = dom,
+ .context = g_main_loop_get_context(eventLoop),
.timeout_func = timeout_func,
+ .timeout_secs = timeout_secs,
+ .timeout_src = NULL,
.opaque = opaque,
.label = label,
.stdin_ioc = NULL,
@@ -4391,27 +4417,14 @@ virshWatchJob(vshControl *ctl,
g_source_set_callback(stdin_src,
(GSourceFunc)virshWatchInterrupt,
&data, NULL);
- g_source_attach(stdin_src,
- g_main_loop_get_context(eventLoop));
- }
-
- if (timeout_secs) {
- vshDebug(ctl, VSH_ERR_DEBUG,
- "watchJob: setting timeout of %d secs\n", timeout_secs);
- timeout_src = g_timeout_source_new_seconds(timeout_secs);
- g_source_set_callback(timeout_src,
- virshWatchTimeout,
- &data, NULL);
- g_source_attach(timeout_src,
- g_main_loop_get_context(eventLoop));
+ g_source_attach(stdin_src, data.context);
}
progress_src = g_timeout_source_new(500);
g_source_set_callback(progress_src,
virshWatchProgress,
&data, NULL);
- g_source_attach(progress_src,
- g_main_loop_get_context(eventLoop));
+ g_source_attach(progress_src, data.context);
g_main_loop_run(eventLoop);
@@ -4420,8 +4433,10 @@ virshWatchJob(vshControl *ctl,
if (*job_err == 0 && verbose) /* print [100 %] */
virshPrintJobProgress(label, 0, 1);
- if (timeout_src)
- g_source_destroy(timeout_src);
+ if (data.timeout_src) {
+ g_source_destroy(data.timeout_src);
+ g_source_unref(data.timeout_src);
+ }
g_source_destroy(progress_src);
if (stdin_src)
g_source_destroy(stdin_src);
--
2.47.0
3 weeks, 5 days
[PATCH] ch: Enable user aliases
by Praveen K Paladugu
Enable parsing user aliases in ch driver.
Signed-off-by: Praveen K Paladugu <praveenkpaladugu(a)gmail.com>
---
src/ch/ch_domain.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/ch/ch_domain.c b/src/ch/ch_domain.c
index bfccabed49..4f5966adce 100644
--- a/src/ch/ch_domain.c
+++ b/src/ch/ch_domain.c
@@ -284,7 +284,8 @@ virDomainDefParserConfig virCHDriverDomainDefParserConfig = {
.domainPostParseBasicCallback = virCHDomainDefPostParseBasic,
.domainPostParseCallback = virCHDomainDefPostParse,
.deviceValidateCallback = chValidateDomainDeviceDef,
- .features = VIR_DOMAIN_DEF_FEATURE_NO_STUB_CONSOLE,
+ .features = VIR_DOMAIN_DEF_FEATURE_NO_STUB_CONSOLE |
+ VIR_DOMAIN_DEF_FEATURE_USER_ALIAS,
};
virCHMonitor *
--
2.47.0
3 weeks, 5 days
[PATCH v4 0/5] ch: handle events from cloud-hypervisor
by Purna Pavan Chandra Aekkaladevi
changes from v3->v4:
* Don't abort; instead kill the VM and exit
* use g_clear_pointer along with g_free
* Fix possible memory leak
* Rebase on latest master
changes from v2->v3:
* Remove patch 'utils: Implement virFileIsNamedPipe' as it is no more needed.
* Remove the eventmonitorpath only if it exists
* Added domain name as a prefix to logs from ch_events.c. This will make
debugging easier.
* Simplified event parsing logic by reserving a byte for null char.
changes from v1->v2:
* Rebase on latest master
* Use /* */ for comments
* Remove fifo file if already exists
* Address other comments from Praveen Paladugu
cloud-hypervisor raises various events, including VM lifecylce operations
such as boot, shutdown, pause, resume, etc. Libvirt will now read these
events and take the necessary actions, such as correctly updating the
domain state. A FIFO file is passed to `--event-monitor` option of
cloud-hypervisor. Libvirt creates a new thread that acts as the reader
of the fifo file and continuously monitors for new events. Currently,
shutdown events are handled by updating the domain state appropriately.
Purna Pavan Chandra Aekkaladevi (5):
ch: pass --event-monitor option to cloud-hypervisor
ch: start a new thread for handling ch events
ch: events: Read and parse cloud-hypervisor events
ch: events: facilitate lifecycle events handling
NEWS: Mention event handling support in ch driver
NEWS.rst | 7 +
po/POTFILES | 1 +
src/ch/ch_events.c | 331 ++++++++++++++++++++++++++++++++++++++++++++
src/ch/ch_events.h | 54 ++++++++
src/ch/ch_monitor.c | 52 ++++++-
src/ch/ch_monitor.h | 11 ++
src/ch/meson.build | 2 +
7 files changed, 451 insertions(+), 7 deletions(-)
create mode 100644 src/ch/ch_events.c
create mode 100644 src/ch/ch_events.h
--
2.34.1
3 weeks, 6 days
[libvirt PATCH v3] qemu: tpm: do not update profile name for transient domains
by Ján Tomko
If we do not have a persistent definition, there's no point in
looking for it since we cannot store it.
Also skip the update if the tpm device(s) in the persistent
definition are different.
This fixes the crash when starting a transient domain.
https://issues.redhat.com/browse/RHEL-69774
Fixes: d79542eec669eb9c449bb8228179e7a87e768017
Signed-off-by: Ján Tomko <jtomko(a)redhat.com>
---
src/qemu/qemu_extdevice.c | 13 ++++++++++++-
src/qemu/qemu_tpm.c | 2 +-
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/src/qemu/qemu_extdevice.c b/src/qemu/qemu_extdevice.c
index a6f31f9773..954cb323a4 100644
--- a/src/qemu/qemu_extdevice.c
+++ b/src/qemu/qemu_extdevice.c
@@ -190,7 +190,18 @@ qemuExtDevicesStart(virQEMUDriver *driver,
for (i = 0; i < def->ntpms; i++) {
virDomainTPMDef *tpm = def->tpms[i];
- virDomainTPMDef *persistentTPMDef = persistentDef->tpms[i];
+ virDomainTPMDef *persistentTPMDef = NULL;
+
+ if (persistentDef) {
+ /* do not try to update the profile in the persistent definition
+ * if the device does not match */
+ if (persistentDef->ntpms == def->ntpms)
+ persistentTPMDef = persistentDef->tpms[i];
+ if (persistentTPMDef &&
+ (persistentTPMDef->type != tpm->type ||
+ persistentTPMDef->model != tpm->model))
+ persistentTPMDef = NULL;
+ }
if (tpm->type == VIR_DOMAIN_TPM_TYPE_EMULATOR &&
qemuExtTPMStart(driver, vm, tpm, persistentTPMDef,
diff --git a/src/qemu/qemu_tpm.c b/src/qemu/qemu_tpm.c
index f223dcb9ae..f5e0184e54 100644
--- a/src/qemu/qemu_tpm.c
+++ b/src/qemu/qemu_tpm.c
@@ -773,7 +773,7 @@ qemuTPMEmulatorBuildCommand(virDomainTPMDef *tpm,
incomingMigration) < 0)
goto error;
- if (run_setup && !incomingMigration &&
+ if (run_setup && !incomingMigration && persistentTPMDef &&
qemuTPMEmulatorUpdateProfileName(&tpm->data.emulator, persistentTPMDef,
cfg, saveDef) < 0)
goto error;
--
2.47.0
3 weeks, 6 days
[libvirt PATCH v2] qemu: tpm: do not update profile name for transient domains
by Ján Tomko
If we do not have a persistent definition, there's no point in
looking for it since we cannot store it.
Also skip the update if the tpm device(s) in the persistent
definition are different.
This fixes the crash when starting a transient domain.
https://issues.redhat.com/browse/RHEL-69774
Fixes: d79542eec669eb9c449bb8228179e7a87e768017
Signed-off-by: Ján Tomko <jtomko(a)redhat.com>
---
src/qemu/qemu_extdevice.c | 12 +++++++++++-
src/qemu/qemu_tpm.c | 2 +-
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/src/qemu/qemu_extdevice.c b/src/qemu/qemu_extdevice.c
index a6f31f9773..21db01a361 100644
--- a/src/qemu/qemu_extdevice.c
+++ b/src/qemu/qemu_extdevice.c
@@ -190,7 +190,17 @@ qemuExtDevicesStart(virQEMUDriver *driver,
for (i = 0; i < def->ntpms; i++) {
virDomainTPMDef *tpm = def->tpms[i];
- virDomainTPMDef *persistentTPMDef = persistentDef->tpms[i];
+ virDomainTPMDef *persistentTPMDef = NULL;
+
+ if (persistentDef) {
+ /* do not try to update the profile in the persistent definition
+ * if the device does not match */
+ if (persistentDef->ntpms == def->ntpms)
+ persistentTPMDef = persistentDef->tpms[i];
+ if (persistentTPMDef->type != tpm->type ||
+ persistentTPMDef->model != tpm->model)
+ persistentTPMDef = NULL;
+ }
if (tpm->type == VIR_DOMAIN_TPM_TYPE_EMULATOR &&
qemuExtTPMStart(driver, vm, tpm, persistentTPMDef,
diff --git a/src/qemu/qemu_tpm.c b/src/qemu/qemu_tpm.c
index f223dcb9ae..f5e0184e54 100644
--- a/src/qemu/qemu_tpm.c
+++ b/src/qemu/qemu_tpm.c
@@ -773,7 +773,7 @@ qemuTPMEmulatorBuildCommand(virDomainTPMDef *tpm,
incomingMigration) < 0)
goto error;
- if (run_setup && !incomingMigration &&
+ if (run_setup && !incomingMigration && persistentTPMDef &&
qemuTPMEmulatorUpdateProfileName(&tpm->data.emulator, persistentTPMDef,
cfg, saveDef) < 0)
goto error;
--
2.47.0
3 weeks, 6 days
