Re: [PATCH v1] virtqemud: remove sysconfig file
On 7/16/21 2:31 AM, Olaf Hering wrote: Am Fri, 16 Jul 2021 00:58:43 -0700 schrieb Andrea Bolognani : The sysconfig files shipped with libvirt contain the defaults, and the admin is absolutely welcome to tweak them however they might like after installation, just as is the case for all the configuration files in /etc/libvirt. Right. Once they are modified for whatever reason things will go downhill. Just recently the default (for libvirtd) changed from --listen to --timeout. To clarify: that was a not-so-recent downstream change. I have an *old* downstream patch for libvirtd.sysconf that adds some (likely no longer required) SUSE metadata. I don't really recall why or how '--listen' ended up in LIBVIRTD_ARGS in that patch. And even though I removed it from the patch nearly 2 years ago, it is still biting me in the ass today :-). That said, I like the trend of moving stuff owned by packages out of /etc and might remove these files from the downstream SUSE package regardless of the outcome here. Regards, Jim
[PATCH] qemu: migration: Use correct flag when preparing block dirty bitmaps
qemuMigrationSrcRunPrepareBlockDirtyBitmaps receives the flags parameter from qemuMigrationSrcRun, where flags are based on the main API enum values. Similar to commit f58349c9c6, use the main API enum instead of internal driver enum when checking flags in qemuMigrationSrcRunPrepareBlockDirtyBitmaps. Signed-off-by: Jim Fehlig --- Noticed by visiual inspection while investigating a bug report similar to https://bugzilla.redhat.com/show_bug.cgi?id=1978526 src/qemu/qemu_migration.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c index 2ec7b7c48b..ba8c0bd2d0 100644 --- a/src/qemu/qemu_migration.c +++ b/src/qemu/qemu_migration.c @@ -3972,7 +3972,7 @@ qemuMigrationSrcRunPrepareBlockDirtyBitmaps(virDomainObj *vm, * directly, otherwise we must create merged bitmaps from the whole * chain */ -if (!(flags & QEMU_MONITOR_MIGRATE_NON_SHARED_INC) && +if (!(flags & VIR_MIGRATE_NON_SHARED_INC) && qemuMigrationSrcRunPrepareBlockDirtyBitmapsMerge(vm, mig) < 0) return -1; -- 2.31.1
[libvirt PATCH] qemu: Signal domain condition in qemuProcessStop a bit later
Signaling the condition before vm->def->id is reset to -1 is dangerous:
in case a waiting thread wakes up, it does not see anything interesting
(the domain is still marked as running) and just enters virDomainObjWait
where it waits forever because the condition will never be signalled
again.
Originally it was impossible to get into such situation because the vm
object was locked all the time between signaling the condition and
resetting vm->def->id, but after commit 860a999802 released in 6.8.0,
qemuDomainObjStopWorker called in qemuProcessStop between
virDomainObjBroadcast and setting vm->def->id to -1 unlocks the vm
object giving other threads a chance to wake up and possibly hang.
In real world, this can be easily reproduced by killing, destroying, or
just shutting down (from the guest OS) a domain while it is being
migrated somewhere else. The migration job would never finish.
We can't fix this by reseting vm->def->id earlier because other
functions (such as qemuProcessKill) do nothing when the domain is
already marked as inactive. So let's make sure we delay signaling the
domain condition to the point when a woken up thread can detect the
domain is not active anymore.
https://bugzilla.redhat.com/show_bug.cgi?id=1949869
Signed-off-by: Jiri Denemark
---
src/qemu/qemu_process.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
index c972c90801..914f936e45 100644
--- a/src/qemu/qemu_process.c
+++ b/src/qemu/qemu_process.c
@@ -7852,9 +7852,6 @@ void qemuProcessStop(virQEMUDriver *driver,
if (!!g_atomic_int_dec_and_test(>nactive) &&
driver->inhibitCallback)
driver->inhibitCallback(false, driver->inhibitOpaque);
-/* Wake up anything waiting on domain condition */
-virDomainObjBroadcast(vm);
-
if ((timestamp = virTimeStringNow()) != NULL) {
qemuDomainLogAppendMessage(driver, vm, "%s: shutting down,
reason=%s\n",
timestamp,
@@ -7925,6 +7922,9 @@ void qemuProcessStop(virQEMUDriver *driver,
vm->def->id = -1;
+/* Wake up anything waiting on domain condition */
+virDomainObjBroadcast(vm);
+
virFileDeleteTree(priv->libDir);
virFileDeleteTree(priv->channelTargetDir);
--
2.32.0
Re: Question about skipping virDomainDiskDefAssignAddress
On 7/16/21 8:51 AM, Daniel P. Berrangé wrote:
On Fri, Jul 16, 2021 at 09:49:40PM +0900, Motohiro Kawahito wrote:
From: "Daniel P. Berrangé"
To: Motohiro Kawahito
Cc: libvir-list@redhat.com
Date: 2021/07/16 17:22
Subject: [EXTERNAL] Re: Question about skipping
virDomainDiskDefAssignAddress
On Fri, Jul 16, 2021 at 01:01:50PM +0900, Motohiro Kawahito wrote:
From: "Daniel P. Berrangé"
To: Motohiro Kawahito
Cc: libvir-list@redhat.com
Date: 2021/07/16 00:42
Subject: [EXTERNAL] Re: Question about skipping
virDomainDiskDefAssignAddress
With the exception of paravirtualized Xen guests, this field in
libvirt XML is *completely* independant of the guest assigned
device name.
eg the XML might say /dev/vda, but the guest might decde to
call it /dev/sda, or /dev/whatever or really absolutely
anything.
Thank you very much for this information! I understand it.
However, I don't understand how we can pass the target device
information
(e.g. 0A80) without an error. Do you know how to do it?
My question was not good, so I opened another thread (How do we
specify
disk device names for non-Linux VMs in XML?).
There is nothing that needs passing. The guest OS decides its naming
however it wants to.
We need to control device number from user. This device number would be
used later, such as detach-disk. Can we pass device number from outside?
Detach-disk requires the same information that is provided when the
disk is first configured in libvir. This is completely separate to the
device number / name seen inside the guest.
To expand on that, in the case of detaching a disk, you could 1) provide
the target dev in the XML you give to "virsh detach-device", 2) give the
target dev name that you provided in the original XML when you call
"virsh detach-disk", or 3) you could specify a custom alias in the
original XML ("" - note that the leading
"ua-" is *required* for a custom alias name) and then give that same
alias to "virsh detach-device-alias". All three will allow you to
reliably select the disk you want, and have the same result.
Re: Question about skipping virDomainDiskDefAssignAddress
On Fri, Jul 16, 2021 at 09:49:40PM +0900, Motohiro Kawahito wrote: > > From: "Daniel P. Berrangé" > > To: Motohiro Kawahito > > Cc: libvir-list@redhat.com > > Date: 2021/07/16 17:22 > > Subject: [EXTERNAL] Re: Question about skipping > virDomainDiskDefAssignAddress > > > > On Fri, Jul 16, 2021 at 01:01:50PM +0900, Motohiro Kawahito wrote: > > > > From: "Daniel P. Berrangé" > > > > To: Motohiro Kawahito > > > > Cc: libvir-list@redhat.com > > > > Date: 2021/07/16 00:42 > > > > Subject: [EXTERNAL] Re: Question about skipping > > > virDomainDiskDefAssignAddress > > > > > > > > > > > With the exception of paravirtualized Xen guests, this field in > > > > libvirt XML is *completely* independant of the guest assigned > > > > device name. > > > > > > > > eg the XML might say /dev/vda, but the guest might decde to > > > > call it /dev/sda, or /dev/whatever or really absolutely > > > > anything. > > > > > > Thank you very much for this information! I understand it. > > > However, I don't understand how we can pass the target device > information > > > (e.g. 0A80) without an error. Do you know how to do it? > > > > > > My question was not good, so I opened another thread (How do we > specify > > > disk device names for non-Linux VMs in XML?). > > > > There is nothing that needs passing. The guest OS decides its naming > > however it wants to. > > We need to control device number from user. This device number would be > used later, such as detach-disk. Can we pass device number from outside? Detach-disk requires the same information that is provided when the disk is first configured in libvir. This is completely separate to the device number / name seen inside the guest. Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
RE: Question about skipping virDomainDiskDefAssignAddress
> From: "Daniel P. Berrangé" > To: Motohiro Kawahito > Cc: libvir-list@redhat.com > Date: 2021/07/16 17:22 > Subject: [EXTERNAL] Re: Question about skipping virDomainDiskDefAssignAddress > > On Fri, Jul 16, 2021 at 01:01:50PM +0900, Motohiro Kawahito wrote: > > > From: "Daniel P. Berrangé" > > > To: Motohiro Kawahito > > > Cc: libvir-list@redhat.com > > > Date: 2021/07/16 00:42 > > > Subject: [EXTERNAL] Re: Question about skipping > > virDomainDiskDefAssignAddress > > > > > > > > With the exception of paravirtualized Xen guests, this field in > > > libvirt XML is *completely* independant of the guest assigned > > > device name. > > > > > > eg the XML might say /dev/vda, but the guest might decde to > > > call it /dev/sda, or /dev/whatever or really absolutely > > > anything. > > > > Thank you very much for this information! I understand it. > > However, I don't understand how we can pass the target device information > > (e.g. 0A80) without an error. Do you know how to do it? > > > > My question was not good, so I opened another thread (How do we specify > > disk device names for non-Linux VMs in XML?). > > There is nothing that needs passing. The guest OS decides its naming > however it wants to. We need to control device number from user. This device number would be used later, such as detach-disk. Can we pass device number from outside? Thanks, Motohiro Kawahito, Commercial Systems, IBM Research - Tokyo 19-21 Nihonbashi, Hakozaki-cho Chuo-ku, Tokyo 103-8510, Japan "Daniel P. Berrangé" wrote on 2021/07/16 17:21:45: > From: "Daniel P. Berrangé" > To: Motohiro Kawahito > Cc: libvir-list@redhat.com > Date: 2021/07/16 17:22 > Subject: [EXTERNAL] Re: Question about skipping virDomainDiskDefAssignAddress > > On Fri, Jul 16, 2021 at 01:01:50PM +0900, Motohiro Kawahito wrote: > > > From: "Daniel P. Berrangé" > > > To: Motohiro Kawahito > > > Cc: libvir-list@redhat.com > > > Date: 2021/07/16 00:42 > > > Subject: [EXTERNAL] Re: Question about skipping > > virDomainDiskDefAssignAddress > > > > > > > > With the exception of paravirtualized Xen guests, this field in > > > libvirt XML is *completely* independant of the guest assigned > > > device name. > > > > > > eg the XML might say /dev/vda, but the guest might decde to > > > call it /dev/sda, or /dev/whatever or really absolutely > > > anything. > > > > Thank you very much for this information! I understand it. > > However, I don't understand how we can pass the target device information > > (e.g. 0A80) without an error. Do you know how to do it? > > > > My question was not good, so I opened another thread (How do we specify > > disk device names for non-Linux VMs in XML?). > > There is nothing that needs passing. The guest OS decides its naming > however it wants to. > > > Regards, > Daniel > -- > |: INVALID URI REMOVED > u=https-3A__berrange.com=DwIDaQ=jf_iaSHvJObTbx- > siA1ZOg=QxJ1l_N36pgeWfjA- > IAUp8rdIFxYQBPq2WW0vIGQ9UE=3Ydoa2LishfBM6RsL-18A7A6B0KwJq5P1Pz1HUEFVR8=tsoEpMWLZOkv2Z2JnxoZX6IhaeqbXFHXKz- > BKqYkXXo= -o-INVALID URI REMOVED > u=https-3A__www.flickr.com_photos_dberrange=DwIDaQ=jf_iaSHvJObTbx- > siA1ZOg=QxJ1l_N36pgeWfjA- > IAUp8rdIFxYQBPq2WW0vIGQ9UE=3Ydoa2LishfBM6RsL-18A7A6B0KwJq5P1Pz1HUEFVR8=q1LDnF5y7kh5TDggyuQXXkjeUIkOTCE3ZzF- > PMMUSas= :| > |: INVALID URI REMOVED > u=https-3A__libvirt.org=DwIDaQ=jf_iaSHvJObTbx- > siA1ZOg=QxJ1l_N36pgeWfjA- > IAUp8rdIFxYQBPq2WW0vIGQ9UE=3Ydoa2LishfBM6RsL-18A7A6B0KwJq5P1Pz1HUEFVR8=mHcYlrzeVj8Xfa7aOJBVzaN6xwt0UOpisCw48oHyeZE= > -o-INVALID URI REMOVED > u=https-3A__fstop138.berrange.com=DwIDaQ=jf_iaSHvJObTbx- > siA1ZOg=QxJ1l_N36pgeWfjA- > IAUp8rdIFxYQBPq2WW0vIGQ9UE=3Ydoa2LishfBM6RsL-18A7A6B0KwJq5P1Pz1HUEFVR8=X5oSjlmRkG8Q5WwavqgQCXQDLKdSReAdEnCbcqJXKTs= > :| > |: INVALID URI REMOVED > u=https-3A__entangle-2Dphoto.org=DwIDaQ=jf_iaSHvJObTbx- > siA1ZOg=QxJ1l_N36pgeWfjA- > IAUp8rdIFxYQBPq2WW0vIGQ9UE=3Ydoa2LishfBM6RsL-18A7A6B0KwJq5P1Pz1HUEFVR8=QqOu1011otltc_p- > N0vNWWAp5TthAuVvzdyew7DlF9Y= -o-https:// > urldefense.proofpoint.com/v2/url? > u=https-3A__www.instagram.com_dberrange=DwIDaQ=jf_iaSHvJObTbx- > siA1ZOg=QxJ1l_N36pgeWfjA- > IAUp8rdIFxYQBPq2WW0vIGQ9UE=3Ydoa2LishfBM6RsL-18A7A6B0KwJq5P1Pz1HUEFVR8=NIQYzwvaiBVe9ypQAT6hvfHsJGi6rI5ws3TgL_MrYx8= > :| >
[PATCH v3 0/2] domstats:add haltpolling time statistic interface
This series add the ability to statistic the halt polling time when VM execute HLT(arm is WFI). v1: https://listman.redhat.com/archives/libvir-list/2021-July/msg00029.html v2: https://listman.redhat.com/archives/libvir-list/2021-July/msg00339.html changes from v1: - Move virGetCgroupValueRaw to utils.c and rename it virGetValueRaw. So that we can call it to obtain halt polling time. - Helper function virGetCpuHaltPollTime and virGetDebugFsKvmValue are added in a separate patch - Use STRPREFIX to match the path prefix. - Fix the logic that domstats will break when platform is non-linux, debugfs isn't mounted and so on. change from v2: - Drop patch 1, use virFileReadValueUllong() to get halt polling data. - Delete unnecessary error report in logs. - Remove the qemuDomainGetStatsCpuHaltPollTime function conditionally compiled on linux. - Document the new parameters in src/libvirt-domain.c. Yang Fei (2): util: Add virGetCpuHaltPollTime qemu: Introduce qemuDomainGetStatsCpuHaltPollTime src/libvirt-domain.c | 7 +++ src/libvirt_private.syms | 1 + src/qemu/qemu_driver.c | 20 +++ src/util/virutil.c | 43 src/util/virutil.h | 4 5 files changed, 75 insertions(+) -- 2.23.0
[PATCH v3 2/2] qemu: Introduce qemuDomainGetStatsCpuHaltPollTime
This function add halt polling time interface in domstats. So that
we can use command 'virsh domstats VM' to get the data if system
support.
Signed-off-by: Yang Fei
---
src/libvirt-domain.c | 7 +++
src/qemu/qemu_driver.c | 20
2 files changed, 27 insertions(+)
diff --git a/src/libvirt-domain.c b/src/libvirt-domain.c
index 750e32f0ca..8e58c1b43f 100644
--- a/src/libvirt-domain.c
+++ b/src/libvirt-domain.c
@@ -11625,6 +11625,13 @@ virConnectGetDomainCapabilities(virConnectPtr conn,
* "cpu.user" - user cpu time spent in nanoseconds as unsigned long long.
* "cpu.system" - system cpu time spent in nanoseconds as unsigned long
*long.
+ * "haltpollsuccess.time" - halt-polling cpu usage about the VCPU polled
+ * until a virtual interrupt was delivered in
+ * nanoseconds as unsigned long long.
+ * "haltpollfail.time" - halt-polling cpu usage about the VCPU had to
schedule
+ * out (either because the maximum poll time was
reached
+ * or it needed to yield the CPU) in nanoseconds as
+ * unsigned long long.
* "cpu.cache.monitor.count" - the number of cache monitors for this domain
* "cpu.cache.monitor..name" - the name of cache monitor
* "cpu.cache.monitor..vcpus" - vcpu list of cache monitor
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index 235f575901..adb4628558 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -17839,6 +17839,23 @@ qemuDomainGetStatsCpuCgroup(virDomainObj *dom,
return 0;
}
+static int
+qemuDomainGetStatsCpuHaltPollTime(virDomainObj *dom,
+ virTypedParamList *params)
+{
+unsigned long long haltPollSuccess = 0;
+unsigned long long haltPollFail = 0;
+pid_t pid = dom->pid;
+
+if (virGetCpuHaltPollTime(pid, , ) < 0)
+return 0;
+
+if (virTypedParamListAddULLong(params, haltPollSuccess,
"haltpollsuccess.time") < 0 ||
+virTypedParamListAddULLong(params, haltPollFail, "haltpollfail.time")
< 0)
+return -1;
+
+return 0;
+}
static int
qemuDomainGetStatsCpu(virQEMUDriver *driver,
@@ -17852,6 +17869,9 @@ qemuDomainGetStatsCpu(virQEMUDriver *driver,
if (qemuDomainGetStatsCpuCache(driver, dom, params) < 0)
return -1;
+if (qemuDomainGetStatsCpuHaltPollTime(dom, params) < 0)
+return -1;
+
return 0;
}
--
2.23.0
[PATCH v3 1/2] util: Add virGetCpuHaltPollTime
Add helper function virGetCpuHaltPollTime to obtain halt polling
time. If the kernel support halt polling time statistic, and mount
debugfs. This function will take effect on KVM VMs.
Signed-off-by: Yang Fei
---
src/libvirt_private.syms | 1 +
src/util/virutil.c | 43
src/util/virutil.h | 4
3 files changed, 48 insertions(+)
diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms
index 68e4b6aab8..64aff4eca4 100644
--- a/src/libvirt_private.syms
+++ b/src/libvirt_private.syms
@@ -3479,6 +3479,7 @@ virDoesUserExist;
virDoubleToStr;
virFormatIntDecimal;
virFormatIntPretty;
+virGetCpuHaltPollTime;
virGetDeviceID;
virGetDeviceUnprivSGIO;
virGetGroupID;
diff --git a/src/util/virutil.c b/src/util/virutil.c
index 311cbbf93a..f5304644c0 100644
--- a/src/util/virutil.c
+++ b/src/util/virutil.c
@@ -1936,3 +1936,46 @@ virPipeNonBlock(int fds[2])
{
return virPipeImpl(fds, true, true);
}
+
+int
+virGetCpuHaltPollTime(pid_t pid,
+ unsigned long long *haltPollSuccess,
+ unsigned long long *haltPollFail)
+{
+g_autofree char *pidToStr = NULL;
+g_autofree char *debugFsPath = NULL;
+g_autofree char *completePath = NULL;
+struct dirent *ent = NULL;
+g_autoptr(DIR) dir = NULL;
+int ret = -1;
+bool found = false;
+
+if (!(debugFsPath = virFileFindMountPoint("debugfs")))
+return ret;
+
+completePath = g_strdup_printf("%s/%s", debugFsPath, "kvm");
+if (virDirOpenIfExists(, completePath) != 1)
+return ret;
+
+pidToStr = g_strdup_printf("%d%c", pid, '-');
+while (virDirRead(dir, , NULL) > 0) {
+if (STRPREFIX(ent->d_name, pidToStr)) {
+found = true;
+break;
+}
+}
+
+if (!found)
+return ret;
+
+if (virFileReadValueUllong(haltPollSuccess, "%s/%s/%s", completePath,
+ ent->d_name, "halt_poll_success_ns") < 0
+|| virFileReadValueUllong(haltPollFail, "%s/%s/%s", completePath,
+ ent->d_name, "halt_poll_fail_ns") < 0) {
+return ret;
+}
+
+ret = 0;
+
+return ret;
+}
diff --git a/src/util/virutil.h b/src/util/virutil.h
index 854b494890..03b225185f 100644
--- a/src/util/virutil.h
+++ b/src/util/virutil.h
@@ -225,3 +225,7 @@ int virPipeQuiet(int fds[2]);
* Returns: -1 on error, 0 on success
*/
int virPipeNonBlock(int fds[2]);
+
+int virGetCpuHaltPollTime(pid_t pid,
+ unsigned long long *haltPollSuccess,
+ unsigned long long *haltPollFail);
--
2.23.0
[PATCH] docs: fixup for patch 09/11
Please use this as fixup. Signed-off-by: Boris Fiuczynski --- docs/formatdomaincaps.html.in | 21 +++-- 1 file changed, 11 insertions(+), 10 deletions(-) diff --git a/docs/formatdomaincaps.html.in b/docs/formatdomaincaps.html.in index 30a95d5594..5dbdb25849 100644 --- a/docs/formatdomaincaps.html.in +++ b/docs/formatdomaincaps.html.in @@ -638,16 +638,6 @@ (Since 5.10) -s390-pv capability - -Reports whether the hypervisor supports the Protected Virtualization. -In order to use Protected Virtualization with libvirt have a look at the -launchSecurity element in the -domain XML. For more details on the Protected Virtualization feature -please see Protected -Virtualization on s390. - - backup Reports whether the hypervisor supports the backup, checkpoint, and @@ -658,6 +648,17 @@ virDomainUndefine is supported. +s390-pv capability + +Reports whether the hypervisor supports the Protected Virtualization. +In order to use Protected Virtualization with libvirt have a look at the +launchSecurity element in the +domain XML. For more details on the Protected Virtualization feature +please see Protected +Virtualization on s390. +(Since 7.6.0) + + SEV capabilities AMD Secure Encrypted Virtualization (SEV) capabilities are exposed under -- 2.31.1
[PATCH 1/2] docs: Allow 'id' attribute for 'cachetune' element
Even though 'id' attribute is output-only, we should accept xml files containing it. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1941594 Signed-off-by: Kristina Hanicova --- docs/formatdomain.rst | 2 +- docs/schemas/domaincommon.rng | 5 + 2 files changed, 6 insertions(+), 1 deletion(-) diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst index 25e6bf73ba..d3c91c2a6d 100644 --- a/docs/formatdomain.rst +++ b/docs/formatdomain.rst @@ -850,7 +850,7 @@ CPU Tuning to which vCPUs this allocation applies. A vCPU can only be member of one ``cachetune`` element allocation. The vCPUs specified by cachetune can be identical with those in memorytune, however they are not allowed to overlap. - Supported subelements are: + The optional attribute ``id`` is output only. Supported subelements are: ``cache`` This optional element controls the allocation of CPU cache and has the diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng index 5ea14b6dbf..c6643bbc7f 100644 --- a/docs/schemas/domaincommon.rng +++ b/docs/schemas/domaincommon.rng @@ -1006,6 +1006,11 @@ + + + + + -- 2.31.1
[PATCH 0/2] Add support for 'id' attribute for 'cachetune' element
Kristina Hanicova (2): docs: Allow 'id' attribute for 'cachetune' element tests: Modify to test output value of
[PATCH 2/2] tests: Modify to test output value of
We can also delete out xml thanks to the change in the call of
the test to DO_TEST instead of DO_TEST_DIFFERENT.
Signed-off-by: Kristina Hanicova
---
tests/genericxml2xmlindata/cachetune.xml | 8 +++---
tests/genericxml2xmloutdata/cachetune.xml | 34 ---
tests/genericxml2xmltest.c| 2 +-
3 files changed, 5 insertions(+), 39 deletions(-)
delete mode 100644 tests/genericxml2xmloutdata/cachetune.xml
diff --git a/tests/genericxml2xmlindata/cachetune.xml
b/tests/genericxml2xmlindata/cachetune.xml
index 40259cf2ee..07e81999a5 100644
--- a/tests/genericxml2xmlindata/cachetune.xml
+++ b/tests/genericxml2xmlindata/cachetune.xml
@@ -1,16 +1,16 @@
-
+
QEMUGuest1
c7a5fdbd-edaf-9455-926a-d65c16db1809
219136
219136
4
-
-
+
+
-
+
diff --git a/tests/genericxml2xmloutdata/cachetune.xml
b/tests/genericxml2xmloutdata/cachetune.xml
deleted file mode 100644
index f05cab70ff..00
--- a/tests/genericxml2xmloutdata/cachetune.xml
+++ /dev/null
@@ -1,34 +0,0 @@
-
- QEMUGuest1
- c7a5fdbd-edaf-9455-926a-d65c16db1809
- 219136
- 219136
- 4
-
-
-
-
-
-
-
-
-
-
-
-hvm
-
-
-
- destroy
- restart
- destroy
-
-/usr/bin/qemu-system-i386
-
-
-
-
-
-
-
-
diff --git a/tests/genericxml2xmltest.c b/tests/genericxml2xmltest.c
index ac89422a32..17448a3465 100644
--- a/tests/genericxml2xmltest.c
+++ b/tests/genericxml2xmltest.c
@@ -214,7 +214,7 @@ mymain(void)
DO_TEST("cachetune-small");
DO_TEST("cachetune-cdp");
-DO_TEST_DIFFERENT("cachetune");
+DO_TEST("cachetune");
DO_TEST_DIFFERENT("cachetune-extra-tunes");
DO_TEST_FULL("cachetune-colliding-allocs", false, true,
TEST_COMPARE_DOM_XML2XML_RESULT_FAIL_PARSE);
--
2.31.1
Re: [PATCH v1] virtqemud: remove sysconfig file
Am Fri, 16 Jul 2021 00:58:43 -0700 schrieb Andrea Bolognani : > This arrangement appears to be very common, too: on my Fedora 34 > machine, /etc/sysconfig contains ~25 files, all owned by some package > and most consisting of at least one non-comment lines. Forgot to reply to this paragraph: None of the files in /etc have to be owned by a package. We are slowly getting there. /etc/sysconfig is not owned by any package, it is entirely maintained by the admin. Olaf pgpCHyS_Br75E.pgp Description: Digitale Signatur von OpenPGP
[PATCH v5 08/11] conf: Add availability of s390-pv in domain capabilities
Adding availability of s390-pv in domain capabilities and adjust tests.
Signed-off-by: Boris Fiuczynski
---
docs/schemas/domaincaps.rng| 9 +
src/conf/domain_capabilities.c | 1 +
src/conf/domain_capabilities.h | 1 +
src/qemu/qemu_capabilities.c | 16
tests/domaincapsdata/qemu_2.11.0.s390x.xml | 1 +
tests/domaincapsdata/qemu_2.12.0.s390x.xml | 1 +
tests/domaincapsdata/qemu_3.0.0.s390x.xml | 1 +
tests/domaincapsdata/qemu_4.0.0.s390x.xml | 1 +
tests/domaincapsdata/qemu_4.2.0.s390x.xml | 1 +
tests/domaincapsdata/qemu_5.2.0.s390x.xml | 1 +
tests/domaincapsdata/qemu_6.0.0.s390x.xml | 1 +
tests/domaincapsmock.c | 17 +
12 files changed, 51 insertions(+)
diff --git a/docs/schemas/domaincaps.rng b/docs/schemas/domaincaps.rng
index 69d7824e7c..8b5267f741 100644
--- a/docs/schemas/domaincaps.rng
+++ b/docs/schemas/domaincaps.rng
@@ -257,6 +257,9 @@
+
+
+
@@ -294,6 +297,12 @@
+
+
+
+
+
+
diff --git a/src/conf/domain_capabilities.c b/src/conf/domain_capabilities.c
index 73139d0ec6..22f0963326 100644
--- a/src/conf/domain_capabilities.c
+++ b/src/conf/domain_capabilities.c
@@ -42,6 +42,7 @@ VIR_ENUM_IMPL(virDomainCapsFeature,
"genid",
"backingStoreInput",
"backup",
+ "s390-pv",
);
static virClass *virDomainCapsClass;
diff --git a/src/conf/domain_capabilities.h b/src/conf/domain_capabilities.h
index a3765832c1..d44acdcd01 100644
--- a/src/conf/domain_capabilities.h
+++ b/src/conf/domain_capabilities.h
@@ -186,6 +186,7 @@ typedef enum {
VIR_DOMAIN_CAPS_FEATURE_GENID,
VIR_DOMAIN_CAPS_FEATURE_BACKING_STORE_INPUT,
VIR_DOMAIN_CAPS_FEATURE_BACKUP,
+VIR_DOMAIN_CAPS_FEATURE_S390_PV,
VIR_DOMAIN_CAPS_FEATURE_LAST
} virDomainCapsFeature;
diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index a0f04bb44c..6deeab8a12 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -6335,6 +6335,21 @@ virQEMUCapsFillDomainFeatureSEVCaps(virQEMUCaps
*qemuCaps,
}
+static void
+virQEMUCapsFillDomainFeatureS390PVCaps(virQEMUCaps *qemuCaps,
+ virDomainCaps *domCaps)
+{
+if (ARCH_IS_S390(qemuCaps->arch)) {
+if (virQEMUCapsGet(qemuCaps,
QEMU_CAPS_MACHINE_CONFIDENTAL_GUEST_SUPPORT) &&
+virQEMUCapsGet(qemuCaps, QEMU_CAPS_S390_PV_GUEST) &&
+virQEMUCapsGetKVMSupportsSecureGuest(qemuCaps))
+domCaps->features[VIR_DOMAIN_CAPS_FEATURE_S390_PV] =
VIR_TRISTATE_BOOL_YES;
+else
+domCaps->features[VIR_DOMAIN_CAPS_FEATURE_S390_PV] =
VIR_TRISTATE_BOOL_NO;
+}
+}
+
+
int
virQEMUCapsFillDomainCaps(virQEMUCaps *qemuCaps,
virArch hostarch,
@@ -6383,6 +6398,7 @@ virQEMUCapsFillDomainCaps(virQEMUCaps *qemuCaps,
virQEMUCapsFillDomainDeviceFSCaps(qemuCaps, filesystem);
virQEMUCapsFillDomainFeatureGICCaps(qemuCaps, domCaps);
virQEMUCapsFillDomainFeatureSEVCaps(qemuCaps, domCaps);
+virQEMUCapsFillDomainFeatureS390PVCaps(qemuCaps, domCaps);
return 0;
}
diff --git a/tests/domaincapsdata/qemu_2.11.0.s390x.xml
b/tests/domaincapsdata/qemu_2.11.0.s390x.xml
index 9593fa17b7..a52e436538 100644
--- a/tests/domaincapsdata/qemu_2.11.0.s390x.xml
+++ b/tests/domaincapsdata/qemu_2.11.0.s390x.xml
@@ -212,6 +212,7 @@
+
diff --git a/tests/domaincapsdata/qemu_2.12.0.s390x.xml
b/tests/domaincapsdata/qemu_2.12.0.s390x.xml
index f5851b9e23..f289a4893c 100644
--- a/tests/domaincapsdata/qemu_2.12.0.s390x.xml
+++ b/tests/domaincapsdata/qemu_2.12.0.s390x.xml
@@ -212,6 +212,7 @@
+
diff --git a/tests/domaincapsdata/qemu_3.0.0.s390x.xml
b/tests/domaincapsdata/qemu_3.0.0.s390x.xml
index c298d6bf71..2aa34677c0 100644
--- a/tests/domaincapsdata/qemu_3.0.0.s390x.xml
+++ b/tests/domaincapsdata/qemu_3.0.0.s390x.xml
@@ -219,6 +219,7 @@
+
diff --git a/tests/domaincapsdata/qemu_4.0.0.s390x.xml
b/tests/domaincapsdata/qemu_4.0.0.s390x.xml
index f1f4151635..ede04824e9 100644
--- a/tests/domaincapsdata/qemu_4.0.0.s390x.xml
+++ b/tests/domaincapsdata/qemu_4.0.0.s390x.xml
@@ -229,6 +229,7 @@
+
diff --git a/tests/domaincapsdata/qemu_4.2.0.s390x.xml
b/tests/domaincapsdata/qemu_4.2.0.s390x.xml
index febda17e6c..f344b289b2 100644
--- a/tests/domaincapsdata/qemu_4.2.0.s390x.xml
+++ b/tests/domaincapsdata/qemu_4.2.0.s390x.xml
@@ -244,6 +244,7 @@
+
diff --git a/tests/domaincapsdata/qemu_5.2.0.s390x.xml
b/tests/domaincapsdata/qemu_5.2.0.s390x.xml
index 2d389c4c89..c30de65f88 100644
--- a/tests/domaincapsdata/qemu_5.2.0.s390x.xml
+++ b/tests/domaincapsdata/qemu_5.2.0.s390x.xml
@@ -246,6
[PATCH v5 00/11] Support for launchSecurity type s390-pv
This patch series introduces the launch security type s390-pv. Specifying s390-pv as launch security type in an s390 domain prepares for running the guest in protected virtualization secure mode, also known as IBM Secure Execution. diff to v4: - changed rng to do the verification for every launchSecurity type - removed previously added XML fail tests - added domain capability documentation diff to v3: - rebased to current master - moved virDomainSEVDef into a union - improved XML formating for launchSecurity - use a shared id on the qemu cmd line for confidential-guest-support - added check for s390-pv host support into XML validation - changed from ignoring to failing if launchSecuroty child elements are provided for s390-pv - reduced test to a single failing test - add availability of s390-pv in domain capabilities diff to v2: - broke up previous patch one into three patches diff to v1: - rebased to current master - added verification check for confidential-guest-support capability Boris Fiuczynski (11): schemas: Refactor launch security conf: Rework SEV XML parse and format methods qemu: Make KVMSupportsSecureGuest capability available conf: Refactor launch security to allow more types qemu: Add s390-pv-guest capability conf: Add s390-pv as launch security type docs: Add s390-pv documentation conf: Add availability of s390-pv in domain capabilities docs: Add s390-pv in domain capabilities documentation qemu: Use common id lsec0 for launchSecurity qemu: Fix error code for SEV launchSecurity unsupported docs/formatdomain.rst | 7 + docs/formatdomaincaps.html.in | 10 ++ docs/kbase/s390_protected_virt.rst| 55 ++-- docs/schemas/domaincaps.rng | 9 ++ docs/schemas/domaincommon.rng | 79 ++- src/conf/domain_capabilities.c| 1 + src/conf/domain_capabilities.h| 1 + src/conf/domain_conf.c| 130 -- src/conf/domain_conf.h| 17 ++- src/conf/virconftypes.h | 2 + src/qemu/qemu_capabilities.c | 24 src/qemu/qemu_capabilities.h | 4 + src/qemu/qemu_cgroup.c| 4 +- src/qemu/qemu_command.c | 75 -- src/qemu/qemu_driver.c| 3 +- src/qemu/qemu_firmware.c | 33 +++-- src/qemu/qemu_namespace.c | 21 ++- src/qemu/qemu_process.c | 35 - src/qemu/qemu_validate.c | 32 - src/security/security_dac.c | 6 +- tests/domaincapsdata/qemu_2.11.0.s390x.xml| 1 + tests/domaincapsdata/qemu_2.12.0.s390x.xml| 1 + tests/domaincapsdata/qemu_3.0.0.s390x.xml | 1 + tests/domaincapsdata/qemu_4.0.0.s390x.xml | 1 + tests/domaincapsdata/qemu_4.2.0.s390x.xml | 1 + tests/domaincapsdata/qemu_5.2.0.s390x.xml | 1 + tests/domaincapsdata/qemu_6.0.0.s390x.xml | 1 + tests/domaincapsmock.c| 17 +++ .../launch-security-s390-pv.xml | 18 +++ tests/genericxml2xmltest.c| 1 + .../qemucapabilitiesdata/caps_6.0.0.s390x.xml | 1 + .../launch-security-s390-pv.s390x-latest.args | 35 + .../launch-security-s390-pv.xml | 30 ...v-missing-platform-info.x86_64-2.12.0.args | 4 +- .../launch-security-sev.x86_64-2.12.0.args| 4 +- .../launch-security-sev.x86_64-6.0.0.args | 4 +- tests/qemuxml2argvmock.c | 16 +++ tests/qemuxml2argvtest.c | 2 + 38 files changed, 552 insertions(+), 135 deletions(-) create mode 100644 tests/genericxml2xmlindata/launch-security-s390-pv.xml create mode 100644 tests/qemuxml2argvdata/launch-security-s390-pv.s390x-latest.args create mode 100644 tests/qemuxml2argvdata/launch-security-s390-pv.xml -- 2.31.1
[PATCH v5 05/11] qemu: Add s390-pv-guest capability
Add s390-pv-guest capability.
Signed-off-by: Boris Fiuczynski
Reviewed-by: Daniel Henrique Barboza
Reviewed-by: Pavel Hrdina
---
src/qemu/qemu_capabilities.c| 2 ++
src/qemu/qemu_capabilities.h| 1 +
tests/qemucapabilitiesdata/caps_6.0.0.s390x.xml | 1 +
3 files changed, 4 insertions(+)
diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index 814a2bab4a..a0f04bb44c 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -636,6 +636,7 @@ VIR_ENUM_IMPL(virQEMUCaps,
/* 405 */
"confidential-guest-support",
"query-display-options",
+ "s390-pv-guest",
);
@@ -1354,6 +1355,7 @@ struct virQEMUCapsStringFlags virQEMUCapsObjectTypes[] = {
{ "input-linux", QEMU_CAPS_INPUT_LINUX },
{ "virtio-gpu-gl-pci", QEMU_CAPS_VIRTIO_GPU_GL_PCI },
{ "virtio-vga-gl", QEMU_CAPS_VIRTIO_VGA_GL },
+{ "s390-pv-guest", QEMU_CAPS_S390_PV_GUEST },
};
diff --git a/src/qemu/qemu_capabilities.h b/src/qemu/qemu_capabilities.h
index d97e36696d..2b1bb57a49 100644
--- a/src/qemu/qemu_capabilities.h
+++ b/src/qemu/qemu_capabilities.h
@@ -616,6 +616,7 @@ typedef enum { /* virQEMUCapsFlags grouping marker for
syntax-check */
/* 405 */
QEMU_CAPS_MACHINE_CONFIDENTAL_GUEST_SUPPORT, /* -machine
confidential-guest-support */
QEMU_CAPS_QUERY_DISPLAY_OPTIONS, /* 'query-display-options' qmp command
present */
+QEMU_CAPS_S390_PV_GUEST, /* -object s390-pv-guest,... */
QEMU_CAPS_LAST /* this must always be the last item */
} virQEMUCapsFlags;
diff --git a/tests/qemucapabilitiesdata/caps_6.0.0.s390x.xml
b/tests/qemucapabilitiesdata/caps_6.0.0.s390x.xml
index 1806c064c9..aae6364e37 100644
--- a/tests/qemucapabilitiesdata/caps_6.0.0.s390x.xml
+++ b/tests/qemucapabilitiesdata/caps_6.0.0.s390x.xml
@@ -169,6 +169,7 @@
+
600
0
39100242
--
2.31.1
[PATCH v5 07/11] docs: Add s390-pv documentation
Add documentation for launch security type s390-pv.
Signed-off-by: Boris Fiuczynski
Reviewed-by: Daniel Henrique Barboza
---
docs/formatdomain.rst | 7
docs/kbase/s390_protected_virt.rst | 55 +-
2 files changed, 54 insertions(+), 8 deletions(-)
diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst
index 25e6bf73ba..4c3c24d9df 100644
--- a/docs/formatdomain.rst
+++ b/docs/formatdomain.rst
@@ -8081,6 +8081,13 @@ Note: DEA/TDEA is synonymous with DES/TDES.
Launch Security
---
+Specifying in a s390 domain prepares
+the guest to run in protected virtualization secure mode, also known as
+IBM Secure Execution. For more required host and guest preparation steps, see
+`Protected Virtualization on s390 `__
+:since:`Since 7.6.0`
+
+
The contents of the element is used to provide
the guest owners input used for creating an encrypted VM using the AMD SEV
feature (Secure Encrypted Virtualization). SEV is an extension to the AMD-V
diff --git a/docs/kbase/s390_protected_virt.rst
b/docs/kbase/s390_protected_virt.rst
index 1718a556d4..4cbdeea7ed 100644
--- a/docs/kbase/s390_protected_virt.rst
+++ b/docs/kbase/s390_protected_virt.rst
@@ -127,10 +127,13 @@ Protected virtualization guests support I/O using virtio
devices.
As the virtio data structures of secure guests are not accessible
by the host, it is necessary to use shared memory ('bounce buffers').
-To enable virtio devices to use shared buffers, it is necessary
-to configure them with platform_iommu enabled. This can done by adding
-``iommu='on'`` to the driver element of a virtio device definition in the
-guest's XML, e.g.
+Since libvirt 7.6.0 the
+` `__
+element with type ``s390-pv`` should be used on protected virtualization
guests.
+Without ``launchSecurity`` you must enable all virtio devices to use shared
+buffers by configuring them with platform_iommu enabled.
+This can done by adding ``iommu='on'`` to the driver element of a virtio
+device definition in the guest's XML, e.g.
::
@@ -140,8 +143,10 @@ guest's XML, e.g.
-It is mandatory to define all virtio bus devices in this way to
-prevent the host from attempting to access protected memory.
+Unless you are using ``launchSecurity`` you must define all virtio bus
+devices in this way to prevent the host from attempting to access
+protected memory.
+
Ballooning will not work and is fenced by QEMU. It should be
disabled by specifying
@@ -158,8 +163,42 @@ allocated 2K entries. A commonly used value for swiotlb is
262144.
Example guest definition
-Minimal domain XML for a protected virtualization guest, essentially
-it's mostly about the ``iommu`` property
+Minimal domain XML for a protected virtualization guest with
+the ``launchSecurity`` element of type ``s390-pv``
+
+::
+
+
+ protected
+ 2048000
+ 2048000
+ 1
+
+ hvm
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Example guest definition without launchSecurity
+===
+
+Minimal domain XML for a protected virtualization guest using the
+``iommu='on'`` setting for each virtio device.
::
--
2.31.1
[PATCH v5 09/11] docs: Add s390-pv in domain capabilities documentation
Add documentation for domain capability s390-pv. Signed-off-by: Boris Fiuczynski --- docs/formatdomaincaps.html.in | 10 ++ 1 file changed, 10 insertions(+) diff --git a/docs/formatdomaincaps.html.in b/docs/formatdomaincaps.html.in index 10d23f4c0b..30a95d5594 100644 --- a/docs/formatdomaincaps.html.in +++ b/docs/formatdomaincaps.html.in @@ -638,6 +638,16 @@ (Since 5.10) +s390-pv capability + +Reports whether the hypervisor supports the Protected Virtualization. +In order to use Protected Virtualization with libvirt have a look at the +launchSecurity element in the +domain XML. For more details on the Protected Virtualization feature +please see Protected +Virtualization on s390. + + backup Reports whether the hypervisor supports the backup, checkpoint, and -- 2.31.1
[PATCH v5 11/11] qemu: Fix error code for SEV launchSecurity unsupported
When SEV is not supported but specified in the domain XML by a user it
should not result in an internal error (VIR_ERR_INTERNAL_ERROR)
therefore switching to XML error (VIR_ERR_CONFIG_UNSUPPORTED).
Signed-off-by: Boris Fiuczynski
---
src/qemu/qemu_validate.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/qemu/qemu_validate.c b/src/qemu/qemu_validate.c
index 7482bedee6..bb672727d5 100644
--- a/src/qemu/qemu_validate.c
+++ b/src/qemu/qemu_validate.c
@@ -1218,7 +1218,7 @@ qemuValidateDomainDef(const virDomainDef *def,
switch ((virDomainLaunchSecurity) def->sec->sectype) {
case VIR_DOMAIN_LAUNCH_SECURITY_SEV:
if (!virQEMUCapsGet(qemuCaps, QEMU_CAPS_SEV_GUEST)) {
-virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
+virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
_("SEV launch security is not supported with "
"this QEMU binary"));
return -1;
--
2.31.1
[PATCH v5 03/11] qemu: Make KVMSupportsSecureGuest capability available
Expose existing KVMSupportsSecureGuest capability.
Signed-off-by: Boris Fiuczynski
---
src/qemu/qemu_capabilities.c | 6 ++
src/qemu/qemu_capabilities.h | 3 +++
2 files changed, 9 insertions(+)
diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index e0c3a07568..814a2bab4a 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -2136,6 +2136,12 @@ const char *virQEMUCapsGetPackage(virQEMUCaps *qemuCaps)
}
+bool virQEMUCapsGetKVMSupportsSecureGuest(virQEMUCaps *qemuCaps)
+{
+return qemuCaps->kvmSupportsSecureGuest;
+}
+
+
int
virQEMUCapsAddCPUDefinitions(virQEMUCaps *qemuCaps,
virDomainVirtType type,
diff --git a/src/qemu/qemu_capabilities.h b/src/qemu/qemu_capabilities.h
index 368883f861..d97e36696d 100644
--- a/src/qemu/qemu_capabilities.h
+++ b/src/qemu/qemu_capabilities.h
@@ -808,5 +808,8 @@ virQEMUCapsCPUFeatureFromQEMU(virQEMUCaps *qemuCaps,
virSEVCapability *
virQEMUCapsGetSEVCapabilities(virQEMUCaps *qemuCaps);
+bool
+virQEMUCapsGetKVMSupportsSecureGuest(virQEMUCaps *qemuCaps) G_GNUC_NO_INLINE;
+
virArch virQEMUCapsArchFromString(const char *arch);
const char *virQEMUCapsArchToString(virArch arch);
--
2.31.1
[PATCH v5 10/11] qemu: Use common id lsec0 for launchSecurity
Use the common id 'lsec0' for all launchSecurity types in the QEMU
command line construction.
Signed-off-by: Boris Fiuczynski
---
src/qemu/qemu_command.c| 10 +-
.../launch-security-s390-pv.s390x-latest.args | 4 ++--
...curity-sev-missing-platform-info.x86_64-2.12.0.args | 4 ++--
.../launch-security-sev.x86_64-2.12.0.args | 4 ++--
.../launch-security-sev.x86_64-6.0.0.args | 4 ++--
5 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index 513bd52a6c..db78deb122 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -6971,13 +6971,13 @@ qemuBuildMachineCommandLine(virCommand *cmd,
switch ((virDomainLaunchSecurity) def->sec->sectype) {
case VIR_DOMAIN_LAUNCH_SECURITY_SEV:
if (virQEMUCapsGet(qemuCaps,
QEMU_CAPS_MACHINE_CONFIDENTAL_GUEST_SUPPORT)) {
-virBufferAddLit(, ",confidential-guest-support=sev0");
+virBufferAddLit(, ",confidential-guest-support=lsec0");
} else {
-virBufferAddLit(, ",memory-encryption=sev0");
+virBufferAddLit(, ",memory-encryption=lsec0");
}
break;
case VIR_DOMAIN_LAUNCH_SECURITY_PV:
-virBufferAddLit(, ",confidential-guest-support=pv0");
+virBufferAddLit(, ",confidential-guest-support=lsec0");
break;
case VIR_DOMAIN_LAUNCH_SECURITY_NONE:
break;
@@ -9859,7 +9859,7 @@ qemuBuildSEVCommandLine(virDomainObj *vm, virCommand *cmd,
if (sev->session)
sessionpath = g_strdup_printf("%s/session.base64", priv->libDir);
-if (qemuMonitorCreateObjectProps(, "sev-guest", "sev0",
+if (qemuMonitorCreateObjectProps(, "sev-guest", "lsec0",
"u:cbitpos", sev->cbitpos,
"u:reduced-phys-bits",
sev->reduced_phys_bits,
"u:policy", sev->policy,
@@ -9884,7 +9884,7 @@ qemuBuildPVCommandLine(virDomainObj *vm, virCommand *cmd)
g_auto(virBuffer) buf = VIR_BUFFER_INITIALIZER;
qemuDomainObjPrivate *priv = vm->privateData;
-if (qemuMonitorCreateObjectProps(, "s390-pv-guest", "pv0",
+if (qemuMonitorCreateObjectProps(, "s390-pv-guest", "lsec0",
NULL) < 0)
return -1;
diff --git a/tests/qemuxml2argvdata/launch-security-s390-pv.s390x-latest.args
b/tests/qemuxml2argvdata/launch-security-s390-pv.s390x-latest.args
index c9d9b84dd3..cb0dac0149 100644
--- a/tests/qemuxml2argvdata/launch-security-s390-pv.s390x-latest.args
+++ b/tests/qemuxml2argvdata/launch-security-s390-pv.s390x-latest.args
@@ -10,7 +10,7 @@ XDG_CONFIG_HOME=/tmp/lib/domain--1-QEMUGuest1/.config \
-name guest=QEMUGuest1,debug-threads=on \
-S \
-object
'{"qom-type":"secret","id":"masterKey0","format":"raw","file":"/tmp/lib/domain--1-QEMUGuest1/master-key.aes"}'
\
--machine
s390-ccw-virtio,accel=kvm,usb=off,dump-guest-core=off,confidential-guest-support=pv0,memory-backend=s390.ram
\
+-machine
s390-ccw-virtio,accel=kvm,usb=off,dump-guest-core=off,confidential-guest-support=lsec0,memory-backend=s390.ram
\
-cpu
gen15a-base,aen=on,cmmnt=on,vxpdeh=on,aefsi=on,diag318=on,csske=on,mepoch=on,msa9=on,msa8=on,msa7=on,msa6=on,msa5=on,msa4=on,msa3=on,msa2=on,msa1=on,sthyi=on,edat=on,ri=on,deflate=on,edat2=on,etoken=on,vx=on,ipter=on,mepochptff=on,ap=on,vxeh=on,vxpd=on,esop=on,msa9_pckmo=on,vxeh2=on,esort=on,apqi=on,apft=on,els=on,iep=on,apqci=on,cte=on,ais=on,bpb=on,gs=on,ppa15=on,zpci=on,sea_esop2=on,te=on,cmm=on
\
-m 214 \
-object '{"qom-type":"memory-backend-ram","id":"s390.ram","size":224395264}' \
@@ -30,6 +30,6 @@ XDG_CONFIG_HOME=/tmp/lib/domain--1-QEMUGuest1/.config \
-device
virtio-blk-ccw,devno=fe.0.,drive=libvirt-1-format,id=virtio-disk0,bootindex=1
\
-audiodev id=audio1,driver=none \
-device virtio-balloon-ccw,id=balloon0,devno=fe.0.0001 \
--object '{"qom-type":"s390-pv-guest","id":"pv0"}' \
+-object '{"qom-type":"s390-pv-guest","id":"lsec0"}' \
-sandbox
on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \
-msg timestamp=on
diff --git
a/tests/qemuxml2argvdata/launch-security-sev-missing-platform-info.x86_64-2.12.0.args
b/tests/qemuxml2argvdata/launch-security-sev-missing-platform-info.x86_64-2.12.0.args
index 4e281e2e59..daa271c35c 100644
---
a/tests/qemuxml2argvdata/launch-security-sev-missing-platform-info.x86_64-2.12.0.args
+++
b/tests/qemuxml2argvdata/launch-security-sev-missing-platform-info.x86_64-2.12.0.args
@@ -11,7 +11,7 @@ QEMU_AUDIO_DRV=none \
-name guest=QEMUGuest1,debug-threads=on \
-S \
-object
secret,id=masterKey0,format=raw,file=/tmp/lib/domain--1-QEMUGuest1/master-key.aes
\
--machine pc-1.0,accel=kvm,usb=off,dump-guest-core=off,memory-encryption=sev0 \
+-machine pc-1.0,accel=kvm,usb=off,dump-guest-core=off,memory-encryption=lsec0 \
[PATCH v5 06/11] conf: Add s390-pv as launch security type
Add launch security type 's390-pv' as well as some tests.
Signed-off-by: Boris Fiuczynski
Reviewed-by: Daniel Henrique Barboza
---
docs/schemas/domaincommon.rng | 5 +++
src/conf/domain_conf.c| 7
src/conf/domain_conf.h| 1 +
src/qemu/qemu_command.c | 26 ++
src/qemu/qemu_firmware.c | 1 +
src/qemu/qemu_namespace.c | 1 +
src/qemu/qemu_process.c | 1 +
src/qemu/qemu_validate.c | 10 ++
.../launch-security-s390-pv.xml | 18 ++
tests/genericxml2xmltest.c| 1 +
.../launch-security-s390-pv.s390x-latest.args | 35 +++
.../launch-security-s390-pv.xml | 30
tests/qemuxml2argvmock.c | 16 +
tests/qemuxml2argvtest.c | 2 ++
14 files changed, 154 insertions(+)
create mode 100644 tests/genericxml2xmlindata/launch-security-s390-pv.xml
create mode 100644
tests/qemuxml2argvdata/launch-security-s390-pv.s390x-latest.args
create mode 100644 tests/qemuxml2argvdata/launch-security-s390-pv.xml
diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng
index 045eb093dd..dbf372b6af 100644
--- a/docs/schemas/domaincommon.rng
+++ b/docs/schemas/domaincommon.rng
@@ -486,6 +486,11 @@
+
+
+s390-pv
+
+
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index af7b4f8ef8..0f49d537a5 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -1401,6 +1401,7 @@ VIR_ENUM_IMPL(virDomainLaunchSecurity,
VIR_DOMAIN_LAUNCH_SECURITY_LAST,
"",
"sev",
+ "s390-pv",
);
static virClass *virDomainObjClass;
@@ -3501,6 +3502,7 @@ virDomainSecDefFree(virDomainSecDef *def)
g_free(def->data.sev.dh_cert);
g_free(def->data.sev.session);
break;
+case VIR_DOMAIN_LAUNCH_SECURITY_PV:
case VIR_DOMAIN_LAUNCH_SECURITY_NONE:
case VIR_DOMAIN_LAUNCH_SECURITY_LAST:
break;
@@ -14788,6 +14790,8 @@ virDomainSecDefParseXML(xmlNodePtr lsecNode,
if (virDomainSEVDefParseXML(>data.sev, lsecNode, ctxt) < 0)
return NULL;
break;
+case VIR_DOMAIN_LAUNCH_SECURITY_PV:
+break;
case VIR_DOMAIN_LAUNCH_SECURITY_NONE:
case VIR_DOMAIN_LAUNCH_SECURITY_LAST:
default:
@@ -26917,6 +26921,9 @@ virDomainSecDefFormat(virBuffer *buf, virDomainSecDef
*sec)
break;
}
+case VIR_DOMAIN_LAUNCH_SECURITY_PV:
+break;
+
case VIR_DOMAIN_LAUNCH_SECURITY_NONE:
case VIR_DOMAIN_LAUNCH_SECURITY_LAST:
return;
diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h
index 4e6426ee78..5c22f252d0 100644
--- a/src/conf/domain_conf.h
+++ b/src/conf/domain_conf.h
@@ -2645,6 +2645,7 @@ struct _virDomainKeyWrapDef {
typedef enum {
VIR_DOMAIN_LAUNCH_SECURITY_NONE,
VIR_DOMAIN_LAUNCH_SECURITY_SEV,
+VIR_DOMAIN_LAUNCH_SECURITY_PV,
VIR_DOMAIN_LAUNCH_SECURITY_LAST,
} virDomainLaunchSecurity;
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index 61fecc607b..513bd52a6c 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -6976,6 +6976,9 @@ qemuBuildMachineCommandLine(virCommand *cmd,
virBufferAddLit(, ",memory-encryption=sev0");
}
break;
+case VIR_DOMAIN_LAUNCH_SECURITY_PV:
+virBufferAddLit(, ",confidential-guest-support=pv0");
+break;
case VIR_DOMAIN_LAUNCH_SECURITY_NONE:
break;
case VIR_DOMAIN_LAUNCH_SECURITY_LAST:
@@ -9874,6 +9877,26 @@ qemuBuildSEVCommandLine(virDomainObj *vm, virCommand
*cmd,
}
+static int
+qemuBuildPVCommandLine(virDomainObj *vm, virCommand *cmd)
+{
+g_autoptr(virJSONValue) props = NULL;
+g_auto(virBuffer) buf = VIR_BUFFER_INITIALIZER;
+qemuDomainObjPrivate *priv = vm->privateData;
+
+if (qemuMonitorCreateObjectProps(, "s390-pv-guest", "pv0",
+ NULL) < 0)
+return -1;
+
+if (qemuBuildObjectCommandlineFromJSON(, props, priv->qemuCaps) < 0)
+return -1;
+
+virCommandAddArg(cmd, "-object");
+virCommandAddArgBuffer(cmd, );
+return 0;
+}
+
+
static int
qemuBuildSecCommandLine(virDomainObj *vm, virCommand *cmd,
virDomainSecDef *sec)
@@ -9885,6 +9908,9 @@ qemuBuildSecCommandLine(virDomainObj *vm, virCommand *cmd,
case VIR_DOMAIN_LAUNCH_SECURITY_SEV:
return qemuBuildSEVCommandLine(vm, cmd, >data.sev);
break;
+case VIR_DOMAIN_LAUNCH_SECURITY_PV:
+return qemuBuildPVCommandLine(vm, cmd);
+break;
case VIR_DOMAIN_LAUNCH_SECURITY_NONE:
break;
case VIR_DOMAIN_LAUNCH_SECURITY_LAST:
diff --git
[PATCH v5 04/11] conf: Refactor launch security to allow more types
Adding virDomainSecDef for general launch security data
and moving virDomainSEVDef as an element for SEV data.
Signed-off-by: Boris Fiuczynski
Reviewed-by: Daniel Henrique Barboza
---
src/conf/domain_conf.c | 133 +---
src/conf/domain_conf.h | 16 +++--
src/conf/virconftypes.h | 2 +
src/qemu/qemu_cgroup.c | 4 +-
src/qemu/qemu_command.c | 47 ++---
src/qemu/qemu_driver.c | 3 +-
src/qemu/qemu_firmware.c| 32 +
src/qemu/qemu_namespace.c | 20 --
src/qemu/qemu_process.c | 34 +++--
src/qemu/qemu_validate.c| 22 --
src/security/security_dac.c | 6 +-
11 files changed, 217 insertions(+), 102 deletions(-)
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index 74254d505b..af7b4f8ef8 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -3491,17 +3491,25 @@ virDomainResctrlDefFree(virDomainResctrlDef *resctrl)
void
-virDomainSEVDefFree(virDomainSEVDef *def)
+virDomainSecDefFree(virDomainSecDef *def)
{
if (!def)
return;
-g_free(def->dh_cert);
-g_free(def->session);
+switch ((virDomainLaunchSecurity) def->sectype) {
+case VIR_DOMAIN_LAUNCH_SECURITY_SEV:
+g_free(def->data.sev.dh_cert);
+g_free(def->data.sev.session);
+break;
+case VIR_DOMAIN_LAUNCH_SECURITY_NONE:
+case VIR_DOMAIN_LAUNCH_SECURITY_LAST:
+break;
+}
g_free(def);
}
+
static void
virDomainOSDefClear(virDomainOSDef *os)
{
@@ -3703,7 +3711,7 @@ void virDomainDefFree(virDomainDef *def)
if (def->namespaceData && def->ns.free)
(def->ns.free)(def->namespaceData);
-virDomainSEVDefFree(def->sev);
+virDomainSecDefFree(def->sec);
xmlFreeNode(def->metadata);
@@ -14714,68 +14722,82 @@ virDomainMemoryTargetDefParseXML(xmlNodePtr node,
}
-static virDomainSEVDef *
-virDomainSEVDefParseXML(xmlNodePtr sevNode,
+static int
+virDomainSEVDefParseXML(virDomainSEVDef *def,
+xmlNodePtr sevNode,
xmlXPathContextPtr ctxt)
{
VIR_XPATH_NODE_AUTORESTORE(ctxt)
-g_autoptr(virDomainSEVDef) def = NULL;
unsigned long policy;
int rc;
-def = g_new0(virDomainSEVDef, 1);
-
ctxt->node = sevNode;
-if (virXMLPropEnum(sevNode, "type", virDomainLaunchSecurityTypeFromString,
- VIR_XML_PROP_NONZERO | VIR_XML_PROP_REQUIRED,
- >sectype) < 0)
-return NULL;
+if (virXPathULongHex("string(./policy)", ctxt, ) < 0) {
+virReportError(VIR_ERR_XML_ERROR, "%s",
+ _("failed to get launch security policy"));
+return -1;
+}
-switch ((virDomainLaunchSecurity) def->sectype) {
-case VIR_DOMAIN_LAUNCH_SECURITY_SEV:
-if (virXPathULongHex("string(./policy)", ctxt, ) < 0) {
-virReportError(VIR_ERR_XML_ERROR, "%s",
- _("failed to get launch security policy"));
-return NULL;
-}
+/* the following attributes are platform dependent and if missing, we can
+ * autofill them from domain capabilities later
+ */
+rc = virXPathUInt("string(./cbitpos)", ctxt, >cbitpos);
+if (rc == 0) {
+def->haveCbitpos = true;
+} else if (rc == -2) {
+virReportError(VIR_ERR_XML_ERROR, "%s",
+ _("Invalid format for launch security cbitpos"));
+return -1;
+}
-/* the following attributes are platform dependent and if missing, we
can
- * autofill them from domain capabilities later
-*/
-rc = virXPathUInt("string(./cbitpos)", ctxt, >cbitpos);
-if (rc == 0) {
-def->haveCbitpos = true;
-} else if (rc == -2) {
-virReportError(VIR_ERR_XML_ERROR, "%s",
- _("Invalid format for launch security cbitpos"));
-return NULL;
-}
+rc = virXPathUInt("string(./reducedPhysBits)", ctxt,
+ >reduced_phys_bits);
+if (rc == 0) {
+def->haveReducedPhysBits = true;
+} else if (rc == -2) {
+virReportError(VIR_ERR_XML_ERROR, "%s",
+ _("Invalid format for launch security "
+ "reduced-phys-bits"));
+return -1;
+}
+
+def->policy = policy;
+def->dh_cert = virXPathString("string(./dhCert)", ctxt);
+def->session = virXPathString("string(./session)", ctxt);
+
+return 0;
+}
-rc = virXPathUInt("string(./reducedPhysBits)", ctxt,
- >reduced_phys_bits);
-if (rc == 0) {
-def->haveReducedPhysBits = true;
-} else if (rc == -2) {
-virReportError(VIR_ERR_XML_ERROR, "%s",
- _("Invalid format for launch security "
- "reduced-phys-bits"));
-return NULL;
-}
-def->policy = policy;
-def->dh_cert
[PATCH v5 01/11] schemas: Refactor launch security
Change launch security to make it reusable for other types. Signed-off-by: Boris Fiuczynski --- docs/schemas/domaincommon.rng | 74 +++ 1 file changed, 41 insertions(+), 33 deletions(-) diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng index 5ea14b6dbf..045eb093dd 100644 --- a/docs/schemas/domaincommon.rng +++ b/docs/schemas/domaincommon.rng @@ -482,42 +482,50 @@ - -sev - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + sev + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
[PATCH v5 02/11] conf: Rework SEV XML parse and format methods
Make use of virDomainLaunchSecurity enum.
Signed-off-by: Boris Fiuczynski
Reviewed-by: Daniel Henrique Barboza
---
src/conf/domain_conf.c | 108 -
1 file changed, 64 insertions(+), 44 deletions(-)
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index f1d4ef021c..74254d505b 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -14732,40 +14732,50 @@ virDomainSEVDefParseXML(xmlNodePtr sevNode,
>sectype) < 0)
return NULL;
-if (virXPathULongHex("string(./policy)", ctxt, ) < 0) {
-virReportError(VIR_ERR_XML_ERROR, "%s",
- _("failed to get launch security policy"));
-return NULL;
-}
+switch ((virDomainLaunchSecurity) def->sectype) {
+case VIR_DOMAIN_LAUNCH_SECURITY_SEV:
+if (virXPathULongHex("string(./policy)", ctxt, ) < 0) {
+virReportError(VIR_ERR_XML_ERROR, "%s",
+ _("failed to get launch security policy"));
+return NULL;
+}
-/* the following attributes are platform dependent and if missing, we can
- * autofill them from domain capabilities later
- */
-rc = virXPathUInt("string(./cbitpos)", ctxt, >cbitpos);
-if (rc == 0) {
-def->haveCbitpos = true;
-} else if (rc == -2) {
-virReportError(VIR_ERR_XML_ERROR, "%s",
- _("Invalid format for launch security cbitpos"));
-return NULL;
-}
+/* the following attributes are platform dependent and if missing, we
can
+ * autofill them from domain capabilities later
+*/
+rc = virXPathUInt("string(./cbitpos)", ctxt, >cbitpos);
+if (rc == 0) {
+def->haveCbitpos = true;
+} else if (rc == -2) {
+virReportError(VIR_ERR_XML_ERROR, "%s",
+ _("Invalid format for launch security cbitpos"));
+return NULL;
+}
-rc = virXPathUInt("string(./reducedPhysBits)", ctxt,
- >reduced_phys_bits);
-if (rc == 0) {
-def->haveReducedPhysBits = true;
-} else if (rc == -2) {
-virReportError(VIR_ERR_XML_ERROR, "%s",
- _("Invalid format for launch security "
- "reduced-phys-bits"));
-return NULL;
-}
+rc = virXPathUInt("string(./reducedPhysBits)", ctxt,
+ >reduced_phys_bits);
+if (rc == 0) {
+def->haveReducedPhysBits = true;
+} else if (rc == -2) {
+virReportError(VIR_ERR_XML_ERROR, "%s",
+ _("Invalid format for launch security "
+ "reduced-phys-bits"));
+return NULL;
+}
-def->policy = policy;
-def->dh_cert = virXPathString("string(./dhCert)", ctxt);
-def->session = virXPathString("string(./session)", ctxt);
+def->policy = policy;
+def->dh_cert = virXPathString("string(./dhCert)", ctxt);
+def->session = virXPathString("string(./session)", ctxt);
-return g_steal_pointer();
+return g_steal_pointer();
+case VIR_DOMAIN_LAUNCH_SECURITY_NONE:
+case VIR_DOMAIN_LAUNCH_SECURITY_LAST:
+default:
+virReportError(VIR_ERR_XML_ERROR,
+ _("unsupported launch security type '%s'"),
+ virDomainLaunchSecurityTypeToString(def->sectype));
+return NULL;
+}
}
@@ -26856,28 +26866,38 @@ virDomainKeyWrapDefFormat(virBuffer *buf,
virDomainKeyWrapDef *keywrap)
static void
virDomainSEVDefFormat(virBuffer *buf, virDomainSEVDef *sev)
{
+g_auto(virBuffer) attrBuf = VIR_BUFFER_INITIALIZER;
+g_auto(virBuffer) childBuf = VIR_BUFFER_INIT_CHILD(buf);
+
if (!sev)
return;
-virBufferAsprintf(buf, "\n",
+virBufferAsprintf(, " type='%s'",
virDomainLaunchSecurityTypeToString(sev->sectype));
-virBufferAdjustIndent(buf, 2);
-if (sev->haveCbitpos)
-virBufferAsprintf(buf, "%d\n", sev->cbitpos);
+switch ((virDomainLaunchSecurity) sev->sectype) {
+case VIR_DOMAIN_LAUNCH_SECURITY_SEV: {
+if (sev->haveCbitpos)
+virBufferAsprintf(, "%d\n",
sev->cbitpos);
-if (sev->haveReducedPhysBits)
-virBufferAsprintf(buf, "%d\n",
- sev->reduced_phys_bits);
-virBufferAsprintf(buf, "0x%04x\n", sev->policy);
-if (sev->dh_cert)
-virBufferEscapeString(buf, "%s\n", sev->dh_cert);
+if (sev->haveReducedPhysBits)
+virBufferAsprintf(,
"%d\n",
+ sev->reduced_phys_bits);
+virBufferAsprintf(, "0x%04x\n", sev->policy);
+if (sev->dh_cert)
+virBufferEscapeString(, "%s\n",
sev->dh_cert);
-if (sev->session)
-virBufferEscapeString(buf, "%s\n", sev->session);
+if (sev->session)
+virBufferEscapeString(, "%s\n",
sev->session);
Re: [PATCH v1] virtqemud: remove sysconfig file
Am Fri, 16 Jul 2021 00:58:43 -0700 schrieb Andrea Bolognani : > The sysconfig files shipped with libvirt contain the defaults, and > the admin is absolutely welcome to tweak them however they might like > after installation, just as is the case for all the configuration > files in /etc/libvirt. Right. Once they are modified for whatever reason things will go downhill. Just recently the default (for libvirtd) changed from --listen to --timeout. This is an incompatible change. There is very little info on the system to workout if the admin actually wanted --listen, and just append some other knob, or if he dirtied the sysconfig file in other ways. Therefore %post or %posttrans scripts have no easy way to decide what to do with the existing sysconfig file to switch to the new default. If --listen would have been configured like I proposed, any admin changes are clear and obvious, and he has to keep the pieces if it falls apart because some default changed. In this case from .service to .socket activation. Furthermore my change should also add every undocumented variable to the service file. Configuration files are not documentation files. This is also violated, but should probably be discussed on another Friday. Olaf pgpkBy7ESBGOA.pgp Description: Digitale Signatur von OpenPGP
[PATCH 9/9] docs/deprecated: deprecate passing plugin args through `arg=`
Signed-off-by: Mahmoud Mandour --- docs/system/deprecated.rst | 6 ++ 1 file changed, 6 insertions(+) diff --git a/docs/system/deprecated.rst b/docs/system/deprecated.rst index e2e0090878..aaf0ee5777 100644 --- a/docs/system/deprecated.rst +++ b/docs/system/deprecated.rst @@ -126,6 +126,12 @@ other options have been processed. This will either have no effect (if if they were not given. The property is therefore useless and should not be specified. +Plugin argument passing through ``arg=`` (since 6.1) + + +Passing arguments through ``arg=`` is redundant is makes the command-line less +readable, especially when the argument itself consist of a name and a value, +e.g. ``arg="arg_name=arg_value"``. Therefore, the usage of ``arg`` is redundant. QEMU Machine Protocol (QMP) commands -- 2.25.1
Re: Question about skipping virDomainDiskDefAssignAddress
On Fri, Jul 16, 2021 at 01:01:50PM +0900, Motohiro Kawahito wrote: > > From: "Daniel P. Berrangé" > > To: Motohiro Kawahito > > Cc: libvir-list@redhat.com > > Date: 2021/07/16 00:42 > > Subject: [EXTERNAL] Re: Question about skipping > virDomainDiskDefAssignAddress > > > > > With the exception of paravirtualized Xen guests, this field in > > libvirt XML is *completely* independant of the guest assigned > > device name. > > > > eg the XML might say /dev/vda, but the guest might decde to > > call it /dev/sda, or /dev/whatever or really absolutely > > anything. > > Thank you very much for this information! I understand it. > However, I don't understand how we can pass the target device information > (e.g. 0A80) without an error. Do you know how to do it? > > My question was not good, so I opened another thread (How do we specify > disk device names for non-Linux VMs in XML?). There is nothing that needs passing. The guest OS decides its naming however it wants to. Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
Re: [PATCH v1] virtqemud: remove sysconfig file
On Thu, Jul 15, 2021 at 11:23:37PM +0200, Olaf Hering wrote: > sysconfig files are owned by the admin of the host. He has the liberty > to put anything he wants into these files. This makes it difficult to > provide different defaults. > > Remove the sysconfig file and place the current desired default into > the service file. > > Local customizations can now go either into /etc/sysconfig/virtqemud > or /etc/systemd/system/virtqemud.service.d/my-knobs.conf I'm unclear on what exactly you're trying to achieve here. The sysconfig files shipped with libvirt contain the defaults, and the admin is absolutely welcome to tweak them however they might like after installation, just as is the case for all the configuration files in /etc/libvirt. I expect the distro's package manager will then do the right thing when it comes to preserving these local modifications across libvirt upgrades - I know for sure that's the case at least in Debian. This arrangement appears to be very common, too: on my Fedora 34 machine, /etc/sysconfig contains ~25 files, all owned by some package and most consisting of at least one non-comment lines. Can you please elaborate on why you feel that changing the status quo is necessary / desirable? -- Andrea Bolognani / Red Hat / Virtualization
