[PATCH 0/4] tests: qemucapabilities: Add data fro the 6.1 cycle
by Peter Krempa
QEMU already committed some significant changes since the tree opened.
The most notable which has fallout in libvirt is the dropping of the
'sheepdog' driver. This series adapts to that and then adds the
qemu capabilities data for this cycle based on the most recent qemu
upstream commit.
Patch 4 is heavily truncated. To fetch the full version please:
git fetch https://gitlab.com/pipo.sk/libvirt.git qemu-caps-6.1
Peter Krempa (4):
testQemuInfoSetArgs: Strip default machine alias only for 'latest'
test cases
qemublocktest: Drop 'network-sheepdog-qcow2' image creation test case
qemuxml2argvtest: Limit 'disk-network-sheepdog' testcase to qemu-6.0.0
tests: qemucapabilities: Add test-data for the qemu-6.1 cycle
.../domaincapsdata/qemu_6.1.0-q35.x86_64.xml | 208 +
.../domaincapsdata/qemu_6.1.0-tcg.x86_64.xml | 211 +
tests/domaincapsdata/qemu_6.1.0.x86_64.xml | 208 +
tests/qemublocktest.c | 1 -
.../imagecreate/network-sheepdog-qcow2.json | 20 -
.../imagecreate/network-sheepdog-qcow2.xml | 12 -
.../caps_6.1.0.x86_64.replies | 32734 ++++++++++++++++
.../caps_6.1.0.x86_64.xml | 3339 ++
.../cpu-tsc-high-frequency.x86_64-latest.args | 2 +-
...> disk-network-sheepdog.x86_64-6.0.0.args} | 2 +-
.../hugepages-memaccess3.x86_64-latest.args | 2 +-
tests/qemuxml2argvtest.c | 2 +-
tests/testutilsqemu.c | 6 +-
13 files changed, 36707 insertions(+), 40 deletions(-)
create mode 100644 tests/domaincapsdata/qemu_6.1.0-q35.x86_64.xml
create mode 100644 tests/domaincapsdata/qemu_6.1.0-tcg.x86_64.xml
create mode 100644 tests/domaincapsdata/qemu_6.1.0.x86_64.xml
delete mode 100644 tests/qemublocktestdata/imagecreate/network-sheepdog-qcow2.json
delete mode 100644 tests/qemublocktestdata/imagecreate/network-sheepdog-qcow2.xml
create mode 100644 tests/qemucapabilitiesdata/caps_6.1.0.x86_64.replies
create mode 100644 tests/qemucapabilitiesdata/caps_6.1.0.x86_64.xml
rename tests/qemuxml2argvdata/{disk-network-sheepdog.x86_64-latest.args => disk-network-sheepdog.x86_64-6.0.0.args} (95%)
--
2.30.2
3 years, 7 months
[PATCH] Delete forward declaration in storage_backend_sheepdog.c.
by peili
---
src/storage/storage_backend_sheepdog.c | 99 +++++++++++++-------------
1 file changed, 48 insertions(+), 51 deletions(-)
diff --git a/src/storage/storage_backend_sheepdog.c b/src/storage/storage_backend_sheepdog.c
index 6490dfae52..6b000ff9b8 100644
--- a/src/storage/storage_backend_sheepdog.c
+++ b/src/storage/storage_backend_sheepdog.c
@@ -35,11 +35,54 @@
#define VIR_FROM_THIS VIR_FROM_STORAGE
-static int virStorageBackendSheepdogRefreshVol(virStoragePoolObj *pool,
- virStorageVolDef *vol);
+static void
+virStorageBackendSheepdogAddHostArg(virCommand *cmd,
+ virStoragePoolObj *pool)
+{
+ virStoragePoolDef *def = virStoragePoolObjGetDef(pool);
+ const char *address = "localhost";
+ int port = 7000;
+ if (def->source.nhost > 0) {
+ if (def->source.hosts[0].name != NULL)
+ address = def->source.hosts[0].name;
+ if (def->source.hosts[0].port)
+ port = def->source.hosts[0].port;
+ }
+ virCommandAddArg(cmd, "-a");
+ virCommandAddArgFormat(cmd, "%s", address);
+ virCommandAddArg(cmd, "-p");
+ virCommandAddArgFormat(cmd, "%d", port);
+}
+
+
+static int
+virStorageBackendSheepdogRefreshVol(virStoragePoolObj *pool,
+ virStorageVolDef *vol)
+{
+ char *output = NULL;
+ virStoragePoolDef *def = virStoragePoolObjGetDef(pool);
+ g_autoptr(virCommand) cmd = NULL;
+
+ cmd = virCommandNewArgList(SHEEPDOGCLI, "vdi", "list", vol->name, "-r", NULL);
+ virStorageBackendSheepdogAddHostArg(cmd, pool);
+ virCommandSetOutputBuffer(cmd, &output);
+ if (virCommandRun(cmd, NULL) < 0)
+ return -1;
+
+ if (virStorageBackendSheepdogParseVdiList(vol, output) < 0)
+ return -1;
+
+ vol->type = VIR_STORAGE_VOL_NETWORK;
+
+ VIR_FREE(vol->key);
+ vol->key = g_strdup_printf("%s/%s", def->source.name, vol->name);
+
+ VIR_FREE(vol->target.path);
+ vol->target.path = g_strdup(vol->name);
+
+ return 0;
+}
-void virStorageBackendSheepdogAddHostArg(virCommand *cmd,
- virStoragePoolObj *pool);
int
virStorageBackendSheepdogParseNodeInfo(virStoragePoolDef *pool,
@@ -88,24 +131,6 @@ virStorageBackendSheepdogParseNodeInfo(virStoragePoolDef *pool,
return -1;
}
-void
-virStorageBackendSheepdogAddHostArg(virCommand *cmd,
- virStoragePoolObj *pool)
-{
- virStoragePoolDef *def = virStoragePoolObjGetDef(pool);
- const char *address = "localhost";
- int port = 7000;
- if (def->source.nhost > 0) {
- if (def->source.hosts[0].name != NULL)
- address = def->source.hosts[0].name;
- if (def->source.hosts[0].port)
- port = def->source.hosts[0].port;
- }
- virCommandAddArg(cmd, "-a");
- virCommandAddArgFormat(cmd, "%s", address);
- virCommandAddArg(cmd, "-p");
- virCommandAddArgFormat(cmd, "%d", port);
-}
static int
virStorageBackendSheepdogAddVolume(virStoragePoolObj *pool, const char *diskInfo)
@@ -134,6 +159,7 @@ virStorageBackendSheepdogAddVolume(virStoragePoolObj *pool, const char *diskInfo
return 0;
}
+
static int
virStorageBackendSheepdogRefreshAllVol(virStoragePoolObj *pool)
{
@@ -310,34 +336,6 @@ virStorageBackendSheepdogParseVdiList(virStorageVolDef *vol,
return -1;
}
-static int
-virStorageBackendSheepdogRefreshVol(virStoragePoolObj *pool,
- virStorageVolDef *vol)
-{
- char *output = NULL;
- virStoragePoolDef *def = virStoragePoolObjGetDef(pool);
- g_autoptr(virCommand) cmd = NULL;
-
- cmd = virCommandNewArgList(SHEEPDOGCLI, "vdi", "list", vol->name, "-r", NULL);
- virStorageBackendSheepdogAddHostArg(cmd, pool);
- virCommandSetOutputBuffer(cmd, &output);
- if (virCommandRun(cmd, NULL) < 0)
- return -1;
-
- if (virStorageBackendSheepdogParseVdiList(vol, output) < 0)
- return -1;
-
- vol->type = VIR_STORAGE_VOL_NETWORK;
-
- VIR_FREE(vol->key);
- vol->key = g_strdup_printf("%s/%s", def->source.name, vol->name);
-
- VIR_FREE(vol->target.path);
- vol->target.path = g_strdup(vol->name);
-
- return 0;
-}
-
static int
virStorageBackendSheepdogResizeVol(virStoragePoolObj *pool,
@@ -356,7 +354,6 @@ virStorageBackendSheepdogResizeVol(virStoragePoolObj *pool,
}
-
virStorageBackend virStorageBackendSheepdog = {
.type = VIR_STORAGE_POOL_SHEEPDOG,
--
2.20.1
3 years, 7 months
[PATCH 0/3] tests: Return EXIT_* from main instead of 0/-1
by Michal Privoznik
See 3/3 for rationale.
Michal Prívozník (3):
testutils: Drop libtool binary name handling
tests: Return EXIT_FAILURE/EXIT_SUCCESS instead of -1/0
testutils: Document and enforce @func callback retvals for
virTestMain()
tests/fchosttest.c | 2 +-
tests/qemusecuritytest.c | 2 +-
tests/scsihosttest.c | 2 +-
tests/seclabeltest.c | 2 +-
tests/storagepoolcapstest.c | 2 +-
tests/testutils.c | 20 +++++++++++++++-----
tests/testutils.h | 4 ++++
tests/virbitmaptest.c | 2 +-
tests/vircaps2xmltest.c | 2 +-
tests/vircapstest.c | 2 +-
tests/virconftest.c | 2 +-
tests/virendiantest.c | 2 +-
tests/virlogtest.c | 2 +-
tests/virresctrltest.c | 2 +-
tests/virscsitest.c | 2 +-
15 files changed, 32 insertions(+), 18 deletions(-)
--
2.26.3
3 years, 7 months
[libvirt PATCH v3 00/10] make internal only secrets work with split daemons
by Daniel P. Berrangé
If you define a secret with private="yes", then libvirt won't let any
client query the secret value after it is set. Only other libvirt
drivers inside the daemon can query it by passing a special internal
only flag to the virSecretGetValue API. The remote driver/daemon
refuses to let this internal flag go over the wire preventing normal
clients from using it
This doesn't work with the split daemons because the virSecretGetValue
API done by virqemud / virtstoraged has to go over the wire to reach
the virsecretd.
We need to come up with an alternative way to "prove" that the caller
of virSecretGetValue is a libvirt daemon, as opposed to a general
libvirt client.
Note with if only traditional POSIX DAC permissions are in effect
then we could consider it pointless trying to restrict access to
clients running the same user/group as the libvirt daemon. We ought
to take into account that the client might be confined by SELinux
though, so the "private secret" concept isn't entirely pointless.
Thus doing a simple uid of client == uid of daemon check is a bit
too weak. The UID check might also not fly if the modular daemons
are run inside containers with user namespaces, as the container
for virtsecretd and virtqemud might have different user mappings
in theory.
This series adds a concept of a "token" which is known only to the
libvirt daemons. The first daemon to use it writes a random hex
string to /var/run/libvirt/common/system.token. Other daemons can
read and compare this. Unless a MAC system is present this is still
largely security theatre, but that's not really worse than the
historical behaviour.
When an API call is made the virIdentity by default reflects the
identity of the UNIX process that initiated it.
When connecting to virtproxyd, the client apps' identity is forwarded
to the next virtNNNNd daemon.
When libvirt drivers, however, initiate an API call we never set any
identity. With monolithic libvirtd, they'd inherit the current client
identity automagically since it was all in the same thread local. With
modular daemons the othe driver would see the identity of the other
libvirt daemon which is bad as this gives elevated privileges in the
ACL check.
Thus we fix the code which drivers use to open a connection to other
daemons, such that it applies the current caller's identity. It does
this using an "elevated" identity though, which means, we have added
in the system token. Thus the virtsecretd daemon getting the call
virSecretGetValue sees the virIdentity reflecting the client
application which originally called the virDomainCreate() API, but
with the system token set. Thus virsecretd can see that the
virSecretGetValue was invoked by another daemon, not a libvirt
client app.
Changed in v3...
Properly mock the new APIs in test suite
Changed in v2...
We can't set the elevated identity only when opening the virConnect
for the secret driver. This works for modular daemons, as the identity
is passed to the virsecretd at time of opening and thus applies to
the later virSecretGetValue call on that connection.
For monolithic daemon, the identity present at virConnectOpen is
irrelevant. The virSecretGetValue call will just directly query
the current thread's identity.
IOW, to work in both deployment scenarios we need to have the
elevated identity set across both virConnectOpen and virSecretGetValue
Daniel P. Berrangé (10):
util: add virRandomToken API
util: introduce concept of a system token into identities
util: generate a persistent system token
util: set system token for system identity
util: add API for copying identity objects
util: helper to temporary elevate privileges of the current identity
src: add API to determine if current identity is a system identity
src: set identity when opening secondary drivers
src: elevate current identity privilege when fetching secret
secret: rework handling of private secrets
src/driver-secret.h | 9 +-
src/driver.c | 27 +++
src/libvirt-secret.c | 2 +-
src/libvirt_private.syms | 8 +
src/libxl/libxl_conf.c | 5 +
src/qemu/qemu_domain.c | 11 +-
src/qemu/qemu_tpm.c | 5 +
src/remote/remote_driver.c | 8 +-
src/secret/secret_driver.c | 34 ++-
src/storage/storage_backend_iscsi.c | 5 +
src/storage/storage_backend_iscsi_direct.c | 5 +
src/storage/storage_backend_rbd.c | 5 +
src/storage/storage_util.c | 5 +
src/util/viridentity.c | 244 ++++++++++++++++++++-
src/util/viridentity.h | 11 +
src/util/viridentitypriv.h | 30 +++
src/util/virrandom.c | 18 ++
src/util/virrandom.h | 1 +
src/util/virsecret.c | 3 +-
tests/qemuxml2argvmock.c | 9 +
tests/qemuxml2argvtest.c | 9 +-
tests/viridentitytest.c | 11 +-
22 files changed, 435 insertions(+), 30 deletions(-)
create mode 100644 src/util/viridentitypriv.h
--
2.31.1
3 years, 7 months
[PATCH] rpm: re-enable ppc64 on RHEL-8
by Daniel P. Berrangé
Historically PowerPC 64 was always supported with qemu-kvm in RHEL.
In future RHEL-9 it is being discontinued and this was addressed
in
commit 03cc3c9064322ac4028a2213105cd230fe28c013
Author: Jiri Denemark <jdenemar(a)redhat.com>
Date: Wed Apr 21 14:55:03 2021 +0200
spec: Do not build qemu driver for Power on RHEL-9
when the specfile was cleaned up to remove RHEL-7 support:
commit 0f601d2f868f2017cdd16e0a7ca90a59e7d5e120
Author: Andrea Bolognani <abologna(a)redhat.com>
Date: Wed May 5 19:30:46 2021 +0200
spec: Bump min_fedora and min_rhel
it also removed the logic that applied to RHEL-8 wrt arch list
and lost PowerPC 64 support on 8. This reverts that part of the
change but with the condition reversed to prioritize the future
state.
Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com>
---
libvirt.spec.in | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/libvirt.spec.in b/libvirt.spec.in
index f421828d16..8ac324be0a 100644
--- a/libvirt.spec.in
+++ b/libvirt.spec.in
@@ -8,7 +8,11 @@
%define arches_qemu_kvm %{ix86} x86_64 %{power64} %{arm} aarch64 s390x
%if 0%{?rhel}
- %define arches_qemu_kvm x86_64 aarch64 s390x
+ %if 0%{?rhel} > 8
+ %define arches_qemu_kvm x86_64 aarch64 s390x
+ %else
+ %define arches_qemu_kvm x86_64 %{power64} aarch64 s390x
+ %endif
%endif
%define arches_64bit x86_64 %{power64} aarch64 s390x riscv64
--
2.31.1
3 years, 7 months
[PATCH] rpm: disable glusterfs on RHEL-9
by Daniel P. Berrangé
Support for glusterfs with KVM is being dropped in RHEL-9 in the
virtualization stack.
Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com>
---
libvirt.spec.in | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/libvirt.spec.in b/libvirt.spec.in
index 8ac324be0a..c52f607bd1 100644
--- a/libvirt.spec.in
+++ b/libvirt.spec.in
@@ -65,10 +65,15 @@
%endif
%define with_storage_gluster 0%{!?_without_storage_gluster:1}
-%ifnarch %{arches_qemu_kvm}
- # gluster is only built where qemu driver is enabled on RHEL
- %if 0%{?rhel}
+%if 0%{?rhel}
+ # Glusterfs dropped in RHEL-9, and before that only
+ # enabled on arches where KVM exists
+ %if 0%{?rhel} > 8
%define with_storage_gluster 0
+ %else
+ %ifnarch %{arches_qemu_kvm}
+ %define with_storage_gluster 0
+ %endif
%endif
%endif
--
2.31.1
3 years, 7 months
[libvirt PATCH v2 0/6] Refactor more XML parsing boilerplate code, part X
by Tim Wiederhake
For background, see
https://listman.redhat.com/archives/libvir-list/2021-April/msg00668.html
Changes since V1:
* Split up VIR_FREE'd and reused ´g_autofree xmlNodePtr *´ variables.
Tim Wiederhake (6):
virNodeDeviceDefParseXML: Use g_auto*
virDomainNumatuneNodeParseXML: Use virXMLProp*
virDomainNumatuneNodeParseXML: Use g_autofree
virDomainNumaDefNodeDistanceParseXML: Use virXMLProp*
virDomainNumaDefParseXML: Use virXMLProp*
virDomainNumaDefParseXML: Use g_autofree
src/conf/node_device_conf.c | 44 ++-
src/conf/numa_conf.c | 305 ++++++------------
.../hugepages-memaccess-invalid.err | 2 +-
3 files changed, 110 insertions(+), 241 deletions(-)
--
2.26.3
3 years, 7 months
[libvirt PATCH 00/10] Refactor more XML parsing boilerplate code, part X
by Tim Wiederhake
For background, see
https://listman.redhat.com/archives/libvir-list/2021-April/msg00668.html
Tim Wiederhake (10):
virNodeDeviceDefParseXML: Use g_auto*
virDomainNumatuneNodeParseXML: Use virXMLProp*
virDomainNumatuneNodeParseXML: Use g_autofree
virDomainNumaDefNodeDistanceParseXML: Use virXMLProp*
virDomainNumaDefParseXML: Use virXMLProp*
virDomainNumaDefParseXML: Use g_autofree
virStorageAdapterParseXMLFCHost: Use virXMLProp*
virStoragePoolDefParseSource: Use virXMLProp*
virStoragePoolDefParseSource: Use VIR_XPATH_NODE_AUTORESTORE
virStoragePoolDefParseXML: Use virXMLProp*
src/conf/node_device_conf.c | 34 +--
src/conf/numa_conf.c | 285 +++++-------------
src/conf/storage_adapter_conf.c | 17 +-
src/conf/storage_conf.c | 83 ++---
.../hugepages-memaccess-invalid.err | 2 +-
5 files changed, 125 insertions(+), 296 deletions(-)
--
2.26.3
3 years, 7 months
How to hot plugin a new vhost-user-blk-pci device to running VM?
by Liang Chaojun
Hi Guy,
Does anyone clear how to hot plugin a new vhost-user-blk-pci device to a running VM?
Before staring vm , I pass the disk through QEMU command line like below.
<qemu:commandline>
<qemu:arg value='-object'/>
<qemu:arg value='memory-backend-file,id=mem0,size=4G,mem-path=/dev/hugepages,share=on'/>
<qemu:arg value='-numa'/>
<qemu:arg value='node,memdev=mem0'/>
<qemu:arg value='-chardev'/>
<qemu:arg value='socket,id=spdk_vhost_blk721ea46a-b306-11eb-a280-525400a98761,path=/var/tmp/vhost.721ea46a-b306-11eb-a280-525400a98761,reconnect=1'/>
<qemu:arg value='-device'/>
<qemu:arg value='vhost-user-blk-pci,chardev=spdk_vhost_blk721ea46a-b306-11eb-a280-525400a98761,bootindex=1,num-queues=4'/>
<qemu:arg value='-chardev'/>
<qemu:arg value='socket,id=spdk_vhost_blk2f699c58-d222-4629-9fdc-400c3aadc55e,path=/var/tmp/vhost.2f699c58-d222-4629-9fdc-400c3aadc55e,reconnect=1'/>
<qemu:arg value='-device'/>
<qemu:arg value='vhost-user-blk-pci,chardev=spdk_vhost_blk2f699c58-d222-4629-9fdc-400c3aadc55e,num-queues=4'/>
</qemu:commandline>
But I don’t know how to live add a vhost-user-blk-pci device on running VM even with calling attachDevice API now.
OS: redhat 7.4 Libvirt version: 3.4
Your help will be appreciated.
Thanks!
3 years, 7 months
[PATCH] rpm: Set version information for libvirt-admin virtual name
by Neal Gompa
The libvirt-daemon package now provides the 'libvirt-admin' virtual
name, but the Provides stanza doesn't declare version information,
which breaks things depending on that package using a versioned
dependency. Fix this by setting the version-release of libvirt to
that name to mimic the previous state.
Fixes: 2244ac168d42c3fa424bae6d33ecdbb8726da7c2
Signed-off-by: Neal Gompa <ngompa13(a)gmail.com>
---
libvirt.spec.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libvirt.spec.in b/libvirt.spec.in
index 9dea6c6787..d7a90c42f5 100644
--- a/libvirt.spec.in
+++ b/libvirt.spec.in
@@ -415,7 +415,7 @@ Requires: gettext
# Ensure smooth upgrades
Obsoletes: libvirt-admin < 7.3.0
-Provides: libvirt-admin
+Provides: libvirt-admin = %{version}-%{release}
Obsoletes: libvirt-bash-completion < 7.3.0
%description daemon
--
2.31.1
3 years, 7 months
