April 2020 - Devel - libvirt List Archives

[PATCH V3 0/5] Introduce getHost support for ARM CPU driver
by ZhengZhenyu 13 May '20

13 May '20

Introduce getHost support for ARM CPU driver. First add some data about commonly used ARM CPU models, and their vendors into cpu_map, then added some helper methods as callbacks to load them. Read and parse vendor_id, part_id and CPU flags of local CPU from corresponding registers. Signed-off-by: Zhenyu Zheng <zhengzhenyulixi(a)gmail.com> ZhengZhenyu (5): cpu_map: Introduce ARM cpu models cpu: Introduce virCPUarmData to virCPUData cpu: Introduce ARM related structs cpu: Add helper funtions to parse vendor and model cpu: Introduce getHost support for ARM CPU driver src/cpu/Makefile.inc.am | 1 + src/cpu/cpu.h | 2 + src/cpu/cpu_arm.c | 450 +++++++++++++++++++++++++++++- src/cpu/cpu_arm_data.h | 31 ++ src/cpu_map/Makefile.inc.am | 7 + src/cpu_map/arm_Falkor.xml | 16 ++ src/cpu_map/arm_Kunpeng-920.xml | 24 ++ src/cpu_map/arm_ThunderX299xx.xml | 16 ++ src/cpu_map/arm_cortex-a53.xml | 16 ++ src/cpu_map/arm_cortex-a57.xml | 15 + src/cpu_map/arm_cortex-a72.xml | 15 + src/cpu_map/arm_vendors.xml | 14 + src/cpu_map/index.xml | 15 + 13 files changed, 619 insertions(+), 3 deletions(-) create mode 100644 src/cpu/cpu_arm_data.h create mode 100644 src/cpu_map/arm_Falkor.xml create mode 100644 src/cpu_map/arm_Kunpeng-920.xml create mode 100644 src/cpu_map/arm_ThunderX299xx.xml create mode 100644 src/cpu_map/arm_cortex-a53.xml create mode 100644 src/cpu_map/arm_cortex-a57.xml create mode 100644 src/cpu_map/arm_cortex-a72.xml create mode 100644 src/cpu_map/arm_vendors.xml -- 2.26.0.windows.1

3 25

[PATCH v1 0/5] qemu: Support iSER transport of iscsi
by Han Han 13 May '20

13 May '20

