- Devel - libvirt List Archives

[PATCH 0/1] vmx: Fix <genid/> mapping
by Michal Privoznik 04 Oct '21

04 Oct '21

Apparently, parsing vmx.genid is not as easy as I thought. Anyway, it was brought up in a private thread that libvirt doesn't report correct UUIDs. For instance for the following input: vm.genid = "-8536691797830587195" vm.genidX = "-1723453263670062919" Libvirt would report: <genid>8987940a-0951-2cc5-e815-10634ff550b9</genid> while virt-v2v would report: <genid>09512cc5-940a-8987-b950-f54f631015e8</genid> Another example: vm.genid = "-6284418052148993891" vm.genidX = "-649955058627554545" Libvirt: <genid>a8c94313-ed9b-609d-f6fa-e5515a89530f</genid> virt-v2v: <genid>ed9b609d-4313-a8c9-0f53-895a51e5faf6</genid> To test my patch I modified tests/vmx2xmldata/esx-in-the-wild-10.vmx (because it already contains vmx.genid, but any file can be modified really), and then ran: libvirt.git/_build/tests $ VIR_TEST_DEBUG=1 VIR_TEST_RANGE=58 ./vmx2xmltest Mind you, the fix is almost direct rewrite of virt-v2v's algorithm, except it's optimized for C and not OCaml :-) You can find various attempts/versions of that on my gitlab: https://gitlab.com/MichalPrivoznik/libvirt/-/commits/vmx_genid/ I'm sending only the last one because that looks the best IMO. Michal Prívozník (1): vmx: Fix <genid/> mapping src/vmx/vmx.c | 16 ++++++++++++---- tests/vmx2xmldata/esx-in-the-wild-10.xml | 2 +- 2 files changed, 13 insertions(+), 5 deletions(-) -- 2.32.0

4 17

[PATCH] docs: describe flag VIR_STORAGE_POOL_CREATE_NORMAL to correct the HTML doc
by Erik Skultety 04 Oct '21

04 Oct '21

