- Devel - libvirt List Archives

libvirt-devaddr: a new library for device address assignment
by Daniel P. Berrangé 05 May '20

05 May '20

We've been doing alot of refactoring of code in recent times, and also have plans for significant infrastructure changes. We still need to spend time delivering interesting features to users / applications. This mail is to introduce an idea for a solution to an specific area applications have had long term pain with libvirt's current "mechanism, not policy" approach - device addressing. This is a way for us to show brand new ideas & approaches for what the libvirt project can deliver in terms of management APIs. To set expectations straight: I have written no code for this yet, merely identified the gap & conceptual solution. The device addressing problem ============================= One of the key jobs libvirt does when processing a new domain XML configuration is to assign addresses to all devices that are present. This involves adding various device controllers (PCI bridges, PCI root ports, IDE/SCSI buses, USB controllers, etc) if they are not already present, and then assigning PCI, USB, IDE, SCSI, etc, addresses to each device so they are associated with controllers. When libvirt spawns a QEMU guest, it will pass full address information to QEMU. Libvirt, as a general rule, aims to avoid defining and implementing policy around expansion of guest configuration / defaults, however, it is inescapable in the case of device addressing due to the need to guarantee a stable hardware ABI to make live migration and save/restore to disk work. The policy that libvirt has implemented for device addressing is, as much as possible, the same as the addressing scheme QEMU would apply itself. While libvirt succeeds in its goal of providing a stable hardware API, the addressing scheme used is not well suited to all deployment scenarios of QEMU. This is an inevitable result of having a specific assignment policy implemented in libvirt which has to trade off mutually incompatible use cases/goals. When the libvirt addressing policy is not been sufficient, management applications are forced to take on address assignment themselves, which is a massive non-trivial job with many subtle problems to consider. Places where libvirt's addressing is insufficient for PCI include * Setting up multiple guest NUMA nodes and associating devices to specific nodes * Pre-emptive creation of extra PCIe root ports, to allow for later device hotplug on PCIe topologies * Determining whether to place a device on a PCI or PCIe bridge * Controlling whether a device is placed into a hotpluggable slot * Controlling whether a PCIe root port supports hotplug or not * Determining whether to places all devices on distinct slots or buses, vs grouping them all into functions on the same slot * Ability to expand the device addressing without being on the hypervisor host Libvirt wishes to avoid implementing many different address assignment policies. It also wishes to keep the domain XML as a representation of the virtual hardware, not add a bunch of properties to it which merely serve as tunable input parameters for device addressing algorithms. There is thus a dilemma here. Management applications increasingly need fine grained control over device addressing, while libvirt doesn't want to expose fine grained policy controls via the XML. The new libvirt-devaddr API =========================== The way out of this is to define a brand new virt management API which tackles this specific problem in a way that addresses all the problems mgmt apps have with device addressing and explicitly provides a variety of policy impls with tunable behaviour. By "new API", I actually mean an entirely new library, completely distinct from libvirt.so, or anything else we've delivered so far. The closest we've come to delivering something at this kind of conceptual level, would be the abortive attempt we made with "libvirt-builder" to deliver a policy-driven API instead of mechanism based. This proposal is still quite different from that attempt. At a high level * The new API is "libvirt-devaddr" - short for "libvirt device addressing" * As input it will take 1. The guest CPU architecture and machine type 2. A list of global tunables specifying desired behaviour of the address assignment policy 3. A minimal list of devices needed in the virtual machine, with optional addresses and optional per-device tunables to override the global tunables * As output it will emit 1. fully expanded list of devices needed in the virtual machine, with addressing information sufficient to ensure stable hardware ABI Initially the API would implement something that behaves the same way as libvirt's current address assignment API. The intended usage would be * Mgmt application makes a minimal list of devices they want in their guest * List of devices is fed into libvirt-devaddr API * Mgmt application gets back a full list of devices & addresses * Mgmt application writes a libvirt XML doc using this full list & addresses * Mgmt application creates the guest in libvirt IOW, this new "libvirt-devaddr" API is intended to be used prior to creating the XML that is used by libvirt. The API could also be used prior to needing to hotplug a new device to an existing guest. This API is intended to be a deliverable of the libvirt project, but it would be completely independent of the current libvirt API. Most especially note that it would NOT use the domain XML in any way. This gives applications maximum flexibility in how they consume this functionality, not trying to force a way to build domain XML. It would have greater freedom in its API design, making different choices from libvirt.so on topics such as programming language (C vs Go vs Python etc), API stability timeframe (forever stable vs sometimes changing API), data formats (structs, vs YAML/JSON vs XML etc), and of course the conceptual approach (policy vs mechanism) The expectation is that this new API would be most likely to be consumed by KubeVirt, OpenStack, Kata, as the list of problems shown earlier is directly based on issues seen working with KubeVirt & OpenStack in particular. It is not limited to these applications and is broadly useful as conceptual thing. It would be a goal that this API should also be used by libvirt itself to replace its current internal device addressing impl. Essentially the new API should be seen as a way to expose/extract the current libvirt internal algorithm, making it available to applications in a flexible manner. I don't anticipate actually copying the current addressing code in libvirt as-is, but it would certainly serve as reference for the kind of logic we need to implement, so you might consider it a "port" or "rewrite" in some very rough sense. I think this new API concept is a good way for the project make a start in using Go for libvirt. The functionality covered has a clearly defined scope limit, making it practical to deliver a real impl in a reasonably short time frame. Extracting this will provide a real world benefit to our application consumers, solving many long standing problems they have with libvirt, and thus justify the effort in doing this work in libvirt in a non-C language. The main question mark would be about how we might make this functionality available to Python apps if we chose Go. It is possible to expose a C API from Go, and we would need this to consume it from libvirt. There is then the need to manually write a Python API binding which is tedious work. 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 :|