The iSER(iSCSI Extensions for RDMA) transport is introduced since QEMU 2.9 [1]. It is only valid in iscsi network disk. Note that for the legacy uri of iscsi iser transport, it will start with 'iser' instead of 'iscsi'. [1]: https://github.com/qemu/qemu/blob/ee573f5326046223b6eef4ae7fbfec31d274e093/… git branch: https://gitlab.com/hhan2/libvirt/-/tree/iser Han Han (5): qemu_capabilities: Introduce iSER transport flag qemu: Support iser transport in iscsi docs: Support iser transport of iscsi tests: unit tests for iser transport news: qemu: Support iSER transport of iscsi docs/formatdomain.html.in | 10 +++-- docs/news.xml | 10 +++++ docs/schemas/domaincommon.rng | 1 + src/qemu/qemu_backup.c | 1 + src/qemu/qemu_block.c | 16 +++++-- src/qemu/qemu_capabilities.c | 2 + src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 17 +++++++ src/qemu/qemu_monitor_json.c | 1 + src/storage/storage_file_gluster.c | 7 +++ src/util/virstoragefile.c | 26 +++++++---- src/util/virstoragefile.h | 1 + .../caps_2.10.0.aarch64.xml | 1 + .../caps_2.10.0.ppc64.xml | 1 + .../caps_2.10.0.s390x.xml | 1 + .../caps_2.10.0.x86_64.xml | 1 + .../caps_2.11.0.s390x.xml | 1 + .../caps_2.11.0.x86_64.xml | 1 + .../caps_2.12.0.aarch64.xml | 1 + .../caps_2.12.0.ppc64.xml | 1 + .../caps_2.12.0.s390x.xml | 1 + .../caps_2.12.0.x86_64.xml | 1 + .../qemucapabilitiesdata/caps_2.9.0.ppc64.xml | 1 + .../qemucapabilitiesdata/caps_2.9.0.s390x.xml | 1 + .../caps_2.9.0.x86_64.xml | 1 + .../qemucapabilitiesdata/caps_3.0.0.ppc64.xml | 1 + .../caps_3.0.0.riscv32.xml | 1 + .../caps_3.0.0.riscv64.xml | 1 + .../qemucapabilitiesdata/caps_3.0.0.s390x.xml | 1 + .../caps_3.0.0.x86_64.xml | 1 + .../qemucapabilitiesdata/caps_3.1.0.ppc64.xml | 1 + .../caps_3.1.0.x86_64.xml | 1 + .../caps_4.0.0.aarch64.xml | 1 + .../qemucapabilitiesdata/caps_4.0.0.ppc64.xml | 1 + .../caps_4.0.0.riscv32.xml | 1 + .../caps_4.0.0.riscv64.xml | 1 + .../qemucapabilitiesdata/caps_4.0.0.s390x.xml | 1 + .../caps_4.0.0.x86_64.xml | 1 + .../caps_4.1.0.x86_64.xml | 1 + .../caps_4.2.0.aarch64.xml | 1 + .../qemucapabilitiesdata/caps_4.2.0.ppc64.xml | 1 + .../qemucapabilitiesdata/caps_4.2.0.s390x.xml | 1 + .../caps_4.2.0.x86_64.xml | 1 + .../caps_5.0.0.aarch64.xml | 1 + .../qemucapabilitiesdata/caps_5.0.0.ppc64.xml | 1 + .../caps_5.0.0.x86_64.xml | 1 + .../qemuxml2argvdata/disk-network-iscsi.args | 8 +++- .../disk-network-iscsi.x86_64-2.12.0.args | 7 ++- .../disk-network-iscsi.x86_64-latest.args | 45 +++++++++++-------- tests/qemuxml2argvdata/disk-network-iscsi.xml | 9 +++- tests/qemuxml2argvtest.c | 5 ++- .../qemuxml2xmloutdata/disk-network-iscsi.xml | 10 ++++- tests/qemuxml2xmltest.c | 4 +- tests/virstoragetest.c | 14 ++++++ 54 files changed, 188 insertions(+), 41 deletions(-) -- 2.25.0

2 7

[PATCH v4 00/34] Configurable policy for handling deprecated interfaces
by Markus Armbruster 08 May '20

08 May '20

