- Devel - libvirt List Archives

[PATCH v2] qemuDomainGetGuestInfo: Exit early if getting info fails
by Michal Privoznik 02 Dec '20

02 Dec '20

If there is an error getting info from guest agent, then the control on qemuDomainGetGuestInfo() jumps onto 'exitagent' label and subsequently continues on 'endagentjob'. Both labels are hit also in success case too. The control then continues by attempting to match fetched info (e.g. disk addresses) with domain def. But this is needless - the API will return error regardless. To return early from the function move both 'exitagent' and 'endagentjob' labels at the end of the function and jump straight onto 'cleanup' afterwards. This allows us to set 'ret = 0' later - only when we know we succeeded. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- v2 of: https://www.redhat.com/archives/libvir-list/2020-December/msg00020.html src/qemu/qemu_driver.c | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 8eaa3ce68f..bca1c84630 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -20116,12 +20116,7 @@ qemuDomainGetGuestInfo(virDomainPtr dom, } } - ret = 0; - - exitagent: qemuDomainObjExitAgent(vm, agent); - - endagentjob: qemuDomainObjEndAgentJob(vm); if (nfs > 0 || ndisks > 0) { @@ -20143,6 +20138,8 @@ qemuDomainGetGuestInfo(virDomainPtr dom, qemuDomainObjEndJob(driver, vm); } + ret = 0; + cleanup: for (i = 0; i < nfs; i++) qemuAgentFSInfoFree(agentfsinfo[i]); @@ -20153,6 +20150,13 @@ qemuDomainGetGuestInfo(virDomainPtr dom, virDomainObjEndAPI(&vm); return ret; + + exitagent: + qemuDomainObjExitAgent(vm, agent); + + endagentjob: + qemuDomainObjEndAgentJob(vm); + goto cleanup; } -- 2.26.2

2 1

[Call for Presentations] FOSDEM 2021: Virt & IaaS Devroom
by Kashyap Chamarthy 02 Dec '20

02 Dec '20

[Cross-posting to KVM, QEMU, and libvirt lists] The Call For Papers for FOSDEM's Virt & IaaS Devroom went out yesterday[1]. Here's the text (slightly formatted for readability): ======================================================================= We are excited to announce that the call for proposals is now open for the Virtualization & IaaS devroom at the upcoming FOSDEM 2021, to be hosted virtually on February 6th 2021. This year will mark FOSDEM's 21th anniversary as one of the longest-running free and open source software developer events, attracting thousands of developers and users from all over the world. Due to Covid-19, FOSDEM will be held virtually this year on February 6th & 7th, 2021. Important Dates --------------- * Submission deadline: 20th of December * Acceptance notifications: 25th of December * Final schedule announcement: 31st of December * Recorded presentations upload deadline: 15th of January * Devroom: 6th February 2021 About the Devroom ----------------- The Virtualization & IaaS devroom will feature session topics such as open source hypervisors and virtual machine managers such as Xen Project, KVM, bhyve, and VirtualBox, and Infrastructure-as-a-Service projects such as KubeVirt, Apache CloudStack, Foreman, OpenStack, oVirt, QEMU and OpenNebula. This devroom will host presentations that focus on topics of shared interest, such as KVM; libvirt; shared storage; virtualized networking; cloud security; clustering and high availability; interfacing with multiple hypervisors; hyperconverged deployments; and scaling across hundreds or thousands of servers. Presentations in this devroom will be aimed at users or developers working on these platforms who are looking to collaborate and improve shared infrastructure or solve common problems. We seek topics that encourage dialog between projects and continued work post-FOSDEM. Submit Your Proposal -------------------- All submissions must be made via the Pentabarf event planning site[1]. If you have not used Pentabarf before, you will need to create an account. If you submitted proposals for FOSDEM in previous years, you can use your existing account. After creating the account, select Create Event to start the submission process. Make sure to select Virtualization and IaaS devroom from the Track list. Please fill out all the required fields, and provide a meaningful abstract and description of your proposed session. Submission Guidelines --------------------- We expect more proposals than we can possibly accept, so it is vitally important that you submit your proposal on or before the deadline. Late submissions are unlikely to be considered. All presentation slots are 30 minutes, with 20 minutes planned for presentations, and 10 minutes for Q&A. All presentations will need to be pre-recorded and put into our system at least a couple of weeks before the event. The presentations should be uploaded by 15th of January and made available under Creative Commons licenses. In the Submission notes field, please indicate that you agree that your presentation will be licensed under the CC-By-SA-4.0 or CC-By-4.0 license and that you agree to have your presentation recorded. For example: "If my presentation is accepted for FOSDEM, I hereby agree to license all recordings, slides, and other associated materials under the Creative Commons Attribution Share-Alike 4.0 International License. Sincerely, <NAME>." In the Submission notes field, please also confirm that if your talk is accepted, you will be able to attend the virtual FOSDEM event for the Q&A. We will not consider proposals from prospective speakers who are unsure whether they will be able to attend the FOSDEM virtual event. If you are experiencing problems with Pentabarf, the proposal submission interface, or have other questions, you can email our devroom mailing list[2] and we will try to help you. Code of Conduct --------------- Following the release of the updated code of conduct for FOSDEM, we'd like to remind all speakers and attendees that all of the presentations and discussions in our devroom are held under the guidelines set in the CoC and we expect attendees, speakers, and volunteers to follow the CoC at all times. If you submit a proposal and it is accepted, you will be required to confirm that you accept the FOSDEM CoC. If you have any questions about the CoC or wish to have one of the devroom organizers review your presentation slides or any other content for CoC compliance, please email us and we will do our best to assist you. Call for Volunteers ------------------- We are also looking for volunteers to help run the devroom. We need assistance with helping speakers to record the presentation as well as helping with streaming and chat moderation for the devroom. Please contact devroom mailing list [2] for more information. Questions? ---------- If you have any questions about this devroom, please send your questions to our devroom mailing list. You can also subscribe to the list to receive updates about important dates, session announcements, and to connect with other attendees. See you all at FOSDEM! [1] https://penta.fosdem.org/submission/FOSDEM21 [2] iaas-virt-devroom at lists.fosdem.org ======================================================================= [+] https://lists.fosdem.org/pipermail/fosdem/2020q4/003109.html -- /kashyap

1 0

[PATCH] coding-style: Document 80 chars limit for line length
by Michal Privoznik 02 Dec '20

02 Dec '20

The idea is to have it like a soft limit: if possible then break lines, if not then have a long line instead of some creative approach. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- docs/coding-style.rst | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/docs/coding-style.rst b/docs/coding-style.rst index cfd7b16638..813128bfb6 100644 --- a/docs/coding-style.rst +++ b/docs/coding-style.rst @@ -131,7 +131,7 @@ around operators and keywords: indent-libvirt() { - indent -bad -bap -bbb -bli4 -br -ce -brs -cs -i4 -l75 -lc75 \ + indent -bad -bap -bbb -bli4 -br -ce -brs -cs -i4 -l80 -lc80 \ -sbi4 -psl -saf -sai -saw -sbi4 -ss -sc -cdw -cli4 -npcs -nbc \ --no-tabs "$@" } @@ -141,6 +141,18 @@ further, by piping it through ``expand -i``, since some leading TABs can get through. Usually they're in macro definitions or strings, and should be converted anyhow. +The recommended length for lines is 80 characters, but common sense +should prevail. It may get tricky around some names (because of how +Libvirt constructs names for functions/enums/etc.) + +:: + + foo( + arg1, arg2 + ); // Bad + foo(arg1, + arg2); // Good + Libvirt requires a C99 compiler for various reasons. However, most of the code base prefers to stick to C89 syntax unless there is a compelling reason otherwise. For example, it is preferable to use -- 2.26.2