7 14

[PATCH 0/3] Xen: Improve the naming mess
by Jim Fehlig 05 May '20

05 May '20

Let's hope it's an improvement :-). See individual patches for details. Jim Fehlig (3): libxl: Use the name 'Xen' in driver tables libxl: Clarify that 'xenlight' should only be used internally docs: Xen improvements docs/aclpolkit.html.in | 4 ++-- docs/formatdomain.html.in | 6 +++--- src/libxl/libxl_conf.h | 8 +++++++- src/libxl/libxl_domain.c | 4 ++-- src/libxl/libxl_driver.c | 20 ++++++++++---------- 5 files changed, 24 insertions(+), 18 deletions(-) -- 2.26.0

2 4

[libvirt PATCH v2] remote: fix driver name check for libxl driver
by Daniel P. Berrangé 04 May '20

04 May '20

The virConnectGetType() returns "Xen" for libxl, not "LIBXL". This prevents users opening a connection to the libxl driver when using the modular daemons. Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- src/remote/remote_daemon_dispatch.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/remote/remote_daemon_dispatch.c b/src/remote/remote_daemon_dispatch.c index 5d1c6971c0..6f67d2fb30 100644 --- a/src/remote/remote_daemon_dispatch.c +++ b/src/remote/remote_daemon_dispatch.c @@ -2111,7 +2111,7 @@ remoteDispatchConnectOpen(virNetServerPtr server G_GNUC_UNUSED, VIR_DEBUG("Primary driver type is '%s'", type); if (STREQ(type, "QEMU") || - STREQ(type, "LIBXL") || + STREQ(type, "Xen") || STREQ(type, "LXC") || STREQ(type, "VBOX") || STREQ(type, "bhyve") || -- 2.26.2

2 1

[libvirt-python PATCH] gitlab: add CONTRIBUTING.rst file to indicate use of merge requests
by Daniel P. Berrangé 04 May '20

04 May '20

With the introduce of automated CI pipelines, we are now ready to switch to using merge requests for the project. With this switch we longer wish to have patches sent to the mailing list, and thus the git-publish config is removed. Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- .gitpublish | 4 ---- CONTRIBUTING.rst | 28 ++++++++++++++++++++++++++++ This CONTRIBUTING.rst is intentionally fairly generic, as I intend to reuse it for most other projects too (libvirt.git being the exception which has far more details). 2 files changed, 28 insertions(+), 4 deletions(-) delete mode 100644 .gitpublish create mode 100644 CONTRIBUTING.rst diff --git a/.gitpublish b/.gitpublish deleted file mode 100644 index dced716..0000000 --- a/.gitpublish +++ /dev/null @@ -1,4 +0,0 @@ -[gitpublishprofile "default"] -base = master -to = libvir-list(a)redhat.com -prefix = libvirt-python PATCH diff --git a/CONTRIBUTING.rst b/CONTRIBUTING.rst new file mode 100644 index 0000000..11e3c41 --- /dev/null +++ b/CONTRIBUTING.rst @@ -0,0 +1,28 @@ +============================== +Contributing to libvirt-python +============================== + +The libvirt Python API binding accepts code contributions via merge requests +on the GitLab project: + + https://gitlab.com/libvirt/libvirt-python/-/merge_requests + +It is required that automated CI pipelines succeed before a merge request +will be accepted. The global pipeline status for the ``master`` branch is +visible at: + + https://gitlab.com/libvirt/libvirt-python/pipelines + +CI pipline results for merge requests will be visible via the contributors' +own private repository fork: + + https://gitlab.com/::YOUR-USER-NAME::/libvirt-python/pipelines + +Contributions submitted to the project must be in compliance with the +Developer Certificate of Origin Version 1.1. This is documented at: + + https://developercertificate.org/ + +In indicate compliance, each commit in a series must have a "Signed-off-by" +tag with the submittor's name and email address. This can be added by passing +the ``-s`` flag to ``git commit`` when creating the patches. -- 2.26.2

2 2

[libvirt PATCH 0/2] CONTRIBUTING: Clean up and improve
by Andrea Bolognani 04 May '20

04 May '20

Andrea Bolognani (2): CONTRIBUTING: Indent command by three spaces CONTRIBUTING: Include note about build system tools CONTRIBUTING.rst | 19 ++++++++++++++----- 1 file changed, 14 insertions(+), 5 deletions(-) -- 2.25.4

3 12

[libvirt PATCH] gitlab: update list of distros used to use latest versions
by Daniel P. Berrangé 04 May '20

04 May '20

Replace Fedora 30 with Fedora 32 Replace Ubuntu 16.04 with Ubuntu 20.04 Switch generic jobs from Fedora 31 to Fedora 32 Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- .gitlab-ci.yml | 32 ++++++++++++++++---------------- 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml index 99e7b510c7..d4df2a02cd 100644 --- a/.gitlab-ci.yml +++ b/.gitlab-ci.yml @@ -85,14 +85,14 @@ x64-centos-8: <<: *native_build_extra_job_definition image: quay.io/libvirt/buildenv-libvirt-centos-8:latest -x64-fedora-30: - <<: *native_build_default_job_definition - image: quay.io/libvirt/buildenv-libvirt-fedora-30:latest - x64-fedora-31: <<: *native_build_extra_job_definition image: quay.io/libvirt/buildenv-libvirt-fedora-31:latest +x64-fedora-32: + <<: *native_build_default_job_definition + image: quay.io/libvirt/buildenv-libvirt-fedora-32:latest + x64-fedora-rawhide: <<: *native_build_default_job_definition image: quay.io/libvirt/buildenv-libvirt-fedora-rawhide:latest @@ -101,14 +101,14 @@ x64-opensuse-151: <<: *native_build_default_job_definition image: quay.io/libvirt/buildenv-libvirt-opensuse-151:latest -x64-ubuntu-1604: - <<: *native_build_default_job_definition - image: quay.io/libvirt/buildenv-libvirt-ubuntu-1604:latest - x64-ubuntu-1804: <<: *native_build_extra_job_definition image: quay.io/libvirt/buildenv-libvirt-ubuntu-1804:latest +x64-ubuntu-2004: + <<: *native_build_default_job_definition + image: quay.io/libvirt/buildenv-libvirt-ubuntu-2004:latest + # Cross compiled build jobs @@ -148,13 +148,13 @@ mipsel-debian-sid: <<: *cross_build_extra_job_definition image: quay.io/libvirt/buildenv-libvirt-debian-sid-cross-mipsel:latest -mingw32-fedora-30: +mingw32-fedora-rawhide: <<: *cross_build_default_job_definition - image: quay.io/libvirt/buildenv-libvirt-fedora-30-cross-mingw32:latest + image: quay.io/libvirt/buildenv-libvirt-fedora-rawhide-cross-mingw32:latest -mingw64-fedora-30: +mingw64-fedora-rawhide: <<: *cross_build_default_job_definition - image: quay.io/libvirt/buildenv-libvirt-fedora-30-cross-mingw64:latest + image: quay.io/libvirt/buildenv-libvirt-fedora-rawhide-cross-mingw64:latest # This artifact published by this job is downloaded by libvirt.org to @@ -172,7 +172,7 @@ website: - $MAKE -C docs install - cd .. - mv vroot/share/doc/libvirt/html/ website - image: quay.io/libvirt/buildenv-libvirt-fedora-31:latest + image: quay.io/libvirt/buildenv-libvirt-fedora-32:latest artifacts: expose_as: 'Website' name: 'website' @@ -191,7 +191,7 @@ codestyle: - cd build - ../autogen.sh || (cat config.log && exit 1) - $MAKE syntax-check - image: quay.io/libvirt/buildenv-libvirt-fedora-31:latest + image: quay.io/libvirt/buildenv-libvirt-fedora-32:latest # This artifact published by this job is downloaded to push to Weblate @@ -211,7 +211,7 @@ potfile: - $MAKE -C po libvirt.pot - cd .. - mv build/po/libvirt.pot libvirt.pot - image: quay.io/libvirt/buildenv-libvirt-fedora-31:latest + image: quay.io/libvirt/buildenv-libvirt-fedora-32:latest artifacts: expose_as: 'Potfile' name: 'potfile' @@ -226,7 +226,7 @@ potfile: # to test developer's personal branches. dco: stage: prebuild - image: quay.io/libvirt/buildenv-libvirt-fedora-31:latest + image: quay.io/libvirt/buildenv-libvirt-fedora-32:latest before_script: - *script_variables script: -- 2.26.2

2 1

[PATCH] virsh: Fix return code for dump
by Xuyandong (Yandong Xu) 04 May '20

04 May '20

>From 4899d04fab878d5a0e13f01b8b137af233bc7d33 Mon Sep 17 00:00:00 2001 From: Xu Yandong <xuyandong2(a)huawei.com> Date: Mon, 4 May 2020 16:36:19 +0800 Subject: [PATCH] virsh: Fix return code for dump After the commit dc0771c, ret variable no longer represents the status of the return code, use data->ret replace it. Signed-off-by: Xu Yandong <xuyandong2(a)huawei.com> --- tools/virsh-domain.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/tools/virsh-domain.c b/tools/virsh-domain.c index 0704529458..61cd72f714 100644 --- a/tools/virsh-domain.c +++ b/tools/virsh-domain.c @@ -5522,7 +5522,6 @@ static bool cmdDump(vshControl *ctl, const vshCmd *cmd) { virDomainPtr dom; - bool ret = false; bool verbose = false; const char *name = NULL; const char *to = NULL; @@ -5556,12 +5555,12 @@ cmdDump(vshControl *ctl, const vshCmd *cmd) virThreadJoin(&workerThread); - if (!ret) + if (!data.ret) vshPrintExtra(ctl, _("\nDomain %s dumped to %s\n"), name, to); cleanup: virshDomainFree(dom); - return !ret; + return !data.ret; } static const vshCmdInfo info_screenshot[] = { -- 2.21.0

4 4

[PATCH 0/2] qemucapabilitiesdata: Update qemu-5.0 data after release and add qemu-5.1
by Peter Krempa 04 May '20

04 May '20

Peter Krempa (2): qemucapabilitiesdata: Update x86_64 capabilities to 5.0.0 release qemucapabilitiesdata: Add test data for x86_64 for the qemu-5.1 dev cycle .../domaincapsdata/qemu_5.1.0-q35.x86_64.xml | 194 + .../domaincapsdata/qemu_5.1.0-tcg.x86_64.xml | 197 + tests/domaincapsdata/qemu_5.1.0.x86_64.xml | 194 + .../caps_5.0.0.x86_64.replies | 8 +- .../caps_5.0.0.x86_64.xml | 4 +- .../caps_5.1.0.x86_64.replies | 28830 ++++++++++++++++ .../caps_5.1.0.x86_64.xml | 3016 ++ 7 files changed, 32437 insertions(+), 6 deletions(-) create mode 100644 tests/domaincapsdata/qemu_5.1.0-q35.x86_64.xml create mode 100644 tests/domaincapsdata/qemu_5.1.0-tcg.x86_64.xml create mode 100644 tests/domaincapsdata/qemu_5.1.0.x86_64.xml create mode 100644 tests/qemucapabilitiesdata/caps_5.1.0.x86_64.replies create mode 100644 tests/qemucapabilitiesdata/caps_5.1.0.x86_64.xml -- 2.26.2

2 3

[PATCH] systemd: start libvirtd after firewalld/iptables services
by Laine Stump 04 May '20

04 May '20

When a system has enabled the iptables/ip6tables services rather than firewalld, there is no explicit ordering of the start of those services vs. libvirtd. This creates a problem when libvirtd.service is started before ip[6]tables, as the latter, when it finally is started, will remove all of the iptables rules that had previously been added by libvirt, including the custom chains where libvirt's rules are kept. This results in an error message similar to the following when a user subsequently tries to start a new libvirt network: "Error while activating network: Call to virNetworkCreate failed: internal error: Failed to apply firewall rules /usr/sbin/ip6tables -w --table filter --insert LIBVIRT_FWO \ --in-interface virbr2 --jump REJECT: ip6tables: No chain/target/match by that name." (Prior to logging this error, it also would have caused failure to forward (or block) traffic in some cases, e.g. for guests on a NATed network, since libvirt's rules to forward/block had all been deleted and libvirt didn't know about it, so it couldn't fix the problem) When this happens, the problem can be remedied by simply restarting libvirtd.service (which has the side-effect of reloading all libvirt-generated firewall rules) Instead, we can just explicitly stating in the libvirtd.service file that libvirtd.service should start after ip6tables.service and ip6tables.service, eliminating the race condition that leads to the error. There is also nothing (that I can see) in the systemd .service files to guarantee that firewalld.service will be started (if enabled) prior to libvirtd.service. The same error scenario given above would occur if libvirtd.service started before firewalld.service. Even before that, though libvirtd would have detected that firewalld.service was disabled, and then turn off all firewalld support. So, for example, firewalld's libvirt zone wouldn't be used, and most likely traffic from guests would therefore be blocked (all with no external indication of the source of the problem other than a debug-level log when libvirtd was started saying that firewalld wasn't in use); also libvirtd wouldn't notice when firewalld reloaded its rules (which also simultaneously deletes all of libvirt's rules). I'm not aware of any reports that have been traced back to libvirtd.service starting before firewalld.service, but have seen that error reported multiple times, and also don't see an existing dependency that would guarantee firewalld.service starts before libvirtd.service, so it's possible it's been happening and we just haven't gotten to the bottom of it. This patch adds an After= line to the libvirtd.service file for each of iptables.service, ip6tables.service, and firewalld.servicee, which should guarantee that libvirtd.service isn't started until systemd has started whichever of the others is enabled. This race was diagnosed, and patch proposed, by Jason Montleon in https://bugzilla.redhat.com/1723698 . At the time (April 2019) danpb agreed with him that this change to libvirtd.service was a reasonable thing to do, but I guess everyone thought someone else was going to post a patch, so in the end nobody did. Signed-off-by: Laine Stump <laine(a)redhat.com> --- src/remote/libvirtd.service.in | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/remote/libvirtd.service.in b/src/remote/libvirtd.service.in index 90b2cad5b0..cc0d4e3693 100644 --- a/src/remote/libvirtd.service.in +++ b/src/remote/libvirtd.service.in @@ -11,6 +11,9 @@ Wants=libvirtd-admin.socket Wants=systemd-machined.service Before=libvirt-guests.service After=network.target +After=firewalld.service +After=iptables.service +After=ip6tables.service After=dbus.service After=iscsid.service After=apparmor.service -- 2.25.4

4 3

[libvirt PATCHv2] docs: note that <dnsmasq:option> was added in libvirt 5.6.0
by Laine Stump 04 May '20

04 May '20

To make it simpler to answer questions of "Why doesn't this thing work for me?" Signed-off-by: Laine Stump <laine(a)redhat.com> --- Sigh. As danpb pointed out when I sent this before, I had copy/pasted a "since" clause (and taken the time to make sure I could still do a build) but hadn't bothered to replace the version number itself in the bit that I pasted :-/ (this is why I don't allow the "trivial" rule for pushing patches to apply to myself) docs/formatnetwork.html.in | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/docs/formatnetwork.html.in b/docs/formatnetwork.html.in index 2bccac014b..9f86e9567d 100644 --- a/docs/formatnetwork.html.in +++ b/docs/formatnetwork.html.in @@ -1124,9 +1124,11 @@ <h3><a id="elementsNamespaces">Network namespaces</a></h3> <p> - A special XML namespace is available for passing options directly to the - underlying dnsmasq configuration file. Usage of XML namespaces comes with no - support guarantees, so use at your own risk. + A special XML namespace is available for passing options + directly to the underlying dnsmasq configuration + file <span class="since">Since 5.6.0</span>. Usage of XML + namespaces comes with no support guarantees, so use at your own + risk. </p> <p> -- 2.25.4

2 1