[libvirt] [PATCH] libvirt: support block device storage type in virshParseSnapshotDiskspec
by Liu Dayu
virsh snapshot-create-as supports 'file' storage type in --diskspec by default.
It doesn't support 'block' storage type in the process of virshParseSnapshotDiskspec().
So if a snapshot on a block device (e.g. LV) was created, the type of current running
storage source in dumpxml is inconsistent with the actual backend storage source.
It will check file-system type mismatch failed and return an error message of
'Migration without shared storage is unsafe' when VM performs a live migration
after this snapshot.
Signed-off-by: Liu Dayu <liu.dayu(a)zte.com.cn>
---
tools/virsh-snapshot.c | 19 +++++++++++++++++--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/tools/virsh-snapshot.c b/tools/virsh-snapshot.c
index f6bb38b..f9c55e0 100644
--- a/tools/virsh-snapshot.c
+++ b/tools/virsh-snapshot.c
@@ -255,6 +255,8 @@ virshParseSnapshotDiskspec(vshControl *ctl, virBufferPtr buf, const char *str)
char **array = NULL;
int narray;
size_t i;
+ struct stat st;
+ int stor_type = VIR_STORAGE_TYPE_NONE;
narray = vshStringToArray(str, &array);
if (narray <= 0)
@@ -272,16 +274,29 @@ virshParseSnapshotDiskspec(vshControl *ctl, virBufferPtr buf, const char *str)
goto cleanup;
}
+ /* possibly update storage type */
+ if (file && STRPREFIX(file, "/dev/") && stat(file, &st) == 0 && S_ISBLK(st.st_mode))
+ stor_type = VIR_STORAGE_TYPE_BLOCK;
+ else
+ stor_type = VIR_STORAGE_TYPE_FILE;
+
virBufferEscapeString(buf, "<disk name='%s'", name);
if (snapshot)
virBufferAsprintf(buf, " snapshot='%s'", snapshot);
+ if (stor_type == VIR_STORAGE_TYPE_BLOCK)
+ virBufferAsprintf(buf, " type='%s'", virStorageTypeToString(stor_type));
+
if (driver || file) {
virBufferAddLit(buf, ">\n");
virBufferAdjustIndent(buf, 2);
if (driver)
virBufferAsprintf(buf, "<driver type='%s'/>\n", driver);
- if (file)
- virBufferEscapeString(buf, "<source file='%s'/>\n", file);
+ if (file) {
+ if (stor_type == VIR_STORAGE_TYPE_BLOCK)
+ virBufferEscapeString(buf, "<source dev='%s'/>\n", file);
+ else
+ virBufferEscapeString(buf, "<source file='%s'/>\n", file);
+ }
virBufferAdjustIndent(buf, -2);
virBufferAddLit(buf, "</disk>\n");
} else {
--
1.8.3.1
5 years, 5 months
[libvirt] [PATCH v2 0/4] Remove VIR_ERR_DEPRECATED & associated pieces
by Daniel P. Berrangé
A deprecation is inherantly a warning, not an error, so adding an error
with this name makes no conceptual sense.
Features in drivers may come & go at any time and we've always use the
VIR_ERR_NO_SUPPORT to indicate when a hypervisor driver does not support
a particular API.
Changed in v2:
- Don't remove the driver API entry point entirely - leave it set
to NULL, so we can document version number range.
Daniel P. Berrangé (4):
qemu: delete methods which are no longer supported
docs: update QEMU driver docs to replace deprecated with deleted
Revert "news: Mention VIR_ERR_DEPRECATED in improvements"
Revert "error: Add VIR_ERR_DEPRECATED error code"
docs/drvqemu.html.in | 2 +-
docs/hvsupport.pl | 25 +++++++++++++++----------
docs/libvirt.css | 4 ++--
docs/news.xml | 10 ----------
include/libvirt/virterror.h | 1 -
src/qemu/qemu_driver.c | 33 ++-------------------------------
src/util/virerror.c | 4 ----
7 files changed, 20 insertions(+), 59 deletions(-)
--
2.21.0
5 years, 6 months
[libvirt] [PATCH 0/4] Remove VIR_ERR_DEPRECATED & associated pieces
by Daniel P. Berrangé
A deprecation is inherantly a warning, not an error, so adding an error
with this name makes no conceptual sense.
Features in drivers may come & go at any time and we've always use the
VIR_ERR_NO_SUPPORT to indicate when a hypervisor driver does not support
a particular API.
Daniel P. Berrangé (4):
qemu: delete methods which are no longer supported
Revert "error: Add VIR_ERR_DEPRECATED error code"
Revert "docs: css: Add style for <span class='deprecated'> ..."
Revert "docs: hvsupport: Add support for deprecating hypervisor
implementations"
docs/hvsupport.pl | 44 ++++++++++++-------------------------
docs/libvirt.css | 10 ---------
include/libvirt/virterror.h | 1 -
src/qemu/qemu_driver.c | 31 --------------------------
src/util/virerror.c | 4 ----
5 files changed, 14 insertions(+), 76 deletions(-)
--
2.21.0
5 years, 6 months
[libvirt] [PATCH] qemu: blockjob: Don't leak 'cfg' from qemuBlockJobEventProcessLegacy
by Peter Krempa
Since c257352797a a reference of 'cfg' would be leaked if the function
does not need to process anything. Fix it by using VIR_AUTOUNREF.
Signed-off-by: Peter Krempa <pkrempa(a)redhat.com>
---
src/qemu/qemu_blockjob.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/src/qemu/qemu_blockjob.c b/src/qemu/qemu_blockjob.c
index f105632a09..d7e1070c93 100644
--- a/src/qemu/qemu_blockjob.c
+++ b/src/qemu/qemu_blockjob.c
@@ -315,7 +315,7 @@ qemuBlockJobEventProcessLegacy(virQEMUDriverPtr driver,
qemuBlockJobDataPtr job,
int asyncJob)
{
- virQEMUDriverConfigPtr cfg = virQEMUDriverGetConfig(driver);
+ VIR_AUTOUNREF(virQEMUDriverConfigPtr) cfg = virQEMUDriverGetConfig(driver);
virDomainDiskDefPtr disk = job->disk;
VIR_DEBUG("disk=%s, mirrorState=%s, type=%d, state=%d, newstate=%d",
@@ -368,8 +368,6 @@ qemuBlockJobEventProcessLegacy(virQEMUDriverPtr driver,
VIR_WARN("Unable to update persistent definition on vm %s "
"after block job", vm->def->name);
}
-
- virObjectUnref(cfg);
}
--
2.21.0
5 years, 6 months
[libvirt] [PATCH v3 0/8] CPU Model Baseline and Comparison for s390x
by Collin Walling
Changelog:
v2
- numerous cleanups
- removed "policy fix function" and now properly check
for policy == -1 in the CPUDef -> JSON parser
- resolved some memory leaks
- added string arg to qemuMonitorJSONParseCPUModelData for
error message to print out proper command name
v1
- introduce baseline
- split patches into small chunks
- free'd lingering qemuMonitorCPUModelInfo pointer
- when converting from virCPUDef -> virJSON, consider
feature policy FORCED for enabled
___
To run these patches, execute the virsh hypervisor-cpu-compare or
hypervisor-cpu-baseline commands and pass an XML file describing one or
more CPU definition. You can use the definition from virsh domcapabilities
or from a guest XML. There is no need extract it from the file and place
it a new one, as the XML parser will look specifically for the CPU tags.
___
These patches hookup the virsh hypervisor-cpu-compare/baseline commands
for the s390x architecture. They take an XML file describing some CPU
definitions and passes the data to QEMU, where the actual CPU model
comparison / baseline calculation is handled (available since QEMU 2.8.5).
These calculations are compared against / baselined with the hypervisor
CPU model, which can be observed via the virsh domcapabilities command
for s390x.
When baselining CPU models and the user appends the --features argument
to the command, s390x will only report back features that supersede the
base model definition.
**NOTE** if the --features flag is intended to expand ALL features
available to a CPU model (such as the huge list of features reported
by a full CPU model expansion), please let me know and I can resolve
this.
The first patch pulls some code out of the CPU Model Expansion JSON
function so that it can be later used for the Comparison and Baseline
JSON functions.
The rest of the patches follow this sequence:
- introduce JSON monitor functions
- introduce capability and update test files
- hook up monitor functions to virsh command
Patch 7 pulls out some code from the CPUDef XML parser to be
reused in the comparison hookup.
Thanks.
x86 and Power review by Daniel Henrique Barboza (thanks!)
Collin Walling (8):
qemu_monitor: helper functions for CPU models
qemu_monitor: implement query-cpu-model-baseline
qemu_capabilities: introduce QEMU_CAPS_QUERY_CPU_MODEL_BASELINE
qemu_driver: hook up query-cpu-model-baseline
qemu_monitor: implement query-cpu-model-comparison
qemu_capabilities: introduce QEMU_CAPS_QUERY_CPU_MODEL_COMPARISON
cpu_conf: xml to cpu definition parse helper
qemu_driver: hook up query-cpu-model-comparison
src/conf/cpu_conf.c | 30 +++
src/conf/cpu_conf.h | 6 +
src/cpu/cpu.c | 14 +-
src/libvirt_private.syms | 1 +
src/qemu/qemu_capabilities.c | 138 +++++++++++
src/qemu/qemu_capabilities.h | 20 ++
src/qemu/qemu_driver.c | 38 +++
src/qemu/qemu_monitor.c | 44 ++++
src/qemu/qemu_monitor.h | 18 ++
src/qemu/qemu_monitor_json.c | 297 ++++++++++++++++++++---
src/qemu/qemu_monitor_json.h | 20 ++
tests/qemucapabilitiesdata/caps_2.10.0.s390x.xml | 2 +
tests/qemucapabilitiesdata/caps_2.11.0.s390x.xml | 2 +
tests/qemucapabilitiesdata/caps_2.12.0.s390x.xml | 2 +
tests/qemucapabilitiesdata/caps_2.8.0.s390x.xml | 2 +
tests/qemucapabilitiesdata/caps_2.9.0.s390x.xml | 2 +
tests/qemucapabilitiesdata/caps_3.0.0.s390x.xml | 2 +
tests/qemucapabilitiesdata/caps_4.0.0.s390x.xml | 2 +
18 files changed, 591 insertions(+), 49 deletions(-)
--
2.7.4
5 years, 6 months
[libvirt] [PATCH v1 00/10] PCI Multifunction hotplug/unplug, part 1
by Daniel Henrique Barboza
This is the first part of the feature discussed at [1]. With the
exception of patch 06, these patches are aimed into preparing
the existing unit test infrastructure for the more sofisticated
multifunction tests to come.
First 3 Michal's patches helped me with unit test issues in
the first 3-4 patches (see [2] for more info), thus I am
relying on them being upstreamed as well.
The whole feature can be checked out at [3]. All patches survives
unit testing. The feature was stress tested with hundreds
of consecutive hotplug/unplugs of a Broadcom BCM5719 multifunction
network card in a guest running in a Power 8 server. Hopefully
I'll find a suitable x86 env to stress test the feature there
too.
[1] https://www.redhat.com/archives/libvir-list/2019-June/msg00703.html
[2] https://www.redhat.com/archives/libvir-list/2019-June/msg00726.html
[3] https://github.com/danielhb/libvirt/tree/multifunction_latest
Daniel Henrique Barboza (1):
util/virhostdev: enhance VFIO device is in use detection
Michal Prívozník (3):
virpcimock: Move actions checking one level up
Revert "virpcitest: Test virPCIDeviceDetach failure"
virpcimock: Create driver_override file in device dirs
Shivaprasad G Bhat (6):
tests: Fix the iommu group path in mock pci
tests: pci: Mock the iommu groups and vfio
virpcitest: Change the stub driver to vfio from pci-stub
virpcimock: Mock the SRIOV Virtual functions
tests: qemu: Add test case for pci-hostdev hotplug
tests: Add a baseline test for multifunction pci device use case
src/util/virhostdev.c | 74 +++--
src/util/virprocess.h | 2 +-
tests/Makefile.am | 7 +
tests/qemuhotplugtest.c | 42 ++-
.../qemuhotplug-hostdev-pci.xml | 6 +
.../qemuhotplug-base-live+hostdev-pci.xml | 58 ++++
...uhotplug-pseries-base-live+hostdev-pci.xml | 51 ++++
.../qemuhotplug-pseries-base-live.xml | 43 +++
.../hostdev-pci-multifunction.args | 35 +++
.../hostdev-pci-multifunction.xml | 59 ++++
.../hostdev-vfio-multidomain.args | 2 +-
.../hostdev-vfio-multidomain.xml | 2 +-
tests/qemuxml2argvdata/hostdev-vfio.args | 2 +-
tests/qemuxml2argvdata/hostdev-vfio.xml | 2 +-
tests/qemuxml2argvdata/net-hostdev-fail.xml | 2 +-
tests/qemuxml2argvdata/net-hostdev-vfio.args | 2 +-
tests/qemuxml2argvdata/net-hostdev-vfio.xml | 2 +-
tests/qemuxml2argvtest.c | 3 +
.../hostdev-pci-multifunction.xml | 79 +++++
tests/qemuxml2xmloutdata/hostdev-vfio.xml | 2 +-
tests/qemuxml2xmloutdata/net-hostdev-vfio.xml | 2 +-
tests/qemuxml2xmltest.c | 1 +
tests/virhostdevtest.c | 4 +-
tests/virpcimock.c | 276 +++++++++++++++---
tests/virpcitest.c | 40 +--
tests/virpcitestdata/0000-06-12.0.config | Bin 0 -> 256 bytes
tests/virpcitestdata/0000-06-12.1.config | Bin 0 -> 256 bytes
tests/virpcitestdata/0000-06-12.2.config | Bin 0 -> 256 bytes
tests/virprocessmock.c | 28 ++
29 files changed, 726 insertions(+), 100 deletions(-)
create mode 100644 tests/qemuhotplugtestdevices/qemuhotplug-hostdev-pci.xml
create mode 100644 tests/qemuhotplugtestdomains/qemuhotplug-base-live+hostdev-pci.xml
create mode 100644 tests/qemuhotplugtestdomains/qemuhotplug-pseries-base-live+hostdev-pci.xml
create mode 100644 tests/qemuhotplugtestdomains/qemuhotplug-pseries-base-live.xml
create mode 100644 tests/qemuxml2argvdata/hostdev-pci-multifunction.args
create mode 100644 tests/qemuxml2argvdata/hostdev-pci-multifunction.xml
create mode 100644 tests/qemuxml2xmloutdata/hostdev-pci-multifunction.xml
create mode 100644 tests/virpcitestdata/0000-06-12.0.config
create mode 100644 tests/virpcitestdata/0000-06-12.1.config
create mode 100644 tests/virpcitestdata/0000-06-12.2.config
create mode 100644 tests/virprocessmock.c
--
2.20.1
5 years, 6 months
[libvirt] [PATCH] network: avoid including sys/sysctl.h on Linux
by Daniel P. Berrangé
The sys/sysctl.h header is only needed on BSD platforms to get
the sysctlbyname() function declaration. On Linux we talk to
procfs instead to change sysctls.
Unfortunately a legacy sys/sysctl.h header does exist on Linux
and including it has recently started triggering a deprecation
warning from glibc.
Protect its inclusion with a HAVE_SYSCTLBYNAME check instead
so that it only gets used on platforms where we need that
function declaration.
Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com>
---
Pushed as build fix for Fedora rawhide
src/network/bridge_driver.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/network/bridge_driver.c b/src/network/bridge_driver.c
index 465487432e..19faf7d514 100644
--- a/src/network/bridge_driver.c
+++ b/src/network/bridge_driver.c
@@ -33,7 +33,7 @@
#include <sys/wait.h>
#include <sys/ioctl.h>
#include <net/if.h>
-#if HAVE_SYS_SYSCTL_H
+#ifdef HAVE_SYSCTLBYNAME
# include <sys/sysctl.h>
#endif
--
2.21.0
5 years, 6 months
[libvirt] [PATCH v3 0/7] cgroups v2 fixes and improvements
by Pavel Hrdina
Pavel Hrdina (7):
util: vircgroup: pass parent cgroup into virCgroupDetectControllersCB
util: vircgroup: improve controller detection
util: vircgroupv2: use any controller to create thread directory
util: vircgroupv2: enable CPU controller only if it's available
util: vircgroupv2: separate return values of
virCgroupV2EnableController
util: vircgroupv2: don't error out if enabling controller fails
util: vircgroupv2: mark only requested controllers as available
src/util/vircgroup.c | 32 +++++++++---------
src/util/vircgroupbackend.h | 3 +-
src/util/vircgroupv1.c | 4 ++-
src/util/vircgroupv2.c | 67 +++++++++++++++++++++++++++----------
4 files changed, 71 insertions(+), 35 deletions(-)
--
2.21.0
5 years, 6 months
[libvirt] [PATCH v2 0/4] qemu: Fix handling of 'dir' volumes with disk type='volume'
by Peter Krempa
Peter Krempa (4):
util: storage: Fix virStorageSourceGetActualType if volume was not
translated
qemu: command: Use 'actualType' when deciding whether to use disk
format
qemu: domain: Allow 'VIR_STORAGE_TYPE_VOLUME' disks with 'fat' format
qemu: Supply correct default type for 'dir' based
VIR_STORAGE_TYPE_VOLUME
src/qemu/qemu_command.c | 2 +-
src/qemu/qemu_domain.c | 13 ++++++++++---
src/util/virstoragefile.c | 12 +++++++++++-
tests/qemuxml2argvdata/disk-source-pool.args | 8 ++++++++
tests/qemuxml2argvdata/disk-source-pool.xml | 16 +++++++++++++++-
tests/qemuxml2xmloutdata/disk-source-pool.xml | 14 ++++++++++++++
6 files changed, 59 insertions(+), 6 deletions(-)
--
2.21.0
5 years, 6 months
[libvirt] Live migration fails with "Migration without shared storage is unsafe" when using netapp storage on CentOS 7 and Libvirt 4.5.0
by Marko Todorić
Hello everyone,
We've been using libvirt version 0.10.2 for a long time (on CentOS 6 OS)
and now we have started creating new KVM cluster all based on CentOS 7
OS and libvirt version 4.5.0 (that came with CentOS repo).
TLDR Version:
- When we try to migrate using "virsh migrate test --live
qemu+ssh://kvm_aquila-02/system" we get an error "error: Unsafe
migration: Migration without shared storage is unsafe".
- When we try to migrate using same method but adding "--unsafe"
migration works.
- When we try to migrate a VPS that is using QCOW image on a shared GFS2
image, mapped on both servers, migration is successful.
We have two servers in a cluster so far, they are connected to NetApp
storage and all luns that VPS server should be using are mapped to both
servers.
Long version with background:
We have plenty CentOS 6 Servers which work perfectly fine with libvirt
version up to 0.10.2. All connected also to a NetApp storage and all
luns are mapped to all servers. LUN's (disks) are visible under
/dev/mapper directory. When we create VPS, we point to raw disk to the
same location, /dev/mapper. For example, VPS "test" would use
"/dev/mapper/test" for disk with "cache=none" in xml file. If we issue
"virsh migrate test --live qemu+ssh://kvm_server-0X/system", it will
successfully migrate VPS to another hypervisor without errors, because
disk already exists there.
We also have a LUN mapped to each hypervisor and GFS2 established in a
cluster between hypervisors where we keep qcow images. We can also
migrate those machines without issues.
On new CentOS 7 hypervisors, we have pretty much the exact same setup.
NetApp storage connected to servers. All VPS LUN's mapped to all
hypervisors. Clustered GFS2 volume.
When we define VPS with approximately same XML, it will NOT migrate it
and will issue out an error stated above. "--unsafe" parameter seems to
work fine. BUT.
We want to setup a proper libvirt/kvm cluster with pcs. I've defined a
pcs resource for each VPS and live migration also doesn't work if i try
"pcs resource move" command. It will not migrate it "live" as it should,
and as it does with QCOW images, probably because of the same reason -
because it's unable to perform live migrate via libvirt without
"unsafe". If there would be any trick to add "--unsafe" parameter to pcs
i would do it, but I'm not aware of it.
Still, seems like a bug that libvirt would not realize that netapp
storage is present in this configuration. Is this maybe corrected in
later versions of libvirt? Unfortunately, 4.5.0 is latest in CentOS repo
but i would try to compile it if needed.
Any help would be greatly appreciated and if more info is needed i will
be more than happy to provide.
Thanks in advance,
Marko Todoric
5 years, 6 months
