- Devel - libvirt List Archives

[PATCH 0/3] virsh: Completers improvements
by Michal Privoznik 15 Mar '22

15 Mar '22

*** BLURB HERE *** Michal Prívozník (3): virsh: Properly terminate string list in virshDomainInterfaceSourceModeCompleter() virsh: Introduce virshEnumComplete() virsh: Don't open code virshEnumComplete() tools/virsh-completer-domain.c | 147 ++++++-------------------------- tools/virsh-completer-host.c | 11 +-- tools/virsh-completer-nodedev.c | 7 +- tools/virsh-completer-pool.c | 7 +- tools/virsh-completer-volume.c | 11 +-- tools/virsh-completer.c | 27 ++++++ tools/virsh-completer.h | 4 + 7 files changed, 67 insertions(+), 147 deletions(-) -- 2.34.1

2 4

REST service for libvirt to simplify SEV(ES) launch measurement
by Daniel P. Berrangé 14 Mar '22

14 Mar '22

Extending management apps using libvirt to support measured launch of QEMU guests with SEV/SEV-ES is unreasonably complicated today, both for the guest owner and for the cloud management apps. We have APIs for exposing info about the SEV host, the SEV guest, guest measurements and secret injections. This is a "bags of bits" solution. We expect apps to them turn this into a user facting solution. It is possible but we're heading to a place where every cloud mgmt app essentially needs to reinvent the same wheel and the guest owner will need to learn custom APIs for dealing with SEV/SEV-ES for each cloud mgmt app. This is pretty awful. We need to do a better job at providing a solution that is more general purpose IMHO. Consider a cloud mgmt app, right now the flow to use the bag of bits libvirt exposes, looks something like * Guest owner tells mgmt app they want to launch a VM * Mgmt app decides what host the VM will be launched on * Guest owner requests cert chain for the virt host from mgmt app * Guest owner validates cert chain for the virt host * Guest owner generates launch blob for the VM * Guest owner provides launch blob to the mgmt app * Management app tells libvirt to launch VM with blob, with CPUs in a paused state * Libvirt luanches QEMU with CPUs stopped * Guest owner requests launch measurement from mgmt app * Guest owner validates measurement * Guest owner generates secret blob * Guest owner sends secret blob to management app * Management app tells libvirt to inject secrets * Libvirt injects secrets to QEMU * Management app tells libvirt to start QEMU CPUs * Libvirt tells QEMU to start CPUs Compare to a non-confidental VM * Guest owner tells mgmt app they want to launch a VM * Mgmt app decides what host the VM will be launched on * Mgmt app tells libvirt to launch VM with CPUs in running state * Libvirt launches QEMU with CPUs running Now, of course the guest owner wouldn't be manually performing the earlier steps, they would want some kind of software to take care of this. No matter what, it still involves a large number of back and forth operations between the guest owner & mgmt app, and between the mgmt app and libvirt. One of libvirt's key jobs is to isolate mgmt apps from differences in behaviour of underlying hypervisor technologies, and we're failing at that job with SEV/SEV-ES, because the mgmt app needs to go through a multi-stage dance on every VM start, that is different from what they do with non-confidential VMs. It is especially unpleasant because there needs to be a "wait state" between when the app selects a host to deploy a VM on, and when it can actually start a VM. In essence the app needs to reserve capacity on a host ahead of time for a VM that will be created some arbitrary time later. This can have significant implications for the mgmt app architectural design that are not neccessarily easy to address, when they expect to just call virDomainCreate have the VM running in one step. It also harms interoperability to libvirt tools. For example if a mgmt tool like virt-manager/OpenStack created a VM using SEV, and you want to start it manually using a different tool like 'virsh', you enter a world of complexity and pain, due to the multi step dance required. AFAICT, in all of this, the mgmt app is really acting as a conduit and is not implementing any interesting logic. The clever stuff is all the responsibility of the guest owner, and/or whatever software for attestation they are using remotely. I think there is scope for enhancing libvirt, such that usage of SEV/SEV-ES has little-to-no burden for the management apps, and much less burden for guest owners. The key to achieving this is to define a protocol for libvirt to connect to a remote service to handle the launch measurements & secret acquisition. The guest owner can provide the address of a service they control (or trust), and libvirt can take care of all the interactions with it. This frees both the user and mgmt app from having to know much about SEV/SEV-ES, with VM startup process being essentially the same as it has always been. The sequence would look like * Guest owner tells attestation service they intend to create a VM with a given UUID, policy, and any other criteria such as cert of the cloud owner, valid OVMF firmware hashes, and providing any needed LUKS keys. * Guest owner tells mgmt app they want to launch a VM, using attestation service at https://somehost/and/url * Mgmt app decides what host the VM will be launched on * Mgmt app tells libvirt to launch VM with CPUs in running state The next steps involve solely libvirt & the attestation service. The mgmt app and guest owner have done their work. * Libvirt contacts the service providing certificate chain for the host to be used, the UUID of the guest, and any other required info about the host. * Attestation service validates the cert chain to ensure it belongs to the cloud owner that was identified previously * Attestation service generates a launch blob and puts it in the response back to libvirt * Libvirt launches QEMU with CPUs paused * Libvirt gets the launch measurement and sends it to the attestation server, with any other required info about the VM instance * Attestation service validates the measurement * Attestation builds the secret table with LUKS keys and puts it in the response back to libvirt * Libvirt injects the secret table to QEMU * Libvirt tells QEMU to start CPUs All the same exchanges of information are present, but the management app doesn't have to get involved. The guest owner also doesn't have to get involved except for a one-time setup step. The software the guest owner uses for attestation also doesn't have to be written to cope with talking to OpenStack, CNV and whatever other vendor specific cloud mgmt apps exist today. This will significantly reduce the burden if supporting SEV/SEV-ES launch measurement in libvirt based apps, and make SEV/SEV-ES guests more "normal" from a mgmt POV. What could this look like from POV of an attestation server API, if we assume HTTPS REST service with a simple JSON payload ... * Guest Owner: Register a new VM to be booted: POST /vm/<UUID> Request body: { "scheme": "amd-sev", "cloud-cert": "certificate of the cloud owner that signs the PEK", "policy": 0x3, "cpu-count": 3, "firmware-hashes": [ "xxxx", "yyyy", ], "kernel-hash": "aaaa", "initrd-hash": "bbbb", "cmdline-hash": "cccc", "secrets": [ { "type": "luks-passphrase", "passphrase": "<blah>" } ] } * Libvirt: Request permission to launch a VM on a host POST /vm/<UUID>/launch Request body: { "pdh": "<blah>", "cert-chain": "<blah>", "cpu-id": "<CPU ID>", ...other relevant bits... } Service decides if the proposed host is acceptable Response body (on success) { "session": "<blah>", "owner-cert": "<blah>", "policy": 3, } * Libvirt: Request secrets to inject to launched VM POST /vm/<UUID>/validate Request body: { "api-minor": 1, "api-major": 2, "build-id": 241, "policy": 3, "measurement": "<blah>", "firmware-hash": "xxxx", "cpu-count": 3, ....other relevant stuff.... } Service validates the measurement... Response body (on success): { "secret-header": "<blah>", "secret-table": "<blah>", } So we can see there are only a couple of REST API calls we need to be able to define. If we could do that then creating a SEV/SEV-ES enabled guest with libvirt would not involve anything more complicated for the mgmt app that providing the URI of the guest owner's attestation service and an identifier for the VM. ie. the XML config could be merely: <launchSecurity type="sev"> <attestation vmid="57f669c2-c427-4132-bc7a-26f56b6a718c" service="http://somehost/some/url"/> </launchSecurity> And then involve virDomainCreate as normal with any other libvirt / QEMU guest. No special workflow is required by the mgmt app. There is a small extra task for the guest owner to register existance of their VM with the attestation service. Aside from that the only change to the way they interact with the cloud mgmt app is to provide the VM ID and URI for the attestation service. No need to learn custom APIs for each different cloud vendor, for dealing with fetching launch measurements or injecting secrets. Finally this attestation service REST protocol doesn't have to be something controlled or defined by libvirt. I feel like it could be a protocol that is defined anywhere and libvirt merely be one consumer of it. Other apps that directly use QEMU may also wish to avail themselves of it. All that really matters from libvirt POV is: - The protocol definition exist to enable the above workflow, with a long term API stability guarantee that it isn't going to changed in incompatible ways - There exists a fully open source reference implementation of sufficient quality to deploy in the real world I know https://github.com/slp/sev-attestation-server exists, but its current design has assumptions about it being used with libkrun AFAICT. I have heard of others interested in writing similar servers, but I've not seen code. We are at a crucial stage where mgmt apps are looking to support measured boot with SEV/SEV-ES and if we delay they'll all go off and do their own thing, and it'll be too late, leading to https://xkcd.com/927/. Especially for apps using libvirt to manage QEMU, I feel we have got a few months window of opportunity to get such a service available, before they all end up building out APIs for the tedious manual workflow, reinventing the wheel. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|