3 3

regression in meson build, AC_PATH_PROG lost
by Olaf Hering 02 Dec '20

02 Dec '20

autoconf allows to specify the path to a runtime binary that is not required during build via an environment variable: AC_PATH_PROG([PARTED], [parted], [], [$LIBVIRT_SBIN_PATH]) meson lacks such essential feature. As a result the package build environment needs to have more packages than necessary installed. This excessive list also pushes libvirt closer to the end of the build dependency chain. Was this considered while the buildsystem was switched to meson? Since meson does not support environment variables it seems the only way to address this is to introduce an option in meson_options.txt for each runtime executable. Will such change be accepted? Olaf

6 23

[libvirt PATCH] scripts: ignore whitespace in pdwtags output
by Daniel P. Berrangé 02 Dec '20

02 Dec '20

The pdwtags program changed its whitespace formatting for enum values in release 1.19: @@ -145,22 +145,22 @@ u_int flags; }; enum admin_procedure { - ADMIN_PROC_CONNECT_OPEN = 1, - ADMIN_PROC_CONNECT_CLOSE = 2, - ADMIN_PROC_CONNECT_GET_LIB_VERSION = 3, - ADMIN_PROC_CONNECT_LIST_SERVERS = 4, - ADMIN_PROC_CONNECT_LOOKUP_SERVER = 5, + ADMIN_PROC_CONNECT_OPEN = 1, + ADMIN_PROC_CONNECT_CLOSE = 2, + ADMIN_PROC_CONNECT_GET_LIB_VERSION = 3, + ADMIN_PROC_CONNECT_LIST_SERVERS = 4, + ADMIN_PROC_CONNECT_LOOKUP_SERVER = 5, Workaround this by telling diff to ignore whitespace changes. Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- scripts/check-remote-protocol.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/check-remote-protocol.py b/scripts/check-remote-protocol.py index cd96e894a7..40c4b481be 100644 --- a/scripts/check-remote-protocol.py +++ b/scripts/check-remote-protocol.py @@ -121,7 +121,7 @@ if n < 1: print("WARNING: install dwarves-1.3 or newer", file=sys.stderr) sys.exit(8) -diff = subprocess.Popen(["diff", "-u", expected, "-"], stdin=subprocess.PIPE) +diff = subprocess.Popen(["diff", "-b", "-u", expected, "-"], stdin=subprocess.PIPE) actualstr = "\n".join(actual) + "\n" # i686 builds on x86_64 host add __attribute__(packed)) to # the structs. This doesn't matter functionally because we -- 2.25.4

2 1

[PATCH for 7.0.0 v1 00/26] Introduce virtio memory support
by Michal Privoznik 02 Dec '20

02 Dec '20

Available also here: https://gitlab.com/MichalPrivoznik/libvirt/-/commits/virtio_mem/ There are new virtio variants of pc-dimm and nvdimm devices. This is the first attempt to impalement support for them in libvirt. Thanks to David Hildenbrand for his valuable input! Michal Prívozník (26): viruuid: Rework virUUIDIsValid() internal.h: Introduce VIR_IS_POW2() docs: Fix nvdimm example wrt to <uuid/> domain_conf: Check NVDIMM UUID in ABI stability qemu_domain_address: Reformat qemuDomainAssignS390Addresses() conf: Require nvdimm path in validate step domain_conf: Fix virDomainMemoryModel type virDomainMemorySourceDefFormat: Utilize virXMLFormatElement() virDomainMemoryTargetDefFormat: Utilize virXMLFormatElement() qemu: Move mem validation into post parse validator conf: Move some of virDomainMemoryDef members into a union conf: Introduce virtio-pmem <memory/> model qemu_capabilities: Introduce QEMU_CAPS_DEVICE_VIRTIO_{P}MEM_PCI qemu_validate: Require virtio-mem device for mem model virtio security: Relabel virtio mem qemu: Allow virtio-pmem in CGroups qemu: Create virtio-pmem in domain namespace qemu_command: Move dimm into qemuBuildDeviceAddressStr() qemu: Build command line for virtio-pmem conf: Introduce virtio-mem <memory/> model qemu: Build command line for virtio-mem qemu: Wire up <memory/> live update qemu: Wire up MEMORY_DEVICE_SIZE_CHANGE event qemu: Refresh the actual size of virtio-mem on monitor reconnect virsh: Simplify @flags handing in cmdSetmem() and cmdSetmaxmem() virsh: Introduce --virtio to setmem docs/formatdomain.rst | 70 +++- docs/schemas/domaincommon.rng | 16 + src/conf/domain_conf.c | 372 ++++++++++++++---- src/conf/domain_conf.h | 38 +- src/internal.h | 10 + src/libvirt_private.syms | 2 + src/qemu/qemu_alias.c | 59 ++- src/qemu/qemu_capabilities.c | 4 + src/qemu/qemu_capabilities.h | 2 + src/qemu/qemu_cgroup.c | 43 +- src/qemu/qemu_command.c | 172 +++++--- src/qemu/qemu_command.h | 5 +- src/qemu/qemu_domain.c | 99 +++-- src/qemu/qemu_domain.h | 1 + src/qemu/qemu_domain_address.c | 98 +++-- src/qemu/qemu_domain_address.h | 3 +- src/qemu/qemu_driver.c | 198 +++++++++- src/qemu/qemu_hotplug.c | 22 +- src/qemu/qemu_hotplug.h | 5 + src/qemu/qemu_monitor.c | 37 ++ src/qemu/qemu_monitor.h | 27 ++ src/qemu/qemu_monitor_json.c | 94 +++-- src/qemu/qemu_monitor_json.h | 5 + src/qemu/qemu_namespace.c | 19 +- src/qemu/qemu_process.c | 52 ++- src/qemu/qemu_validate.c | 78 ++-- src/security/security_apparmor.c | 35 +- src/security/security_dac.c | 48 ++- src/security/security_selinux.c | 48 ++- src/security/virt-aa-helper.c | 22 +- src/util/virrandom.c | 2 +- src/util/viruuid.c | 17 +- src/util/viruuid.h | 2 +- .../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 | 2 + .../caps_5.2.0.x86_64.xml | 2 + ...mory-hotplug-virtio-mem.x86_64-latest.args | 53 +++ .../memory-hotplug-virtio-mem.xml | 78 ++++ ...ory-hotplug-virtio-pmem.x86_64-latest.args | 45 +++ .../memory-hotplug-virtio-pmem.xml | 54 +++ tests/qemuxml2argvtest.c | 2 + ...emory-hotplug-virtio-mem.x86_64-latest.xml | 1 + ...mory-hotplug-virtio-pmem.x86_64-latest.xml | 1 + tests/qemuxml2xmltest.c | 3 + tools/virsh-domain.c | 138 ++++++- 47 files changed, 1703 insertions(+), 384 deletions(-) create mode 100644 tests/qemuxml2argvdata/memory-hotplug-virtio-mem.x86_64-latest.args create mode 100644 tests/qemuxml2argvdata/memory-hotplug-virtio-mem.xml create mode 100644 tests/qemuxml2argvdata/memory-hotplug-virtio-pmem.x86_64-latest.args create mode 100644 tests/qemuxml2argvdata/memory-hotplug-virtio-pmem.xml create mode 120000 tests/qemuxml2xmloutdata/memory-hotplug-virtio-mem.x86_64-latest.xml create mode 120000 tests/qemuxml2xmloutdata/memory-hotplug-virtio-pmem.x86_64-latest.xml -- 2.26.2

6 38

[PATCH] target/ppc: Remove "compat" property of server class POWER CPUs
by Greg Kurz 02 Dec '20

02 Dec '20

This property has been deprecated since QEMU 5.0 by commit 22062e54bb68. We only kept a legacy hack that internally converts "compat" into the official "max-cpu-compat" property of the pseries machine type. According to our deprecation policy, we could have removed it for QEMU 5.2 already. Do it now ; since ppc_cpu_parse_featurestr() now just calls the generic parent_parse_features handler, drop it as well. Users are supposed to use the "max-cpu-compat" property of the pseries machine type instead. Signed-off-by: Greg Kurz <groug(a)kaod.org> --- docs/system/deprecated.rst | 7 ---- target/ppc/translate_init.c.inc | 59 --------------------------------- 2 files changed, 66 deletions(-) diff --git a/docs/system/deprecated.rst b/docs/system/deprecated.rst index 565389697e84..09c8f380bc82 100644 --- a/docs/system/deprecated.rst +++ b/docs/system/deprecated.rst @@ -281,13 +281,6 @@ a future version of QEMU. It's unclear whether anybody is still using CPU emulation in QEMU, and there are no test images available to make sure that the code is still working. -``compat`` property of server class POWER CPUs (since 5.0) -'''''''''''''''''''''''''''''''''''''''''''''''''''''''''' - -The ``compat`` property used to set backwards compatibility modes for -the processor has been deprecated. The ``max-cpu-compat`` property of -the ``pseries`` machine type should be used instead. - ``lm32`` CPUs (since 5.2.0) ''''''''''''''''''''''''''' diff --git a/target/ppc/translate_init.c.inc b/target/ppc/translate_init.c.inc index 78cc8f043b92..e4082cfde746 100644 --- a/target/ppc/translate_init.c.inc +++ b/target/ppc/translate_init.c.inc @@ -10470,63 +10470,6 @@ static ObjectClass *ppc_cpu_class_by_name(const char *name) return oc; } -static void ppc_cpu_parse_featurestr(const char *type, char *features, - Error **errp) -{ - Object *machine = qdev_get_machine(); - const PowerPCCPUClass *pcc = POWERPC_CPU_CLASS(object_class_by_name(type)); - - if (!features) { - return; - } - - if (object_property_find(machine, "max-cpu-compat")) { - int i; - char **inpieces; - char *s = features; - Error *local_err = NULL; - char *compat_str = NULL; - - /* - * Backwards compatibility hack: - * - * CPUs had a "compat=" property which didn't make sense for - * anything except pseries. It was replaced by "max-cpu-compat" - * machine option. This supports old command lines like - * -cpu POWER8,compat=power7 - * By stripping the compat option and applying it to the machine - * before passing it on to the cpu level parser. - */ - inpieces = g_strsplit(features, ",", 0); - *s = '\0'; - for (i = 0; inpieces[i]; i++) { - if (g_str_has_prefix(inpieces[i], "compat=")) { - warn_report_once("CPU 'compat' property is deprecated; " - "use max-cpu-compat machine property instead"); - compat_str = inpieces[i]; - continue; - } - if ((i != 0) && (s != features)) { - s = g_stpcpy(s, ","); - } - s = g_stpcpy(s, inpieces[i]); - } - - if (compat_str) { - char *v = compat_str + strlen("compat="); - object_property_set_str(machine, "max-cpu-compat", v, &local_err); - } - g_strfreev(inpieces); - if (local_err) { - error_propagate(errp, local_err); - return; - } - } - - /* do property processing with generic handler */ - pcc->parent_parse_features(type, features, errp); -} - PowerPCCPUClass *ppc_cpu_get_family_class(PowerPCCPUClass *pcc) { ObjectClass *oc = OBJECT_CLASS(pcc); @@ -10905,8 +10848,6 @@ static void ppc_cpu_class_init(ObjectClass *oc, void *data) device_class_set_parent_reset(dc, ppc_cpu_reset, &pcc->parent_reset); cc->class_by_name = ppc_cpu_class_by_name; - pcc->parent_parse_features = cc->parse_features; - cc->parse_features = ppc_cpu_parse_featurestr; cc->has_work = ppc_cpu_has_work; cc->do_interrupt = ppc_cpu_do_interrupt; cc->cpu_exec_interrupt = ppc_cpu_exec_interrupt; -- 2.26.2

3 3

[PATCH] polkit: Allow libvirt group access to libvirtd ro socket
by Jim Fehlig 02 Dec '20

02 Dec '20

As a normal user, 'virsh connect qemu:///system' and 'virsh connect --readonly qemu:///system' will prompt for root password. If the user is added to the libvirt group, only 'virsh connect --readonly qemu:///system' will prompt for root password. The libvirt polkit rules already allow libvirt group members access to the rw socket. Add a rule allowing to access the ro socket. Signed-off-by: Jim Fehlig <jfehlig(a)suse.com> --- src/remote/libvirtd.rules | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/src/remote/libvirtd.rules b/src/remote/libvirtd.rules index 01a15fac2e..d9be94fcc4 100644 --- a/src/remote/libvirtd.rules +++ b/src/remote/libvirtd.rules @@ -1,5 +1,12 @@ -// Allow any user in the 'libvirt' group to connect to system libvirtd -// without entering a password. +// Allow any user in the 'libvirt' group to connect to the system libvirtd +// ro and rw sockets without entering a password. + +polkit.addRule(function(action, subject) { + if (action.id == "org.libvirt.unix.monitor" && + subject.isInGroup("libvirt")) { + return polkit.Result.YES; + } +}); polkit.addRule(function(action, subject) { if (action.id == "org.libvirt.unix.manage" && -- 2.29.2

4 6

[PATCH 00/21] move checks from parse functions to post parse
by Daniel Henrique Barboza 02 Dec '20

02 Dec '20

Hi, This started as a simple NVDIMM change, then I realized there is a Gitlab work item for it [1], so I took the extra mile and did a bit more. I'll copy/paste here the motivation for this kind of change, provided by Cole in [1]: ----- The code that handles domain/VM XML parsing (virDomainDefParseXML in src/domain/domain_conf.c) has various validation checks sprinkled within it. Many of these checks should be moved out of the parse step and into virDomainDefPostParse, so they can be shared by various places in the code that build a domain definition without XML, such as converting from native vmware/virtualbox/xen formats. ----- There are still checks to be moved after this work. If this is accepted I'll update [1] with more details/tips about how to proceed with the remaining checks. Some g_auto* cleanups were done along the way. [1] https://gitlab.com/libvirt/libvirt/-/issues/7 Daniel Henrique Barboza (21): domain_conf.c: move NVDIMM 'labelsize' check to post parse domain_conf.c: use g_autofree in 'dev' in virDomainDefParseBootXML() domain_conf.c: modernize virDomainDefBootOrderPostParse() domain_conf.c: move boot related timeouts check to post parse domain_conf.c: do not leak 'video' in virDomainDefParseXML() domain_conf.c: move primary video check to virDomainDefPostParseVideo() domain_conf.c: use g_autoptr() with virDomainVideoDefPtr domain_conf.c: move QXL attributes check to virDomainVideoDefPostParse() virstorageencryption.h: add AUTOPTR_CLEANUP_FUNC for virStorageEncryptionPtr domain_conf: modernize virDomainDiskDefParseXML() domain_conf.c: move vendor, product and tray checks to post parse domain_conf.c: move smartcard address check to post parse domain_conf.c: modernize virDomainSmartcardDefParseXML domain_conf.c: remove 'error' label in virDomainDefTunablesParse() domain_conf.c: move duplicate blkio path check to post parse domain_conf.c: move virDomainPCIControllerOpts checks to post parse domain_conf.c: move pci-root/pcie-root address check to post parse domain_conf.c: modernize virDomainControllerDefParseXML() domain_conf.c: modernize virDomainDefControllersParse() domain_conf.c: use VIR_ERR_CONFIG_UNSUPPORTED in post parse domain_conf.c: move idmapEntry checks to post parse src/conf/domain_conf.c | 762 ++++++++++-------- src/conf/domain_conf.h | 4 + src/util/virstorageencryption.h | 1 + tests/qemuxml2argvdata/pci-root-address.err | 2 +- .../pseries-default-phb-numa-node.err | 2 +- .../video-multiple-primaries.err | 1 + .../video-multiple-primaries.xml | 32 + tests/qemuxml2argvtest.c | 5 + 8 files changed, 451 insertions(+), 358 deletions(-) create mode 100644 tests/qemuxml2argvdata/video-multiple-primaries.err create mode 100644 tests/qemuxml2argvdata/video-multiple-primaries.xml -- 2.26.2

2 38

[PATCH 0/3] qemu: Couple of qemuDomainGetGuestInfo() related cleanups
by Michal Privoznik 02 Dec '20

02 Dec '20

While reviewing Marc-André's patches I've noticed couple of cleanup possible. Michal Prívozník (3): qemuDomainGetGuestInfo: Exit early if getting info fails virJSONValueObjectGetStringArray: Report error if @key is not an array qemu: Use virJSONValueObjectGetStringArray() more src/qemu/qemu_agent.c | 30 +++---------------- src/qemu/qemu_driver.c | 3 ++ src/qemu/qemu_monitor_json.c | 56 +++++------------------------------- src/util/virjson.c | 6 +++- 4 files changed, 19 insertions(+), 76 deletions(-) -- 2.26.2

2 7

[libvirt PATCH] docs: Update language bindings spotlight
by Andrea Bolognani 01 Dec '20

01 Dec '20

We should highlight the language bindings that are actively maintained, keep up with the core library's development pace, have good API coverage and are relevant to people looking to integrate libvirt into their projects in $currentyear: based on these criteria, it makes sense to highlight the Go binding instead of the Java one. Signed-off-by: Andrea Bolognani <abologna(a)redhat.com> --- docs/index.html.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/index.html.in b/docs/index.html.in index df182c27b6..f44e055174 100644 --- a/docs/index.html.in +++ b/docs/index.html.in @@ -18,7 +18,7 @@ </p> <ul> <li>is a toolkit to manage <a href="platforms.html">virtualization platforms</a></li> - <li>is accessible from C, Python, Perl, Java and more</li> + <li>is accessible from C, Python, Perl, Go and more</li> <li>is licensed under open source licenses</li> <li>supports <a href="drvqemu.html">KVM</a>, <a href="drvqemu.html">QEMU</a>, <a href="drvxen.html">Xen</a>, -- 2.26.2

2 1

[PATCH] qemu: Recreate NUMA caps when creating connect capabilities
by Michal Privoznik 01 Dec '20

01 Dec '20

In v6.0.0-rc1~439 (and friends) we tried to cache NUMA capabilities because we assumed they are immutable. And to some extent they are (NUMA hotplug is not a thing, is it). However, our capabilities contain also some runtime info that can change, e.g. hugepages pool allocation sizes or total amount of memory per node (host side memory hotplug might change the value). When rebuilding virCaps (e.g. for 'virsh capabilities') we have to dropped the cached info and rebuild it from scratch so that the correct runtime info is reported. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1819058 Fixes: 1a1d848694f6c2f1d98a371124928375bc3bb4a3 Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- After this, we are still caching CPU caps, but I'm not sure if that is a problem. Perhaps if CPU was hotplugged/unplugged? I don't know. src/qemu/qemu_conf.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c index d6615ca0dd..89a16349bf 100644 --- a/src/qemu/qemu_conf.c +++ b/src/qemu/qemu_conf.c @@ -1380,6 +1380,12 @@ virCapsPtr virQEMUDriverCreateCapabilities(virQEMUDriverPtr driver) "DOI \"%s\"", model, doi); } + /* Forcibly recreate NUMA caps. They are not static + * (e.g. size of hugepages pools can change). */ + qemuDriverLock(driver); + g_clear_pointer(&driver->hostnuma, virCapabilitiesHostNUMAUnref); + qemuDriverUnlock(driver); + caps->host.numa = virQEMUDriverGetHostNUMACaps(driver); caps->host.cpu = virQEMUDriverGetHostCPU(driver); return g_steal_pointer(&caps); -- 2.26.2