This series extends QMP introspection to cover deprecation. Additionally, new option -compat lets you configure what to do when deprecated interfaces get used. This is intended for testing users of the management interfaces. It is experimental. -compat deprecated-input=<in-policy> configures what to do when deprecated input is received. Available policies: * accept: Accept deprecated commands and arguments (default) * reject: Reject them * crash: Crash -compat deprecated-output=<out-policy> configures what to do when deprecated output is sent. Available output policies: * accept: Emit deprecated command results and events (default) * hide: Suppress them For now, -compat covers only deprecated syntactic aspects of QMP. We may want to extend it to cover semantic aspects, CLI, and experimental features. PATCH 01-04: Documentation fixes PATCH 05-10: Test improvements PATCH 11-24: Add feature flags to remaining user-defined types and to struct members PATCH 25-26: New special feature 'deprecated', visible in introspection PATCH 27-34: New -compat to set policy for handling stuff marked with feature 'deprecated' v4: PATCH 05+07: Temporary memory leak plugged [Marc-André] PATCH 23: Rewritten [Marc-André] PATCH 24: Comment typo [Marc-André] PATCH 30: Memory leaks plugged v3: * Rebased, non-trivial conflicts in PATCH 01+26+27+34 due to RST conversion and code motion * PATCH 28-29: Old PATCH 28 split up to ease review * PATCH 30-31: New * PATCH 32-33: Old PATCH 29 split up to ease review Comparison to RFC (24 Oct 2019): * Cover arguments and results in addition to commands and events * Half-baked "[RFC PATCH 18/19] qapi: Include a warning in the response to a deprecated command" dropped See also last item of Subject: Minutes of KVM Forum BoF on deprecating stuff Date: Fri, 26 Oct 2018 16:03:51 +0200 Message-ID: <87mur0ls8o.fsf(a)dusky.pond.sub.org> https://lists.nongnu.org/archive/html/qemu-devel/2018-10/msg05828.html Cc: Lukáš Doktor <ldoktor(a)redhat.com> Cc: libguestfs(a)redhat.com Cc: libvir-list(a)redhat.com Cc: Daniel P. Berrange <berrange(a)redhat.com> Cc: Peter Krempa <pkrempa(a)redhat.com> Cc: Kevin Wolf <kwolf(a)redhat.com> Markus Armbruster (34): qemu-doc: Belatedly document QMP command arg & result deprecation qapi: Belatedly update doc comment for @wait deprecation docs/devel/qapi-code-gen: Clarify allow-oob introspection docs/devel/qapi-code-gen: Document 'features' introspection tests/test-qmp-cmds: Factor out qmp_dispatch() test helpers tests/test-qmp-cmds: Check responses more thoroughly tests/test-qmp-cmds: Simplify test data setup tests/test-qmp-event: Simplify test data setup tests/test-qmp-event: Use qobject_is_equal() tests/test-qmp-event: Check event is actually emitted qapi/schema: Clean up around QAPISchemaEntity.connect_doc() qapi: Add feature flags to remaining definitions qapi: Consistently put @features parameter right after @ifcond qapi/introspect: Rename *qlit* to reduce confusion qapi/introspect: Factor out _make_tree() qapi/schema: Change _make_features() to a take feature list qapi/schema: Reorder classes so related ones are together qapi/schema: Rename QAPISchemaObjectType{Variant,Variants} qapi/schema: Call QAPIDoc.connect_member() in just one place qapi: Add feature flags to struct members qapi: Inline do_qmp_dispatch() into qmp_dispatch() qapi: Simplify how qmp_dispatch() deals with QCO_NO_SUCCESS_RESP qapi: Simplify how qmp_dispatch() gets the request ID qapi: Replace qmp_dispatch()'s TODO comment by an explanation qapi: New special feature flag "deprecated" qapi: Mark deprecated QMP parts with feature 'deprecated' qemu-options: New -compat to set policy for deprecated interfaces qapi: Implement deprecated-output=hide for QMP command results qapi: Implement deprecated-output=hide for QMP events qapi: Implement deprecated-output=hide for QMP event data qapi: Implement deprecated-output=hide for QMP introspection qapi: Implement deprecated-input=reject for QMP commands qapi: Implement deprecated-input=reject for QMP command arguments qapi: New -compat deprecated-input=crash docs/devel/qapi-code-gen.txt | 79 ++- docs/system/deprecated.rst | 48 +- tests/qapi-schema/doc-good.texi | 32 ++ qapi/block-core.json | 48 +- qapi/block.json | 30 +- qapi/char.json | 1 + qapi/compat.json | 52 ++ qapi/control.json | 11 +- qapi/introspect.json | 28 +- qapi/machine.json | 34 +- qapi/migration.json | 36 +- qapi/misc.json | 13 +- qapi/qapi-schema.json | 1 + include/qapi/compat-policy.h | 20 + include/qapi/qmp/dispatch.h | 1 + include/qapi/qobject-input-visitor.h | 9 + include/qapi/qobject-output-visitor.h | 9 + include/qapi/visitor-impl.h | 3 + include/qapi/visitor.h | 9 + monitor/monitor-internal.h | 3 - monitor/misc.c | 2 - monitor/qmp-cmds-control.c | 102 +++- qapi/qapi-visit-core.c | 9 + qapi/qmp-dispatch.c | 149 +++--- qapi/qobject-input-visitor.c | 29 ++ qapi/qobject-output-visitor.c | 20 + qemu-storage-daemon.c | 2 - softmmu/vl.c | 17 + tests/test-qmp-cmds.c | 249 +++++---- tests/test-qmp-event.c | 203 +++----- qapi/Makefile.objs | 8 +- qapi/trace-events | 1 + qemu-options.hx | 22 + scripts/qapi/commands.py | 20 +- scripts/qapi/doc.py | 16 +- scripts/qapi/events.py | 24 +- scripts/qapi/expr.py | 14 +- scripts/qapi/introspect.py | 104 ++-- scripts/qapi/schema.py | 488 ++++++++++-------- scripts/qapi/types.py | 8 +- scripts/qapi/visit.py | 28 +- tests/Makefile.include | 1 + tests/qapi-schema/alternate-base.err | 2 +- tests/qapi-schema/doc-good.json | 22 +- tests/qapi-schema/doc-good.out | 18 + .../qapi-schema/features-deprecated-type.err | 2 + .../qapi-schema/features-deprecated-type.json | 3 + .../qapi-schema/features-deprecated-type.out | 0 tests/qapi-schema/qapi-schema-test.json | 51 +- tests/qapi-schema/qapi-schema-test.out | 48 +- tests/qapi-schema/test-qapi.py | 26 +- 51 files changed, 1393 insertions(+), 762 deletions(-) create mode 100644 qapi/compat.json create mode 100644 include/qapi/compat-policy.h create mode 100644 tests/qapi-schema/features-deprecated-type.err create mode 100644 tests/qapi-schema/features-deprecated-type.json create mode 100644 tests/qapi-schema/features-deprecated-type.out -- 2.21.1