5 12

[PATCH 0/2] qemu_namespace: Two simple improvements
by Michal Privoznik 14 Mar '22

14 Mar '22

These are inspired by Nikola's question here: https://listman.redhat.com/archives/libvir-list/2022-February/228812.html See my reply here: https://listman.redhat.com/archives/libvir-list/2022-March/229263.html Michal Prívozník (2): qemu_namespace: Don't unlink paths from cgroupDeviceACL qemu_namespace: Be less aggressive in removing /dev nodes from namespace src/qemu/qemu_namespace.c | 92 +++++++++++++++++++++++++++------------ 1 file changed, 63 insertions(+), 29 deletions(-) -- 2.34.1

2 3

[PATCH v3 00/29] ppc64 PowerNV machines support
by Daniel Henrique Barboza 14 Mar '22

14 Mar '22

Hi, This new version contains changes proposed by Jano. The most notable change is on patch 9, where pnv_pnv3/pnv_phb4 capabilities are now being probed and, if the QEMU version isn't high enough, they are cleared from qemuCaps. For convenience, the patches that are pending review/acks are patches 14, 17, 19, 20, 22, 23 and 24. v2 link: https://listman.redhat.com/archives/libvir-list/2022-January/msg01149.html Daniel Henrique Barboza (29): qemu_domain.c: add PowerNV machine helpers qemu_capabilities.c: use 'MachineIsPowerPC' in DeviceDiskCaps qemu_domain: turn qemuDomainMachineIsPSeries() static qemu_validate.c: use qemuDomainIsPowerPC() in qemuValidateDomainChrDef() qemu_domain.c: define ISA as default PowerNV serial qemu_validate.c: enhance 'machine type not supported' message qemu_domain.c: disable default devices for PowerNV machines tests: add basic PowerNV8 test qemu: introduce QEMU_CAPS_DEVICE_PNV_PHB3 conf, qemu: add 'pnv-phb3-root-port' PCI controller model name conf, qemu: add 'pnv-phb3' PCI controller model name domain_conf.c: fix identation in virDomainControllerDefParseXML() conf: parse and format <target chip-id='...'/> formatdomain.rst: add 'index' semantics for PowerNV domains conf: introduce virDomainControllerIsPowerNVPHB conf, qemu: add default 'chip-id' value for pnv-phb3 controllers conf, qemu: add default 'targetIndex' value for pnv-phb3 devs qemu_command.c: add command line for the pnv-phb3 device qemu_domain_address.c: change pnv-phb3 minimal downstream slot domain_conf: always format pnv-phb3-root-port address tests: add pnv-phb3-root-port test domain_validate.c: allow targetIndex 0 out of idx 0 for PowerNV PHBs domain_conf.c: reject duplicated pnv-phb3 devices qemu: introduce QEMU_CAPS_DEVICE_PNV_PHB4 conf, qemu: add 'pnv-phb4-root-port' PCI controller model name domain_conf.c: add phb4-root-port to IsPowerNVRootPort() conf, qemu: add 'pnv-phb4' controller model name domain_conf.c: add pnv-phb4 to ControllerIsPowerNVPHB() tests: add PowerNV9 tests docs/formatdomain.rst | 12 +- docs/schemas/domaincommon.rng | 10 ++ src/conf/domain_conf.c | 156 ++++++++++++++---- src/conf/domain_conf.h | 8 + src/conf/domain_validate.c | 5 +- src/libvirt_private.syms | 1 + src/qemu/qemu_capabilities.c | 19 ++- src/qemu/qemu_capabilities.h | 4 + src/qemu/qemu_command.c | 21 ++- src/qemu/qemu_domain.c | 51 +++++- src/qemu/qemu_domain.h | 4 +- src/qemu/qemu_domain_address.c | 64 ++++++- src/qemu/qemu_validate.c | 62 ++++++- .../qemucapabilitiesdata/caps_5.0.0.ppc64.xml | 2 + .../qemucapabilitiesdata/caps_5.2.0.ppc64.xml | 2 + .../qemucapabilitiesdata/caps_6.2.0.ppc64.xml | 2 + .../qemucapabilitiesdata/caps_7.0.0.ppc64.xml | 2 + .../powernv8-basic.ppc64-latest.args | 34 ++++ tests/qemuxml2argvdata/powernv8-basic.xml | 16 ++ tests/qemuxml2argvdata/powernv8-dupPHBs.err | 1 + .../powernv8-dupPHBs.ppc64-latest.err | 1 + tests/qemuxml2argvdata/powernv8-dupPHBs.xml | 27 +++ .../powernv8-root-port.ppc64-latest.args | 35 ++++ tests/qemuxml2argvdata/powernv8-root-port.xml | 17 ++ .../powernv8-two-sockets.ppc64-latest.args | 35 ++++ .../qemuxml2argvdata/powernv8-two-sockets.xml | 26 +++ .../powernv9-dupPHBs.ppc64-latest.err | 1 + tests/qemuxml2argvdata/powernv9-dupPHBs.xml | 27 +++ .../powernv9-root-port.ppc64-latest.args | 35 ++++ tests/qemuxml2argvdata/powernv9-root-port.xml | 17 ++ tests/qemuxml2argvtest.c | 7 + .../powernv8-basic.ppc64-latest.xml | 34 ++++ .../powernv8-root-port.ppc64-latest.xml | 39 +++++ .../powernv8-two-sockets.ppc64-latest.xml | 39 +++++ .../powernv9-root-port.ppc64-latest.xml | 39 +++++ .../qemuxml2xmloutdata/powernv9-root-port.xml | 36 ++++ tests/qemuxml2xmltest.c | 5 + 37 files changed, 848 insertions(+), 48 deletions(-) create mode 100644 tests/qemuxml2argvdata/powernv8-basic.ppc64-latest.args create mode 100644 tests/qemuxml2argvdata/powernv8-basic.xml create mode 100644 tests/qemuxml2argvdata/powernv8-dupPHBs.err create mode 100644 tests/qemuxml2argvdata/powernv8-dupPHBs.ppc64-latest.err create mode 100644 tests/qemuxml2argvdata/powernv8-dupPHBs.xml create mode 100644 tests/qemuxml2argvdata/powernv8-root-port.ppc64-latest.args create mode 100644 tests/qemuxml2argvdata/powernv8-root-port.xml create mode 100644 tests/qemuxml2argvdata/powernv8-two-sockets.ppc64-latest.args create mode 100644 tests/qemuxml2argvdata/powernv8-two-sockets.xml create mode 100644 tests/qemuxml2argvdata/powernv9-dupPHBs.ppc64-latest.err create mode 100644 tests/qemuxml2argvdata/powernv9-dupPHBs.xml create mode 100644 tests/qemuxml2argvdata/powernv9-root-port.ppc64-latest.args create mode 100644 tests/qemuxml2argvdata/powernv9-root-port.xml create mode 100644 tests/qemuxml2xmloutdata/powernv8-basic.ppc64-latest.xml create mode 100644 tests/qemuxml2xmloutdata/powernv8-root-port.ppc64-latest.xml create mode 100644 tests/qemuxml2xmloutdata/powernv8-two-sockets.ppc64-latest.xml create mode 100644 tests/qemuxml2xmloutdata/powernv9-root-port.ppc64-latest.xml create mode 100644 tests/qemuxml2xmloutdata/powernv9-root-port.xml -- 2.35.1