From: Robin Lee <cheeselee(a)fedoraproject.org> This patch makes the descriptions of virStoragePoolCreateFlags annotate to the correct flag in the generated HTML file. --- Resending a merged change from GitLab. include/libvirt/libvirt-storage.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/libvirt/libvirt-storage.h b/include/libvirt/libvirt-storage.h index b459fe3e8e..f89856b93e 100644 --- a/include/libvirt/libvirt-storage.h +++ b/include/libvirt/libvirt-storage.h @@ -70,6 +70,7 @@ typedef enum { } virStoragePoolDeleteFlags; typedef enum { + /* Create the pool but do not perform pool build */ VIR_STORAGE_POOL_CREATE_NORMAL = 0, /* Create the pool and perform pool build without any flags */ -- 2.31.1

1 0

[PATCH v5 0/4] introduce support for acpi-bridge-hotplug feature
by Ani Sinha 02 Oct '21

02 Oct '21

changelog: v5: rebased the patchset with the latest master. v4: split the original series into two - pci-root controller specific one (https://www.mail-archive.com/libvir-list@redhat.com/msg221645.html) and this one specific to pci bridges. The conf xml has been introduced as per suggestion by Berrange here: https://patchew.org/Libvirt/20210912032631.2853520-1-ani@anisinha.ca Changes has been introduced to parse and validate the xml accordingly as well as to add backend qemu commandline option. v3: reorganized the patches as per Laine's suggestion. Added more details in commit messages. Added conf description in formatdomain.rst. Added changelog for next release. v2: fixed bugs and added additional missing unit tests. v1: initial implementation. Had some bugs and missed some unit tests This change introduces a new libvirt sub-element <pci> under <features> that can be used to configure all pci related features. Currently the only sub-sub element supported by this sub-element is 'acpi-bridge-hotplug' as shown below: <features> <pci> <acpi-bridge-hotplug state='on|off'/> </pci> </features> The above option is only available for qemu driver and that too for x86 guests only. It is a global option. 'acpi-bridge-hotplug' option enables or disables ACPI hotplug support for cold-plugged pci bridges. Examples of bridges include PCI-PCI bridge (pci-bridge controller) or PCIe-PCI bridges for pc machines and pcie-root-port controller for q35 machines. Being global option, no other bridge specific option are required. For pc machine type in x86, this option is available in qemu for a long time, from version 2.1. Please see the following changes in qemu repo: 9e047b982452c6 ("piix4: add acpi pci hotplug support") 133a2da488062e ("pc: acpi: generate AML only for PCI0 devices if PCI bridge hotplug is disabled") For q35 machine type, this was introduced in qemu 6.1 with the following changes in qemu repo: (a) c0e427d6eb5fef ("hw/acpi/ich9: Enable ACPI PCI hot-plug") (b) 17858a16950860 ("hw/acpi/ich9: Set ACPI PCI hot-plug as default on Q35") The reasons for enabling ACPI based hotplug for PCIe (q35) based machines (as opposed to native hotplug) are outlined in (b). There are use cases where users would still want to use native hotplug (see notes). Therefore, this config option enables users to choose either ACPI based hotplug or native hotplug for bridges (for example for pcie root port controller in q35 machines). Notes: One concrete example of why one might still want to use native hotplug with pcie-root-port controller is the fact that we are still discovering issues with acpi hotplug on PCIE. One such issue is: https://lists.gnu.org/archive/html/qemu-devel/2021-09/msg02146.html Another reason is that users have been using native hotplug on pcie root ports up until now. They have built and tested their systems based on native hotplug. They may not want to suddenly move to acpi based hotplug just because it is now the default in qemu. Supporting the option to chose one or the other through libvirt makes things simpler for end users. Ani Sinha (4): qemu: capablities: detect presence of acpi-pci-hotplug-with-bridge-support conf: introduce support for acpi-bridge-hotplug feature qemu: command: add support for acpi-bridge-hotplug feature NEWS: add new acpi pci hotplug config option in the release note for next release NEWS.rst | 7 ++ docs/formatdomain.rst | 11 +++ docs/schemas/domaincommon.rng | 15 ++++ src/conf/domain_conf.c | 89 ++++++++++++++++++- src/conf/domain_conf.h | 9 ++ src/qemu/qemu_capabilities.c | 4 + src/qemu/qemu_capabilities.h | 2 + src/qemu/qemu_command.c | 14 +++ src/qemu/qemu_validate.c | 46 ++++++++++ .../caps_2.11.0.x86_64.xml | 1 + .../caps_2.12.0.x86_64.xml | 1 + .../caps_3.0.0.x86_64.xml | 1 + .../caps_3.1.0.x86_64.xml | 1 + .../caps_4.0.0.x86_64.xml | 1 + .../caps_4.1.0.x86_64.xml | 1 + .../caps_4.2.0.x86_64.xml | 1 + .../caps_5.0.0.x86_64.xml | 1 + .../caps_5.1.0.x86_64.xml | 1 + .../caps_5.2.0.x86_64.xml | 1 + .../caps_6.0.0.x86_64.xml | 1 + .../caps_6.1.0.x86_64.xml | 2 + .../aarch64-acpi-hotplug-bridge-disable.err | 1 + .../aarch64-acpi-hotplug-bridge-disable.xml | 33 +++++++ ...pc-i440fx-acpi-hotplug-bridge-disable.args | 31 +++++++ .../pc-i440fx-acpi-hotplug-bridge-disable.err | 1 + .../pc-i440fx-acpi-hotplug-bridge-disable.xml | 33 +++++++ .../pc-i440fx-acpi-hotplug-bridge-enable.xml | 33 +++++++ .../q35-acpi-hotplug-bridge-disable.args | 33 +++++++ .../q35-acpi-hotplug-bridge-disable.err | 1 + .../q35-acpi-hotplug-bridge-disable.xml | 47 ++++++++++ .../q35-acpi-hotplug-bridge-enable.xml | 47 ++++++++++ tests/qemuxml2argvtest.c | 16 ++++ .../pc-i440fx-acpi-hotplug-bridge-disable.xml | 1 + .../pc-i440fx-acpi-hotplug-bridge-enable.xml | 1 + .../q35-acpi-hotplug-bridge-disable.xml | 1 + .../q35-acpi-hotplug-bridge-enable.xml | 1 + tests/qemuxml2xmltest.c | 14 +++ 37 files changed, 503 insertions(+), 1 deletion(-) create mode 100644 tests/qemuxml2argvdata/aarch64-acpi-hotplug-bridge-disable.err create mode 100644 tests/qemuxml2argvdata/aarch64-acpi-hotplug-bridge-disable.xml create mode 100644 tests/qemuxml2argvdata/pc-i440fx-acpi-hotplug-bridge-disable.args create mode 100644 tests/qemuxml2argvdata/pc-i440fx-acpi-hotplug-bridge-disable.err create mode 100644 tests/qemuxml2argvdata/pc-i440fx-acpi-hotplug-bridge-disable.xml create mode 100644 tests/qemuxml2argvdata/pc-i440fx-acpi-hotplug-bridge-enable.xml create mode 100644 tests/qemuxml2argvdata/q35-acpi-hotplug-bridge-disable.args create mode 100644 tests/qemuxml2argvdata/q35-acpi-hotplug-bridge-disable.err create mode 100644 tests/qemuxml2argvdata/q35-acpi-hotplug-bridge-disable.xml create mode 100644 tests/qemuxml2argvdata/q35-acpi-hotplug-bridge-enable.xml create mode 120000 tests/qemuxml2xmloutdata/pc-i440fx-acpi-hotplug-bridge-disable.xml create mode 120000 tests/qemuxml2xmloutdata/pc-i440fx-acpi-hotplug-bridge-enable.xml create mode 120000 tests/qemuxml2xmloutdata/q35-acpi-hotplug-bridge-disable.xml create mode 120000 tests/qemuxml2xmloutdata/q35-acpi-hotplug-bridge-enable.xml -- 2.25.1

1 4

[libvirt PATCH v5 0/7] Add a PCI/PCIe device VPD Capability
by Dmitrii Shcherbakov 01 Oct '21

01 Oct '21

Add support for deserializing the binary PCI/PCIe VPD format and exposing VPD resources as XML elements in a new nested capability of PCI/PCIe devices called 'vpd'. The series contains the following incremental changes: * The PCI VPD parser module, in-memory resource representation and tests; * VPD-related helpers added to the virpci module; * VPD capability support: XML serialization/deserialization from/into VPD resource data structures; * Documentation. The VPD format is specified in "I.3. VPD Definitions" in PCI specs (2.2+) and "6.28.1 VPD Format" PCIe 4.0. As section 6.28 in PCIe 4.0 notes, the PCI Local Bus and PCIe VPD formats are binary compatible and PCIe 4.0 merely started incorporating what was already present in PCI specs. Linux kernel exposes a binary blob in the VPD format via sysfs since v2.6.26 (commit 94e6108803469a37ee1e3c92dafdd1d59298602f) which requires a parser to interpret. There are usage scenarios where information such as the board serial number needs to be retrieved from PCI(e) VPD. Projects like Nova can utilize this information for cases which involve virtual interface plugging on SmartNIC DPUs but there may be other scenarios and types of information useful to retrieve from VPD. The fact that the format is binary requires proper parsing instead of substring searching hence the full parser is proposed. Likewise, checksum validation requires proper parsing as well. A usage example is present here: https://review.opendev.org/c/openstack/nova/+/808199 The patch follows a prior discussion on the mailing list which has additional context about the use-case but a narrower proposal: https://listman.redhat.com/archives/libvir-list/2021-May/msg00873.html https://www.mail-archive.com/libvir-list@redhat.com/msg218165.html The new functionality is mostly contained in virpcivpd with a couple of new functions added to virpci. Additionally, the necessary XML serialization/deserialization and glue code is added to expose the VPD capability to external clients as XML. A new capability flag is added along with a new capability in order to allow for filtering of PCI devices with the VPD capability using virsh: virsh nodedev-list --cap vpd sudo virsh nodedev-dumpxml --device pci_dddd_bb_ss_f In this example having the root uid is required in order to access the vpd sysfs entry, therefore, the nodedev XML output will only contain the VPD capability if virsh is run as root. The capability is treated as dynamic due to the presence of read-write sections in the VPD format per PCI/PCIe specs (the idea being that read-write resource fields may potentially be altered by the DPU OS over time independently from the host OS). Unit tests cover the parser functionality (including many possible invalid cases), in-memory representation as well as XML serialization and deserialization. Manual functional testing was performed with 2 DPUs and several other NIC models which expose PCI(e) VPD. Testing have also been performed for devices that do not have VPD or those that expose a VPD capability but exhibit invalid behavior (I/O errors while reading a sysfs entry). Per the existing guidelines, the implementation relies heavily on glib for various purposes. https://libvirt.org/glib-adoption.html * v5 fixes a couple of minor typos and adds NEWS entries. * The v4 of the patch includes a number of fixes compared to v3: * Fixed the patch to correctly build against older glib (2.56.0); * Notably, glib commit 86c073dba9d82ef3f1bc3d3116b058b9b5c3b1eb (in 2.59.0) fixes g_autolist support for derivable Glib types. To make things work in 2.56.0 a workaround is conditionally applied; * virCreateAnonymousFile now uses a temporary file which is unlinked after creation instead of memfd because OpenSUSE 15.2 does not have support memfd; * Keyword resources now use GTree instead of GHashTable as the underlying data structure: * This allows for stable ordering which is important for XML2XML tests as they were failing with when GLib versions were different, resulting in a different ordering of elements; * The keyword resource iteration function was complex and got replaced by a simpler g_tree_foreach-based approach; * Added more testing: functions added to virpci are now assessed by creating a mocked vpd file under a mocked sysfs structure while the parser is still tested in virpcivpdtest file; * Refactoring: * Applied changes based on the indent tool operation with some post-processing; * Renamed functions which had the Glib naming style to use camel case where possible. Auto-generated declarations are an exception: gobject/gtype.h defines type_name##_init, type_name##_class_init, module_obj_name##_get_type functions which were left unchanged; * camelCase is now used for local variables and function parameters; * Replaced //-style comments with multi-line ones; * Split out one patch into 4 based on distinct features: * PCI VPD parser functionality and the respective in-memory types; * VPD helpers in virpci; * XML serialization/deserialization and VPD capability support; * Documentation. Build & test results for targets in ci/manifest.yaml: ci/helper test --meson-args='-Dexpensive_tests=enabled' <target> https://gist.github.com/dshcherb/225b5da9478275f08c220487814ffd1c Dmitrii Shcherbakov (7): Add a PCI/PCIe device VPD Parser News: Add a PCI VPD parser Add PCI VPD-related helper functions to virpci News: Add PCI VPD-related helper functions to virpci Add PCI VPD Capability Support News: Add PCI VPD capability support Add PCI VPD Capability Documentation NEWS.rst | 22 + build-aux/syntax-check.mk | 4 +- docs/drvnodedev.html.in | 46 ++ docs/formatnode.html.in | 24 +- docs/schemas/nodedev.rng | 40 + include/libvirt/libvirt-nodedev.h | 1 + po/POTFILES.in | 1 + src/conf/node_device_conf.c | 271 +++++++ src/conf/node_device_conf.h | 6 +- src/conf/virnodedeviceobj.c | 7 +- src/libvirt_private.syms | 17 + src/node_device/node_device_driver.c | 2 + src/node_device/node_device_udev.c | 2 + src/util/meson.build | 1 + src/util/virpci.c | 62 ++ src/util/virpci.h | 3 + src/util/virpcivpd.c | 755 ++++++++++++++++++ src/util/virpcivpd.h | 117 +++ src/util/virpcivpdpriv.h | 45 ++ tests/meson.build | 1 + .../pci_0000_42_00_0_vpd.xml | 33 + .../pci_0000_42_00_0_vpd.xml | 1 + tests/nodedevxml2xmltest.c | 1 + tests/testutils.c | 40 + tests/testutils.h | 4 + tests/virpcimock.c | 30 + tests/virpcitest.c | 64 ++ tests/virpcivpdtest.c | 705 ++++++++++++++++ tools/virsh-nodedev.c | 3 + 29 files changed, 2303 insertions(+), 5 deletions(-) create mode 100644 src/util/virpcivpd.c create mode 100644 src/util/virpcivpd.h create mode 100644 src/util/virpcivpdpriv.h create mode 100644 tests/nodedevschemadata/pci_0000_42_00_0_vpd.xml create mode 120000 tests/nodedevxml2xmlout/pci_0000_42_00_0_vpd.xml create mode 100644 tests/virpcivpdtest.c -- 2.30.2

3 23

Release of libvirt-7.8.0
by Jiri Denemark 01 Oct '21

01 Oct '21

The 7.8.0 release of both libvirt and libvirt-python is tagged and signed tarballs and source RPMs are available at https://libvirt.org/sources/ https://libvirt.org/sources/python/ Thanks everybody who helped with this release by sending patches, reviewing, testing, or providing feedback. Your work is greatly appreciated. * New features * nodedev: Add ability to automatically start mediated devices The autostart status of a persistent mediated devices can be managed with the new APIs ``virNodeDeviceSetAutostart()`` and ``virNodeDeviceGetAutostart()``. The corresponding virsh command is ``nodedev-autostart``. In addition, two new APIs were added to get additional information about node devices: ``virNodeDeviceIsPersistent()`` checks whether the device is persistently defined, and ``virNodeDeviceIsActive()`` checks whether the node device is currently active. This information can also be retrieved with the new virsh command ``nodedev-info``. Enjoy. Jirka

1 0

[PATCH] conf: fix block type CDROM cannot support startupPolicy
by Jie Wang 01 Oct '21

01 Oct '21

block type CDROM also support startupPolicy in the past, so let us fix it. Signed-off-by: Jie Wang <wangjie88(a)huawei.com> --- src/conf/domain_conf.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index f7025bffe4..dd374e8ab3 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -30853,9 +30853,10 @@ virDomainDiskTranslateSourcePool(virDomainDiskDef *def) } if (def->startupPolicy != 0 && - virStorageSourceGetActualType(def->src) != VIR_STORAGE_TYPE_FILE) { + (virStorageSourceGetActualType(def->src) != VIR_STORAGE_TYPE_FILE && + virStorageSourceGetActualType(def->src) != VIR_STORAGE_TYPE_BLOCK)) { virReportError(VIR_ERR_XML_ERROR, "%s", - _("'startupPolicy' is only valid for 'file' type volume")); + _("'startupPolicy' is only valid for 'file' or 'block' type volume")); return -1; } -- 2.24.0.windows.2