3 5

[RFC] Faster libvirtd restart with nwfilter rules, one more time
by nshirokovskiy 08 May '20

08 May '20

Hi, all. Some time ago I posted RFC [1] concerning an issue of unresponsive libvird during restart if there is large number of VMs that have network filters on their interfaces. It was identified that in most cases we don't need actually to reinstall network filter rules on daemon restart. Thus I proposed patches [2] that check whether we need to reapply rules or not. The first version has a drawback that daemon won't reapply rules if someone mangled them between daemon stop and start (and this can be done just by restarting firewalld). The second one is just ugly :) Around that time Florian Westphal in a letter off the mailing list suggested to use {iptables|ebtables}-restore to apply rules in one binary call. These binaries has --noflush option so that we won't reset current state of tables. We also need one more -L call for iptables/ebtables to query current filter state to be able to construct input for restore binaries. I wonder can we use this approach? I see currently only one issue - we won't use firealld to spawn rules. But why we need to spawn rules through firewalld if it present? We use passthrough mode anyway. I tried to dig history for hints but didn't found anything. Patch [3] introduced spawning rules thru firewalld-cmd. Nikolay [1] [RFC] Faster libvirtd restart with nwfilter rules https://www.redhat.com/archives/libvir-list/2018-September/msg01206.html [2] nwfilter: don't reinstantiate filters if they are not changed v1: https://www.redhat.com/archives/libvir-list/2018-October/msg00904.html v2: https://www.redhat.com/archives/libvir-list/2018-October/msg01317.html [3] network: use firewalld instead of iptables, when available v0: https://www.redhat.com/archives/libvir-list/2012-April/msg01236.html v1: https://www.redhat.com/archives/libvir-list/2012-August/msg00447.html ... v4: https://www.redhat.com/archives/libvir-list/2012-August/msg01097.html

5 7

[libvirt PATCH] libxl: vga.kind none when no device specified
by Artur Puzio 07 May '20

07 May '20

When no video device is specified in config we should set both hvm.nographic to 1 and hvm.vga.kind to NONE. Without hvm.vga.kind=LIBXL_VGA_INTERFACE_TYPE_NONE both -nographic and -device 'cirrus-vga' are on qemu cmdline. --- src/libxl/libxl_conf.c | 1 + tests/libxlxml2domconfigdata/fullvirt-acpi-slic.json | 3 +++ tests/libxlxml2domconfigdata/fullvirt-cpuid.json | 3 +++ 3 files changed, 7 insertions(+) diff --git a/src/libxl/libxl_conf.c b/src/libxl/libxl_conf.c index 458dfc2399..a0059fc2a7 100644 --- a/src/libxl/libxl_conf.c +++ b/src/libxl/libxl_conf.c @@ -2404,6 +2404,7 @@ libxlMakeVideo(virDomainDefPtr def, libxl_domain_config *d_config) b_info->video_memkb = def->videos[0]->vram; } else { libxl_defbool_set(&b_info->u.hvm.nographic, 1); + b_info->u.hvm.vga.kind = LIBXL_VGA_INTERFACE_TYPE_NONE; } return 0; diff --git a/tests/libxlxml2domconfigdata/fullvirt-acpi-slic.json b/tests/libxlxml2domconfigdata/fullvirt-acpi-slic.json index e804389fea..f16b4a971a 100644 --- a/tests/libxlxml2domconfigdata/fullvirt-acpi-slic.json +++ b/tests/libxlxml2domconfigdata/fullvirt-acpi-slic.json @@ -20,6 +20,9 @@ "acpi": "True", "acpi_firmware": "/path/to/slic.dat", "nographic": "True", + "vga": { + "kind": "none" + }, "vnc": { "enable": "False" }, diff --git a/tests/libxlxml2domconfigdata/fullvirt-cpuid.json b/tests/libxlxml2domconfigdata/fullvirt-cpuid.json index d46b464642..ddc423bca7 100644 --- a/tests/libxlxml2domconfigdata/fullvirt-cpuid.json +++ b/tests/libxlxml2domconfigdata/fullvirt-cpuid.json @@ -27,6 +27,9 @@ "apic": "True", "acpi": "True", "nographic": "True", + "vga": { + "kind": "none" + }, "vnc": { "enable": "False" }, -- 2.26.2