1 30

[PATCH] scripts: Fix the parameter of warning function
by luzhipeng 14 Mar '22

14 Mar '22

The parameter of self.warning is inconsistent with it's definition, So fix it. Signed-off-by: luzhipeng <luzhipeng(a)cestc.cn> --- scripts/apibuild.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/apibuild.py b/scripts/apibuild.py index bdd3077c48..99b16f47fa 100755 --- a/scripts/apibuild.py +++ b/scripts/apibuild.py @@ -317,7 +317,7 @@ class index: if type in type_map: type_map[type][name] = d else: - self.warning("Unable to register type ", type) + self.warning("Unable to register type %s" % type) if name == debugsym and not quiet: print("New symbol: %s" % (d)) -- 2.34.0.windows.1

1 0

[PATCH 0/1]scripts: Fix the parameter of warning function
by luzhipeng 14 Mar '22

14 Mar '22

luzhipeng (1): scripts: Fix the parameter of warning function scripts/apibuild.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 2.34.0.windows.1

2 2

[PATCH] scripts: Fix the parameter of warning function
by luzhipeng 14 Mar '22

14 Mar '22

--- scripts/apibuild.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/apibuild.py b/scripts/apibuild.py index bdd3077c48..99b16f47fa 100755 --- a/scripts/apibuild.py +++ b/scripts/apibuild.py @@ -317,7 +317,7 @@ class index: if type in type_map: type_map[type][name] = d else: - self.warning("Unable to register type ", type) + self.warning("Unable to register type %s" % type) if name == debugsym and not quiet: print("New symbol: %s" % (d)) -- 2.34.0.windows.1