3 2

Re: [PATCH] failover: allow to pause the VM during the migration
by Laine Stump 01 Oct '21

01 Oct '21

On 9/30/21 1:09 PM, Laurent Vivier wrote: > If we want to save a snapshot of a VM to a file, we used to follow the > following steps: > > 1- stop the VM: > (qemu) stop > > 2- migrate the VM to a file: > (qemu) migrate "exec:cat > snapshot" > > 3- resume the VM: > (qemu) cont > > After that we can restore the snapshot with: > qemu-system-x86_64 ... -incoming "exec:cat snapshot" > (qemu) cont This is the basics of what libvirt does for a snapshot, and steps 1+2 are what it does for a "managedsave" (where it saves the snapshot to disk and then terminates the qemu process, for later re-animation). In those cases, it seems like this new parameter could work for us - instead of explicitly pausing the guest prior to migrating it to disk, we would set this new parameter to on, then directly migrate-to-disk (relying on qemu to do the pause). Care will need to be taken to assure that error recovery behaves the same though. There are a couple of cases when libvirt apparently *doesn't* pause the guest during the migrate-to-disk, both having to do with saving a coredump of the guest. Since I really have no idea of how common/important that is (or even if my assessment of the code is correct), I'm Cc'ing this patch to libvir-list to make sure it catches the attention of someone who knows the answers and implications. > But when failover is configured, it doesn't work anymore. > > As the failover needs to ask the guest OS to unplug the card > the machine cannot be paused. > > This patch introduces a new migration parameter, "pause-vm", that > asks the migration to pause the VM during the migration startup > phase after the the card is unplugged. > > Once the migration is done, we only need to resume the VM with > "cont" and the card is plugged back: > > 1- set the parameter: > (qemu) migrate_set_parameter pause-vm on > > 2- migrate the VM to a file: > (qemu) migrate "exec:cat > snapshot" > > The primary failover card (VFIO) is unplugged and the VM is paused. > > 3- resume the VM: > (qemu) cont > > The VM restarts and the primary failover card is plugged back > > The VM state sent in the migration stream is "paused", it means > when the snapshot is loaded or if the stream is sent to a destination > QEMU, the VM needs to be resumed manually. > > Signed-off-by: Laurent Vivier <lvivier(a)redhat.com> > --- > qapi/migration.json | 20 +++++++++++++++--- > include/hw/virtio/virtio-net.h | 1 + > hw/net/virtio-net.c | 33 ++++++++++++++++++++++++++++++ > migration/migration.c | 37 +++++++++++++++++++++++++++++++++- > monitor/hmp-cmds.c | 8 ++++++++ > 5 files changed, 95 insertions(+), 4 deletions(-) > > diff --git a/qapi/migration.json b/qapi/migration.json > index 88f07baedd06..86284d96ad2a 100644 > --- a/qapi/migration.json > +++ b/qapi/migration.json > @@ -743,6 +743,10 @@ > # block device name if there is one, and to their node name > # otherwise. (Since 5.2) > # > +# @pause-vm: Pause the virtual machine before doing the migration. > +# This allows QEMU to unplug a card before doing the > +# migration as it depends on the guest kernel. (since 6.2) > +# > # Since: 2.4 > ## > { 'enum': 'MigrationParameter', > @@ -758,7 +762,7 @@ > 'xbzrle-cache-size', 'max-postcopy-bandwidth', > 'max-cpu-throttle', 'multifd-compression', > 'multifd-zlib-level' ,'multifd-zstd-level', > - 'block-bitmap-mapping' ] } > + 'block-bitmap-mapping', 'pause-vm' ] } > > ## > # @MigrateSetParameters: > @@ -903,6 +907,10 @@ > # block device name if there is one, and to their node name > # otherwise. (Since 5.2) > # > +# @pause-vm: Pause the virtual machine before doing the migration. > +# This allows QEMU to unplug a card before doing the > +# migration as it depends on the guest kernel. (since 6.2) > +# > # Since: 2.4 > ## > # TODO either fuse back into MigrationParameters, or make > @@ -934,7 +942,8 @@ > '*multifd-compression': 'MultiFDCompression', > '*multifd-zlib-level': 'uint8', > '*multifd-zstd-level': 'uint8', > - '*block-bitmap-mapping': [ 'BitmapMigrationNodeAlias' ] } } > + '*block-bitmap-mapping': [ 'BitmapMigrationNodeAlias' ], > + '*pause-vm': 'bool' } } > > ## > # @migrate-set-parameters: > @@ -1099,6 +1108,10 @@ > # block device name if there is one, and to their node name > # otherwise. (Since 5.2) > # > +# @pause-vm: Pause the virtual machine before doing the migration. > +# This allows QEMU to unplug a card before doing the > +# migration as it depends on the guest kernel. (since 6.2) > +# > # Since: 2.4 > ## > { 'struct': 'MigrationParameters', > @@ -1128,7 +1141,8 @@ > '*multifd-compression': 'MultiFDCompression', > '*multifd-zlib-level': 'uint8', > '*multifd-zstd-level': 'uint8', > - '*block-bitmap-mapping': [ 'BitmapMigrationNodeAlias' ] } } > + '*block-bitmap-mapping': [ 'BitmapMigrationNodeAlias' ], > + '*pause-vm': 'bool' } } > > ## > # @query-migrate-parameters: > diff --git a/include/hw/virtio/virtio-net.h b/include/hw/virtio/virtio-net.h > index 824a69c23f06..a6c186e28b45 100644 > --- a/include/hw/virtio/virtio-net.h > +++ b/include/hw/virtio/virtio-net.h > @@ -210,6 +210,7 @@ struct VirtIONet { > bool failover; > DeviceListener primary_listener; > Notifier migration_state; > + VMChangeStateEntry *vm_state; > VirtioNetRssData rss_data; > struct NetRxPkt *rx_pkt; > struct EBPFRSSContext ebpf_rss; > diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c > index f205331dcf8c..c83364eac47b 100644 > --- a/hw/net/virtio-net.c > +++ b/hw/net/virtio-net.c > @@ -39,6 +39,7 @@ > #include "migration/misc.h" > #include "standard-headers/linux/ethtool.h" > #include "sysemu/sysemu.h" > +#include "sysemu/runstate.h" > #include "trace.h" > #include "monitor/qdev.h" > #include "hw/pci/pci.h" > @@ -3303,6 +3304,35 @@ static void virtio_net_migration_state_notifier(Notifier *notifier, void *data) > virtio_net_handle_migration_primary(n, s); > } > > +static void virtio_net_failover_restart_cb(void *opaque, bool running, > + RunState state) > +{ > + DeviceState *dev; > + VirtIONet *n = opaque; > + Error *err = NULL; > + PCIDevice *pdev; > + > + if (!running) { > + return; > + } > + > + dev = failover_find_primary_device(n); > + if (!dev) { > + return; > + } > + > + pdev = PCI_DEVICE(dev); > + if (!pdev->partially_hotplugged) { > + return; > + } > + > + if (!failover_replug_primary(n, dev, &err)) { > + if (err) { > + error_report_err(err); > + } > + } > +} > + > static bool failover_hide_primary_device(DeviceListener *listener, > QemuOpts *device_opts) > { > @@ -3360,6 +3390,8 @@ static void virtio_net_device_realize(DeviceState *dev, Error **errp) > device_listener_register(&n->primary_listener); > n->migration_state.notify = virtio_net_migration_state_notifier; > add_migration_state_change_notifier(&n->migration_state); > + n->vm_state = qemu_add_vm_change_state_handler( > + virtio_net_failover_restart_cb, n); > n->host_features |= (1ULL << VIRTIO_NET_F_STANDBY); > } > > @@ -3508,6 +3540,7 @@ static void virtio_net_device_unrealize(DeviceState *dev) > if (n->failover) { > device_listener_unregister(&n->primary_listener); > remove_migration_state_change_notifier(&n->migration_state); > + qemu_del_vm_change_state_handler(n->vm_state); > } > > max_queues = n->multiqueue ? n->max_queues : 1; > diff --git a/migration/migration.c b/migration/migration.c > index bb909781b7f5..9c96986d4abf 100644 > --- a/migration/migration.c > +++ b/migration/migration.c > @@ -901,6 +901,9 @@ MigrationParameters *qmp_query_migrate_parameters(Error **errp) > s->parameters.block_bitmap_mapping); > } > > + params->has_pause_vm = true; > + params->pause_vm = s->parameters.pause_vm; > + > return params; > } > > @@ -1549,6 +1552,11 @@ static void migrate_params_test_apply(MigrateSetParameters *params, > dest->has_block_bitmap_mapping = true; > dest->block_bitmap_mapping = params->block_bitmap_mapping; > } > + > + if (params->has_pause_vm) { > + dest->has_pause_vm = true; > + dest->pause_vm = params->pause_vm; > + } > } > > static void migrate_params_apply(MigrateSetParameters *params, Error **errp) > @@ -1671,6 +1679,10 @@ static void migrate_params_apply(MigrateSetParameters *params, Error **errp) > QAPI_CLONE(BitmapMigrationNodeAliasList, > params->block_bitmap_mapping); > } > + > + if (params->has_pause_vm) { > + s->parameters.pause_vm = params->pause_vm; > + } > } > > void qmp_migrate_set_parameters(MigrateSetParameters *params, Error **errp) > @@ -1718,6 +1730,12 @@ void qmp_migrate_start_postcopy(Error **errp) > " started"); > return; > } > + > + if (s->parameters.pause_vm) { > + error_setg(errp, "Postcopy cannot be started if pause-vm is on"); > + return; > + } > + > /* > * we don't error if migration has finished since that would be racy > * with issuing this command. > @@ -3734,13 +3752,27 @@ static void qemu_savevm_wait_unplug(MigrationState *s, int old_state, > "failure"); > } > } > - > migrate_set_state(&s->state, MIGRATION_STATUS_WAIT_UNPLUG, new_state); > } else { > migrate_set_state(&s->state, old_state, new_state); > } > } > > +/* stop the VM before starting the migration but after device unplug */ > +static void pause_vm_after_unplug(MigrationState *s) > +{ > + if (s->parameters.pause_vm) { > + qemu_mutex_lock_iothread(); > + qemu_system_wakeup_request(QEMU_WAKEUP_REASON_OTHER, NULL); > + s->vm_was_running = runstate_is_running(); > + if (vm_stop_force_state(RUN_STATE_PAUSED)) { > + migrate_set_state(&s->state, MIGRATION_STATUS_ACTIVE, > + MIGRATION_STATUS_FAILED); > + } > + qemu_mutex_unlock_iothread(); > + } > +} > + > /* > * Master migration thread on the source VM. > * It drives the migration and pumps the data down the outgoing channel. > @@ -3790,6 +3822,8 @@ static void *migration_thread(void *opaque) > qemu_savevm_wait_unplug(s, MIGRATION_STATUS_SETUP, > MIGRATION_STATUS_ACTIVE); > > + pause_vm_after_unplug(s); > + > s->setup_time = qemu_clock_get_ms(QEMU_CLOCK_HOST) - setup_start; > > trace_migration_thread_setup_complete(); > @@ -4265,6 +4299,7 @@ static void migration_instance_init(Object *obj) > params->has_announce_max = true; > params->has_announce_rounds = true; > params->has_announce_step = true; > + params->has_pause_vm = true; > > qemu_sem_init(&ms->postcopy_pause_sem, 0); > qemu_sem_init(&ms->postcopy_pause_rp_sem, 0); > diff --git a/monitor/hmp-cmds.c b/monitor/hmp-cmds.c > index b5e71d9e6f52..71bc8c15335b 100644 > --- a/monitor/hmp-cmds.c > +++ b/monitor/hmp-cmds.c > @@ -513,6 +513,10 @@ void hmp_info_migrate_parameters(Monitor *mon, const QDict *qdict) > } > } > } > + > + monitor_printf(mon, "%s: %s\n", > + MigrationParameter_str(MIGRATION_PARAMETER_PAUSE_VM), > + params->pause_vm ? "on" : "off"); > } > > qapi_free_MigrationParameters(params); > @@ -1399,6 +1403,10 @@ void hmp_migrate_set_parameter(Monitor *mon, const QDict *qdict) > error_setg(&err, "The block-bitmap-mapping parameter can only be set " > "through QMP"); > break; > + case MIGRATION_PARAMETER_PAUSE_VM: > + p->has_pause_vm = true; > + visit_type_bool(v, param, &p->pause_vm, &err); > + break; > default: > assert(0); > } >

