[PATCH 0/2] node_device: Treat NVMe disks as regular disks
by Michal Privoznik
Apparently udev doesn't think that NVMe disk is really a disk because it
doesn't set ID_TYPE attribute to "disk" (it doesn't set the attribute at
all). But it does set DEVTYPE=disk so with a little bit of work we can
report NVMe disks as devices with VIR_NODE_DEV_CAP_STORAGE capability.
Michal Prívozník (2):
node_device: Rework udevKludgeStorageType()
node_device: Treat NVMe disks as regular disks
src/node_device/node_device_udev.c | 43 ++++++++++++++++--------------
1 file changed, 23 insertions(+), 20 deletions(-)
--
2.34.1
2 years, 10 months
[PATCH v1] meson: recognize sles when guessing default_qemu_user
by Olaf Hering
NAME="SLES"
VERSION="15-SP3"
VERSION_ID="15.3"
PRETTY_NAME="SUSE Linux Enterprise Server 15 SP3"
ID="sles"
ID_LIKE="suse"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:suse:sles:15:sp3"
DOCUMENTATION_URL="https://documentation.suse.com/"
Signed-off-by: Olaf Hering <olaf(a)aepfle.de>
---
meson.build | 1 +
1 file changed, 1 insertion(+)
Commit 4c69d64efa3731d074d198f871fd42e74c4a39f6 revealed the bug, /etc/os-release must exist during build.
diff --git a/meson.build b/meson.build
index b6d1286f3f..b2d9e8ed65 100644
--- a/meson.build
+++ b/meson.build
@@ -1673,6 +1673,7 @@ if not get_option('driver_qemu').disabled()
os_release.contains('fedora') or
os_release.contains('gentoo') or
os_release.contains('rhel') or
+ os_release.contains('sles') or
os_release.contains('suse'))
default_qemu_user = 'qemu'
default_qemu_group = 'qemu'
2 years, 10 months
[libvirt PATCH] spec: Don't clean up *.la and *.a files
by Andrea Bolognani
autotools used to produce those, but meson doesn't.
Signed-off-by: Andrea Bolognani <abologna(a)redhat.com>
---
libvirt.spec.in | 14 --------------
1 file changed, 14 deletions(-)
diff --git a/libvirt.spec.in b/libvirt.spec.in
index f0ff4c0ece..0e6cd13bb2 100644
--- a/libvirt.spec.in
+++ b/libvirt.spec.in
@@ -1195,20 +1195,6 @@ export SOURCE_DATE_EPOCH=$(stat --printf='%Y' %{_specdir}/%{name}.spec)
%meson_install
-rm -f $RPM_BUILD_ROOT%{_libdir}/*.la
-rm -f $RPM_BUILD_ROOT%{_libdir}/*.a
-rm -f $RPM_BUILD_ROOT%{_libdir}/libvirt/lock-driver/*.la
-rm -f $RPM_BUILD_ROOT%{_libdir}/libvirt/lock-driver/*.a
-rm -f $RPM_BUILD_ROOT%{_libdir}/libvirt/connection-driver/*.la
-rm -f $RPM_BUILD_ROOT%{_libdir}/libvirt/connection-driver/*.a
-rm -f $RPM_BUILD_ROOT%{_libdir}/libvirt/storage-backend/*.la
-rm -f $RPM_BUILD_ROOT%{_libdir}/libvirt/storage-backend/*.a
-rm -f $RPM_BUILD_ROOT%{_libdir}/libvirt/storage-file/*.la
-rm -f $RPM_BUILD_ROOT%{_libdir}/libvirt/storage-file/*.a
-%if %{with_wireshark}
-rm -f $RPM_BUILD_ROOT%{wireshark_plugindir}/libvirt.la
-%endif
-
# We don't want to install /etc/libvirt/qemu/networks in the main %%files list
# because if the admin wants to delete the default network completely, we don't
# want to end up re-incarnating it on every RPM upgrade.
--
2.34.1
2 years, 10 months
[libvirt PATCH 0/3] mingw: Misc cleanups
by Andrea Bolognani
Andrea Bolognani (3):
mingw: Don't ship virt-admin
mings: Don't ship virt-(xml|pki)-validate
mingw: Don't ship virkey* manual pages
mingw-libvirt.spec.in | 14 --------------
1 file changed, 14 deletions(-)
--
2.34.1
2 years, 10 months
[PATCH] qemuDomainSetupDisk: Initialize 'targetPaths'
by Peter Krempa
Compiler isn't able to see that 'virDevMapperGetTargets' in cases e.g.
when the devmapper isn't available may not initialize the value in the
pointer passed as the second argument.
The usage 'qemuDomainSetupDisk' lead to an accidental infinite loop as
previous calls apparently doctored the stack to a point where
'g_slist_concat' would end up in an infinite loop trying to find the end
of the list.
Fixes: 6c49c2ee9fc
Closes: https://gitlab.com/libvirt/libvirt/-/issues/268
Signed-off-by: Peter Krempa <pkrempa(a)redhat.com>
---
src/qemu/qemu_namespace.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/qemu/qemu_namespace.c b/src/qemu/qemu_namespace.c
index 23b1160c5e..94453033f5 100644
--- a/src/qemu/qemu_namespace.c
+++ b/src/qemu/qemu_namespace.c
@@ -251,7 +251,7 @@ qemuDomainSetupDisk(virStorageSource *src,
if (!(tmpPath = virPCIDeviceAddressGetIOMMUGroupDev(&next->nvme->pciAddr)))
return -1;
} else {
- GSList *targetPaths;
+ GSList *targetPaths = NULL;
if (virStorageSourceIsEmpty(next) ||
!virStorageSourceIsLocalStorage(next)) {
--
2.34.1
2 years, 10 months
[PATCH] libxl: Add lock process indicator to saved VM state
by Jim Fehlig
Commit fa58f571ee added a lock processes indicator to the
libxlDomainObjPrivate struct to note that a lock process was
successfully started for the VM. However, the commit neglected to
add the indicator to the VM's saved state file. As a result, the
indicator is lost on libvirtd restart, along with the knowledge of
whether a lock process was started for the VM.
This change adds support for the indicator in the domainObjPrivate
data parse and format callbacks, ensuring its value survives libvirtd
restarts.
Signed-off-by: Jim Fehlig <jfehlig(a)suse.com>
---
src/libxl/libxl_domain.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
index feca60f7d2..8962adc60f 100644
--- a/src/libxl/libxl_domain.c
+++ b/src/libxl/libxl_domain.c
@@ -226,6 +226,7 @@ libxlDomainObjPrivateXMLParse(xmlXPathContextPtr ctxt,
libxlDomainObjPrivate *priv = vm->privateData;
priv->lockState = virXPathString("string(./lockstate)", ctxt);
+ priv->lockProcessRunning = virXPathBoolean("count(./lockProcessRunning) > 0", ctxt);
return 0;
}
@@ -239,6 +240,9 @@ libxlDomainObjPrivateXMLFormat(virBuffer *buf,
if (priv->lockState)
virBufferAsprintf(buf, "<lockstate>%s</lockstate>\n", priv->lockState);
+ if (priv->lockProcessRunning)
+ virBufferAddLit(buf, "<lockProcessRunning/>\n");
+
return 0;
}
--
2.34.1
2 years, 10 months
[libvirt PATCH v7 00/18] qemu: Introduce hvf domain type for Hypervisor.framework
by Andrea Bolognani
In order to hopefully address [libvirt#147] at long last, I've picked
up Roman's patches from 2018 and attempted to forward-port them.
More specifically, I've used the [roolebo/hvf-domain] branch as a
starting point, since it seems to contain a few improvements over
[v2] and was just easier to pick up.
The code is mostly his own, so I've retained the existing authorship
information, but I've dropped Reviewed-by tags for commits that have
been modified in non-trivial ways. I've applied very minimal style
tweaks along the way, but overall I've tried to modify the existing
patches as little as possible.
The new test cases, such as they are, pass, and no regressions to KVM
support appear to have been introduced in the process. I don't
currently have access to a machine running macOS, so I can't verify
that it's actually possible to start a hardware-accelerated VM by
myself, but a couple of users have confirmed that the new feature
works.
Changes from [v6]:
* addressed review comments;
* moved virQEMUCapsAccelStr() and friends closer to the existing
virQEMUCapsGetAccel() since they are very similar in purpose;
* squashed my "fixup!" commits into the original ones now that
they have been reviewed.
Changes from [v5]:
* rebased on top of master, dealing with a couple of
straightforward merge conflicts in the process;
* moved NEWS entry to the 8.1.0 section.
Changes from [v4]:
* fixed an issue that prevented machine types from being probed
correctly, effectively making the entire thing non functional;
* only report HVF support as available when the guest architecture
and the host architecture match.
Changes from [v3]:
* reintroduced the patch that was missing in the initial version
of the forward-port;
* converted the documentation to reStructuredText and trimmed it
significantly;
* reworked virQEMUCapsAccelStr() based on Dan's suggestions;
* reworked macOS support in the test suite based on Dan's
suggestions;
* fixed a few minor issues found while doing the above.
Changes from [v2]:
* rebased on top of master;
* added a couple of simple test cases.
Useful links:
* GitLab: [abologna/hvf]
* CI: [pipeline]
[libvirt#147] https://gitlab.com/libvirt/libvirt/-/issues/147
[roolebo/hvf-domain] https://github.com/roolebo/libvirt/tree/hvf-domain
[abologna/hvf] https://gitlab.com/abologna/libvirt/-/commits/hvf
[pipeline] https://gitlab.com/abologna/libvirt/-/pipelines/453678312
[v6] https://listman.redhat.com/archives/libvir-list/2022-January/msg00685.html
[v5] https://listman.redhat.com/archives/libvir-list/2022-January/msg00411.html
[v4] https://listman.redhat.com/archives/libvir-list/2022-January/msg00280.html
[v3] https://listman.redhat.com/archives/libvir-list/2022-January/msg00131.html
[v2] https://listman.redhat.com/archives/libvir-list/2018-November/msg00802.html
Andrea Bolognani (5):
qemu: Only probe KVM on Linux
tests: Introduce testQemuHostOS
tests: Add macOS support to testutilsqemu
tests: Add macOS support to qemuxml2*test
tests: Add HVF test cases
Roman Bolshakov (13):
qemu: Add KVM CPUs into cache only if KVM is present
conf: Add hvf domain type
qemu: Define hvf capability
qemu: Query hvf capability on macOS
qemu: Expose hvf domain type if hvf is supported
qemu: Introduce virQEMUCapsAccelStr
qemu: Introduce virQEMUCapsTypeIsAccelerated
qemu: Introduce virQEMUCapsHaveAccel
qemu: Correct CPU capabilities probing for hvf
docs: Add hvf on QEMU driver page
docs: Note hvf support for domain elements
docs: Add support page for libvirt on macOS
news: Mention hvf domain type
NEWS.rst | 5 +
docs/docs.html.in | 3 +
docs/drvqemu.rst | 48 +++++-
docs/formatdomain.rst | 22 +--
docs/index.html.in | 4 +-
docs/macos.rst | 44 ++++++
docs/meson.build | 1 +
docs/schemas/domaincommon.rng | 1 +
src/conf/domain_conf.c | 1 +
src/conf/domain_conf.h | 1 +
src/qemu/qemu_capabilities.c | 146 ++++++++++++++++--
src/qemu/qemu_capabilities.h | 1 +
src/qemu/qemu_command.c | 4 +
src/qemu/qemu_process.c | 10 +-
.../hvf-aarch64-virt-headless.args | 48 ++++++
.../hvf-aarch64-virt-headless.xml | 45 ++++++
.../hvf-x86_64-q35-headless.args | 47 ++++++
.../hvf-x86_64-q35-headless.x86_64-latest.err | 1 +
.../hvf-x86_64-q35-headless.xml | 44 ++++++
tests/qemuxml2argvtest.c | 43 +++++-
.../hvf-aarch64-virt-headless.xml | 94 +++++++++++
.../hvf-x86_64-q35-headless.xml | 97 ++++++++++++
tests/qemuxml2xmltest.c | 43 +++++-
tests/testutilsqemu.c | 146 ++++++++++++++----
tests/testutilsqemu.h | 10 ++
25 files changed, 845 insertions(+), 64 deletions(-)
create mode 100644 docs/macos.rst
create mode 100644 tests/qemuxml2argvdata/hvf-aarch64-virt-headless.args
create mode 100644 tests/qemuxml2argvdata/hvf-aarch64-virt-headless.xml
create mode 100644 tests/qemuxml2argvdata/hvf-x86_64-q35-headless.args
create mode 100644 tests/qemuxml2argvdata/hvf-x86_64-q35-headless.x86_64-latest.err
create mode 100644 tests/qemuxml2argvdata/hvf-x86_64-q35-headless.xml
create mode 100644 tests/qemuxml2xmloutdata/hvf-aarch64-virt-headless.xml
create mode 100644 tests/qemuxml2xmloutdata/hvf-x86_64-q35-headless.xml
--
2.34.1
2 years, 10 months
[PATCH 00/33] ppc64 PowerNV machines support
by Daniel Henrique Barboza
Hi,
The ppc64 PowerNV (Power Non-Virtualized) machine types is the
bare-metal emulation of the IBM Power server. They follow a different
specification than the virtualized guest emulation, a.k.a the pSeries
guest that Libvirt supports for awhile.
There is an interest in running these PowerNV machines using Libvirt, in
particular due to the growing popularity of the OpenCI project. This is
the motivation of this work.
Although these machines are present in QEMU for a few years now, they
only became "Libvirt compliant" recently in upstream QEMU. The reason is
that running with '-nodefaults' wouldn't allow users to add PHBs
manually in the command line. Since the correspondent capabilities are
already present since QEMU 5.0 I didn't find a good way to block the
creation of powerNV domains for older QEMU versions (suggestions
welcome).
Support for these machines consists of adding a specific root-port and
pcie-root implemementation for each one of them. powernv8 uses
pnv-phb3-root-port/pnv-phb3 and powernv9 uses pnv-phb4-root-port/pnv-phb4.
PowerNV PHBs have a similar handling as the already existing
spapr-pci-host-bridge bus.
These domains needs BMC devices to turn off from the OS. These devices
aren't implemented in Libvirt yet (to my surprise, given that it's an
Intel interface), so the domains needs to be turned off using 'virsh
destroy'. I have patches that implements the required BMC devices, but
decided to post them as a follow up to not make this patch set too
large.
The series is organized as follows:
- patch 1: same patch sent a few days ago in [1], reposted here because the
capabilities was added on top of it;
- patches 2-9: cleanups and simplifications to allow a simple powernv8
domain to boot;
- patches 10-26: add root-port and phb of the powernv8 machine;
- patches 27-33: add root-port and phb of the powernv9 machine.
No change in existing pcie-root and pcie-root-port models were made.
This work can also be fetched from here:
https://gitlab.com/danielhb/libvirt/-/tree/pnv_v1
Frederic, fell free to give this a ride and let us know how it goes.
[1] https://listman.redhat.com/archives/libvir-list/2022-January/msg00766.html
Daniel Henrique Barboza (33):
tests: update QEMU and domain ppc64 capabilities for qemu 7.0
qemu_domain.c: add PowerNV machine helpers
qemu_capabilities.c: use 'MachineIsPowerPC' in DeviceDiskCaps
qemu_validate.c: use qemuDomainIsPowerPC() in
qemuValidateDomainChrDef()
qemu_domain.c: define ISA as default PowerNV serial
qemu_validate.c: enhance 'machine type not supported' message
qemu_domain.c: disable default devices for PowerNV machines
tests: add basic PowerNV8 test
qemu_migration.c: forbid powernv domains migration
qemu: introduce QEMU_CAPS_DEVICE_PNV_PHB3_ROOT_PORT
conf: add 'pnv-phb3-root-port' domain definition
qemu: add 'modelName' value for pnv-phb3-root-port device
qemu: introduce QEMU_CAPS_DEVICE_PNV_PHB3
conf: add 'pnv-phb3' controller model
qemu: add 'modelName' value for pnv-phb3 device
domain_conf.c: fix identation in virDomainControllerDefParseXML()
conf: parse and format <target chip-id='...'/>
introduce virDomainControllerIsPowerNVPHB
conf, qemu: add default 'chip-id' value for pnv-phb3 controllers
conf, qemu: add default 'targetIndex' value for pnv-phb3 devs
qemu_command.c: add command line for the pnv-phb3 device
qemu_domain_address.c: change pnv-phb3 minimal downstream slot
domain_conf: format pnv-phb3-root-port empty addr
tests: add pnv-phb3-root-port test
domain_validate.c: allow targetIndex 0 out of idx 0 for PowerNV PHBs
domain_conf.c: reject duplicated pnv-phb3 devices
qemu: introduce QEMU_CAPS_DEVICE_PNV_PHB4_ROOT_PORT
conf: add 'pnv-phb4-root-port' domain definition
qemu: add 'modelName' value for pnv-phb4-root-port device
qemu: introduce QEMU_CAPS_DEVICE_PNV_PHB4
conf: add 'pnv-phb4' controller model
qemu: add 'modelName' value for pnv-phb4 device
tests: add PowerNV9 tests
docs/formatdomain.rst | 4 +
docs/schemas/domaincommon.rng | 10 +
src/conf/domain_conf.c | 157 +-
src/conf/domain_conf.h | 8 +
src/conf/domain_validate.c | 5 +-
src/libvirt_private.syms | 1 +
src/qemu/qemu_capabilities.c | 12 +-
src/qemu/qemu_capabilities.h | 4 +
src/qemu/qemu_command.c | 21 +-
src/qemu/qemu_domain.c | 56 +-
src/qemu/qemu_domain.h | 4 +-
src/qemu/qemu_domain_address.c | 64 +-
src/qemu/qemu_migration.c | 6 +
src/qemu/qemu_validate.c | 63 +-
tests/domaincapsdata/qemu_7.0.0.ppc64.xml | 148 +
.../qemucapabilitiesdata/caps_5.0.0.ppc64.xml | 4 +
.../qemucapabilitiesdata/caps_5.2.0.ppc64.xml | 4 +
.../qemucapabilitiesdata/caps_6.2.0.ppc64.xml | 4 +
.../caps_7.0.0.ppc64.replies | 33825 ++++++++++++++++
.../qemucapabilitiesdata/caps_7.0.0.ppc64.xml | 1143 +
...default-video-type-ppc64.ppc64-latest.args | 8 +-
tests/qemuxml2argvdata/powernv8-basic.args | 32 +
tests/qemuxml2argvdata/powernv8-basic.xml | 16 +
tests/qemuxml2argvdata/powernv8-dupPHBs.err | 1 +
tests/qemuxml2argvdata/powernv8-dupPHBs.xml | 27 +
.../qemuxml2argvdata/powernv8-root-port.args | 33 +
tests/qemuxml2argvdata/powernv8-root-port.xml | 17 +
.../qemuxml2argvdata/powernv8-two-sockets.xml | 26 +
tests/qemuxml2argvdata/powernv9-dupPHBs.err | 1 +
tests/qemuxml2argvdata/powernv9-dupPHBs.xml | 27 +
.../qemuxml2argvdata/powernv9-root-port.args | 33 +
tests/qemuxml2argvdata/powernv9-root-port.xml | 17 +
...ault-cpu-kvm-pseries-2.7.ppc64-latest.args | 8 +-
...ault-cpu-kvm-pseries-3.1.ppc64-latest.args | 8 +-
...ault-cpu-kvm-pseries-4.2.ppc64-latest.args | 8 +-
...ault-cpu-tcg-pseries-2.7.ppc64-latest.args | 8 +-
...ault-cpu-tcg-pseries-3.1.ppc64-latest.args | 8 +-
...ault-cpu-tcg-pseries-4.2.ppc64-latest.args | 8 +-
.../ppc64-pseries-graphics.ppc64-latest.args | 22 +-
.../ppc64-pseries-headless.ppc64-latest.args | 16 +-
.../ppc64-tpmproxy-single.ppc64-latest.args | 6 +-
.../ppc64-tpmproxy-with-tpm.ppc64-latest.args | 8 +-
.../tpm-emulator-spapr.ppc64-latest.args | 14 +-
tests/qemuxml2argvtest.c | 18 +
tests/qemuxml2xmloutdata/powernv8-basic.xml | 31 +
.../qemuxml2xmloutdata/powernv8-root-port.xml | 36 +
.../powernv8-two-sockets.xml | 38 +
.../qemuxml2xmloutdata/powernv9-root-port.xml | 36 +
tests/qemuxml2xmltest.c | 15 +
tests/testutilsqemu.c | 2 +-
50 files changed, 35963 insertions(+), 108 deletions(-)
create mode 100644 tests/domaincapsdata/qemu_7.0.0.ppc64.xml
create mode 100644 tests/qemucapabilitiesdata/caps_7.0.0.ppc64.replies
create mode 100644 tests/qemucapabilitiesdata/caps_7.0.0.ppc64.xml
create mode 100644 tests/qemuxml2argvdata/powernv8-basic.args
create mode 100644 tests/qemuxml2argvdata/powernv8-basic.xml
create mode 100644 tests/qemuxml2argvdata/powernv8-dupPHBs.err
create mode 100644 tests/qemuxml2argvdata/powernv8-dupPHBs.xml
create mode 100644 tests/qemuxml2argvdata/powernv8-root-port.args
create mode 100644 tests/qemuxml2argvdata/powernv8-root-port.xml
create mode 100644 tests/qemuxml2argvdata/powernv8-two-sockets.xml
create mode 100644 tests/qemuxml2argvdata/powernv9-dupPHBs.err
create mode 100644 tests/qemuxml2argvdata/powernv9-dupPHBs.xml
create mode 100644 tests/qemuxml2argvdata/powernv9-root-port.args
create mode 100644 tests/qemuxml2argvdata/powernv9-root-port.xml
create mode 100644 tests/qemuxml2xmloutdata/powernv8-basic.xml
create mode 100644 tests/qemuxml2xmloutdata/powernv8-root-port.xml
create mode 100644 tests/qemuxml2xmloutdata/powernv8-two-sockets.xml
create mode 100644 tests/qemuxml2xmloutdata/powernv9-root-port.xml
--
2.34.1
2 years, 10 months
[PATCH] conf: network: Allow hostnames to start with a number
by Peter Krempa
From: Nicolas Lécureuil <neoclust(a)mageia.org>
RFC952 mandated that hostnames would start with an alpha character.
This requirement was later relaxed by RFC1123 which allowed hostnames to
start with a number as well.
https://datatracker.ietf.org/doc/html/rfc952
https://datatracker.ietf.org/doc/html/rfc1123#page-13
Signed-off-by: Nicolas Lécureuil <nicolas.lecureuil(a)siveo.net>
Reviewed-by: Peter Krempa <pkrempa(a)redhat.com>
---
Pushed after review of a trivial merge request.
src/conf/network_conf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/conf/network_conf.c b/src/conf/network_conf.c
index 10d3330fdf..c769bbaeb5 100644
--- a/src/conf/network_conf.c
+++ b/src/conf/network_conf.c
@@ -548,7 +548,7 @@ virNetworkDHCPHostDefParseXML(const char *networkName,
}
name = virXMLPropString(node, "name");
- if (name && (!g_ascii_isalpha(name[0]))) {
+ if (name && !(g_ascii_isalpha(name[0]) || g_ascii_isdigit(name[0]))) {
virReportError(VIR_ERR_XML_ERROR,
_("Cannot use host name '%s' in network '%s'"),
name, networkName);
--
2.34.1
2 years, 10 months
[PATCH 0/3] Fix hotplug of unassigned hostdevs
by Michal Privoznik
Honestly, I don't understand the reasoning behind <address
type='unassigned'/> (esp. when the device is not accessible to the guest
anyway). We offer virNodeDeviceDettach() and virNodeDeviceReAttach().
But apparently there are some issues with hotplug/hotunplug of hostdevs
with such type of address.
Michal Prívozník (3):
domain_validate: Refuse VIR_DOMAIN_DEVICE_ADDRESS_TYPE_UNASSIGNED
qemuDomainAttachHostPCIDevice: Handle hostevs with unassigned type of
address
qemuDomainDetachDeviceLive: Handle hostevs with unassigned type of
address
src/conf/domain_validate.c | 45 ++++++++++++++++++++++++++++++++++++++
src/qemu/qemu_hotplug.c | 20 ++++++++++++++---
2 files changed, 62 insertions(+), 3 deletions(-)
--
2.34.1
2 years, 10 months