1 0

[PATCH 0/3] qemu: Introduce 'manual' snapshot mode for storage providers not managed by libvirt
by Peter Krempa 14 Mar '22

14 Mar '22

Peter Krempa (3): conf: snapshot: Introduce 'manual' mode for snapshot of a disk qemuSnapshotCreateActiveExternal: Implement manual snapshot mode kbase: Introduce 'snapshots' page and describe the new 'manual' snapshot docs/formatdomain.rst | 15 +++++----- docs/formatsnapshot.rst | 9 ++++++ docs/kbase/index.rst | 3 ++ docs/kbase/meson.build | 1 + docs/kbase/snapshots.rst | 53 +++++++++++++++++++++++++++++++++ docs/schemas/domainsnapshot.rng | 3 ++ src/conf/domain_conf.c | 1 + src/conf/domain_conf.h | 1 + src/conf/snapshot_conf.c | 6 ++++ src/qemu/qemu_snapshot.c | 24 +++++++++++---- src/test/test_driver.c | 17 +++++++++++ 11 files changed, 121 insertions(+), 12 deletions(-) create mode 100644 docs/kbase/snapshots.rst -- 2.35.1

2 5

[libvirt PATCH] docs: downloads: fix link to libvirt GitLab group
by Ján Tomko 11 Mar '22

