[libvirt] [PATCH v2 0/8] Usb hub Cold(un)plug and hot(un)plug support
by Han Han
v1: https://www.redhat.com/archives/libvir-list/2018-October/msg00563.html
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1375423
Han Han (8):
qemu: Allow coldplugging of hub device
qemu: Allow coldunplugging of hub device
qemu_alias: Refactor hub alias assignment for hotplug
qemu_command: Make qemuBuildHubDevStr global
private_syms: add virDomainHubDefFree to libvirt_private.syms
qemu: implement usb hub device hotplug
qemu: implement usb hub device hotunplug
news: Cold(un)plug and hot(un)plug support for usb hub device
docs/news.xml | 5 ++
src/conf/domain_conf.c | 30 +++++++++
src/conf/domain_conf.h | 3 +
src/libvirt_private.syms | 2 +
src/qemu/qemu_alias.c | 22 +++++--
src/qemu/qemu_alias.h | 4 ++
src/qemu/qemu_command.c | 2 +-
src/qemu/qemu_command.h | 4 ++
src/qemu/qemu_driver.c | 30 +++++++--
src/qemu/qemu_hotplug.c | 132 ++++++++++++++++++++++++++++++++++++++-
src/qemu/qemu_hotplug.h | 12 ++++
11 files changed, 236 insertions(+), 10 deletions(-)
--
2.19.1
5 years, 6 months
[libvirt] [PATCH v3 00/20] Incremental Backup API additions
by Eric Blake
The following is the latest version of my API proposal for
incremental backups, and matches the demo I will be presenting
as part of my KVM Forum 2018 talk tomorrow afternoon:
https://kvmforum2018.sched.com/event/FzuB/facilitating-incremental-backup...
The patches are also available via https://repo.or.cz/libvirt/ericb.git
at the tag backup-v3.
The qemu integration is still incomplete (I don't have push
mode backups working, only pull mode; and there are still some
things to fine-tune as I figure out how to better support
external snapshots and block commit/stream), and I still haven't
gotten any opinions on whether it is better to have:
virDomainSnapshotCreateXML("<domainsnapshot>...") # existing
virDomainBackupBegin("<domainbackup>...", "<domaincheckpoint>...") # this series
virDomainSnapshotCheckpointCreateXML("<domainsnapshot>...", "<domaincheckpoint>...") # new
or to make checkpoint creation part of the snapshot and backup XML, as in:
virDomainSnapshotCreateXML("<domainsnapshot><domaincheckpoint>...</domainsnapshot>") # extension of existing
virDomainBackupBegin("<domainbackup><domaincheckpoint>...</domainbackup>") # tweak to this series
It's also obvious that we don't want to check in the qemu implementation
until after Peter's blockdev work has landed AND qemu has gotten rid
of the x- prefix in its QMP interactions, although the state of this
series SHOULD be sufficient to prove that the proposed interface is
at least flexible enough to adapt to whatever qemu tweaks land and
whatever other hypervisors may support. Whether to accept the API now
(to make backporting qemu support downstream across versions without
rebasing to an even later date for the API) is a harder question;
Jirka has already expressed distaste at the idea.
There are probably still loads of things needing fixing in this version,
I already know I did not address all of Peter's review comments on v2.
My unit test coverage is not very complete on the XML parsing, and there
are definitely some hacks in place to get things to the point of a working
demo that need to be polished for robustness.
Below is a diff since the v2 posting (patches 1-10 here, for later
patches a comparison against the state of my tree at the time I posted v2):
https://www.redhat.com/archives/libvir-list/2018-October/msg00700.html
001/20:[----] [--] 'snapshots: Avoid term 'checkpoint' for full system snapshot'
002/20:[----] [--] 'domain_conf: Expose virDomainStorageNetworkParseHost'
003/20:[down] 'qemu: Allow optional export name during NBD export'
004/20:[----] [--] 'backup: Document nuances between different state capture APIs'
005/20:[----] [--] 'backup: Introduce virDomainCheckpointPtr'
006/20:[0012] [FC] 'backup: Document new XML for backups'
007/20:[----] [--] 'backup: Introduce virDomainCheckpoint APIs'
008/20:[0024] [FC] 'backup: Introduce virDomainBackup APIs'
009/20:[----] [--] 'backup: Add new domain:checkpoint access control'
010/20:[0001] [FC] 'backup: Implement backup APIs for remote driver'
011/20:[0007] [FC] 'wip: backup: Parse and output checkpoint XML'
012/20:[0199] [FC] 'wip: backup: Parse and output backup XML'
013/20:[----] [--] 'backup: Implement virsh support for checkpoints'
014/20:[----] [--] 'wip: backup: virsh support for backup'
015/20:[0223] [FC] 'backup: Add new qemu monitor interactions'
016/20:[0123] [FC] 'backup: qemu: Implement metadata tracking for checkpoint APIs'
017/20:[down] 'wip: backup: Wire up qemu checkpoint commands over QMP'
018/20:[0072] [FC] 'wip: backup: qemu: Implement framework for backup job APIs'
019/20:[down] 'backup: Wire up qemu full pull backup commands over QMP'
020/20:[down] 'backup: implement qemu incremental pull backup'
No direct dependency on this one, but included in my git tag:
https://www.redhat.com/archives/libvir-list/2018-October/msg00899.html
Eric Blake (20):
snapshots: Avoid term 'checkpoint' for full system snapshot
domain_conf: Expose virDomainStorageNetworkParseHost
qemu: Allow optional export name during NBD export
backup: Document nuances between different state capture APIs
backup: Introduce virDomainCheckpointPtr
backup: Document new XML for backups
backup: Introduce virDomainCheckpoint APIs
backup: Introduce virDomainBackup APIs
backup: Add new domain:checkpoint access control
backup: Implement backup APIs for remote driver
wip: backup: Parse and output checkpoint XML
wip: backup: Parse and output backup XML
backup: Implement virsh support for checkpoints
wip: backup: virsh support for backup
backup: Add new qemu monitor interactions
backup: qemu: Implement metadata tracking for checkpoint APIs
wip: backup: Wire up qemu checkpoint commands over QMP
wip: backup: qemu: Implement framework for backup job APIs
backup: Wire up qemu full pull backup commands over QMP
backup: implement qemu incremental pull backup
include/libvirt/virterror.h | 6 +-
src/util/virerror.c | 21 +-
include/libvirt/libvirt-domain-checkpoint.h | 177 ++
include/libvirt/libvirt-domain-snapshot.h | 2 +-
include/libvirt/libvirt-domain.h | 17 +-
include/libvirt/libvirt.h | 3 +-
src/access/viraccessperm.h | 8 +-
src/conf/checkpoint_conf.h | 218 +++
src/conf/domain_conf.h | 16 +-
src/datatypes.h | 31 +-
src/driver-hypervisor.h | 74 +-
src/qemu/qemu_conf.h | 2 +
src/qemu/qemu_domain.h | 29 +-
src/qemu/qemu_monitor.h | 17 +
src/qemu/qemu_monitor_json.h | 19 +
tools/virsh-checkpoint.h | 29 +
tools/virsh-completer.h | 4 +
tools/virsh-util.h | 3 +
tools/virsh.h | 1 +
docs/Makefile.am | 3 +
docs/apibuild.py | 2 +
docs/docs.html.in | 9 +-
docs/domainstatecapture.html.in | 314 ++++
docs/format.html.in | 1 +
docs/formatcheckpoint.html.in | 291 ++++
docs/formatsnapshot.html.in | 33 +-
docs/index.html.in | 3 +-
docs/schemas/domainbackup.rng | 185 ++
docs/schemas/domaincheckpoint.rng | 94 ++
examples/object-events/event-test.c | 3 +
libvirt.spec.in | 3 +
mingw-libvirt.spec.in | 6 +
po/POTFILES | 3 +
src/Makefile.am | 2 +
src/access/viraccessperm.c | 5 +-
src/conf/Makefile.inc.am | 2 +
src/conf/checkpoint_conf.c | 1541 +++++++++++++++++
src/conf/domain_conf.c | 52 +-
src/conf/snapshot_conf.c | 4 +-
src/datatypes.c | 62 +-
src/libvirt-domain-checkpoint.c | 925 ++++++++++
src/libvirt-domain-snapshot.c | 7 +-
src/libvirt-domain.c | 8 +-
src/libvirt_private.syms | 30 +
src/libvirt_public.syms | 23 +
src/qemu/qemu_conf.c | 5 +
src/qemu/qemu_domain.c | 205 ++-
src/qemu/qemu_driver.c | 1494 ++++++++++++++++-
src/qemu/qemu_migration.c | 2 +-
src/qemu/qemu_monitor.c | 73 +-
src/qemu/qemu_monitor_json.c | 217 +++
src/qemu/qemu_process.c | 7 +
src/remote/remote_daemon_dispatch.c | 15 +
src/remote/remote_driver.c | 33 +-
src/remote/remote_protocol.x | 239 ++-
src/remote_protocol-structs | 129 ++
src/rpc/gendispatch.pl | 32 +-
tests/Makefile.am | 15 +-
tests/domainbackupxml2xmlin/backup-pull.xml | 9 +
tests/domainbackupxml2xmlin/backup-push.xml | 9 +
tests/domainbackupxml2xmlin/empty.xml | 1 +
tests/domainbackupxml2xmlout/backup-pull.xml | 9 +
tests/domainbackupxml2xmlout/backup-push.xml | 9 +
tests/domainbackupxml2xmlout/empty.xml | 7 +
tests/domaincheckpointxml2xmlin/empty.xml | 1 +
tests/domaincheckpointxml2xmlin/sample.xml | 7 +
tests/domaincheckpointxml2xmlout/empty.xml | 10 +
tests/domaincheckpointxml2xmlout/sample.xml | 16 +
tests/domaincheckpointxml2xmltest.c | 231 +++
tests/qemumonitorjsontest.c | 2 +-
tests/virschematest.c | 4 +
tools/Makefile.am | 3 +-
tools/virsh-checkpoint.c | 1578 ++++++++++++++++++
tools/virsh-completer.c | 52 +-
tools/virsh-domain.c | 6 +-
tools/virsh-snapshot.c | 2 +-
tools/virsh-util.c | 11 +
tools/virsh.c | 2 +
tools/virsh.pod | 14 +-
79 files changed, 8619 insertions(+), 118 deletions(-)
create mode 100644 include/libvirt/libvirt-domain-checkpoint.h
create mode 100644 src/conf/checkpoint_conf.h
create mode 100644 tools/virsh-checkpoint.h
create mode 100644 docs/domainstatecapture.html.in
create mode 100644 docs/formatcheckpoint.html.in
create mode 100644 docs/schemas/domainbackup.rng
create mode 100644 docs/schemas/domaincheckpoint.rng
create mode 100644 src/conf/checkpoint_conf.c
create mode 100644 src/libvirt-domain-checkpoint.c
create mode 100644 tests/domainbackupxml2xmlin/backup-pull.xml
create mode 100644 tests/domainbackupxml2xmlin/backup-push.xml
create mode 100644 tests/domainbackupxml2xmlin/empty.xml
create mode 100644 tests/domainbackupxml2xmlout/backup-pull.xml
create mode 100644 tests/domainbackupxml2xmlout/backup-push.xml
create mode 100644 tests/domainbackupxml2xmlout/empty.xml
create mode 100644 tests/domaincheckpointxml2xmlin/empty.xml
create mode 100644 tests/domaincheckpointxml2xmlin/sample.xml
create mode 100644 tests/domaincheckpointxml2xmlout/empty.xml
create mode 100644 tests/domaincheckpointxml2xmlout/sample.xml
create mode 100644 tests/domaincheckpointxml2xmltest.c
create mode 100644 tools/virsh-checkpoint.c
--
2.17.2
5 years, 6 months
[libvirt] [PATCH V2 0/3] libxl: add support for soft reset
by Jim Fehlig
Patches 1 and 2 are new to V2 and make slight improvements to
libxlDomainShutdownThread. Patch 3 is adjusted to work with Xen 4.6.
Jim Fehlig (3):
libxl: remove redundant calls to virObjectEventStateQueue
libxl: Remove some goto labels in libxlDomainShutdownThread
libxl: add support for soft reset
src/libxl/libxl_domain.c | 99 ++++++++++++++++++++++++++++------------
1 file changed, 69 insertions(+), 30 deletions(-)
--
2.18.0
5 years, 6 months
[libvirt] [PATCH v2] snapshot: Don't hose list on deletion failure
by Eric Blake
If qemuDomainSnapshotDiscard() fails for any reason (rare,
but possible with an ill-timed ENOMEM or if
qemuDomainSnapshotForEachQcow2() has problems talking to the
qemu guest monitor), then an attempt to retry the snapshot
deletion API will crash because we didn't undo the effects
of virDomainSnapshotDropParent() temporarily rearranging the
internal list structures, and the second attempt to drop
parents will dereference NULL. Fix it by instead noting that
there are only two callers to qemuDomainSnapshotDiscard(),
and only one of the two callers wants the parent to be updated;
thus we can move the call to virDomainSnapshotDropParent()
into a code path that only gets executed on success.
Signed-off-by: Eric Blake <eblake(a)redhat.com>
---
v2: avoid use-after-free
---
src/qemu/qemu_domain.c | 6 ++++--
src/qemu/qemu_driver.c | 1 -
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
index f00f1b3fdb..dd67be5e2a 100644
--- a/src/qemu/qemu_domain.c
+++ b/src/qemu/qemu_domain.c
@@ -8246,7 +8246,7 @@ int
qemuDomainSnapshotDiscard(virQEMUDriverPtr driver,
virDomainObjPtr vm,
virDomainSnapshotObjPtr snap,
- bool update_current,
+ bool update_parent,
bool metadata_only)
{
char *snapFile = NULL;
@@ -8275,7 +8275,7 @@ qemuDomainSnapshotDiscard(virQEMUDriverPtr driver,
goto cleanup;
if (snap == vm->current_snapshot) {
- if (update_current && snap->def->parent) {
+ if (update_parent && snap->def->parent) {
parentsnap = virDomainSnapshotFindByName(vm->snapshots,
snap->def->parent);
if (!parentsnap) {
@@ -8298,6 +8298,8 @@ qemuDomainSnapshotDiscard(virQEMUDriverPtr driver,
if (unlink(snapFile) < 0)
VIR_WARN("Failed to unlink %s", snapFile);
+ if (update_parent)
+ virDomainSnapshotDropParent(snap);
virDomainSnapshotObjListRemove(vm->snapshots, snap);
ret = 0;
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index a52e2495d5..9f71641dfa 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -16526,7 +16526,6 @@ qemuDomainSnapshotDelete(virDomainSnapshotPtr snapshot,
snap->first_child = NULL;
ret = 0;
} else {
- virDomainSnapshotDropParent(snap);
ret = qemuDomainSnapshotDiscard(driver, vm, snap, true, metadata_only);
}
--
2.17.2
5 years, 6 months
[libvirt] [PATCH v7 00/14] PCI passthrough support on s390
by Yi Min Zhao
Abstract
========
The PCI representation in QEMU has been extended for S390
allowing configuration of zPCI attributes like uid (user-defined
identifier) and fid (PCI function identifier).
The details can be found here:
https://lists.gnu.org/archive/html/qemu-devel/2016-06/msg07262.html
To support the new zPCI feature of the S390 platform, a new element of
PCI address is introduced. It has two optional attributes, @uid and
@fid. For example:
<hostdev mode='subsystem' type='pci'>
<driver name='vfio'/>
<source>
<address domain='0x0001' bus='0x00' slot='0x00' function='0x0'/>
</source>
<address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'>
<zpci uid='0x0003' fid='0x00000027'/>
</address>
</hostdev>
If they are defined by the user, unique values within the guest domain
must be used. If they are not specified and the architecture requires
them, they are automatically generated with non-conflicting values.
zPCI address as an extension of the PCI address are stored in a new
structure 'virZPCIDeviceAddress' which is a member of common PCI
Address structure. Additionally, two hashtables are used for assignment
and reservation of zPCI uid/fid.
In support of extending the PCI address, a new PCI address extension flag is
introduced. This extension flag allows is not only dedicated for the S390
platform but also other architectures needing certain extensions to PCI
address space.
Code Base
=========
commit in master:
3a1cdb06fd conf: Fix bug in finding alloc through matching vcpus
Change Log
==========
v6->v7:
1. Optimize some functions' names and code logic.
2. Fixup build error.
3. Add negative test case for patch 9.
4. Use virXMLFormatElement() in virDomainDeviceInfoFormat().
v5->v6:
1. Modify zPCI XML definition.
2. Optimize the logic of zPCI address assignment and reservation.
3. Add extension flag into PCI address structure.
4. Update commit messages.
v4->v5:
1. Update the version number.
2. Fixup code style error.
3. Separate qemu code into single patch.
4. Rebase the patches to the new code of master branch.
v3->v4:
1. Update docs.
2. Format code style.
3. Optimize zPCI support check.
4. Move the check of zPCI defined in xml but unsupported by Qemu to
qemuDomainDeviceDefValidate().
5. Change zpci address member of PCI address struct from pointer to
instance.
6. Modify zpci address definition principle. Currently the user must
either define both of uid and fid or not.
v2->v3:
1. Revise code style.
2. Update test cases.
3. Introduce qemuDomainCollectPCIAddressExtension() to collect PCI
extension addresses.
4. Introduce virDeviceInfoPCIAddressExtensionPresent() to check if zPCI
address exists.
5. Optimize zPCI address check logic.
6. Optimize passed parameters of zPCI addr alloc/release/reserve functions.
7. Report enum range error in qemuDomainDeviceSupportZPCI().
8. Update commit messages.
v1->v2:
1. Separate test commit and merge testcases into corresponding commits that
introduce the functionalities firstly.
2. Spare some checks for zpci device.
3. Add vsock and controller support.
4. Add uin32 type schema.
5. Rename zpciuid and zpcifid to zpci_uid and zpci_fid.
6. Always return multibus support on S390.
Yi Min Zhao (14):
conf: Add definitions for 'uid' and 'fid' PCI address attributes
qemu: Introduce zPCI capability
conf: Introduce a new PCI address extension flag
qemu: Enable PCI multi bus for S390 guests
qemu: Auto add pci-root for s390/s390x guests
conf: Introduce address caching for PCI extensions
conf: use virXMLFormatElement() in virDomainDeviceInfoFormat()
conf: Introduce parser, formatter for uid and fid
qemu: Add zPCI address definition check
conf: Allocate/release 'uid' and 'fid' in PCI address
qemu: Generate and use zPCI device in QEMU command line
qemu: Add hotpluging support for PCI devices on S390 guests
docs: Add 'uid' and 'fid' information
news: Update news for PCI address extension attributes
cfg.mk | 1 +
docs/formatdomain.html.in | 10 +-
docs/news.xml | 11 +
docs/schemas/basictypes.rng | 27 ++
docs/schemas/domaincommon.rng | 1 +
src/bhyve/bhyve_device.c | 3 +-
src/conf/device_conf.c | 69 ++++
src/conf/device_conf.h | 7 +
src/conf/domain_addr.c | 340 +++++++++++++++++-
src/conf/domain_addr.h | 27 +-
src/conf/domain_conf.c | 50 ++-
src/libvirt_private.syms | 7 +
src/qemu/qemu_capabilities.c | 6 +
src/qemu/qemu_capabilities.h | 1 +
src/qemu/qemu_command.c | 104 ++++++
src/qemu/qemu_command.h | 2 +
src/qemu/qemu_domain.c | 37 ++
src/qemu/qemu_domain_address.c | 205 ++++++++++-
src/qemu/qemu_hotplug.c | 160 ++++++++-
src/util/virpci.c | 26 ++
src/util/virpci.h | 15 +
.../caps_2.10.0.s390x.xml | 1 +
.../caps_2.11.0.s390x.xml | 1 +
.../caps_2.12.0.s390x.xml | 1 +
.../qemucapabilitiesdata/caps_2.7.0.s390x.xml | 1 +
.../qemucapabilitiesdata/caps_2.8.0.s390x.xml | 1 +
.../qemucapabilitiesdata/caps_2.9.0.s390x.xml | 1 +
.../qemucapabilitiesdata/caps_3.0.0.s390x.xml | 1 +
.../disk-virtio-s390-zpci.args | 26 ++
.../disk-virtio-s390-zpci.xml | 19 +
.../hostdev-vfio-zpci-autogenerate.args | 25 ++
.../hostdev-vfio-zpci-autogenerate.xml | 18 +
.../hostdev-vfio-zpci-boundaries.args | 29 ++
.../hostdev-vfio-zpci-boundaries.xml | 30 ++
.../hostdev-vfio-zpci-multidomain-many.args | 39 ++
.../hostdev-vfio-zpci-multidomain-many.xml | 79 ++++
.../hostdev-vfio-zpci-wrong-arch.xml | 34 ++
tests/qemuxml2argvdata/hostdev-vfio-zpci.args | 25 ++
tests/qemuxml2argvdata/hostdev-vfio-zpci.xml | 21 ++
tests/qemuxml2argvtest.c | 22 ++
.../disk-virtio-s390-zpci.xml | 31 ++
.../hostdev-vfio-zpci-autogenerate.xml | 34 ++
.../hostdev-vfio-zpci-boundaries.xml | 48 +++
.../hostdev-vfio-zpci-multidomain-many.xml | 97 +++++
.../qemuxml2xmloutdata/hostdev-vfio-zpci.xml | 32 ++
tests/qemuxml2xmltest.c | 17 +
46 files changed, 1707 insertions(+), 35 deletions(-)
create mode 100644 tests/qemuxml2argvdata/disk-virtio-s390-zpci.args
create mode 100644 tests/qemuxml2argvdata/disk-virtio-s390-zpci.xml
create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-autogenerate.args
create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-autogenerate.xml
create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-boundaries.args
create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-boundaries.xml
create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-multidomain-many.args
create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-multidomain-many.xml
create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-wrong-arch.xml
create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci.args
create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci.xml
create mode 100644 tests/qemuxml2xmloutdata/disk-virtio-s390-zpci.xml
create mode 100644 tests/qemuxml2xmloutdata/hostdev-vfio-zpci-autogenerate.xml
create mode 100644 tests/qemuxml2xmloutdata/hostdev-vfio-zpci-boundaries.xml
create mode 100644 tests/qemuxml2xmloutdata/hostdev-vfio-zpci-multidomain-many.xml
create mode 100644 tests/qemuxml2xmloutdata/hostdev-vfio-zpci.xml
--
Yi Min
5 years, 6 months
[libvirt] [PATCH v1 1/1] qemu_domain, qemu_process: maxCpus check to non-x86 guests
by Daniel Henrique Barboza
This patch makes two quality of life changes for non-x86 guests. The
first one is a maxCpus validation at qemuDomainDefValidate. The check
is made by the same function used to do that at qemuProcessStartValidateXML,
qemuValidateCpuCount. This ensures that the user doesn't goes over the
board with the maxCpus value when editing the XML, only to be faced with a
runtime error when starting it.
To do that, the following changes were made:
- qemuValidateCpuCount was made public. It was renamed to
qemuProcessValidateCpuCount to be compliant with the other public methods
at qemu_process.h;
- the method signature was slightly adapted to fit the const 'def'
variable used in qemuDomainDefValidate. This change has no downside in
in its original usage at qemuProcessStartValidateXML.
The second QoL change is adding the maxCpus value in the error message
of the now qemuProcessValidateCpuCount. This simple change allows the
user to quickly edit the XML to comply with the acceptable limit without
having to know QEMU internals. x86 guests, that might have been created
prior to the x86 qemuDomainDefValidate maxCpus check code, will also
benefit from this change.
After this patch, this is the expect result running a Power 9 guest with
a maxCpus of 40000:
$ ./virsh start dhb
error: Failed to start domain dhb
error: unsupported configuration: Maximum CPUs greater than specified machine type limit 240
And this is the result when trying to edit maxCpus to an invalid value:
$ ./virsh edit dhb
error: unsupported configuration: Maximum CPUs greater than specified machine type limit 240
Failed. Try again? [y,n,i,f,?]:
error: unsupported configuration: Maximum CPUs greater than specified machine type limit 240
Signed-off-by: Daniel Henrique Barboza <danielhb413(a)gmail.com>
---
src/qemu/qemu_domain.c | 5 +++++
src/qemu/qemu_process.c | 13 +++++++------
src/qemu/qemu_process.h | 3 +++
3 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
index 939b2a3da2..5a39b11da7 100644
--- a/src/qemu/qemu_domain.c
+++ b/src/qemu/qemu_domain.c
@@ -4100,6 +4100,11 @@ qemuDomainDefValidate(const virDomainDef *def,
}
}
+ if (!ARCH_IS_X86(def->os.arch) &&
+ qemuProcessValidateCpuCount(def, qemuCaps) < 0) {
+ goto cleanup;
+ }
+
if (def->nresctrls &&
def->virtType != VIR_DOMAIN_VIRT_KVM) {
virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
index 29b0ba1590..0de5b503d6 100644
--- a/src/qemu/qemu_process.c
+++ b/src/qemu/qemu_process.c
@@ -3901,9 +3901,9 @@ qemuProcessSPICEAllocatePorts(virQEMUDriverPtr driver,
}
-static int
-qemuValidateCpuCount(virDomainDefPtr def,
- virQEMUCapsPtr qemuCaps)
+int
+qemuProcessValidateCpuCount(const virDomainDef *def,
+ virQEMUCapsPtr qemuCaps)
{
unsigned int maxCpus = virQEMUCapsGetMachineMaxCpus(qemuCaps, def->os.machine);
@@ -3914,8 +3914,9 @@ qemuValidateCpuCount(virDomainDefPtr def,
}
if (maxCpus > 0 && virDomainDefGetVcpusMax(def) > maxCpus) {
- virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
- _("Maximum CPUs greater than specified machine type limit"));
+ virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
+ _("Maximum CPUs greater than specified machine type limit %u"),
+ maxCpus);
return -1;
}
@@ -5165,7 +5166,7 @@ qemuProcessStartValidateXML(virQEMUDriverPtr driver,
* If back compat isn't a concern, XML validation should probably
* be done at parse time.
*/
- if (qemuValidateCpuCount(vm->def, qemuCaps) < 0)
+ if (qemuProcessValidateCpuCount(vm->def, qemuCaps) < 0)
return -1;
/* checks below should not be executed when starting a qemu process for a
diff --git a/src/qemu/qemu_process.h b/src/qemu/qemu_process.h
index c2f7c2b5d2..1716230475 100644
--- a/src/qemu/qemu_process.h
+++ b/src/qemu/qemu_process.h
@@ -215,4 +215,7 @@ int qemuProcessStartManagedPRDaemon(virDomainObjPtr vm);
void qemuProcessKillManagedPRDaemon(virDomainObjPtr vm);
+int qemuProcessValidateCpuCount(const virDomainDef *def,
+ virQEMUCapsPtr qemuCaps);
+
#endif /* __QEMU_PROCESS_H__ */
--
2.17.1
5 years, 6 months
[libvirt] External disk snapshot paths and the revert operation
by Povilas Kanapickas
Hey,
It seems that there's an issue of how external disk snapshots currently
work. The snapshot definition xml[1] that is supplied to the API has a
list of disks each of which specify where the new overlay disks should
be placed.
This leads to ambiguities when we want to revert the domain to a
snapshot with children. Consider the following situation:
0. Initial state:
Domain definition: disk at disk-base.qcow2
1. We create a snapshot snap1 placing the overlay at disk-snap1.qcow2
Domain definition: disk at disk-snap1.qcow2
Disks:
- disk-base.qcow2 (read-only)
- disk-snap1.qcow2 (overlay, base: disk-base.qcow2)
Snapshots:
- snap1 (snapshot domain disk list: disk-base.qcow2,
snapshot disk list: disk-snap1.qcow2)
2. We create another snapshot snap2 placing the overlay at disk-snap2.qcow2
VM definition: disk at disk-snap2.qcow2
Disks:
- disk-base.qcow2 (read-only)
- disk-snap1.qcow2 (overlay, base: disk-base.qcow2, read-only)
- disk-snap2.qcow2 (overlay, base: disk-snap1.qcow2)
Snapshots:
- snap1 (snapshot domain disk list: disk-base.qcow2,
snapshot disk list: disk-snap1.qcow2)
- snap2 (snapshot domain disk list: disk-snap1.qcow2,
snapshot disk list: disk-snap2.qcow2)
Now what happens if we want to revert to snap1? We can't use any of the
paths that snap1 itself references: both disk-base.qcow2 and
disk-snap1.qcow2 are read-only as part of the backing chain for disks
used by snap2. Possible options are these:
- we can reuse disk-snap2.qcow2 which we no longer need as it contains
overlay on top of snap2. This is non-optimal because now the path of the
disk after revert depends on the disk path before it.
- we can think of some name with the expectation that the user will
change it later anyway.
I think that both of the above are non-optimal because we don't actually
revert to the exact state we took the snapshot of. The user is
effectively no longer in control of the disk path after the revert.
One of possible solutions would be add additional flag during the
snapshot creation that would change the current behavior. Instead of
creating a new disk for the overlay we could move the base disk to the
specified path and create the overlay in its place. The advantages of
this behavior would be the following:
- the path to the current disk used in the domain would not change when
taking snapshots. This way we could avoid the problem listed above and
easily revert to any snapshot.
- the confusion in naming of the overlay disks would be reduced.
Currently the path specified when creating snapshot refers to the
overlay image. Most of the time user does not know what will be changed
in the domain until the next snapshot. So any path he chooses will
likely not reflect what will end up in the overlay at the time of the
next snapshot. If it was possible to specify the path where the current
disk should be put instead, then the user could just name it after the
snapshot and it would correctly represent the contents of that disk.
The major disadvantage of the approach is that it would introduce extra
complexity in the presently simple interface and also the underlying
code. I've completely disregarded the case of taking snapshots while the
domain is running, so there might be hidden complications there as well.
Personally, I don't mind the current situation too much, but if libvirt
developers think it's a thing worth fixing I would be willing to work on it.
Any opinions?
Regards,
Povilas
[1]: https://libvirt.org/formatsnapshot.html
5 years, 6 months
[libvirt] [PATCH] nwfilter: intantiate filters on loading driver
by Nikolay Shirokovskiy
Before using filters binding filters instantiation was done by hypervisors
drivers initialization code (qemu was the only such hypervisor). Now qemu
reconnection done supposes it should be done by nwfilter driver probably.
Let's add this missing step.
Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy(a)virtuozzo.com>
---
src/nwfilter/nwfilter_driver.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/nwfilter/nwfilter_driver.c b/src/nwfilter/nwfilter_driver.c
index 1ee5162..1ab906f 100644
--- a/src/nwfilter/nwfilter_driver.c
+++ b/src/nwfilter/nwfilter_driver.c
@@ -264,6 +264,9 @@ nwfilterStateInitialize(bool privileged,
if (virNWFilterBindingObjListLoadAllConfigs(driver->bindings, driver->bindingDir) < 0)
goto error;
+ if (virNWFilterBuildAll(driver, false) < 0)
+ goto error;
+
nwfilterDriverUnlock();
return 0;
--
1.8.3.1
5 years, 6 months
[libvirt] [jenkins-ci PATCH v2 0/3] Add libvirt-ocaml
by Pino Toscano
Now that the libvirt-ocaml repository is fixed, let's build it in CI.
Changes from v1 to v2:
- split according to Andrea's hints
- removed --with-libvirt as argument for configure, no more needed
after upstream changes
Pino Toscano (3):
guests: add mappings for OCaml components
guests: pull dependencies for libvirt-ocaml
Add libvirt-ocaml project
guests/host_vars/libvirt-centos-7/main.yml | 1 +
guests/host_vars/libvirt-debian-9/main.yml | 1 +
guests/host_vars/libvirt-debian-sid/main.yml | 1 +
guests/host_vars/libvirt-fedora-27/main.yml | 1 +
guests/host_vars/libvirt-fedora-28/main.yml | 1 +
.../host_vars/libvirt-fedora-rawhide/main.yml | 1 +
guests/host_vars/libvirt-freebsd-10/main.yml | 1 +
guests/host_vars/libvirt-freebsd-11/main.yml | 1 +
.../libvirt-freebsd-current/main.yml | 1 +
guests/host_vars/libvirt-ubuntu-16/main.yml | 1 +
guests/host_vars/libvirt-ubuntu-18/main.yml | 1 +
guests/playbooks/build/jobs/defaults.yml | 2 ++
.../build/projects/libvirt-ocaml.yml | 27 +++++++++++++++++++
guests/vars/mappings.yml | 6 +++++
guests/vars/projects/libvirt-ocaml.yml | 5 ++++
jobs/defaults.yaml | 2 ++
projects/libvirt-ocaml.yaml | 23 ++++++++++++++++
17 files changed, 76 insertions(+)
create mode 100644 guests/playbooks/build/projects/libvirt-ocaml.yml
create mode 100644 guests/vars/projects/libvirt-ocaml.yml
create mode 100644 projects/libvirt-ocaml.yaml
--
2.17.2
5 years, 6 months