2 3

[PATCH v2] lxc: Cleanup after failed startup
by Michal Privoznik 01 Dec '20

01 Dec '20

If starting an container fails, the virLXCProcessStop() is called. But since vm->def->id is not set until libvirt_lxc is spawned (the domain's ID is PID of that process), virLXCProcessStop() returns early as virDomainObjIsActive() returns false. But doing so leaves behind resources reserved for the containers during the startup process. Most notably, hostdevs are not re-attached to the host, the domain's transient XML is not removed, etc. To resolve this, virLXCProcessCleanup() is called in this case. However, it is modified to accept @flags which allows caller to run only specific cleanups (depending how far in container creation the failure occurred). There is plenty of cleanups which don't need this guard because either they detect a NULL pointer or try to release an unique resource. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- v2 of: https://www.redhat.com/archives/libvir-list/2020-November/msg00317.html diff to v1: - Run some cleanups selectively src/lxc/lxc_process.c | 52 ++++++++++++++++++++++++++++++++++--------- 1 file changed, 41 insertions(+), 11 deletions(-) diff --git a/src/lxc/lxc_process.c b/src/lxc/lxc_process.c index c5a710fc3f..5763052e99 100644 --- a/src/lxc/lxc_process.c +++ b/src/lxc/lxc_process.c @@ -145,18 +145,27 @@ lxcProcessRemoveDomainStatus(virLXCDriverConfigPtr cfg, } +typedef enum { + VIR_LXC_PROCESS_CLEANUP_RELEASE_SECLABEL = (1 << 0), + VIR_LXC_PROCESS_CLEANUP_RESTORE_SECLABEL = (1 << 1), + VIR_LXC_PROCESS_CLEANUP_REMOVE_TRANSIENT = (1 << 2), +} virLXCProcessCleanupFlags; + /** * virLXCProcessCleanup: * @driver: pointer to driver structure * @vm: pointer to VM to clean up * @reason: reason for switching the VM to shutoff state + * @flags: allows to run selective cleanups only * - * Cleanout resources associated with the now dead VM - * + * Clean out resources associated with the now dead VM. + * If @flags is zero then whole cleanup process is done, + * otherwise only selected sections are run. */ static void virLXCProcessCleanup(virLXCDriverPtr driver, virDomainObjPtr vm, - virDomainShutoffReason reason) + virDomainShutoffReason reason, + unsigned int flags) { size_t i; virLXCDomainObjPrivatePtr priv = vm->privateData; @@ -164,8 +173,11 @@ static void virLXCProcessCleanup(virLXCDriverPtr driver, virLXCDriverConfigPtr cfg = virLXCDriverGetConfig(driver); virConnectPtr conn = NULL; - VIR_DEBUG("Cleanup VM name=%s pid=%d reason=%d", - vm->def->name, (int)vm->pid, (int)reason); + VIR_DEBUG("Cleanup VM name=%s pid=%d reason=%d flags=0x%x", + vm->def->name, (int)vm->pid, (int)reason, flags); + + if (flags == 0) + flags = ~0; /* now that we know it's stopped call the hook if present */ if (virHookPresent(VIR_HOOK_DRIVER_LXC)) { @@ -177,9 +189,15 @@ static void virLXCProcessCleanup(virLXCDriverPtr driver, NULL, xml, NULL); } - virSecurityManagerRestoreAllLabel(driver->securityManager, - vm->def, false, false); - virSecurityManagerReleaseLabel(driver->securityManager, vm->def); + if (flags & VIR_LXC_PROCESS_CLEANUP_RESTORE_SECLABEL) { + virSecurityManagerRestoreAllLabel(driver->securityManager, + vm->def, false, false); + } + + if (flags & VIR_LXC_PROCESS_CLEANUP_RELEASE_SECLABEL) { + virSecurityManagerReleaseLabel(driver->securityManager, vm->def); + } + /* Clear out dynamically assigned labels */ if (vm->def->nseclabels && vm->def->seclabels[0]->type == VIR_DOMAIN_SECLABEL_DYNAMIC) { @@ -258,7 +276,9 @@ static void virLXCProcessCleanup(virLXCDriverPtr driver, NULL, xml, NULL); } - virDomainObjRemoveTransientDef(vm); + if (flags & VIR_LXC_PROCESS_CLEANUP_REMOVE_TRANSIENT) + virDomainObjRemoveTransientDef(vm); + virObjectUnref(cfg); virObjectUnref(conn); } @@ -904,7 +924,7 @@ int virLXCProcessStop(virLXCDriverPtr driver, } cleanup: - virLXCProcessCleanup(driver, vm, reason); + virLXCProcessCleanup(driver, vm, reason, 0); return 0; } @@ -1198,6 +1218,7 @@ int virLXCProcessStart(virConnectPtr conn, g_autoptr(virCgroup) selfcgroup = NULL; int status; g_autofree char *pidfile = NULL; + unsigned int stopFlags = 0; if (virCgroupNewSelf(&selfcgroup) < 0) return -1; @@ -1265,6 +1286,7 @@ int virLXCProcessStart(virConnectPtr conn, VIR_DEBUG("Setting current domain def as transient"); if (virDomainObjSetDefTransient(driver->xmlopt, vm, NULL) < 0) goto cleanup; + stopFlags |= VIR_LXC_PROCESS_CLEANUP_REMOVE_TRANSIENT; /* Run an early hook to set-up missing devices */ if (virHookPresent(VIR_HOOK_DRIVER_LXC)) { @@ -1312,11 +1334,13 @@ int virLXCProcessStart(virConnectPtr conn, goto cleanup; } virDomainAuditSecurityLabel(vm, true); + stopFlags |= VIR_LXC_PROCESS_CLEANUP_RELEASE_SECLABEL; VIR_DEBUG("Setting domain security labels"); if (virSecurityManagerSetAllLabel(driver->securityManager, vm->def, NULL, false, false) < 0) goto cleanup; + stopFlags |= VIR_LXC_PROCESS_CLEANUP_RESTORE_SECLABEL; VIR_DEBUG("Setting up consoles"); for (i = 0; i < vm->def->nconsoles; i++) { @@ -1525,7 +1549,13 @@ int virLXCProcessStart(virConnectPtr conn, } if (rc != 0) { virErrorPreserveLast(&err); - virLXCProcessStop(driver, vm, VIR_DOMAIN_SHUTOFF_FAILED); + if (virDomainObjIsActive(vm)) { + virLXCProcessStop(driver, vm, VIR_DOMAIN_SHUTOFF_FAILED); + } else { + /* virLXCProcessStop() is NOP if the container is not active. + * If there was a failure whilst creating it, cleanup manually. */ + virLXCProcessCleanup(driver, vm, VIR_DOMAIN_SHUTOFF_FAILED, stopFlags); + } } virCommandFree(cmd); for (i = 0; i < nttyFDs; i++) -- 2.26.2

1 1

[libvirt PATCH 0/9] qemu: report guest disks informations
by marcandre.lureau＠redhat.com 01 Dec '20

01 Dec '20

From: Marc-André Lureau <marcandre.lureau(a)redhat.com> Hi, The following series extends virDomainGetGuestInfo to report disk informations provided by the new QGA "guest-get-disks" command in QEMU 5.2. Please review, Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1899527 Marc-André Lureau (9): qemu_agent: rename qemuAgentDiskInfo->qemuAgentDiskAddress qemu_agent: export qemuAgentDiskAddressFree & add g_auto qemu_agent: factor out qemuAgentGetDiskAddress util: json: add virJSONValueObjectGetStringArray convenience qemu: use virJSONValueObjectGetStringArray qemu_agent: add qemuAgentGetDisks domain: add disk informations to virDomainGetGuestInfo qemu_driver: report guest disk informations virsh: add --disk informations to guestinfo command include/libvirt/libvirt-domain.h | 1 + src/libvirt-domain.c | 17 +++ src/libvirt_private.syms | 1 + src/qemu/qemu_agent.c | 182 +++++++++++++++++++++++-------- src/qemu/qemu_agent.h | 25 ++++- src/qemu/qemu_driver.c | 103 ++++++++++++++++- src/qemu/qemu_monitor_json.c | 34 +----- src/util/virjson.c | 30 +++++ src/util/virjson.h | 1 + tests/qemuagenttest.c | 111 +++++++++++++++++++ tools/virsh-domain.c | 6 + 11 files changed, 430 insertions(+), 81 deletions(-) -- 2.29.0

5 18

[PATCH v2 0/2] gitlab: Add issue templates
by Peter Krempa 01 Dec '20

01 Dec '20

Gitlab allows projects to define templates for filing issues [1]. Libvirt didn't have them yet. We can use them to encourage users to file better bug reports and feature requests. Differences to v1: - dropped bug-qemu.md template - vastly shortened comment blocks - all comments are single line only to prevent users adding info inside of them - more fill-in fields instead of comment guidance You can test-drive the proposed templates in my test repo: https://gitlab.com/pipo.sk/test/-/issues/new Peter Krempa (2): gitlab: Add issue template for reporting a generic bug gitlab: Add issue template for a feature request .gitlab/issue_templates/bug.md | 26 ++++++++++++++++++++++++++ .gitlab/issue_templates/feature.md | 14 ++++++++++++++ 2 files changed, 40 insertions(+) create mode 100644 .gitlab/issue_templates/bug.md create mode 100644 .gitlab/issue_templates/feature.md -- 2.28.0

2 5

Release of libvirt-6.10.0
by Jiri Denemark 01 Dec '20

01 Dec '20

The 6.10.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 any other feedback. Your work is greatly appreciated. * Security * qemu: Enable client TLS certificate validation by default for ``chardev``, ``migration``, and ``backup`` servers. The default value if qemu.conf options ``chardev_tls_x509_verify``, ``migrate_tls_x509_verify``, or ``backup_tls_x509_verify`` are not specified explicitly in the config file and also the ``default_tls_x509_verify`` config option is missing are now '1'. This ensures that only legitimate clients access servers, which don't have any additional form of authentication. * New features * qemu: Implement OpenSSH authorized key file management APIs New APIs (``virDomainAuthorizedSSHKeysGet()`` and ``virDomainAuthorizedSSHKeysSet()``) and virsh commands (``get-user-sshkeys`` and ``set-user-sshkeys``) are added to manage authorized_keys SSH file for user. * hyperv: implement new APIs The ``virDomainGetMaxMemory()``, ``virDomainSetMaxMemory()``, ``virDomainGetSchedulerType()``, ``virDomainGetSchedulerParameters()``, ``virDomainGetSchedulerParametersFlags()``, ``virDomainGetVcpus()``, ``virDomainGetVcpusFlags()``, ``virDomainGetMaxVcpus()``, ``virDomainSetVcpus()``, and ``virDomainSetVcpusFlags()`` APIs have been implemented in the Hyper-V driver. * Improvements * virsh: Support network disks in ``virsh attach-disk`` The ``virsh attach-disk`` helper command which simplifies attaching of disks without the need for the user to formulate the disk XML manually now supports network-backed images. Users can specify the protocol and host specification with new command line arguments. Please refer to the man page of virsh for further information. * Bug fixes * remote: fixed performance regression in SSH tunnelling The ``virt-ssh-helper`` binary introduced in 6.8.0 had very poor scalability which impacted libvirt tunnelled migration and storage volume upload/download in particular. It has been updated and now has performance on par with netcat. * Removed features * hyperv: removed support for the Hyper-V V1 WMI API This drops support for Windows Server 2008R2 and 2012. The earliest supported version is now Windows 2012R2. Enjoy. Jirka

1 0

[PATCH 00/24] qemu: Prepare for QAPIfied 'object-add'
by Peter Krempa 01 Dec '20

01 Dec '20

Prepare libvirt for the changes proposed for qemu: https://www.redhat.com/archives/libvir-list/2020-November/msg01580.html Patches 1-12/24 are pure refactors and can be merged right away. Patches 13-15/24 can be merged, but the justification will be weak without the rest. Patches 16-22/24 are RFC until the qemu bits are merged. Patch 23/24 adds capabilities and needs to be udpated later Patch 24/24 is not to be merged! Note that patch 23/24 is intentionally missing from the mailing list posting as it's just a dump of QEMU capabilities from newest qemu. No need to litter the list with it. Also note that after the last patch tests will fail. See that patch for the reason. Fetch the full series at: git fetch https://gitlab.com/pipo.sk/libvirt.git object-add-qapi-3 Peter Krempa (24): qemuMonitorJSONSetMigrationParams: Take double pointer for @params qemuMonitorSetMigrationCapabilities: Take double pointer for @caps qemuMonitorJSONSetMigrationCapabilities: Refactor cleanup testQemuMonitorJSONqemuMonitorJSONGetMigrationCapabilities: refactor cleanup qemuMonitorJSONAddObject: Take double pointer for @props qemuMonitorJSONMakeCommandInternal: Clear @arguments when stolen qemuMonitorAddObject: Fix semantics of @alias qemuMonitorAddObject: Refactor cleanup util: json: Replace virJSONValueObjectSteal by virJSONValueObjectRemoveKey tests: qemuxml2argv: Don't check whether -netdev was QAPIfied repeatedly qemuBuildChrChardevStr: Rename 'flags' to 'cdevflags' testCompareXMLToArgvValidateSchema: Populate autoNodeset qemu: command: Generate commandline of 'masterKey0' secret via JSON qemu: command: Generate commandline of 'sev0' sev-guest object via JSON qemu: command: Generate commandline of iothread objects JSON qemu: capabilities: Introduce QEMU_CAPS_OBJECT_QAPIFIED tests: qemuxml2argv: Validate generation of JSON props for object-add qemu: command: Introduce raw JSON passthrough for '-object' for testing qemu: monitor: Make wrapping of 'props' of 'object-add' optional qemuMonitorCreateObjectPropsWrap: Open-code in qemuBuildMemoryBackendProps qemu: monitor: Don't add 'props' wrapper if qemu has QEMU_CAPS_OBJECT_QAPIFIED qemumonitorjsontest: Remove bomb guarding object-add qemu: capabilities: Add 6.0 capabilities with qapified object-add [DONTMERGE] qemuxml2argvtest: Force QMP validation with latest caps src/qemu/qemu_capabilities.c | 2 + src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 332 +- src/qemu/qemu_migration_params.c | 22 +- src/qemu/qemu_monitor.c | 121 +- src/qemu/qemu_monitor.h | 8 +- src/qemu/qemu_monitor_json.c | 57 +- src/qemu/qemu_monitor_json.h | 6 +- src/util/virjson.c | 29 +- src/util/virqemu.c | 48 +- src/util/virqemu.h | 3 +- .../domaincapsdata/qemu_6.0.0-q35.x86_64.xml | 197 + .../domaincapsdata/qemu_6.0.0-tcg.x86_64.xml | 203 + tests/domaincapsdata/qemu_6.0.0.x86_64.xml | 197 + .../caps_6.0.0.x86_64.replies | 32021 ++++++++++++++++ .../caps_6.0.0.x86_64.xml | 3205 ++ tests/qemumonitorjsontest.c | 40 +- ...v-missing-platform-info.x86_64-2.12.0.args | 2 +- .../launch-security-sev.x86_64-2.12.0.args | 2 +- tests/qemuxml2argvtest.c | 44 +- 20 files changed, 36202 insertions(+), 338 deletions(-) create mode 100644 tests/domaincapsdata/qemu_6.0.0-q35.x86_64.xml create mode 100644 tests/domaincapsdata/qemu_6.0.0-tcg.x86_64.xml create mode 100644 tests/domaincapsdata/qemu_6.0.0.x86_64.xml create mode 100644 tests/qemucapabilitiesdata/caps_6.0.0.x86_64.replies create mode 100644 tests/qemucapabilitiesdata/caps_6.0.0.x86_64.xml -- 2.28.0

1 23

[PATCH 0/3] qemu: Remove caching in handler for query-command-line-options
by Peter Krempa 01 Dec '20

01 Dec '20

Shuffle around where we extract the data, so that we don't have to call the monitor multiple times which necessitates caching. Peter Krempa (3): qemu: monitor: Implement new handlers for 'query-command-line-options' virQEMUCapsProbeQMPCommandLine: Rewrite using qemuMonitorGetCommandLineOptions qemuMonitorGetCommandLineOptionParameters: remove the unused function and helpers src/qemu/qemu_capabilities.c | 34 +++++---- src/qemu/qemu_monitor.c | 34 +-------- src/qemu/qemu_monitor.h | 9 +-- src/qemu/qemu_monitor_json.c | 138 +++++++++-------------------------- src/qemu/qemu_monitor_json.h | 6 +- tests/qemumonitorjsontest.c | 117 ----------------------------- 6 files changed, 58 insertions(+), 280 deletions(-) -- 2.28.0

2 4

Re: [PATCH for-6.0 6/6] qapi: Deprecate 'query-kvm'
by Daniel P. Berrangé 01 Dec '20

01 Dec '20

Copying libvir-list for the deprecation warning. On Mon, Nov 16, 2020 at 04:10:11PM +0300, Roman Bolshakov wrote: > 'query-accel' QMP command should be used instead. > > Signed-off-by: Roman Bolshakov <r.bolshakov(a)yadro.com> > --- > qapi/machine.json | 6 +++++- > 1 file changed, 5 insertions(+), 1 deletion(-) docs/system/deprecated.rst needs to be updated for any deprecation to be visible to consumers of QEMU. > > diff --git a/qapi/machine.json b/qapi/machine.json > index 5648d8d24d..130b0dbebc 100644 > --- a/qapi/machine.json > +++ b/qapi/machine.json > @@ -579,6 +579,9 @@ > # > # Returns information about KVM acceleration > # > +# Features: > +# @deprecated: This command is deprecated, use 'query-accel' instead. > +# > # Returns: @AccelInfo > # > # Since: 0.14.0 > @@ -589,7 +592,8 @@ > # <- { "return": { "enabled": true, "present": true } } > # > ## > -{ 'command': 'query-kvm', 'returns': 'AccelInfo' } > +{ 'command': 'query-kvm', 'returns': 'AccelInfo', > + 'features': [ 'deprecated' ] } > > ## > # @query-accel: > -- > 2.29.2 > > 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 11

[libvirt PATCH] vircgroupv2: fix virCgroupV2DenyDevice
by Pavel Hrdina 30 Nov '20

30 Nov '20

The original logic is incorrect. We would delete the device entry from eBPF map only if the newval would be same as current val in the map. In case that the device was allowed only as read-only but later we remove all permissions for that device it would remain in the table with empty values. The old code would still deny the device but it's not working as intended. Instead we will update the value in advance. If the updated value is 0 it means that we are removing all permissions so it should be removed from the map, otherwise we will update the value in map. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1810356 Signed-off-by: Pavel Hrdina <phrdina(a)redhat.com> --- src/util/vircgroupv2.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/util/vircgroupv2.c b/src/util/vircgroupv2.c index 2b32f614e4..40cfa20376 100644 --- a/src/util/vircgroupv2.c +++ b/src/util/vircgroupv2.c @@ -1796,7 +1796,9 @@ virCgroupV2DenyDevice(virCgroupPtr group, return 0; } - if (newval == val) { + val = val & ~newval; + + if (val == 0) { if (virBPFDeleteElem(group->unified.devices.mapfd, &key) < 0) { virReportSystemError(errno, "%s", _("failed to remove device from BPF cgroup map")); @@ -1804,7 +1806,6 @@ virCgroupV2DenyDevice(virCgroupPtr group, } group->unified.devices.count--; } else { - val ^= val & newval; if (virBPFUpdateElem(group->unified.devices.mapfd, &key, &val) < 0) { virReportSystemError(errno, "%s", _("failed to update device in BPF cgroup map")); -- 2.28.0

2 1

[PATCH 0/3] gitlab: Add issue templates
by Peter Krempa 30 Nov '20

30 Nov '20

Gitlab allows projects to define templates for filing issues [1]. Libvirt didn't have them yet. We can use them to encourage users to file better bug reports and feature requests. You can test-drive the proposed templates in my test repo: https://gitlab.com/pipo.sk/test/-/issues/new?issue%5Bassignee_id%5D=&issue%… Any suggestions on how to improve them further are very welcome. [1] https://docs.gitlab.com/ee/user/project/description_templates.html Peter Krempa (3): gitlab: Add issue template for reporting a generic bug gitlab: Add issue template for a feature request gitlab: Add issue template for filing a bug in libvirt's qemu driver .gitlab/issue_templates/bug-qemu.md | 56 +++++++++++++++++++++++++++++ .gitlab/issue_templates/bug.md | 55 ++++++++++++++++++++++++++++ .gitlab/issue_templates/feature.md | 26 ++++++++++++++ 3 files changed, 137 insertions(+) create mode 100644 .gitlab/issue_templates/bug-qemu.md create mode 100644 .gitlab/issue_templates/bug.md create mode 100644 .gitlab/issue_templates/feature.md -- 2.28.0

4 10

[PATCH v2 0/6] Final changes to fix test suite on macOS
by Roman Bolshakov 28 Nov '20

28 Nov '20

The set of changes fixes qemuxml2argvtest and closes issue #58. Changes since v1: - Simplified lookup of symbols in main executable (Michal) - Reduced timeout to 90s for qemuxml2argvtest (Andrea) - Two new patches to fix qemucapsprobe Pipeline results: https://gitlab.com/roolebo/libvirt/-/pipelines/220225729 Roman Bolshakov (6): tests: Fix opendir mocks on macOS tests: Fix mock chaining on macOS qemuxml2argvtest: Increase timeout on macOS ci: Run test suite on macOS tests: Delay mock creation qemucapsprobemock: Fix lookup of qemu functions ci/cirrus/build.yml | 3 +-- tests/meson.build | 49 +++++++++++++++++++++++++----------------- tests/virfilewrapper.c | 4 ++++ tests/virmock.h | 13 +++++++++++ tests/virpcimock.c | 5 +++++ 5 files changed, 52 insertions(+), 22 deletions(-) -- 2.29.2

2 14

Entering freeze for libvirt-6.10.0
by Jiri Denemark 28 Nov '20

28 Nov '20

I have just tagged v6.10.0-rc1 in the repository and pushed signed tarballs and source RPMs to https://libvirt.org/sources/ Please give the release candidate some testing and in case you find a serious issue which should have a fix in the upcoming release, feel free to reply to this thread to make sure the issue is more visible. If you have not done so yet, please update NEWS.rst to document any significant change you made since the last release. Thanks, Jirka

1 1

QEMU Advent Calendar 2020 Call for Images
by Eldon Stegall 27 Nov '20

27 Nov '20

Hi, QEMU Advent Calendar 2020 is around the corner and we are looking for volunteers to contribute disk images that showcase something cool, bring back retro computing memories, or simply entertain with a puzzle or game. QEMU Advent Calendar publishes a QEMU disk image each day from December 1-24. Each image is a surprise designed to delight an audience consisting of the QEMU community and beyond. You can see previous years here: https://www.qemu-advent-calendar.org/ You can help us make this year's calendar awesome by: * Sending disk images ( or links to larger images ) * Replying with ideas for disk images (reply off-list to avoid spoilers!) If you have an idea after the start of the advent, go ahead and send it. We may find space to include it, or go ahead and get a jump on 2021! Here are the requirements for disk images: * Content must be freely redistributable (i.e. no proprietary license that prevents distribution). For GPL based software, you need to provide the source code, too. * Provide a name and a short description of the disk image (e.g. with hints on what to try) * Provide a ./run shell script that prints out the name and description/hints and launches QEMU * Provide a 320x240 screenshot/image/logo for the website * Size should be ideally under 100 MB per disk image (but if some few images are bigger, that should be OK, too) Check out this disk image as an example of how to distribute an image: https://www.qemu-advent-calendar.org/2018/download/day24.tar.xz PS: QEMU Advent Calendar is a secular calendar (not religious). The idea is to create a fun experience for the QEMU community which can be shared with everyone. You don't need to celebrate Christmas or another religious festival to participate! Thanks, and best wishes! Eldon

1 0

[libvirt PATCH v4] ci: Switch to meson build system
by Erik Skultety 27 Nov '20

27 Nov '20

Add meson required bits to the ci logic in the repo to be able to run a meson build in a container. This patch also drops several environment variables we don't need with meson anymore. Signed-off-by: Erik Skultety <eskultet(a)redhat.com> --- v3: https://www.redhat.com/archives/libvir-list/2020-November/msg01293.html Since v3: - further review comments - introduced CI_MESON_ARGS variable ci/Makefile | 38 +++++++------------------------------- ci/build.sh | 29 ++++++----------------------- 2 files changed, 13 insertions(+), 54 deletions(-) diff --git a/ci/Makefile b/ci/Makefile index c7c8eb9a45..d9d14f82c2 100644 --- a/ci/Makefile +++ b/ci/Makefile @@ -20,27 +20,6 @@ CI_HOST_SRCDIR = $(CI_SCRATCHDIR)/src # the $(CI_HOST_SRCDIR) directory from the host CI_CONT_SRCDIR = $(CI_USER_HOME)/libvirt -# Relative directory to perform the build in. This -# defaults to using a separate build dir, but can be -# set to empty string for an in-source tree build. -CI_VPATH = build - -# The directory holding the build output inside the -# container. -CI_CONT_BUILDDIR = $(CI_CONT_SRCDIR)/$(CI_VPATH) - -# Can be overridden with mingw{32,64}-configure if desired -CI_CONFIGURE = $(CI_CONT_SRCDIR)/configure - -# Default to using all possible CPUs -CI_SMP = $(shell getconf _NPROCESSORS_ONLN) - -# Any extra arguments to pass to make -CI_MAKE_ARGS = - -# Any extra arguments to pass to configure -CI_CONFIGURE_ARGS = - # Script containing environment preparation steps CI_PREPARE_SCRIPT = $(CI_ROOTDIR)/prepare.sh @@ -220,13 +199,10 @@ ci-run-command@%: ci-prepare-tree --login \ --user="#$(CI_UID)" \ --group="#$(CI_GID)" \ - CONFIGURE_OPTS="$$CONFIGURE_OPTS" \ + MESON_OPTS="$$MESON_OPTS" \ CI_CONT_SRCDIR="$(CI_CONT_SRCDIR)" \ - CI_CONT_BUILDDIR="$(CI_CONT_BUILDDIR)" \ - CI_SMP="$(CI_SMP)" \ - CI_CONFIGURE="$(CI_CONFIGURE)" \ - CI_CONFIGURE_ARGS="$(CI_CONFIGURE_ARGS)" \ - CI_MAKE_ARGS="$(CI_MAKE_ARGS)" \ + CI_MESON_ARGS="$(CI_MESON_ARGS)" \ + CI_NINJA_ARGS="$(CI_NINJA_ARGS)" \ $(CI_COMMAND) || exit 1' @test "$(CI_CLEAN)" = "1" && rm -rf $(CI_SCRATCHDIR) || : @@ -236,8 +212,8 @@ ci-shell@%: ci-build@%: $(MAKE) -C $(CI_ROOTDIR) ci-run-command@$* CI_COMMAND="$(CI_USER_HOME)/build" -ci-check@%: - $(MAKE) -C $(CI_ROOTDIR) ci-build@$* CI_MAKE_ARGS="check" +ci-test@%: + $(MAKE) -C $(CI_ROOTDIR) ci-build@$* CI_NINJA_ARGS+=test ci-list-images: @echo @@ -266,6 +242,6 @@ ci-help: @echo " CI_CLEAN=0 - do not delete '$(CI_SCRATCHDIR)' after completion" @echo " CI_REUSE=1 - re-use existing '$(CI_SCRATCHDIR)' content" @echo " CI_ENGINE=auto - container engine to use (podman, docker)" - @echo " CI_CONFIGURE_ARGS= - extra arguments passed to configure" - @echo " CI_MAKE_ARGS= - extra arguments passed to make, e.g. space delimited list of targets" + @echo " CI_MESON_ARGS= - extra arguments passed to meson" + @echo " CI_NINJA_ARGS= - extra arguments passed to ninja" @echo diff --git a/ci/build.sh b/ci/build.sh index 2da84c080a..740b46a935 100644 --- a/ci/build.sh +++ b/ci/build.sh @@ -7,32 +7,15 @@ # # to make. -mkdir -p "$CI_CONT_BUILDDIR" || exit 1 -cd "$CI_CONT_BUILDDIR" +cd "$CI_CONT_SRCDIR" export VIR_TEST_DEBUG=1 -NOCONFIGURE=1 "$CI_CONT_SRCDIR/autogen.sh" || exit 1 -# $CONFIGURE_OPTS is a env that can optionally be set in the container, +# $MESON_OPTS is an env that can optionally be set in the container, # populated at build time from the Dockerfile. A typical use case would -# be to pass --host/--target args to trigger cross-compilation -# -# This can be augmented by make local args in $CI_CONFIGURE_ARGS -"$CI_CONFIGURE" $CONFIGURE_OPTS $CI_CONFIGURE_ARGS -if test $? != 0; then - test -f config.log && cat config.log - exit 1 -fi -find -name test-suite.log -delete +# be to pass options to trigger cross-compilation -make -j"$CI_SMP" $CI_MAKE_ARGS +meson build --werror $MESON_OPTS $CI_MESON_ARGS || \ +(cat build/meson-logs/meson-log.txt && exit 1) -if test $? != 0; then \ - LOGS=$(find -name test-suite.log) - if test "$LOGS"; then - echo "=== LOG FILE(S) START ===" - cat $LOGS - echo "=== LOG FILE(S) END ===" - fi - exit 1 -fi +ninja -C build $CI_NINJA_ARGS -- 2.26.2

2 4