4 3

translating CD-ROM device paths from i440fx to Q35 in virt-v2v (was: test-v2v-cdrom: update the CD-ROM's bus to SATA in the converted domain)
by Laszlo Ersek 30 Sep '21

30 Sep '21

(+libvirt-devel) On 09/29/21 21:22, Richard W.M. Jones wrote: > We currently partially install the virtio block drivers in the Windows > guest (just enough to get the guest to boot on the target), and > Windows itself re-installs the virtio block driver and other drivers > it needs, and that's enough to get it to see C: > > As for other hard disk partitions, Windows does indeed contain a > mapping to other drives in the Registry but IIRC it's not sensitive to > the device driver (unlike Linux /dev/vdX vs /dev/sdX). If you're > interested in that, see libguestfs.git/daemon/inspect_fs_windows.ml: > get_drive_mappings. We never bothered with attempting to handle > conversion of floppy drives or CD-ROMs for Windows. OK. So AIUI, that means no work is needed here for Windows. > On Linux we do better: We iterate over all the configuration files in > /etc and change device paths. The significance of this bug is we need > to change (eg) /dev/hdc to /dev/<something>. The difficulty is > working out where the device will appear on the target and not having > it conflict with any hard disk, something we partly control (see > virt-v2v.git/convert/target_bus_assignment.ml*) AIUI the conflict avoidance logic ("no overlapping disks") is already in place. The question is how to translate device paths in /etc/fstab and similar. Please correct me if I'm wrong: at the moment, I believe virt-v2v parses and manipulates the following elements and attributes in the domain XML: <target dev='hda' bus='ide'/> <target dev='hdb' bus='ide'/> <target dev='hdc' bus='ide'/> <target dev='hdd' bus='ide'/> ^^^ ^^^ My understanding is however that the target/@dev attribute is mostly irrelevant: https://libvirt.org/formatdomain.html#hard-drives-floppy-disks-cdroms The dev attribute indicates the "logical" device name. The actual device name specified is not guaranteed to map to the device name in the guest OS. Treat it as a device ordering hint. [...] What actually matters is the target/@bus attribute, in combination with the sibling element <address>. Such as: <target dev='hda' bus='ide'/> ^^^ <address type='drive' controller='0' bus='0' target='0' unit='0'/> ^ ^ ^ <target dev='hdb' bus='ide'/> ^^^ <address type='drive' controller='0' bus='0' target='0' unit='1'/> ^ ^ ^ <target dev='hdc' bus='ide'/> ^^^ <address type='drive' controller='0' bus='1' target='0' unit='0'/> ^ ^ ^ <target dev='hdd' bus='ide'/> ^^^ <address type='drive' controller='0' bus='1' target='0' unit='1'/> ^ ^ ^ So, target/@dev should be mostly ignored; what matters is the following tuple: (target/@bus, address/@controller, address/@bus, address/@unit) Extracting just the tuples: (ide, 0, 0, 0) (ide, 0, 0, 1) (ide, 0, 1, 0) (ide, 0, 1, 1) The first two components of each tuple -- i.e., (ide, 0) -- refer to the following IDE controller: <controller type='ide' index='0'> ^^^^^^^^^^ ^^^^^^^^^ <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/> </controller> and then the rest of the components, such as (0, 0), (0, 1), (1, 0), (1, 1), identify the disk on that IDE controller. (Side comment: the PCI location of the (first) IDE controller is fixed in QEMU; if one tries to change it, libvirt complains: "Primary IDE controller must have PCI address 0:0:1.1".) (Side comment: on the QEMU command line, this maps to -device ide-cd,bus=ide.0,unit=0,... \ -device ide-cd,bus=ide.0,unit=1,... \ -device ide-cd,bus=ide.1,unit=0,... \ -device ide-cd,bus=ide.1,unit=1,... \ ) Inside the guest, /dev/hd* nodes don't even exist, so it's unlikely that /etc/fstab would refer to them. /etc/fstab can however refer to symlinks under "/dev/disk/by-id" (for example): lrwxrwxrwx. 1 root root 9 Sep 30 11:54 ata-QEMU_DVD-ROM_QM00001 -> ../../sr0 lrwxrwxrwx. 1 root root 9 Sep 30 11:54 ata-QEMU_DVD-ROM_QM00002 -> ../../sr1 lrwxrwxrwx. 1 root root 9 Sep 30 11:54 ata-QEMU_DVD-ROM_QM00003 -> ../../sr2 lrwxrwxrwx. 1 root root 9 Sep 30 11:54 ata-QEMU_DVD-ROM_QM00004 -> ../../sr3 Furthermore, we have pseudo-files (directories) such as: /sys/devices/pci0000:00/0000:00:01.1/ata1/host0/target0:0:0/0:0:0:0/block/sr0 /sys/devices/pci0000:00/0000:00:01.1/ata1/host0/target0:0:1/0:0:1:0/block/sr1 /sys/devices/pci0000:00/0000:00:01.1/ata2/host1/target1:0:0/1:0:0:0/block/sr2 /sys/devices/pci0000:00/0000:00:01.1/ata2/host1/target1:0:1/1:0:1:0/block/sr3 ^ ^ So in order to map a device path from the original guest's "/etc/fstab", such as "/dev/disk/by-id/ata-QEMU_DVD-ROM_QM00003", to the original domain XML's <disk> element, we have to do the following in the "source" appliance: NODE=$(realpath /dev/disk/by-id/ata-QEMU_DVD-ROM_QM00003) # -> /dev/sr2 NODE=${NODE#/dev/} # -> sr2 DEVPATH=$(ls -d /sys/devices/pci0000:00/0000:00:01.1/ata?/host?/target?:0:?/?:0:?:0/block/$NODE) # -> /sys/devices/pci0000:00/0000:00:01.1/ata2/host1/target1:0:0/1:0:0:0/block/sr2 And then map the "1:0:0:0" pathname component from $DEVPATH to: <target dev='hdc' bus='ide'/> <address type='drive' controller='0' bus='1' target='0' unit='0'/> ^^^^^^^ ^^^^^^^^ [1]:0:0:0 1:0:[0]:0 in the original domain XML. This tells us under what device node the original guest sees the host-side file (<source> element). After conversion, on the Q35 board, the inverse mapping is needed. We start from the domain XML, <target dev='sd*' bus='sata'/> <address type='drive' controller='0' bus='0' target='0' unit='0'/> <target dev='sd*' bus='sata'/> <address type='drive' controller='0' bus='0' target='0' unit='1'/> <target dev='sd*' bus='sata'/> <address type='drive' controller='0' bus='0' target='0' unit='2'/> <target dev='sd*' bus='sata'/> <address type='drive' controller='0' bus='0' target='0' unit='3'/> <target dev='sd*' bus='sata'/> <address type='drive' controller='0' bus='0' target='0' unit='4'/> <target dev='sd*' bus='sata'/> <address type='drive' controller='0' bus='0' target='0' unit='5'/> <controller type='sata' index='0'> <address type='pci' domain='0x0000' bus='0x00' slot='0x1f' function='0x2'/> </controller> (Side comment: the PCI B/D/F of the SATA controller is also fixed in QEMU; otherwise libvirt complains: "Primary SATA controller must have PCI address 0:0:1f.2".) (Side comment: the QEMU command line is -device ide-cd,bus=ide.0,... \ -device ide-cd,bus=ide.1,... \ -device ide-cd,bus=ide.2,... \ -device ide-cd,bus=ide.3,... \ -device ide-cd,bus=ide.4,... \ -device ide-cd,bus=ide.5,... \ ) In the guest we have: /sys/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sr0 /sys/devices/pci0000:00/0000:00:1f.2/ata2/host1/target1:0:0/1:0:0:0/block/sr1 /sys/devices/pci0000:00/0000:00:1f.2/ata3/host2/target2:0:0/2:0:0:0/block/sr2 /sys/devices/pci0000:00/0000:00:1f.2/ata4/host3/target3:0:0/3:0:0:0/block/sr3 /sys/devices/pci0000:00/0000:00:1f.2/ata5/host4/target4:0:0/4:0:0:0/block/sr4 /sys/devices/pci0000:00/0000:00:1f.2/ata6/host5/target5:0:0/5:0:0:0/block/sr5 So, assuming we mapped the original (i440fx) "/dev/disk/by-id/ata-QEMU_DVD-ROM_QM00003" guest device path to some <source> element (= host-side file) in the original domain XML, and assuming virt-v2v assigned the same <source> element to the following element on the Q35 board: <target dev='sd*' bus='sata'/> <address type='drive' controller='0' bus='0' target='0' unit='4'/> ^^^^^^^^ we find the device node in the destination appliance as follows: NODE=$(basename /sys/devices/pci0000:00/0000:00:1f.2/ata?/host?/target?:0:0/4:0:0:0/block/*) ^ unit='4' # -> sr4 and then replace "/dev/disk/by-id/ata-QEMU_DVD-ROM_QM00003" with "/dev/sr4" in "/etc/fstab". All this requires virt-v2v to parse complete <address> elements from the original domain XML, and to generate complete <address> elements in the destination domain XML. Is that feasible? The @wwn and @serial attributes don't look safe to me, because the guest could refer to them even when the original domain XML does not spell them out (eg. "QM00003" is such a @serial). So neither can we trust that a @serial is present in the original XML, nor can we just go ahead and generate a @serial if it is absent. (The generation step could immediately break references such as "QM00003" in the guest.) /dev/disk/by-label and /dev/disk/by-uuid are based on media contents, and multiple CD-ROMs may (read-only) map the same host-side file, so those are not good for mapping either, I think. Also does not cover CD-ROM devices that are empty (have no medium) at the time of conversion, but "/etc/fstab" still refers to them (potentially with "noauto"). So I think the only reliable ID is the hardware device path. ... Now if *that* needs to work when the original guest comes from a different management application than libvirt, then I have no idea. The original address (PCI B/D/F of the IDE controller, and IDE bus and unit of the drive) need to be known somehow; otherwise we cannot associate the guest-side "/dev/..." reference with the host-side file underlying that CD-ROM. Thanks, Laszlo

3 3

[PATCH v3 0/5] Add support for two i386 pm options which control acpi hotplug
by Ani Sinha 30 Sep '21

30 Sep '21

Hi all: This patchset introduces libvirt xml support for the following two pm conf options: <pm> <acpi-hotplug-bridge enabled='no'/> <acpi-root-hotplug enabled='yes'/> </pm> The above two options are only available for qemu driver and that too for x86 guests only. Both of them are global options. ``acpi-hotplug-bridge`` option enables or disables ACPI hotplug support for cold plugged bridges. Examples of cold plugged bridges include PCI-PCI bridge (pci-bridge controller) for pc machines and pcie-root-port controller for q35 machines. The corresponding commandline options to qemu for x86 guests are: (pc machines): -global PIIX4_PM.acpi-pci-hotplug-with-bridge-support=<off/on> (q35 machines): -global ICH9-LPC.acpi-pci-hotplug-with-bridge-support=<off/on> Being global options, no other bridge specific options for pci-bridge controller or pcie-root-port controllers are required. For pc machine type in x86, this option is available in qemu for a long time, from version 2.1. Please see the changes in qemu.git: 9e047b982452c6 ("piix4: add acpi pci hotplug support") 133a2da488062e ("pc: acpi: generate AML only for PCI0 devices if PCI bridge hotplug is disabled") For q35 machine type, this was introduced in qemu 6.1 with the following changes in qemu.git: (a) c0e427d6eb5fef ("hw/acpi/ich9: Enable ACPI PCI hot-plug") (b) 17858a16950860 ("hw/acpi/ich9: Set ACPI PCI hot-plug as default on Q35") The reasons for enabling ACPI based hotplug for PCIe (q35) based machines (as opposed to native hotplug) for bridges are outlined in (b). It is possible that some users might still want to use native hotplug on PCIe [1]. Therefore, this conf option enables users to choose either ACPI based hotplug or native hotplug for cold plugged bridges (for example for pcie root port controller in q35 machines). ``acpi-root-hotplug`` option enables or disables ACPI based hotplug for PCI root bus (pci-root controller). This option is only available for pc machine type. The corresponding commandline option to qemu for x86 guests is: -global PIIX4_PM.acpi-root-pci-hotplug=<off/on> This additional option enables users to disable hotplug for all devices in the system without adding an additional PCI-PCI bridge, putting the devices behind the bridge and using the existing ``acpi-hotplug-bridge`` option to disable hotplug on that bridge. This feature was introduced from qemu version 5.2 with the following change in qemu.git: 3d7e78aa7777f ("Introduce a new flag for i440fx to disable PCI hotplug on the root bus") The above qemu commit describes some compelling reasons why users might to disable hotplug on PCI root buses [2]. A brief summary of the patches: >[PATCH v3 1/5] qemu: capablities: detect presence of >[PATCH v3 2/5] qemu: capablities: detect presence of Patches 1 and 2 implement support for qemu capability checks for the above config options. >[PATCH v3 3/5] conf: introduce acpi-hotplug-bridge and Patch 3 actually adds the config option to the schema and adds related unit tests. >[PATCH v3 4/5] qemu: command: add support for qemu options that Patch 4 adds the backend qemu commandline support for the options. It also adds relevant unit tests for the same. >[PATCH v3 5/5] NEWS: add new acpi pci hotplug options in the release Patch 5 adds the release notes for the next libvirt release. Changelog: v1: initial implementation. Had some bugs and missed some unit tests. v2: fixed bugs and added additional missing unit tests. v3: reorganized the patches as per Laine's suggestion. Added more details in commit messages. Added conf description in formatdomain.rst. Added changelog for next release. Notes: [1] One concrete example of why one might still want to use native hotplug with pcie-root-port controller is the fact that we are still discovering issues with acpi hotplug on PCIE. One such issue is: https://lists.gnu.org/archive/html/qemu-devel/2021-09/msg02146.html Another reason is that users have been using native hotplug on pcie root ports up until now. They have built and tested their systems based on native hotplug. They may not want to suddenly move to acpi based hotplug just because it is now the default in qemu. Supporting the option to chose one or the other through libvirt makes things simpler for end users. [2] The use case scenario described by Laine in https://listman.redhat.com/archives/libvir-list/2020-February/msg00110.html intentionally does not discuss i440fx and focusses solely on q35. I do realize that redhat has moved on from i440fx and currently efforts for new features are concentrated on q35 machines only. We have had some hard debates on this on the qemu mailing list before. The fact of the matter is that i440fx is not at 1-1 parity with q35. There are many users who are currenly using i440fx and are simply not ready to move to q35 without sacrificing some existing features they support today. For example https://wiki.qemu.org/images/4/4e/Q35.pdf lists some of q35 limitations. https://www.linux-kvm.org/images/0/06/2012-forum-Q35.pdf provides more information on the differences. Hence we need to solve the issue Laine has described in the above email for i440fx without adding additional bridges. Further, in Daniel Berrange's words from : https://lists.gnu.org/archive/html/qemu-devel/2020-04/msg03012.html "From the upstream POV, there's been no decision / agreement to phase out PIIX, this is purely a RHEL downstream decision & plan. If other distros / users have a different POV, and find the feature useful, we should accept the patch if it meets the normal QEMU patch requirements. " Also to be noted that I have already experimented this qemu commandline option using libvirt passthrough feature as has been documented in http://blog.vmsplice.net/2011/04/how-to-pass-qemu-command-line-options.html This was only meant to be a short term solution until libvirt started supporting this natively. Supporting this option through libvirt would simplify their use case as well as add capability validations and graceful failure scenarios in case qemu did not support the option. [3] Finally, I implemented support for ``acpi-root-hotplug`` option in Qemu. Since adding the support for this option, I have not run away :-) I am still around, fixing other issues in the same subsystem in qemu and also now I have added myself as a reviewer of patches in this area. I will also be trying to support/maintain this new xml conf option in libvirt to the extent I can in future with the help of other experienced maintainers. Obviously this is all freelance work at this moment and is highly dependent on available free time.

4 42

[PATCH] qemuDomainChangeDiskLive: Modify 'startupPolicy' before changing source
by Peter Krempa 30 Sep '21

30 Sep '21

We don't support all startup policies with all source types so to correctly allow switching from a 'file' based cdrom with 'optional' startup policy to a 'block' based one which doesn't support optional we must update the startup policy field first. Obviously we need to have fallback if the update fails. Reported-by: Vojtech Juranek <vjuranek(a)redhat.com> Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- src/qemu/qemu_driver.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index bd41ddbc3c..dfc27572c4 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -7038,6 +7038,7 @@ qemuDomainChangeDiskLive(virDomainObj *vm, { virDomainDiskDef *disk = dev->data.disk; virDomainDiskDef *orig_disk = NULL; + virDomainStartupPolicy origStartupPolicy; virDomainDeviceDef oldDev = { .type = dev->type }; if (!(orig_disk = virDomainDiskByTarget(vm->def, disk->dst))) { @@ -7047,6 +7048,7 @@ qemuDomainChangeDiskLive(virDomainObj *vm, } oldDev.data.disk = orig_disk; + origStartupPolicy = orig_disk->startupPolicy; if (virDomainDefCompatibleDevice(vm->def, dev, &oldDev, VIR_DOMAIN_DEVICE_ACTION_UPDATE, true) < 0) @@ -7065,13 +7067,20 @@ qemuDomainChangeDiskLive(virDomainObj *vm, return -1; } + /* update startup policy first before updating disk image */ + orig_disk->startupPolicy = dev->data.disk->startupPolicy; + if (qemuDomainChangeEjectableMedia(driver, vm, orig_disk, - dev->data.disk->src, force) < 0) + dev->data.disk->src, force) < 0) { + /* revert startup policy before failing */ + orig_disk->startupPolicy = origStartupPolicy; return -1; + } dev->data.disk->src = NULL; } + /* in case when we aren't updating disk source we update startup policy here */ orig_disk->startupPolicy = dev->data.disk->startupPolicy; orig_disk->snapshot = dev->data.disk->snapshot; -- 2.31.1

5 8