11 Mar '22

s/libvirt.org/libvirt/ Signed-off-by: Ján Tomko <jtomko(a)redhat.com> --- docs/downloads.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Pushed as trivial. diff --git a/docs/downloads.rst b/docs/downloads.rst index d438166b78..e32fd1ba99 100644 --- a/docs/downloads.rst +++ b/docs/downloads.rst @@ -314,7 +314,7 @@ GIT source repository --------------------- All modules maintained by the libvirt project have their primary source -available in the `libvirt group on GitLab <https://gitlab.com/libvirt.org/>`__. +available in the `libvirt group on GitLab <https://gitlab.com/libvirt/>`__. Each module can be cloned anonymously using: :: -- 2.35.1

1 0

[RFC patch 0/2] nwfilter: don't query netfilter inside transactions
by Nikolay Shirokovskiy 11 Mar '22

11 Mar '22

Hi, all. In the process of fixing a corner case in nwfilter in case of libvirtd crash I noticed the peculiar way it works for recursive removes/renames of chains. So I proposing a change which is described in the second patch. This is an RFC and as such is incomplete: - only recursive removing is patched and renaming is not - tests are not fixed Nikolay Shirokovskiy (2): utils: make virFirewallAddRuleFullV public nwfilter: don't query netfilter inside transactions src/libvirt_private.syms | 1 + src/nwfilter/nwfilter_ebiptables_driver.c | 154 +++++++++++----------- src/util/virfirewall.c | 2 +- src/util/virfirewall.h | 7 + 4 files changed, 84 insertions(+), 80 deletions(-) -- 2.31.1

2 4