3 5

[PATCH v2] Improve blockpull man entry
by Sebastian Mitterle 06 May '20

06 May '20

1. Fix usage of bandwidth, base arguments. 2. Explain valid arguments for `base`. 3. Move explanation for `--keep-relative` to end considering it's not a very frequent use case. 4. Add reference to documentation for relative paths in backing chains. Signed-off-by: Sebastian Mitterle <smitterl(a)redhat.com> --- docs/manpages/virsh.rst | 19 ++++++++++++++----- 1 file changed, 14 insertions(+), 5 deletions(-) diff --git a/docs/manpages/virsh.rst b/docs/manpages/virsh.rst index dc404ddfe8..71bd968fab 100644 --- a/docs/manpages/virsh.rst +++ b/docs/manpages/virsh.rst @@ -1345,7 +1345,7 @@ blockpull .. code-block:: - blockpull domain path [bandwidth] [--bytes] [base] + blockpull domain path [bandwidth [--bytes] [base]] [--wait [--verbose] [--timeout seconds] [--async]] [--keep-relative] @@ -1356,6 +1356,12 @@ the new backing file and only the intermediate portion of the chain is pulled. Once all requested data from the backing image chain has been pulled, the disk no longer depends on that portion of the backing chain. +*base* can be specified in two ways: either as indexed target name 'name[i]' +where 'name' corresponds to the disk target name (<target dev='name'/>) and +'i' corresponds to the 'index' of the '<backingStore>'; or as the file name +of the backing file (<source file='name'/>). + + By default, this command returns as soon as possible, and data for the entire disk is pulled in the background; the progress of the operation can be checked with ``blockjob``. However, if *--wait* is @@ -1367,16 +1373,19 @@ is triggered, *--async* will return control to the user as fast as possible, otherwise the command may continue to block a little while longer until the job is done cleaning up. -Using the *--keep-relative* flag will keep the backing chain names -relative. - *path* specifies fully-qualified path of the disk; it corresponds to a unique target name (<target dev='name'/>) or source file (<source file='name'/>) for one of the disk devices attached to *domain* (see also ``domblklist`` for listing these names). + *bandwidth* specifies copying bandwidth limit in MiB/s. For further information on the *bandwidth* argument see the corresponding section for the ``blockjob`` -command. +command. Using *--bytes* flag indicates the value in *bandwidth* is given in +bytes. + +Using the *--keep-relative* flag will keep the backing chain names +relative (details on `https://www.libvirt.org/kbase/backing_chains.html +<https://www.libvirt.org/kbase/backing_chains.html>`__). blockresize -- 2.25.2

2 1

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

[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

[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

Entering freeze for libvirt 6.3.0
by Daniel Veillard 01 May '20

01 May '20

We are getting close to the end of the month, so I tagged RC1 in git and pushed signed source tarball and rpms to the usual place: https://libvirt.org/sources/ Seems to work fine in my very limited testing, CI seems green except for a couple of mingw tests, so that looks good from a distance. Please give it some testing, RC2 should land on Thursday, and then if everything looks fine I could push the final version over the coming week-end. Stay safe, please test it, thanks, Daniel -- Daniel Veillard | Red Hat Developers Tools http://developer.redhat.com/ veillard(a)redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/

3 3