- Devel - libvirt List Archives

ANNOUNCE: primary git repos switched to https://gitlab.com/libvirt/
by Daniel P. Berrangé 07 Apr '20

07 Apr '20

Hello All, As of this email, the primary host for libvirt project git repositories has been switched to gitlab.com with all projects under the following group: https://gitlab.com/libvirt The development process remains the same for now, with patches still to be submitted to this mailing list as before. The repositories on libvirt.org will continue to exist, but as an automated read-only mirror of the primary gitlab.com repositories, so may be delayed 30-60 minutes vs the primary repos. To update your current checkouts to point to the new primary repos use the following: git remote set-url origin https://gitlab.com/libvirt/$REPO.git eg git remote set-url origin https://gitlab.com/libvirt/libvirt.git (if you are a person with commit rights you'll need to use the ssh URL instead which I've emailed you about directly) Switching over to require merge requests is a separate task that will be done incrementally for repos over a period of time, with further announcements made on this at a later date. As long as a ".gitpublish" config file exists in a repo, then patches for that repo should continue to be sent to this mailing list. 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 :|

1 0

backport new changes to 4.0.0
by Jiatong Shen 07 Apr '20

07 Apr '20

Hello, Sorry in advance if I am asking questions at the wrong place. I would like know if we have plans to backport new features to old releases, for example block copy remote disks. If the answer is no, then where can I find some guidance on building a libvirt debian packages? Thank you very much for the help. -- Best Regards, Jiatong Shen

3 2

[PATCH v3 00/10] Another round of qemu:///embed fixes
by Michal Privoznik 06 Apr '20

06 Apr '20

v3 of: https://www.redhat.com/archives/libvir-list/2020-March/msg01112.html diff to v2: - Patch 2/10 is new; after discussion to v2 we can access driver->privileged and driver->embeddedRoot directly - Patch 3/10 is slightly reworked; it still drops unnecessary layers of nesting in the default case (/var/lib/libvirt/qemu/ram) but it doesn't do that if user provides a path via qemu.conf Michal Prívozník (10): tests: Fix virQEMUDriverConfigNew() calling with respect to @root qemu: Drop virQEMUDriverIsPrivileged() qemu: Drop two layers of nesting of memoryBackingDir conf: Move virDomainGenerateMachineName to hypervisor/ virDomainDriverGenerateMachineName: Factor out embed path hashing qemuDomainGetMachineName: Access embeddedRoot from driver rather than cfg Revert "qemu_conf: Track embed root dir" qemu: Make hugepages path generation embed driver aware qemu: Make memory path generation embed driver aware qemu: Make auto dump path generation embed driver aware src/conf/domain_conf.c | 72 --------------- src/conf/domain_conf.h | 7 -- src/hypervisor/domain_driver.c | 88 +++++++++++++++++++ src/hypervisor/domain_driver.h | 11 +++ src/libvirt_private.syms | 3 +- src/lxc/lxc_domain.c | 3 +- src/qemu/qemu_cgroup.c | 4 +- src/qemu/qemu_command.c | 23 +++-- src/qemu/qemu_conf.c | 76 +++++++++------- src/qemu/qemu_conf.h | 23 +++-- src/qemu/qemu_domain.c | 19 ++-- src/qemu/qemu_driver.c | 42 ++++----- src/qemu/qemu_interface.c | 6 +- src/qemu/qemu_process.c | 7 +- tests/domaincapstest.c | 2 +- .../qemuxml2argvdata/cpu-numa-memshared.args | 8 +- .../fd-memory-no-numa-topology.args | 2 +- .../fd-memory-numa-topology.args | 4 +- .../fd-memory-numa-topology2.args | 8 +- .../fd-memory-numa-topology3.args | 12 +-- .../hugepages-memaccess2.args | 12 +-- .../qemuxml2argvdata/pages-dimm-discard.args | 4 +- ...vhost-user-fs-fd-memory.x86_64-latest.args | 2 +- tests/testutilsqemu.c | 2 +- tests/virsystemdtest.c | 5 +- 25 files changed, 235 insertions(+), 210 deletions(-) -- 2.24.1

2 11

[libvirt-jenkins-ci PATCH 0/5] Introduce the new 'gitlab' flavor
by Erik Skultety 06 Apr '20

06 Apr '20

Erik Skultety (5): guests: templates: Introduce a gitlab-runner systemd service template guests: templates: Introduce a gitlab-runner RC init service template guests: Introduce the new 'gitlab' flavor playbooks: gitlab: Force a random password for the root account guests: lcitool: Enable the new 'gitlab' flavor in the lcitool script guests/group_vars/all/main.yml | 3 + guests/lcitool | 29 ++++++-- guests/playbooks/update/main.yml | 5 ++ guests/playbooks/update/tasks/gitlab.yml | 68 +++++++++++++++++++ .../update/templates/gitlab-runner.j2 | 32 +++++++++ .../update/templates/gitlab-runner.service.j2 | 12 ++++ 6 files changed, 144 insertions(+), 5 deletions(-) create mode 100644 guests/playbooks/update/tasks/gitlab.yml create mode 100644 guests/playbooks/update/templates/gitlab-runner.j2 create mode 100644 guests/playbooks/update/templates/gitlab-runner.service.j2 -- 2.25.1

2 26

[PATCH] libxl: fix crash when initializing driver
by Jim Fehlig 06 Apr '20

06 Apr '20

Commit 54a401af478 split out DriverConfigInit from DriverConfigNew, but then called it a bit late from libxlStateInitialize. The cfg is used in libxlDriverConfigLoadFile and when uninitialized results in a crash. Calling DriverConfigInit immediately after DriverConfigNew fixes the crash. Signed-off-by: Jim Fehlig <jfehlig(a)suse.com> --- src/libxl/libxl_driver.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c index 7ec4fcc3d1..980984b199 100644 --- a/src/libxl/libxl_driver.c +++ b/src/libxl/libxl_driver.c @@ -702,14 +702,14 @@ libxlStateInitialize(bool privileged, if (!(cfg = libxlDriverConfigNew())) goto error; + if (libxlDriverConfigInit(cfg) < 0) + goto error; + driverConf = g_strdup_printf("%s/libxl.conf", cfg->configBaseDir); if (libxlDriverConfigLoadFile(cfg, driverConf) < 0) goto error; - if (libxlDriverConfigInit(cfg) < 0) - goto error; - /* Register the callbacks providing access to libvirt's event loop */ libxl_osevent_register_hooks(cfg->ctx, &libxl_osevent_callbacks, cfg->ctx); -- 2.26.0

3 3

[PATCH] formatdomain.html.in: fix 'sockets' info in topology element
by Daniel Henrique Barboza 06 Apr '20

06 Apr '20

In the 'topology' element it is mentioned, regarding the sockets value, "They refer to the total number of CPU sockets". This is not accurate. What we're doing is calculating the number of sockets per NUMA node, which can be checked in the current implementation of virHostCPUGetInfoPopulateLinux(). Calculating the total number of sockets would break the topology sanity check nodes*sockets*cores*threads=online_cpus. This documentation fix is important to avoid user confusion when seeing the output of 'virsh capabilities' and expecting it to be equal to the output of 'lscpu'. E.g in a Power 9 host this 'lscpu' output: Architecture: ppc64le Byte Order: Little Endian CPU(s): 160 On-line CPU(s) list: 0-159 Thread(s) per core: 4 Core(s) per socket: 20 Socket(s): 2 NUMA node(s): 2 Model: 2.2 (pvr 004e 1202) Model name: POWER9, altivec supported And this XML output from virsh capabilities: <cpu> <arch>ppc64le</arch> <model>POWER9</model> <vendor>IBM</vendor> <topology sockets='1' dies='1' cores='20' threads='4'/> (...) </cpu> Both are correct, as long as we mention in the Libvirt documentation that 'sockets' in the topology element represents the number of sockets per NUMA node. Signed-off-by: Daniel Henrique Barboza <danielhb413(a)gmail.com> --- docs/formatdomain.html.in | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in index aaeb05961f..7940d6ace5 100644 --- a/docs/formatdomain.html.in +++ b/docs/formatdomain.html.in @@ -1675,9 +1675,9 @@ <dd>The <code>topology</code> element specifies requested topology of virtual CPU provided to the guest. Four attributes, <code>sockets</code>, <code>dies</code>, <code>cores</code>, and <code>threads</code>, - accept non-zero positive integer values. They refer to the total number - of CPU sockets, number of dies per socket, number of cores per die, and - number of threads per core, respectively. The <code>dies</code> + accept non-zero positive integer values. They refer to the number of + CPU sockets per NUMA node, number of dies per socket, number of cores + per die, and number of threads per core, respectively. The <code>dies</code> attribute is optional and will default to 1 if omitted, while the other attributes are all mandatory. Hypervisors may require that the maximum number of vCPUs specified by the <code>cpus</code> element equals to -- 2.25.1

2 1

[PATCH] tools: variables clean-up in libvirt-guests script
by Prathamesh Chavan 06 Apr '20

06 Apr '20

Redeclared variables in script functions marked as local. Variables `guest_running` and `guests_shutting_down` in the functions 'guest_is_on` and `check_guests_shutdown` were untouched, as the functions returned values in these variables. Signed-off-by: Prathamesh Chavan <pc44800(a)gmail.com> --- I'm submitting this as my BiteSizedTask for GSoC'20 I've cc'd Martin Kletzander, as he is mentor for this task, and to ensure that the needful was done by me. After running `make check`, I received "PASS: 98 and SKIP: 7" as the result. Travis-ci build report can be found at [1]. For my project, 'Introducing job control to the storage driver', right now I'm going through the `/src/qemu/THREADS.txt` as well as previous work done by Tucker DiNapoli during GSoC'14, as well as the proposal of Taowei Luo for GSoC'15. Their email threads are surely helping me get a better picture of the project. Apart from this, please let me know if there is anything else, which could help me with this project. Thansk! [1]: https://travis-ci.org/github/pratham-pc/libvirt/builds/668209157 tools/libvirt-guests.sh.in | 104 +++++++++++++++++++------------------ 1 file changed, 54 insertions(+), 50 deletions(-) diff --git a/tools/libvirt-guests.sh.in b/tools/libvirt-guests.sh.in index a881f6266e..90a18fee49 100644 --- a/tools/libvirt-guests.sh.in +++ b/tools/libvirt-guests.sh.in @@ -65,7 +65,7 @@ retval() { # If URI is "default" virsh is called without the "-c" argument # (using libvirt's default connection) run_virsh() { - uri=$1 + local uri=$1 shift if [ "x$uri" = xdefault ]; then @@ -86,7 +86,7 @@ run_virsh_c() { # check if URI is reachable test_connect() { - uri=$1 + local uri=$1 if run_virsh "$uri" connect 2>/dev/null; then return 0; @@ -103,8 +103,8 @@ test_connect() # --transient: list only transient guests # [none]: list both persistent and transient guests list_guests() { - uri=$1 - persistent=$2 + local uri=$1 + local persistent=$2 list=$(run_virsh_c "$uri" list --uuid $persistent) if [ $? -ne 0 ]; then @@ -118,8 +118,8 @@ list_guests() { # guest_name URI UUID # return name of guest UUID on URI guest_name() { - uri=$1 - uuid=$2 + local uri=$1 + local uuid=$2 run_virsh "$uri" domname "$uuid" 2>/dev/null } @@ -128,8 +128,8 @@ guest_name() { # check if guest UUID on URI is running # Result is returned by variable "guest_running" guest_is_on() { - uri=$1 - uuid=$2 + local uri=$1 + local uuid=$2 guest_running=false id=$(run_virsh "$uri" domid "$uuid") @@ -161,13 +161,13 @@ start() { return 0 fi - isfirst=true - bypass= - sync_time=false + local isfirst=true + local bypass= + local sync_time=false test "x$BYPASS_CACHE" = x0 || bypass=--bypass-cache test "x$SYNC_TIME" = x0 || sync_time=true while read uri list; do - configured=false + local configured=false set -f for confuri in $URIS; do set +f @@ -186,7 +186,7 @@ start() { eval_gettext "Resuming guests on \$uri URI..."; echo for guest in $list; do - name=$(guest_name "$uri" "$guest") + local name=$(guest_name "$uri" "$guest") eval_gettext "Resuming guest \$name: " if guest_is_on "$uri" "$guest"; then if "$guest_running"; then @@ -217,17 +217,17 @@ start() { # was saved. suspend_guest() { - uri=$1 - guest=$2 + local uri=$1 + local guest=$2 - name=$(guest_name "$uri" "$guest") - label=$(eval_gettext "Suspending \$name: ") - bypass= - slept=0 + local name=$(guest_name "$uri" "$guest") + local label=$(eval_gettext "Suspending \$name: ") + local bypass= + local slept=0 test "x$BYPASS_CACHE" = x0 || bypass=--bypass-cache printf '%s...\n' "$label" run_virsh "$uri" managedsave $bypass "$guest" >/dev/null & - virsh_pid=$! + local virsh_pid=$! while true; do sleep 1 kill -0 "$virsh_pid" >/dev/null 2>&1 || break @@ -251,15 +251,17 @@ suspend_guest() # was successfully shutdown or the timeout defined by $SHUTDOWN_TIMEOUT expired. shutdown_guest() { - uri=$1 - guest=$2 + local uri=$1 + local guest=$2 - name=$(guest_name "$uri" "$guest") + local name=$(guest_name "$uri" "$guest") eval_gettext "Starting shutdown on guest: \$name" echo retval run_virsh "$uri" shutdown "$guest" >/dev/null || return - timeout=$SHUTDOWN_TIMEOUT - check_timeout=false + local timeout=$SHUTDOWN_TIMEOUT + local check_timeout=false + local format= + local slept= if [ $timeout -gt 0 ]; then check_timeout=true format=$(eval_gettext "Waiting for guest %s to shut down, %d seconds left\n") @@ -300,8 +302,8 @@ shutdown_guest() # was issued to libvirt to allow parallel shutdown. shutdown_guest_async() { - uri=$1 - guest=$2 + local uri=$1 + local guest=$2 name=$(guest_name "$uri" "$guest") eval_gettext "Starting shutdown on guest: \$name" @@ -323,8 +325,8 @@ guest_count() # Result is returned in "guests_shutting_down" check_guests_shutdown() { - uri=$1 - guests_to_check=$2 + local uri=$1 + local guests_to_check=$2 guests_shutting_down= for guest in $guests_to_check; do @@ -344,16 +346,16 @@ check_guests_shutdown() # a shutdown complete notice for guests that have finished print_guests_shutdown() { - uri=$1 - before=$2 - after=$3 + local uri=$1 + local before=$2 + local after=$3 for guest in $before; do case " $after " in *" $guest "*) continue;; esac - name=$(guest_name "$uri" "$guest") + local name=$(guest_name "$uri" "$guest") if [ -n "$name" ]; then eval_gettext "Shutdown of guest \$name complete." echo @@ -365,12 +367,14 @@ print_guests_shutdown() # Shutdown guests GUESTS on machine URI in parallel shutdown_guests_parallel() { - uri=$1 - guests=$2 - - on_shutdown= - check_timeout=false - timeout=$SHUTDOWN_TIMEOUT + local uri=$1 + local guests=$2 + + local on_shutdown= + local check_timeout=false + local timeout=$SHUTDOWN_TIMEOUT + local slept= + local format= if [ $timeout -gt 0 ]; then check_timeout=true format=$(eval_gettext "Waiting for %d guests to shut down, %d seconds left\n") @@ -382,7 +386,7 @@ shutdown_guests_parallel() while [ -n "$guests" ] && [ $(guest_count "$on_shutdown") -lt "$PARALLEL_SHUTDOWN" ]; do set -- $guests - guest=$1 + local guest=$1 shift guests=$* if [ -z "$(echo $on_shutdown | grep $guest)" ] && @@ -394,9 +398,9 @@ shutdown_guests_parallel() sleep 1 set -- $guests - guestcount=$# + local guestcount=$# set -- $on_shutdown - shutdowncount=$# + local shutdowncount=$# if $check_timeout; then if [ $(($timeout % 5)) -eq 0 ]; then @@ -415,7 +419,7 @@ shutdown_guests_parallel() fi fi - on_shutdown_prev=$on_shutdown + local on_shutdown_prev=$on_shutdown check_guests_shutdown "$uri" "$on_shutdown" on_shutdown="$guests_shutting_down" print_guests_shutdown "$uri" "$on_shutdown_prev" "$on_shutdown" @@ -428,8 +432,8 @@ stop() { # last stop was not followed by start [ -f "$LISTFILE" ] && return 0 - suspending=true - if [ "x$ON_SHUTDOWN" = xshutdown ]; then + local suspending=true + if [ "/x$ON_SHUTDOWN" = xshutdown ]; then suspending=false if [ $SHUTDOWN_TIMEOUT -lt 0 ]; then gettext "SHUTDOWN_TIMEOUT must be equal or greater than 0" @@ -448,9 +452,9 @@ stop() { eval_gettext "Running guests on \$uri URI: " - list=$(list_guests "$uri") + local list=$(list_guests "$uri") if [ $? -eq 0 ]; then - empty=true + local empty=true for uuid in $list; do "$empty" || printf ", " printf %s "$(guest_name "$uri" "$uuid")" @@ -464,9 +468,9 @@ stop() { fi if "$suspending"; then - transient=$(list_guests "$uri" "--transient") + local transient=$(list_guests "$uri" "--transient") if [ $? -eq 0 ]; then - empty=true + local empty=true for uuid in $transient; do if "$empty"; then eval_gettext "Not suspending transient guests on URI: \$uri: " @@ -563,7 +567,7 @@ rh_status() { # usage [val] # Display usage string, then exit with VAL (defaults to 2). usage() { - program_name=$0 + local program_name=$0 eval_gettext "Usage: \$program_name {start|stop|status|restart|"\ "condrestart|try-restart|reload|force-reload|gueststatus|shutdown}"; echo exit ${1-2} -- 2.17.1

3 4

[PATCH] qemu_cgroup.c: use VIR_AUTOSTRINGLIST, g_autofree and g_autoptr
by Seeteena Thoufeek 06 Apr '20

06 Apr '20

Signed-off-by: Seeteena Thoufeek <s1seetee(a)linux.vnet.ibm.com> --- src/qemu/qemu_cgroup.c | 91 +++++++++++++++++++------------------------------- 1 file changed, 35 insertions(+), 56 deletions(-) diff --git a/src/qemu/qemu_cgroup.c b/src/qemu/qemu_cgroup.c index c0e30f6..d34c515 100644 --- a/src/qemu/qemu_cgroup.c +++ b/src/qemu/qemu_cgroup.c @@ -62,7 +62,7 @@ qemuSetupImagePathCgroup(virDomainObjPtr vm, { qemuDomainObjPrivatePtr priv = vm->privateData; int perms = VIR_CGROUP_DEVICE_READ; - char **targetPaths = NULL; + VIR_AUTOSTRINGLIST targetPaths = NULL; size_t i; int rv; int ret = -1; @@ -82,12 +82,11 @@ qemuSetupImagePathCgroup(virDomainObjPtr vm, virCgroupGetDevicePermsString(perms), rv); if (rv < 0) - goto cleanup; + return ret; if (rv > 0) { /* @path is neither character device nor block device. */ - ret = 0; - goto cleanup; + return 0; } if (virDevMapperGetTargets(path, &targetPaths) < 0 && @@ -95,7 +94,7 @@ qemuSetupImagePathCgroup(virDomainObjPtr vm, virReportSystemError(errno, _("Unable to get devmapper targets for %s"), path); - goto cleanup; + return ret; } for (i = 0; targetPaths && targetPaths[i]; i++) { @@ -105,13 +104,10 @@ qemuSetupImagePathCgroup(virDomainObjPtr vm, virCgroupGetDevicePermsString(perms), rv); if (rv < 0) - goto cleanup; + return ret; } - ret = 0; - cleanup: - virStringListFree(targetPaths); - return ret; + return 0; } @@ -739,7 +735,7 @@ static int qemuSetupDevicesCgroup(virDomainObjPtr vm) { qemuDomainObjPrivatePtr priv = vm->privateData; - virQEMUDriverConfigPtr cfg = NULL; + g_autoptr(virQEMUDriverConfig) cfg = virQEMUDriverGetConfig(priv->driver); const char *const *deviceACL = NULL; int rv = -1; int ret = -1; @@ -757,15 +753,15 @@ qemuSetupDevicesCgroup(virDomainObjPtr vm) return 0; } - goto cleanup; + return ret; } if (qemuSetupFirmwareCgroup(vm) < 0) - goto cleanup; + return ret; for (i = 0; i < vm->def->ndisks; i++) { if (qemuSetupImageChainCgroup(vm, vm->def->disks[i]->src) < 0) - goto cleanup; + return ret; } rv = virCgroupAllowDevice(priv->cgroup, 'c', DEVICE_PTY_MAJOR, -1, @@ -773,9 +769,8 @@ qemuSetupDevicesCgroup(virDomainObjPtr vm) virDomainAuditCgroupMajor(vm, priv->cgroup, "allow", DEVICE_PTY_MAJOR, "pty", "rw", rv == 0); if (rv < 0) - goto cleanup; + return ret; - cfg = virQEMUDriverGetConfig(priv->driver); deviceACL = cfg->cgroupDeviceACL ? (const char *const *)cfg->cgroupDeviceACL : defaultDeviceACL; @@ -791,7 +786,7 @@ qemuSetupDevicesCgroup(virDomainObjPtr vm) virDomainAuditCgroupMajor(vm, priv->cgroup, "allow", DEVICE_SND_MAJOR, "sound", "rw", rv == 0); if (rv < 0) - goto cleanup; + return ret; } for (i = 0; deviceACL[i] != NULL; i++) { @@ -805,57 +800,54 @@ qemuSetupDevicesCgroup(virDomainObjPtr vm) virDomainAuditCgroupPath(vm, priv->cgroup, "allow", deviceACL[i], "rw", rv); if (rv < 0 && !virLastErrorIsSystemErrno(ENOENT)) - goto cleanup; + return ret; } if (virDomainChrDefForeach(vm->def, true, qemuSetupChardevCgroupCB, vm) < 0) - goto cleanup; + return ret; if (vm->def->tpm && qemuSetupTPMCgroup(vm) < 0) - goto cleanup; + return ret; for (i = 0; i < vm->def->nhostdevs; i++) { /* This may allow /dev/vfio/vfio multiple times, but that * is not a problem. Kernel will have only one record. */ if (qemuSetupHostdevCgroup(vm, vm->def->hostdevs[i]) < 0) - goto cleanup; + return ret; } for (i = 0; i < vm->def->nmems; i++) { if (qemuSetupMemoryDevicesCgroup(vm, vm->def->mems[i]) < 0) - goto cleanup; + return ret; } for (i = 0; i < vm->def->ngraphics; i++) { if (qemuSetupGraphicsCgroup(vm, vm->def->graphics[i]) < 0) - goto cleanup; + return ret; } for (i = 0; i < vm->def->nvideos; i++) { if (qemuSetupVideoCgroup(vm, vm->def->videos[i]) < 0) - goto cleanup; + return ret; } for (i = 0; i < vm->def->ninputs; i++) { if (qemuSetupInputCgroup(vm, vm->def->inputs[i]) < 0) - goto cleanup; + return ret; } for (i = 0; i < vm->def->nrngs; i++) { if (qemuSetupRNGCgroup(vm, vm->def->rngs[i]) < 0) - goto cleanup; + return ret; } if (vm->def->sev && qemuSetupSEVCgroup(vm) < 0) - goto cleanup; + return ret; - ret = 0; - cleanup: - virObjectUnref(cfg); - return ret; + return 0; } @@ -924,13 +916,13 @@ qemuInitCgroup(virDomainObjPtr vm, { int ret = -1; qemuDomainObjPrivatePtr priv = vm->privateData; - virQEMUDriverConfigPtr cfg = virQEMUDriverGetConfig(priv->driver); + g_autoptr(virQEMUDriverConfig) cfg = virQEMUDriverGetConfig(priv->driver); if (!virQEMUDriverIsPrivileged(priv->driver)) - goto done; + return 0; if (!virCgroupAvailable()) - goto done; + return 0; virCgroupFree(&priv->cgroup); @@ -938,7 +930,7 @@ qemuInitCgroup(virDomainObjPtr vm, virDomainResourceDefPtr res; if (VIR_ALLOC(res) < 0) - goto cleanup; + return ret; res->partition = g_strdup("/machine"); @@ -949,7 +941,7 @@ qemuInitCgroup(virDomainObjPtr vm, virReportError(VIR_ERR_CONFIG_UNSUPPORTED, _("Resource partition '%s' must start with '/'"), vm->def->resource->partition); - goto cleanup; + return ret; } if (virCgroupNewMachine(priv->machineName, @@ -964,16 +956,9 @@ qemuInitCgroup(virDomainObjPtr vm, cfg->maxThreadsPerProc, &priv->cgroup) < 0) { if (virCgroupNewIgnoreError()) - goto done; - - goto cleanup; + return 0; } - - done: - ret = 0; - cleanup: - virObjectUnref(cfg); - return ret; + return ret; } static void @@ -1058,14 +1043,14 @@ int qemuConnectCgroup(virDomainObjPtr vm) { qemuDomainObjPrivatePtr priv = vm->privateData; - virQEMUDriverConfigPtr cfg = virQEMUDriverGetConfig(priv->driver); + g_autoptr(virQEMUDriverConfig) cfg = virQEMUDriverGetConfig(priv->driver); int ret = -1; if (!virQEMUDriverIsPrivileged(priv->driver)) - goto done; + return 0; if (!virCgroupAvailable()) - goto done; + return 0; virCgroupFree(&priv->cgroup); @@ -1075,14 +1060,9 @@ qemuConnectCgroup(virDomainObjPtr vm) cfg->cgroupControllers, priv->machineName, &priv->cgroup) < 0) - goto cleanup; + return ret; qemuRestoreCgroupState(vm); - - done: - ret = 0; - cleanup: - virObjectUnref(cfg); return ret; } @@ -1269,7 +1249,7 @@ qemuCgroupEmulatorAllNodesAllow(virCgroupPtr cgroup, qemuCgroupEmulatorAllNodesDataPtr *retData) { qemuCgroupEmulatorAllNodesDataPtr data = NULL; - char *all_nodes_str = NULL; + g_autofree char *all_nodes_str = NULL; virBitmapPtr all_nodes = NULL; int ret = -1; @@ -1298,7 +1278,6 @@ qemuCgroupEmulatorAllNodesAllow(virCgroupPtr cgroup, ret = 0; cleanup: - VIR_FREE(all_nodes_str); virBitmapFree(all_nodes); qemuCgroupEmulatorAllNodesDataFree(data); -- 1.8.3.1

3 2

[PATCH v3 0/3] add support for QEMU 9pfs 'multidevs' option
by Christian Schoenebeck 06 Apr '20

06 Apr '20

QEMU 4.2 added a new option 'multidevs' for 9pfs. The following patch adds support for this new option to libvirt. In short, what is this about: to distinguish files uniquely from each other in general, numeric file IDs are typically used for comparison, which in practice is the combination of a file's device ID and the file's inode number. Unfortunately 9p protocol's QID field used for this purpose, currently is too small to fit both the device ID and inode number in, which hence is a problem if one 9pfs export contains multiple devices and may thus lead to misbheaviours on guest (e.g. with SAMBA file servers) in that case due to potential file ID collisions. To mitigate this problem with 9pfs a 'multidevs' option was introduced in QEMU 4.2 for defining how to deal with this, e.g. multidevs=remap will cause QEMU's 9pfs implementation to remap all inodes from host side to different inode numbers on guest side in a way that prevents file ID collisions. NOTE: In the libvirt docs changes of this libvirt patch I simply assumed "since 6.2.0". So the final libvirt version number would need to be adjusted in that text if necessary. See QEMU discussion with following Message-ID for details: 8a2ffe17fda3a86b9a5a437e1245276881f1e235.1567680121.git.qemu_oss(a)crudebyte.com v2->v3: * Rebased to master (SHA-1 e4bf03b8ff). * Auto sense QEMU capability for command line option fsdev.multidevs instead of checking for QEMU version 4.2. [patch 1] * Auto regenerated capabilities data for all archs (fixes capability test). [patch 1] * Added XML test. [patch 2] * Added argv test. [patch 3] Message-ID of v2: cover.1584723662.git.qemu_oss(a)crudebyte.com Christian Schoenebeck (3): qemu: capabilities: add QEMU_CAPS_VIRTFS_MULTIDEVS conf: add 'multidevs' option qemu: add support for 'multidevs' option docs/formatdomain.html.in | 40 ++++++++++++- docs/schemas/domaincommon.rng | 10 ++++ src/conf/domain_conf.c | 29 ++++++++++ src/conf/domain_conf.h | 13 +++++ src/qemu/qemu_capabilities.c | 2 + src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 7 +++ src/qemu/qemu_domain.c | 12 ++++ .../caps_4.2.0.aarch64.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 + .../virtio-9p-multidevs.x86_64-latest.args | 45 +++++++++++++++ .../qemuxml2argvdata/virtio-9p-multidevs.xml | 53 ++++++++++++++++++ tests/qemuxml2argvtest.c | 2 + .../virtio-9p-multidevs.x86_64-latest.xml | 56 +++++++++++++++++++ tests/qemuxml2xmltest.c | 2 + 19 files changed, 277 insertions(+), 1 deletion(-) create mode 100644 tests/qemuxml2argvdata/virtio-9p-multidevs.x86_64-latest.args create mode 100644 tests/qemuxml2argvdata/virtio-9p-multidevs.xml create mode 100644 tests/qemuxml2xmloutdata/virtio-9p-multidevs.x86_64-latest.xml -- 2.20.1

2 9

[libvirt PATCH] fix build by NULL string handling
by Mishal Shah 06 Apr '20

06 Apr '20

Fix libvirt build by taking care of NULL string handling --- src/openvz/openvz_driver.c | 6 +++++- tests/sockettest.c | 8 ++++++-- 2 files changed, 11 insertions(+), 3 deletions(-) diff --git a/src/openvz/openvz_driver.c b/src/openvz/openvz_driver.c index 1a189dbbe7..46f117cd00 100644 --- a/src/openvz/openvz_driver.c +++ b/src/openvz/openvz_driver.c @@ -2084,7 +2084,7 @@ openvzDomainMigratePrepare3Params(virConnectPtr dconn, virDomainDefPtr def = NULL; virDomainObjPtr vm = NULL; char *my_hostname = NULL; - const char *hostname = NULL; + char *hostname = NULL; virURIPtr uri = NULL; int ret = -1; @@ -2149,6 +2149,10 @@ openvzDomainMigratePrepare3Params(virConnectPtr dconn, } } + if (hostname == NULL) { + goto error; + } + *uri_out = g_strdup_printf("ssh://%s", hostname); ret = 0; diff --git a/tests/sockettest.c b/tests/sockettest.c index 29a565de40..f0a0815b88 100644 --- a/tests/sockettest.c +++ b/tests/sockettest.c @@ -188,8 +188,12 @@ static int testMaskNetwork(const char *addrstr, return -1; if (STRNEQ(networkstr, gotnet)) { - VIR_FREE(gotnet); - fprintf(stderr, "Expected %s, got %s\n", networkstr, gotnet); + if (gotnet == NULL) { + fprintf(stderr, "Expected %s, got empty string\n", networkstr); + } else { + fprintf(stderr, "Expected %s, got %s\n", networkstr, gotnet); + VIR_FREE(gotnet); + } return -1; } VIR_FREE(gotnet); -- 2.17.1

2 4

[libvirt PATCH] github: enable lockdown of issues and merge requests
by Daniel P. Berrangé 06 Apr '20

06 Apr '20

Libvirt uses GitHub as an automated read-only mirror. The goals were to have a disaster recovery backup for libvirt.org, a way to make it easy for people to clone their own private copy of libvirt Git, and finally as a way to interact with apps like Travis. The project description was set to a message telling people that we don't respond to pull requests. This was quite a negative message to potential contributors, and also did not give them any guidance about the right way to submit to libvirt. Many also missed the description and submitted issues or pull requests regardless. It is possible to disable the issue tracker in GitHub, but there is no way to disable merge requests. Disabling the issue tracker would also leave the problem of users not being given any positive information about where they should be reporting instead. There is a fairly new 3rd party application built for GitHub that provides a bot which auto-responds to both issues and merge requests, closing and locking them, with a arbitrary comment: https://github.com/apps/repo-lockdown This commit adds a suitable configuration file for libvirt, which tries to give a positive response to user's issue/pullreq and guide them to the desired contribution path on GitLab. Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- FYI, I have configured the test.git repo to demonstrate the operation. See the comments / actions performed here: https://github.com/libvirt/test/pull/3 https://github.com/libvirt/test/issues/2 This lockdown.yml file will need to be created in each libvirt git repo, with just the URL changed. If this patch is approved, then I propose to directly push the equivalent config file to every other git repo, without spamming libvir-list for review of each. Ideally we should be creating a CONTRIBUTING.md file in each repo too, as both GitHub and GitLab direct users to look at this file for information about how to contribute. This is how we could guide people to use GitLab in the first place, avoiding them filing issues/pulls on the wrong site and triggering this bot. .github/lockdown.yml | 36 ++++++++++++++++++++++++++++++++++++ 1 file changed, 36 insertions(+) create mode 100644 .github/lockdown.yml diff --git a/.github/lockdown.yml b/.github/lockdown.yml new file mode 100644 index 0000000000..09cbdf1b4a --- /dev/null +++ b/.github/lockdown.yml @@ -0,0 +1,36 @@ +# Configuration for Repo Lockdown - https://github.com/dessant/repo-lockdown + +# Close issues and pull requests +close: true + +# Lock issues and pull requests +lock: true + +# Optionally, specify configuration settings just for `issues` or `pulls` +issues: + comment: | + Thank you for your interest in the libvirt project. + + Since this repository is a read-only mirror of the project's master repostory hosted on GitLab, issues opened here are not processed. + + We kindly request that new issues are reported to + + https://gitlab.com/libvirt/libvirt/-/issues/new + + Thank you for your time and understanding. + +pulls: + comment: | + Thank you for your interest in the libvirt project. + + Since this repository is a read-only mirror of the project's master repostory hosted on GitLab, merge requests opened here are not processed. + + We kindly request that contributors fork the project at + + https://gitlab.com/libvirt/libvirt/ + + push changes to the fork, and then open a new merge request at + + https://gitlab.com/libvirt/libvirt/-/merge_requests/new + + Thank you for your time and understanding. -- 2.24.1

5 12

[PATCH] cpu.c: Use g_autoptr and g_autofree in virCPUDataParse
by Seeteena Thoufeek 03 Apr '20

03 Apr '20

Signed-off-by: Seeteena Thoufeek <s1seetee(a)linux.vnet.ibm.com> --- src/cpu/cpu.c | 18 +++++++----------- 1 file changed, 7 insertions(+), 11 deletions(-) diff --git a/src/cpu/cpu.c b/src/cpu/cpu.c index 631c755..e556ffe 100644 --- a/src/cpu/cpu.c +++ b/src/cpu/cpu.c @@ -772,40 +772,36 @@ virCPUDataPtr virCPUDataParse(const char *xmlStr) { struct cpuArchDriver *driver; - xmlDocPtr xml = NULL; - xmlXPathContextPtr ctxt = NULL; + g_autoptr(xmlDoc) xml = NULL; + g_autoptr(xmlXPathContext) ctxt = NULL; virCPUDataPtr data = NULL; - char *arch = NULL; + g_autofree char *arch = NULL; VIR_DEBUG("xmlStr=%s", xmlStr); if (!(xml = virXMLParseStringCtxt(xmlStr, _("CPU data"), &ctxt))) { virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("cannot parse CPU data")); - goto cleanup; + return data; } if (!(arch = virXPathString("string(/cpudata/@arch)", ctxt))) { virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("missing CPU data architecture")); - goto cleanup; + return data; } if (!(driver = cpuGetSubDriverByName(arch))) - goto cleanup; + return data; if (!driver->dataParse) { virReportError(VIR_ERR_NO_SUPPORT, _("cannot parse %s CPU data"), arch); - goto cleanup; + return data; } data = driver->dataParse(ctxt); - cleanup: - xmlXPathFreeContext(ctxt); - xmlFreeDoc(xml); - VIR_FREE(arch); return data; } -- 1.8.3.1

2 1

[PATCH 0/4] support for virtio packed virtqueues
by Bjoern Walk 03 Apr '20

03 Apr '20

QEMU recently (86044b24e) introduced packed virtqueues for virtio that supposedly have better cache utilization and performance compared to the default split queues. So here's a patch set that expose the virtio parameter as a optional libvirt XML attribute to virtio-backed devices, e.g.: <interface type='user'> <mac address='00:11:22:33:44:55'/> <model type='virtio'/> <driver packed='on'/> </interface> The default value if the attribute is omitted is still 'off' and regular split virtqueues are used. Bjoern Walk (4): qemu: capabilities: add 'packed' capability conf: domain: support for virtio packed option qemu: command: support for virtio packed option docs: documentation for virtio packed option docs/formatdomain.html.in | 8 +++++ docs/schemas/domaincommon.rng | 5 +++ src/conf/domain_conf.c | 28 ++++++++++++++++ src/conf/domain_conf.h | 1 + src/qemu/qemu_capabilities.c | 6 ++++ src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 10 ++++++ .../caps_4.2.0.aarch64.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 + tests/qemuxml2argvdata/virtio-options.args | 32 ++++++++++--------- tests/qemuxml2argvdata/virtio-options.xml | 26 +++++++-------- tests/qemuxml2argvtest.c | 3 +- tests/qemuxml2xmltest.c | 3 +- 16 files changed, 98 insertions(+), 30 deletions(-) -- 2.24.1

6 13

[PATCH 00/15] move validations out of qemu_domain.c
by Daniel Henrique Barboza 03 Apr '20

03 Apr '20

This is a suggestion made by Peter in [1], in the review discussion of a series in which I started moving qemuCaps validation from qemu_command.c to qemu_domain.c [2]. I'll quote here what he said back then: "My only suggestion is that after this we should move all validation into a separate file. qemu_domain was a code dumping place for a long time and since we now have a lot of common code moving it out would be benficial for cleaning up an making it more obvious." This is my first go at it with a new file called 'qemu_validate.c'. The code changes are trivial - just moving stuff from qemu_domain to qemu_validate - but the amount of changes can sure make for really tedious reviews. Patches were split according to my own criteria of how annoying would it be to review each one. The maintainer is, as always, welcome to squash them up as necessary. There are still validations to be moved inside qemu_domain.c after this series. I chose to do this first round to validate the idea instead of rocking a 40-something patch series all of a sudden. Once this is figured out we can proceed with the moving. After all this is settled I intend to continue the work I started in [2], but using qemu_validate.c instead of qemu_domain.c as destination. [1] https://www.redhat.com/archives/libvir-list/2019-December/msg00608.html [2] https://www.redhat.com/archives/libvir-list/2019-December/msg00570.html Daniel Henrique Barboza (15): qemu: introducing qemu_validate.c/h qemu: move static functions of qemuDomainDefValidate() qemu: move qemuDomainValidateDef() to qemu_validate.c qemu: move qemuDomainDeviceDefValidateAddress() to qemu_validation.c qemu: move qemuDomainDeviceDefValidateAddress() to qemu_validate.c qemu: move qemuDomainChrDefValidate() to qemu_validate.c qemu: move qemuDomainDeviceDefValidateHostdev() to qemu_validate.c qemu: move qemuDomainDeviceDefValidateVideo() to qemu_validate.c qemu: move qemuDomainDeviceDefValidateDisk() to qemu_validate.c qemu: move qemuValidateDomainDeviceDefController() to qemu_validate.c qemu: move qemuDomainDeviceDefValidateGraphics() to qemu_validate.c qemu: move qemuDomainDeviceDefValidateFS() to qemu_validate.c qemu: move qemuDomainDeviceDefValidateSound() to qemu_validate.c qemu: move remaining qemuDomainDeviceDefValidate() helpers qemu: move qemuValidateDomainDeviceDef() to qemu_validate.c po/POTFILES.in | 1 + src/qemu/Makefile.inc.am | 2 + src/qemu/qemu_domain.c | 3895 ++------------------------------------ src/qemu/qemu_validate.c | 3592 +++++++++++++++++++++++++++++++++++ src/qemu/qemu_validate.h | 34 + tests/qemublocktest.c | 3 +- 6 files changed, 3801 insertions(+), 3726 deletions(-) create mode 100644 src/qemu/qemu_validate.c create mode 100644 src/qemu/qemu_validate.h -- 2.25.1

2 33

[PATCH] rng: Support encryption and slices element in snapshot XML
by Han Han 03 Apr '20

03 Apr '20

Signed-off-by: Han Han <hhan(a)redhat.com> --- docs/schemas/domainsnapshot.rng | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/docs/schemas/domainsnapshot.rng b/docs/schemas/domainsnapshot.rng index 8e39feb2..c881da74 100644 --- a/docs/schemas/domainsnapshot.rng +++ b/docs/schemas/domainsnapshot.rng @@ -160,6 +160,12 @@ <zeroOrMore> <ref name='devSeclabel'/> </zeroOrMore> + <optional> + <ref name='diskSourceCommon'/> + </optional> + <optional> + <ref name="encryption"/> + </optional> <empty/> </element> </optional> @@ -179,6 +185,12 @@ <zeroOrMore> <ref name='devSeclabel'/> </zeroOrMore> + <optional> + <ref name='diskSourceCommon'/> + </optional> + <optional> + <ref name="encryption"/> + </optional> <empty/> </element> </optional> -- 2.25.0

3 2

[PATCH] qemu_checkpoint.c: Use g_autofree in qemuCheckpointPrepare()
by Seeteena Thoufeek 03 Apr '20

03 Apr '20

This is the only instance of g_autofree change applicable for qemu_checkpoint.c Signed-off-by: Seeteena Thoufeek <s1seetee(a)linux.vnet.ibm.com> --- src/qemu/qemu_checkpoint.c | 17 ++++++----------- 1 file changed, 6 insertions(+), 11 deletions(-) diff --git a/src/qemu/qemu_checkpoint.c b/src/qemu/qemu_checkpoint.c index 3a510c9..ccd10cb 100644 --- a/src/qemu/qemu_checkpoint.c +++ b/src/qemu/qemu_checkpoint.c @@ -405,9 +405,8 @@ qemuCheckpointPrepare(virQEMUDriverPtr driver, virDomainObjPtr vm, virDomainCheckpointDefPtr def) { - int ret = -1; size_t i; - char *xml = NULL; + g_autofree char *xml = NULL; qemuDomainObjPrivatePtr priv = vm->privateData; /* Easiest way to clone inactive portion of vm->def is via @@ -419,10 +418,10 @@ qemuCheckpointPrepare(virQEMUDriverPtr driver, priv->qemuCaps, VIR_DOMAIN_DEF_PARSE_INACTIVE | VIR_DOMAIN_DEF_PARSE_SKIP_VALIDATE))) - goto cleanup; + return -1; if (virDomainCheckpointAlignDisks(def) < 0) - goto cleanup; + return -1; for (i = 0; i < def->ndisks; i++) { virDomainCheckpointDiskDefPtr disk = &def->disks[i]; @@ -434,7 +433,7 @@ qemuCheckpointPrepare(virQEMUDriverPtr driver, virReportError(VIR_ERR_CONFIG_UNSUPPORTED, _("bitmap for disk '%s' must match checkpoint name '%s'"), disk->name, def->parent.name); - goto cleanup; + return -1; } if (vm->def->disks[i]->src->format != VIR_STORAGE_FILE_QCOW2) { @@ -444,15 +443,11 @@ qemuCheckpointPrepare(virQEMUDriverPtr driver, disk->name, virStorageFileFormatTypeToString( vm->def->disks[i]->src->format)); - goto cleanup; + return -1; } } - ret = 0; - - cleanup: - VIR_FREE(xml); - return ret; + return 0; } static int -- 1.8.3.1

2 1

[libvirt-jenkins-ci PATCH] lcitool: Fix $PYTHON value in environment
by Andrea Bolognani 03 Apr '20

03 Apr '20

Starting with commit commit d76f41ece09b9aaf492553fe466c30a22c78e509 Author: Andrea Bolognani <abologna(a)redhat.com> Date: Fri Mar 27 17:21:26 2020 +0100 lcitool: Include paths in the inventory Figuring them out at runtime is neat, but in practice they don't change frequently enough for it to be necessary; more importantly, including them in the inventory means we can use them in the Dockerfile generator in addition to the Ansible playbooks. Signed-off-by: Andrea Bolognani <abologna(a)redhat.com> Reviewed-by: Daniel P. Berrangé <berrange(a)redhat.com> we have hardcoded the path of the Python interpreter to be used for builds in the inventory; an unforeseen consequence of this change is that Python builds on CentOS 7 have started failing. The reason for that is simple, but not immediately obvious. While on most target platforms we have a single Python interpreter installed, on CentOS 7 we still need two: Python 3 works fine when it comes to building projects, but it's missing a bunch of modules that Ansible needs to run, so we're stuck with Python 2 for Ansible use. This has worked fine for us so far. As part of the change above, however, due to a naming clash we have ended up in a situation where the bootstrap task, which installs a Python suitable for Ansible, overrides the Python intended for builds as set in the inventory. Of course this would result in breakages only on CentOS 7, where the two Pythons differ. Fix this by removing the runtime detection from the bootstrap task and storing the relevant information in the inventory. Signed-off-by: Andrea Bolognani <abologna(a)redhat.com> --- guests/host_vars/libvirt-centos-7/main.yml | 1 + guests/host_vars/libvirt-centos-8/main.yml | 1 + guests/host_vars/libvirt-debian-10/main.yml | 1 + guests/host_vars/libvirt-debian-9/main.yml | 1 + guests/host_vars/libvirt-debian-sid/main.yml | 1 + guests/host_vars/libvirt-fedora-30/main.yml | 1 + guests/host_vars/libvirt-fedora-31/main.yml | 1 + guests/host_vars/libvirt-fedora-rawhide/main.yml | 1 + guests/host_vars/libvirt-freebsd-11/main.yml | 1 + guests/host_vars/libvirt-freebsd-12/main.yml | 1 + guests/host_vars/libvirt-freebsd-current/main.yml | 1 + guests/host_vars/libvirt-opensuse-151/main.yml | 1 + guests/host_vars/libvirt-ubuntu-1604/main.yml | 1 + guests/host_vars/libvirt-ubuntu-1804/main.yml | 1 + guests/playbooks/update/tasks/bootstrap.yml | 11 +---------- 15 files changed, 15 insertions(+), 10 deletions(-) diff --git a/guests/host_vars/libvirt-centos-7/main.yml b/guests/host_vars/libvirt-centos-7/main.yml index f1fef44..104b702 100644 --- a/guests/host_vars/libvirt-centos-7/main.yml +++ b/guests/host_vars/libvirt-centos-7/main.yml @@ -30,4 +30,5 @@ python: /usr/bin/python3 su: /bin/su sudoers: /etc/sudoers +ansible_python_package: python2 ansible_python_interpreter: /usr/bin/python2 diff --git a/guests/host_vars/libvirt-centos-8/main.yml b/guests/host_vars/libvirt-centos-8/main.yml index 48edb78..441802c 100644 --- a/guests/host_vars/libvirt-centos-8/main.yml +++ b/guests/host_vars/libvirt-centos-8/main.yml @@ -30,4 +30,5 @@ python: /usr/bin/python3 su: /bin/su sudoers: /etc/sudoers +ansible_python_package: python3 ansible_python_interpreter: /usr/bin/python3 diff --git a/guests/host_vars/libvirt-debian-10/main.yml b/guests/host_vars/libvirt-debian-10/main.yml index 37036e6..e3aca55 100644 --- a/guests/host_vars/libvirt-debian-10/main.yml +++ b/guests/host_vars/libvirt-debian-10/main.yml @@ -32,4 +32,5 @@ python: /usr/bin/python3 su: /bin/su sudoers: /etc/sudoers +ansible_python_package: python3 ansible_python_interpreter: /usr/bin/python3 diff --git a/guests/host_vars/libvirt-debian-9/main.yml b/guests/host_vars/libvirt-debian-9/main.yml index b46efd1..0599aa4 100644 --- a/guests/host_vars/libvirt-debian-9/main.yml +++ b/guests/host_vars/libvirt-debian-9/main.yml @@ -32,4 +32,5 @@ python: /usr/bin/python3 su: /bin/su sudoers: /etc/sudoers +ansible_python_package: python3 ansible_python_interpreter: /usr/bin/python3 diff --git a/guests/host_vars/libvirt-debian-sid/main.yml b/guests/host_vars/libvirt-debian-sid/main.yml index 36045cd..565b0be 100644 --- a/guests/host_vars/libvirt-debian-sid/main.yml +++ b/guests/host_vars/libvirt-debian-sid/main.yml @@ -32,4 +32,5 @@ python: /usr/bin/python3 su: /bin/su sudoers: /etc/sudoers +ansible_python_package: python3 ansible_python_interpreter: /usr/bin/python3 diff --git a/guests/host_vars/libvirt-fedora-30/main.yml b/guests/host_vars/libvirt-fedora-30/main.yml index 71b8e7b..d31a84a 100644 --- a/guests/host_vars/libvirt-fedora-30/main.yml +++ b/guests/host_vars/libvirt-fedora-30/main.yml @@ -45,4 +45,5 @@ python: /usr/bin/python3 su: /bin/su sudoers: /etc/sudoers +ansible_python_package: python3 ansible_python_interpreter: /usr/bin/python3 diff --git a/guests/host_vars/libvirt-fedora-31/main.yml b/guests/host_vars/libvirt-fedora-31/main.yml index c692715..389cfac 100644 --- a/guests/host_vars/libvirt-fedora-31/main.yml +++ b/guests/host_vars/libvirt-fedora-31/main.yml @@ -33,4 +33,5 @@ python: /usr/bin/python3 su: /bin/su sudoers: /etc/sudoers +ansible_python_package: python3 ansible_python_interpreter: /usr/bin/python3 diff --git a/guests/host_vars/libvirt-fedora-rawhide/main.yml b/guests/host_vars/libvirt-fedora-rawhide/main.yml index bea4ad1..374cb4c 100644 --- a/guests/host_vars/libvirt-fedora-rawhide/main.yml +++ b/guests/host_vars/libvirt-fedora-rawhide/main.yml @@ -33,4 +33,5 @@ python: /usr/bin/python3 su: /bin/su sudoers: /etc/sudoers +ansible_python_package: python3 ansible_python_interpreter: /usr/bin/python3 diff --git a/guests/host_vars/libvirt-freebsd-11/main.yml b/guests/host_vars/libvirt-freebsd-11/main.yml index 7fbab39..c289221 100644 --- a/guests/host_vars/libvirt-freebsd-11/main.yml +++ b/guests/host_vars/libvirt-freebsd-11/main.yml @@ -31,4 +31,5 @@ python: /usr/local/bin/python3 su: /usr/bin/su sudoers: /usr/local/etc/sudoers +ansible_python_package: python3 ansible_python_interpreter: /usr/local/bin/python3 diff --git a/guests/host_vars/libvirt-freebsd-12/main.yml b/guests/host_vars/libvirt-freebsd-12/main.yml index abedd95..3bc3cc6 100644 --- a/guests/host_vars/libvirt-freebsd-12/main.yml +++ b/guests/host_vars/libvirt-freebsd-12/main.yml @@ -31,4 +31,5 @@ python: /usr/local/bin/python3 su: /usr/bin/su sudoers: /usr/local/etc/sudoers +ansible_python_package: python3 ansible_python_interpreter: /usr/local/bin/python3 diff --git a/guests/host_vars/libvirt-freebsd-current/main.yml b/guests/host_vars/libvirt-freebsd-current/main.yml index 9b0ba1f..02297e0 100644 --- a/guests/host_vars/libvirt-freebsd-current/main.yml +++ b/guests/host_vars/libvirt-freebsd-current/main.yml @@ -31,4 +31,5 @@ python: /usr/local/bin/python3 su: /usr/bin/su sudoers: /usr/local/etc/sudoers +ansible_python_package: python3 ansible_python_interpreter: /usr/local/bin/python3 diff --git a/guests/host_vars/libvirt-opensuse-151/main.yml b/guests/host_vars/libvirt-opensuse-151/main.yml index 3e674cc..656de36 100644 --- a/guests/host_vars/libvirt-opensuse-151/main.yml +++ b/guests/host_vars/libvirt-opensuse-151/main.yml @@ -31,4 +31,5 @@ python: /usr/bin/python3 su: /bin/su sudoers: /etc/sudoers +ansible_python_package: python3 ansible_python_interpreter: /usr/bin/python3 diff --git a/guests/host_vars/libvirt-ubuntu-1604/main.yml b/guests/host_vars/libvirt-ubuntu-1604/main.yml index 1eb2345..476d7ed 100644 --- a/guests/host_vars/libvirt-ubuntu-1604/main.yml +++ b/guests/host_vars/libvirt-ubuntu-1604/main.yml @@ -31,4 +31,5 @@ python: /usr/bin/python3 su: /bin/su sudoers: /etc/sudoers +ansible_python_package: python3 ansible_python_interpreter: /usr/bin/python3 diff --git a/guests/host_vars/libvirt-ubuntu-1804/main.yml b/guests/host_vars/libvirt-ubuntu-1804/main.yml index c9515b6..5a1ffcf 100644 --- a/guests/host_vars/libvirt-ubuntu-1804/main.yml +++ b/guests/host_vars/libvirt-ubuntu-1804/main.yml @@ -32,4 +32,5 @@ python: /usr/bin/python3 su: /bin/su sudoers: /etc/sudoers +ansible_python_package: python3 ansible_python_interpreter: /usr/bin/python3 diff --git a/guests/playbooks/update/tasks/bootstrap.yml b/guests/playbooks/update/tasks/bootstrap.yml index 2e1dc42..410fe66 100644 --- a/guests/playbooks/update/tasks/bootstrap.yml +++ b/guests/playbooks/update/tasks/bootstrap.yml @@ -4,14 +4,5 @@ when: - package_format == 'pkg' -- set_fact: - python: python3 - -- set_fact: - python: python2 - when: - - os_name == 'CentOS' - - os_version == '7' - - name: Bootstrap Ansible - raw: '{{ package_manager }} install -y {{ python }}' + raw: '{{ package_manager }} install -y {{ ansible_python_package }}' -- 2.25.1

2 1

[libvirt PATCH v2 0/6] daemons: Improve timeout handling, plus some cleanups
by Andrea Bolognani 03 Apr '20

03 Apr '20

Changes from [v1]: * move timeout setting from the service files to the sysconf files instead of the other way around; * remove obsolete KRB5_KTNAME override completely, including from OpenRC init scripts; * don't enable timeout for virtlogd, as it's not safe, and virtlockd, as it's probably safe but I messed this one up before so honestly why risk it. [v1] https://www.redhat.com/archives/libvir-list/2020-April/msg00030.html Andrea Bolognani (6): daemons: Support --timeout 0 systemd: Tweak existing sysconf files systemd: Add sysconf files for all daemons systemd: Move timeout from service files to sysconf files qemu: Allow audio driver override in virtqemud remote: Drop KRB5_KTNAME override libvirt.spec.in | 11 +++++++++++ src/interface/Makefile.inc.am | 2 ++ src/interface/virtinterfaced.service.in | 3 ++- src/interface/virtinterfaced.sysconf | 3 +++ src/libxl/Makefile.inc.am | 2 ++ src/libxl/virtxend.service.in | 3 ++- src/libxl/virtxend.sysconf | 3 +++ src/locking/lock_daemon.c | 6 +++--- src/locking/virtlockd.sysconf | 6 +++--- src/logging/log_daemon.c | 6 +++--- src/logging/virtlogd.sysconf | 6 +++--- src/lxc/Makefile.inc.am | 2 ++ src/lxc/virtlxcd.service.in | 3 ++- src/lxc/virtlxcd.sysconf | 3 +++ src/network/Makefile.inc.am | 2 ++ src/network/virtnetworkd.service.in | 3 ++- src/network/virtnetworkd.sysconf | 3 +++ src/node_device/Makefile.inc.am | 2 ++ src/node_device/virtnodedevd.service.in | 3 ++- src/node_device/virtnodedevd.sysconf | 3 +++ src/nwfilter/Makefile.inc.am | 2 ++ src/nwfilter/virtnwfilterd.service.in | 3 ++- src/nwfilter/virtnwfilterd.sysconf | 3 +++ src/qemu/Makefile.inc.am | 2 ++ src/qemu/virtqemud.service.in | 3 ++- src/qemu/virtqemud.sysconf | 12 ++++++++++++ src/remote/Makefile.inc.am | 5 ++++- src/remote/libvirtd.init.in | 1 - src/remote/libvirtd.sasl | 4 +--- src/remote/libvirtd.sysconf | 3 --- src/remote/remote_daemon.c | 6 +++--- src/remote/virtproxyd.init.in | 1 - src/remote/virtproxyd.service.in | 3 ++- src/remote/virtproxyd.sysconf | 3 +++ src/secret/Makefile.inc.am | 2 ++ src/secret/virtsecretd.service.in | 3 ++- src/secret/virtsecretd.sysconf | 3 +++ src/storage/Makefile.inc.am | 2 ++ src/storage/virtstoraged.service.in | 3 ++- src/storage/virtstoraged.sysconf | 3 +++ src/vbox/Makefile.inc.am | 2 ++ src/vbox/virtvboxd.service.in | 3 ++- src/vbox/virtvboxd.sysconf | 3 +++ src/vz/Makefile.inc.am | 2 ++ src/vz/virtvzd.service.in | 3 ++- src/vz/virtvzd.sysconf | 3 +++ tools/libvirt-guests.sysconf | 2 ++ 47 files changed, 124 insertions(+), 36 deletions(-) create mode 100644 src/interface/virtinterfaced.sysconf create mode 100644 src/libxl/virtxend.sysconf create mode 100644 src/lxc/virtlxcd.sysconf create mode 100644 src/network/virtnetworkd.sysconf create mode 100644 src/node_device/virtnodedevd.sysconf create mode 100644 src/nwfilter/virtnwfilterd.sysconf create mode 100644 src/qemu/virtqemud.sysconf create mode 100644 src/remote/virtproxyd.sysconf create mode 100644 src/secret/virtsecretd.sysconf create mode 100644 src/storage/virtstoraged.sysconf create mode 100644 src/vbox/virtvboxd.sysconf create mode 100644 src/vz/virtvzd.sysconf -- 2.25.1

2 12

[PATCH] maint: Post-release version bump to 6.3.0
by Peter Krempa 03 Apr '20

03 Apr '20

Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- configure.ac | 2 +- docs/news.xml | 8 ++++++++ 2 files changed, 9 insertions(+), 1 deletion(-) Pushed. diff --git a/configure.ac b/configure.ac index e565437062..10573497fa 100644 --- a/configure.ac +++ b/configure.ac @@ -16,7 +16,7 @@ dnl You should have received a copy of the GNU Lesser General Public dnl License along with this library. If not, see dnl <http://www.gnu.org/licenses/>. -AC_INIT([libvirt], [6.2.0], [libvir-list(a)redhat.com] [], [https://libvirt.org] +AC_INIT([libvirt], [6.3.0], [libvir-list(a)redhat.com] [], [https://libvirt.org] if test $srcdir = "." then diff --git a/docs/news.xml b/docs/news.xml index 30de995a7c..0d3f3386ec 100644 --- a/docs/news.xml +++ b/docs/news.xml @@ -42,6 +42,14 @@ --> <libvirt> + <release version="v6.3.0" date="unreleased"> + <section title="New features"> + </section> + <section title="Improvements"> + </section> + <section title="Bug fixes"> + </section> + </release> <release version="v6.2.0" date="2020-04-02"> <section title="New features"> <change> -- 2.25.1

1 0

[PATCH v4 0/7] Tighten qemu-img rules on missing backing format
by Eric Blake 02 Apr '20

02 Apr '20

3 14

Release of libvirt-6.2.0
by Daniel Veillard 02 Apr '20

02 Apr '20

Mea-culpa I forgot to push RC2 on Tuesday, rather than pushing the release off by 2 more days, I decided to push the release today to stay on schedule. As a result 6.2.0 is out, tagged in git and source tarball and rpm are available at the usual place: https://libvirt.org/sources/ I also pushed a release of the python binding with minimal changes that can be found at: https://libvirt.org/sources/libvirt/ New features: - qemu: NVDIMM support for pSeries guests QEMU 5.0 implements NVDIMM memory support for pSeries guests. This is done by adding an 'uuid' element in the memory XML, which can either be provided in the XML or, if omitted, generated automatically. - qemu: Add virtiofs support This feature, introduced in QEMU 4.2, is a more modern alternative to virtio-9p, which is exposed through the same <filesystem/> element. - admin: Support reloading TLS certificates After renewing TLS certificates, it was usually necessary to restart libvirtd for the new ones to be loaded: now the same result can be obtained without restarting the daemon by using virt-admin server-update-tls. Removed features: - Removed support for INI style of comments With switching of our internal code to GLib, parsing of client authentication config files is handed over to GLib which does not support INI style of comments starting with a semicolon (;). Use number sign (#) instead. * Improvements - qemu: Don't compare local and remote hostnames on migration This check was introduced to prevent same-host migration, but did not work as expected when multiple libvirtd instances were running on the same host but in different containers. With this release, the host UUID (which should be unique to the container) is checked instead. - qemu: Use per-VM event loops Instead of using a single even loop to process communication with the QEMU monitor and guest agent, create a separate one for each VM. This helps with scalability and prevents scenarios where a single malfunctioning VM could affect all those running on the same host. - qemu: Support migration with SLIRP helper interface With QEMU 5.0, a new D-Bus backend allows migration of external processes. When needed, libvirt will start a per-vm D-Bus bus, and migrate the slirp-helper along with QEMU. Bug fixes: - qemu: Open backing chain late for shallow block copy reusing external images With introduction of -blockdev for QEMU storage configuration in libvirt-5.10 we've started opening the backing chain of the destination/mirror of a virDomainBlockcopy started with VIR_DOMAIN_BLOCK_COPY_REUSE_EXT | VIR_DOMAIN_BLOCK_COPY_SHALLOW flags when starting the job rather than when virDomainBlockJobAbort with VIR_DOMAIN_BLOCK_JOB_ABORT_PIVOT is issued. For users depending on this undocumented quirky pre-blockdev behaviour this caused a regression as the backing chain could not be modified while the copy of the top image was progressing due to QEMU image locking. Note that this fix also requires qemu-5.0 while -blockdev is used starting from QEMU-4.2. - Don't generate machine names containing dots Even though the guest name containing dots is not a problem for libvirt itself, we need to strip them out when registering with machined because of the latter's requirements. Thanks everybody who contributed to this release be it with bug reports, fixes, reviews, documentation, etc ... Enjoy the release, stay safe! 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/

1 0

SRPMs as download artifacts (was: Re: libvirt Source RPMs for CentOS or RHEL?)
by Andrea Bolognani 02 Apr '20

02 Apr '20

[moving to libvir-list] On Thu, 2020-04-02 at 09:41 +0100, Daniel P. Berrangé wrote: > On Thu, Apr 02, 2020 at 08:47:30AM +0800, FuLong Wang wrote: > > Do we have libvirt source rpms (version above 5.9.0) for CentOS or RHEL? > > > > I only find source rpms for fedora in below public link. > > > > https://libvirt.org/sources/ > > Please ignore all the RPMs you see there, they really shouldn't be > used. Can we just stop generating them? And get rid of all the existing ones, especially silly stuff like the binary RPMs from 2013 targeting Fedora 17. This will have the additional benefit of making it easier to find what you're looking for, since it will no longer be hidden among a heap of irrelevant garbage. > The source tarballs (eg libvirt-5.9.0.tar.xz) contain a spec file > inside. > > This means you can generate RPMs for your precise distro using something > akin to the following commands: > > $ rpmbuild -ts libvirt-5.9.0.tar.xz > $ sudo dnf install redhat-rpm-config > $ sudo dnf builddep $HOME/rpmbuild/SRPMS/libvirt-5.9.0-1.fc31.src.rpm > $ rpmbuild --rebuild $HOME/rpmbuild/SRPMS/libvirt-5.9.0-1.fc31.src.rpm I think it would make sense to document this quick procedure somewhere, if we haven't already. There's some obvious overlap with our 'make rpm' target, but that one requires unpacking the release archive and running configure beforehand, so it's not quite as nice for someone who just wants to quickly get a working set of RPMs. -- Andrea Bolognani / Red Hat / Virtualization

2 2

disable passwd access to spice and specify disable-ticketing
by Vasiliy Tolstov 02 Apr '20

02 Apr '20

Hi! i need to have passwordless auth to spice (because it is restricted to 127.0.0.1 and nobody can connect to it, in feature i want to use it via unix socket). I'm checking docs at libvirt site and don't see any disable-ticketing options. SO how can I pass this option and allow access without a password to spice? Thanks! -- Vasiliy Tolstov, e-mail: v.tolstov(a)selfip.ru

2 2

request: wiki account
by Sebastian Mitterle 02 Apr '20

02 Apr '20

As mentioned on https://wiki.libvirt.org/page/Main_Page I'd like to request a wiki account for contributions on wiki.libvirt.org Preferred username: smitterl Thank you in advance, Sebastian

1 0

[libvirt PATCH 0/8] daemons: Improve timeout handling, plus some cleanups
by Andrea Bolognani 02 Apr '20

02 Apr '20

The main motivation for this series is explained in patch 2/8, but of course in the process I managed to locate a number of yaks that were looking quite hairy indeed... Andrea Bolognani (8): daemons: Support --timeout 0 Revert "remote: move timeout arg into sysconf file" Revert "logging: Use default timeout of 120 seconds for virtlogd" logging, locking: Set default timeout of 120 seconds Add sysconf files for all daemons spec: Include new sysconf files qemu: Allow audio driver override in virtqemud remote: Drop KRB5_KTNAME override libvirt.spec.in | 11 +++++++++++ src/interface/Makefile.inc.am | 2 ++ src/interface/virtinterfaced.service.in | 3 ++- src/interface/virtinterfaced.sysconf | 3 +++ src/libxl/Makefile.inc.am | 2 ++ src/libxl/virtxend.service.in | 3 ++- src/libxl/virtxend.sysconf | 3 +++ src/locking/lock_daemon.c | 6 +++--- src/locking/virtlockd.service.in | 2 +- src/logging/log_daemon.c | 6 +++--- src/logging/virtlogd.service.in | 2 +- src/logging/virtlogd.sysconf | 2 +- src/lxc/Makefile.inc.am | 2 ++ src/lxc/virtlxcd.service.in | 3 ++- src/lxc/virtlxcd.sysconf | 3 +++ src/network/Makefile.inc.am | 2 ++ src/network/virtnetworkd.service.in | 3 ++- src/network/virtnetworkd.sysconf | 3 +++ src/node_device/Makefile.inc.am | 2 ++ src/node_device/virtnodedevd.service.in | 3 ++- src/node_device/virtnodedevd.sysconf | 3 +++ src/nwfilter/Makefile.inc.am | 2 ++ src/nwfilter/virtnwfilterd.service.in | 3 ++- src/nwfilter/virtnwfilterd.sysconf | 3 +++ src/qemu/Makefile.inc.am | 2 ++ src/qemu/virtqemud.service.in | 3 ++- src/qemu/virtqemud.sysconf | 12 ++++++++++++ src/remote/Makefile.inc.am | 5 ++++- src/remote/libvirtd.sasl | 4 +--- src/remote/libvirtd.service.in | 6 +++++- src/remote/libvirtd.sysconf | 15 +++------------ src/remote/remote_daemon.c | 6 +++--- src/remote/virtproxyd.service.in | 3 ++- src/remote/virtproxyd.sysconf | 3 +++ src/secret/Makefile.inc.am | 2 ++ src/secret/virtsecretd.service.in | 3 ++- src/secret/virtsecretd.sysconf | 3 +++ src/storage/Makefile.inc.am | 2 ++ src/storage/virtstoraged.service.in | 3 ++- src/storage/virtstoraged.sysconf | 3 +++ src/vbox/Makefile.inc.am | 2 ++ src/vbox/virtvboxd.service.in | 3 ++- src/vbox/virtvboxd.sysconf | 3 +++ src/vz/Makefile.inc.am | 2 ++ src/vz/virtvzd.service.in | 3 ++- src/vz/virtvzd.sysconf | 3 +++ 46 files changed, 127 insertions(+), 41 deletions(-) create mode 100644 src/interface/virtinterfaced.sysconf create mode 100644 src/libxl/virtxend.sysconf create mode 100644 src/lxc/virtlxcd.sysconf create mode 100644 src/network/virtnetworkd.sysconf create mode 100644 src/node_device/virtnodedevd.sysconf create mode 100644 src/nwfilter/virtnwfilterd.sysconf create mode 100644 src/qemu/virtqemud.sysconf create mode 100644 src/remote/virtproxyd.sysconf create mode 100644 src/secret/virtsecretd.sysconf create mode 100644 src/storage/virtstoraged.sysconf create mode 100644 src/vbox/virtvboxd.sysconf create mode 100644 src/vz/virtvzd.sysconf -- 2.25.1

4 32

[PATCH 0/2] Optimize initialization of storage files
by Peter Krempa 02 Apr '20

02 Apr '20

See 2/2. Peter Krempa (2): qemuSecurityChownCallback: Remove 'cleanup' section qemuSecurityChownCallback: Don't initialize storage file subsystem for local file src/qemu/qemu_driver.c | 31 +++++++++++++------------------ 1 file changed, 13 insertions(+), 18 deletions(-) -- 2.24.1

2 4

[PATCH 0/5] qemu: caps: Bump capabilities to qemu-5.0.0-rc1
by Peter Krempa 02 Apr '20

02 Apr '20

Peter Krempa (5): qemumonitorjsontest: Space out test name concatenation qemuMonitorTestProcessCommandDefaultValidate: Output validator output to stderr qemumonitorjsontest: AddNetdev: Use real variant syntax-check: Exempt tests/qemucapabilitiesdata from 'sc_prohibit_devname' qemu: capabilities: Update qemu-5.0.0 capabilities for x86_64 to rc1 build-aux/syntax-check.mk | 2 +- .../caps_5.0.0.x86_64.replies | 2314 +++++++++++------ .../caps_5.0.0.x86_64.xml | 144 +- tests/qemumonitorjsontest.c | 6 +- tests/qemumonitortestutils.c | 13 +- 5 files changed, 1707 insertions(+), 772 deletions(-) -- 2.25.1

2 6

[PATCH 0/3] Fix use-after-free in block job reconnection code
by Peter Krempa 02 Apr '20

02 Apr '20

Peter Krempa (3): qemu: migration: Don't use return value of qemuBlockJobUpdate qemuBlockJobUpdate: Remove return value qemuBlockJobRefreshJobs: Warn readers that 'job' may be invalid after update src/qemu/qemu_blockjob.c | 9 +++------ src/qemu/qemu_blockjob.h | 7 ++++--- src/qemu/qemu_migration.c | 17 +++++++---------- 3 files changed, 14 insertions(+), 19 deletions(-) -- 2.24.1

3 7

[PATCH for 6.2.0] qemuDomainSnapshotDiskPrepareOne: Fix logic of relative backing store update
by Peter Krempa 02 Apr '20

02 Apr '20

Commit 2ace7a87a8aced68c250 introduced a logic bug by an improperly modified condition where we'd skip to the else branch when reusing of external images was requested and blockdev is available. The original intentions were to skip the backing store update with blockdev. Fix it by only asserting the boolean which was used to track whether we support update of the backing store only when blockdev is not present along with the appropriate rename. https://bugzilla.redhat.com/show_bug.cgi?id=1820016 Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- src/qemu/qemu_driver.c | 19 +++++++++++-------- 1 file changed, 11 insertions(+), 8 deletions(-) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 78024614cf..ff97f10f11 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -15129,7 +15129,7 @@ qemuDomainSnapshotDiskPrepareOne(virQEMUDriverPtr driver, { virDomainDiskDefPtr persistdisk; bool supportsCreate; - bool supportsBacking; + bool updateRelativeBacking = false; dd->disk = disk; @@ -15158,19 +15158,22 @@ qemuDomainSnapshotDiskPrepareOne(virQEMUDriverPtr driver, } supportsCreate = virStorageFileSupportsCreate(dd->src); - supportsBacking = virStorageFileSupportsBackingChainTraversal(dd->src); - if (supportsCreate || supportsBacking) { + /* relative backing store paths need to be updated so that relative + * block commit still works. With blockdev we must update it when doing + * commit anyways so it's skipped here */ + if (!blockdev && + virStorageFileSupportsBackingChainTraversal(dd->src)) + updateRelativeBacking = true; + + if (supportsCreate || updateRelativeBacking) { if (qemuDomainStorageFileInit(driver, vm, dd->src, NULL) < 0) return -1; dd->initialized = true; - /* relative backing store paths need to be updated so that relative - * block commit still works. With blockdev we must update it when doing - * commit anyways so it's skipped here */ - if (reuse && !blockdev) { - if (supportsBacking) { + if (reuse) { + if (updateRelativeBacking) { g_autofree char *backingStoreStr = NULL; if (virStorageFileGetBackingStoreStr(dd->src, &backingStoreStr) < 0) -- 2.25.1

2 1

Re: [PATCH 5/5] cpu: Introduce getHost supoort for ARM
by Daniel P. Berrangé 02 Apr '20

02 Apr '20

Re-adding libvir-list to the CC line. On Mon, Mar 30, 2020 at 08:20:44PM +0800, Zhenyu Zheng wrote: > Hi, yes, I think we can do that using inline assembly, I can check it out > if you think it is a better solution, > do you have any suggestions for the features(cpu flags) part? It seems that > ARM does not have a location/register > that holds all the flags, seems that we have to query alot of different > registers to check for features, which could > be quite messy. Perhaps there is a way to record the location/register info in the XML against each feature name, so that the code itself can stay simple and just be driven from the metadata ? I'm not familiar enough with Arm to know how feasiable this is though, so will have to leave that to others to give an opinion. > > On Mon, Mar 30, 2020 at 8:01 PM Daniel P. Berrangé <berrange(a)redhat.com> > wrote: > > > On Mon, Mar 30, 2020 at 07:32:36PM +0800, Zhenyu Zheng wrote: > > > Hi Daniel, > > > > > > Thanks for thre review and reply, my first implementation was going to > > > gather data from /proc/cpuinfo, but unlike X86, we can only get this kind > > > of info: > > > > > > processor : 0 > > > BogoMIPS : 200.00 > > > Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid > > > CPU implementer : 0x43 > > > CPU architecture: 8 > > > CPU variant : 0x1 > > > CPU part : 0x0a1 > > > CPU revision : 1 > > > > > > so we have to perform some translation to perform human readable > > > information, and I mentioned that 'lscpu' has done that too. So Andrea > > > Bolognani > > > suggested that maybe we can use it directly, to avoid re-implement the > > > translation. Here is the discussion: > > > https://www.redhat.com/archives/libvir-list/2020-March/msg00812.html > > > > On x86 we get majority of info straight from calling the CPUID instruction, > > not /proc/cpuinfo, and use our XML data files in src/cpu_map to translate > > things into human readable names. I see you're adding XML data files > > with names in the earlier patches. Is it possible to add the hex values > > for the CPU implementer/architecture/variant/part to these XML files so > > we can directly map them in libvirt, in the same way we do for x86 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 :|

2 1

[PATCH] news: Document recent dbus-vmstate changes
by Michal Privoznik 01 Apr '20

01 Apr '20

Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- docs/news.xml | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/docs/news.xml b/docs/news.xml index 7ef18cf7b8..37b7fd9bba 100644 --- a/docs/news.xml +++ b/docs/news.xml @@ -114,6 +114,17 @@ malfunctioning VM could affect all those running on the same host. </description> </change> + <change> + <summary> + qemu: Support migration with SLIRP interface + </summary> + <description> + As <code>libslirp</code> evolves, so does QEMU. The recent change is + that instead of peer-to-peer connection between QEMU and + <code>slirp-helper</code> process a separate D-BUS bus is created. + This enables QEMU to migrate with a SLIRP interface. + </description> + </change> </section> <section title="Bug fixes"> <change> -- 2.24.1

4 4

[libvirt PATCH 0/4] AUTHORS: assorted improvements
by Ján Tomko 01 Apr '20

01 Apr '20

Ján Tomko (4): AUTHORS: s/Authors/authors/ AUTHORS: use slashes for Andrea's e-mail address AUTHORS: add some emojis AUTHORS: remove myself AUTHORS.in | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) -- 2.25.1

2 5

[libvirt PATCH] news: Update for libvirt 6.2.0
by Andrea Bolognani 01 Apr '20

01 Apr '20

Signed-off-by: Andrea Bolognani <abologna(a)redhat.com> --- docs/news.xml | 54 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 54 insertions(+) diff --git a/docs/news.xml b/docs/news.xml index bcec1d81e9..7ef18cf7b8 100644 --- a/docs/news.xml +++ b/docs/news.xml @@ -55,6 +55,27 @@ automatically. </description> </change> + <change> + <summary> + qemu: Add virtiofs support + </summary> + <description> + This feature, introduced in QEMU 4.2, is a more modern alternative + to virtio-9p, which is exposed through the same + <code><filesystem/></code> element. + </description> + </change> + <change> + <summary> + admin: Support reloading TLS certificates + </summary> + <description> + After renewing TLS certificates, it was usually necessary to restart + libvirtd for the new ones to be loaded: now the same result can be + obtained without restarting the daemon by using <code>virt-admin + server-update-tls</code>. + </description> + </change> </section> <section title="Removed features"> <change> @@ -70,6 +91,29 @@ </change> </section> <section title="Improvements"> + <change> + <summary> + qemu: Don't compare local and remote hostnames on migration + </summary> + <description> + This check was introduced to prevent same-host migration, but did + not work as expected when multiple libvirtd instances were running + on the same host but in different containers. With this release, the + host UUID (which should be unique to the container) is checked + instead. + </description> + </change> + <change> + <summary> + qemu: Use per-VM event loops + </summary> + <description> + Instead of using a single even loop to process communication with + the QEMU monitor and guest agent, create a separate one for each VM. + This helps with scalability and prevents scenarios where a single + malfunctioning VM could affect all those running on the same host. + </description> + </change> </section> <section title="Bug fixes"> <change> @@ -90,6 +134,16 @@ QEMU-4.2. </description> </change> + <change> + <summary> + Don't generate machine names containing dots + </summary> + <description> + Even though the guest name containing dots is not a problem for + libvirt itself, we need to strip them out when registering with + machined because of the latter's requirements. + </description> + </change> </section> </release> <release version="v6.1.0" date="2020-03-03"> -- 2.25.1

2 1

[PATCH 0/2] qemu: Fix two checkpoint redefine issues
by Peter Krempa 01 Apr '20

01 Apr '20

Peter Krempa (2): qemu: checkpoint: Allow checkpoint redefine for offline VMs virDomainCheckpointRedefinePrep: Set 'current' checkpoint if there isn't any src/conf/checkpoint_conf.c | 4 ++++ src/qemu/qemu_checkpoint.c | 20 +++++++++++--------- 2 files changed, 15 insertions(+), 9 deletions(-) -- 2.25.1

2 4

[libvirt PATCH 0/3] qemu: s390: fix disk error policy with blockdev
by Ján Tomko 01 Apr '20

01 Apr '20

https://bugzilla.redhat.com/show_bug.cgi?id=1819250 Ján Tomko (3): tests: qemu: add disk-error-policy tests for s390x qemu: add QEMU_CAPS_STORAGE_WERROR qemu: use QEMU_CAPS_STORAGE_WERROR for disk-error attributes src/qemu/qemu_capabilities.c | 8 ++++ src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 4 +- .../caps_2.10.0.s390x.xml | 1 + .../caps_2.11.0.s390x.xml | 1 + .../caps_2.12.0.s390x.xml | 1 + .../qemucapabilitiesdata/caps_2.7.0.s390x.xml | 1 + .../qemucapabilitiesdata/caps_2.8.0.s390x.xml | 1 + .../qemucapabilitiesdata/caps_2.9.0.s390x.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 + .../disk-error-policy-s390x.s390x-2.12.0.args | 42 ++++++++++++++++++ .../disk-error-policy-s390x.s390x-latest.args | 43 +++++++++++++++++++ .../disk-error-policy-s390x.xml | 37 ++++++++++++++++ tests/qemuxml2argvtest.c | 2 + 33 files changed, 161 insertions(+), 2 deletions(-) create mode 100644 tests/qemuxml2argvdata/disk-error-policy-s390x.s390x-2.12.0.args create mode 100644 tests/qemuxml2argvdata/disk-error-policy-s390x.s390x-latest.args create mode 100644 tests/qemuxml2argvdata/disk-error-policy-s390x.xml -- 2.25.1

2 4

[GSoC][RPC] Project Proposal: "Introducing Job control to the storage driver"
by Prathamesh Chavan 31 Mar '20

31 Mar '20

GSoC Proposal - 2020 ==================== Project Name: Introducing Job control to the storage driver =========================================================== About Me: ========= Name: Prathamesh Chavan University: Indian Institute of Technology Kharagpur Major: Computer Science and Engineering(Dual Degree) Email: pc44800(a)gmail.com Blog: pratham-pc.github.io Contact: +91-993-235-8333 Time Zone: IST (UTC +5:30) Background: =========== I am a final year dual degree (B.Tech & M.Tech) student from the Department of Computer Science and Engineering at IIT Kharagpur. During my first year of college, I got introduced to open source through Kharagpur Open Source Society and later I became part of it. As my master's thesis project, I'm working on a tiered file system with Software Wear Management for NVM Technologies. I always wanted to get involved in storage technologies and the development process and Google Summer of Code is a great way to achieve it. I've been part of Google Summer of code in my second year of college under the Git Organization. It was my first experience with a large codebase. Information related to it is available in GSoC - 2017's archive[1]. Last year summers, I also interned at Nutanix. I worked on Logbay, which is a configuration-based data collection, archiving and streaming tool used by all services on Nutanix Controller-VM (CVM). I added multi-platform support to Logbay by identifying all the dependencies of Logbay on the other CVM based services and introduced an interface between these dependencies and Logbay-Core for allowing it to be used on different platforms where they aren’t available. I also implemented the interface on a Dev-VM and added multi-port support in it for allowing multiple instances of Logbay to run on a single Dev-VM to simulate a multi-node cluster which allowed the developers to test their changes on their Dev-VM itself. The Project: ============ Introducing job control to the storage driver Summary: Implement abstract job control and use it to improve storage driver. Mentor: Pavel Hrdina Abstract: ========= Currently, libvirt support job cancellation and progress reporting on domains. That is, if there's a long-running job on a domain, e.g. migration, libvirt reports how much data has already been transferred to the destination and how much still needs to be transferred. However, libvirt lacks such information reporting in storage area, to which libvirt developers refer to as the storage driver. The aim is to report progress on several storage tasks, like volume wiping, file allocation an others. Job Control in Domain: ====================== In src/qemu/qemu_domain.h, we can find the struct qemuDomainJobObj, which is a job object in domains, and is used for: coordinating between jobs, help identify which API call owns the job object, and contain rest additional info regarding the normal job/agent job/async job. This qemuDomainJobObj is part of another struct qemuDomainObjPrivate, which majorly is the object, the driver's API majorly interacts with which calling jobs on. Whenever an API call is made, depending upon the type of the job, specific locks are acquired and then the job is carried out. Exact design details regarding the implementation of such APIs are present in `src/qemu/THREADS.txt`. Job Control in Storage: ======================= Whenever an API call is made to a storageVol, the member `in_use` of the struct `virStorageVolDef` is used as a reference counter. This allows us to check whether the storage volume is already in use or not, and whether the current API call can be carried out. Once the API call exits, the reference counter is decremented. Reporting of job-progress as done in case of Domains: ===================================================== Additionally, when an async job is running: it also contains qemuDomainJobInfo: which stores the progress data of the async job, and an another qemuDomainJobInfo stores the statistics data of a recently completed job. Functions virDomainGetJobInfo() and virDomainGetJobStats() present in libvirt-domain.c help extract information about progress of a background job on a domain. Plan to implement something similar in Storage Jobs: ==================================================== Firstly, it's important to bring in the notion of jobs to the storage driver. Right now the API calls get directly executed if the required mutex locks are acquired. But this gives the rest of the API calls less information about what is running currently or has the locks acquired. Further, the domain jobs additionally contain a lot of information which can even be useful in case of the storage API calls. Firstly, identification of what all API calls are occurring on Storage Volumes in storage driver, and classifying them into something similar to normal jobs and async jobs (the long-running ones). Also, some of the API calls will not be acquiring a job (ones which didn't change the reference counter). After this, a document similar to src/qemu/THREADS.txt needs to be created for storage job handling and should mention the new design of the existing storage APIs, acquiring jobs and appropriate locks as required. Additional new APIs need to be implemented for the creation, deletion of storage jobs. These would be similar to the domain job API present in qemu/qemu_domain.h such as qemuDomainObjBeginJob(), etc. This specifically also included storage equivalent functions of virDomainGetJobInfo() and virDomainGetJobStats(). These would be used by the long-running storage jobs to report completion progress. Existing storage API needs to be implemented with this new job notion and the reference counter member 'in_use' be removed. Other desired changes: ====================== 1. Unification of the notion of jobs throughout: one of the steps taking keeping this in mind could be to have the storage job API implementation as close to the domain job API, so that later on unification would be easier. Unification, IMO, is left in the future scope of the project. 2. Prediction of time-remaining for job completion as the progress for various jobs is reported. BiteSizedTask attempted: ======================== Clean up variables in tools/libvirt-guests.sh.in Mentor: Martin Kletzander A patch was floated on the mailing list and its latest version can be found here[2]. Rest of the plans for the summers: ================================== Due to the on-going COVID-19 Pandemic, my internship was canceled. Hence, I'll be available full-time for the project. In August, I'll be joining Nutanix as a Full-time Employee. PS: === 1. It was already very late by the I decided to take part in GSoC'20. Hence, I wasn't able to give the required amount of time for preparing this project's proposal. If it would be okay, I'll still like to keep updating this proposal after the deadline and add a few important things, such as solid project deliverables along with a timeline. 2. As Pavel Hrdina is the mentor of this project, and as this project was suggested by Michal Privoznik, I've cc'd both of them to this email. 3. Since I still haven't spent enough time understanding the details of the existing APIs, I might have gone wrong at a few places, and I would be glad to have them pointed out. 4. One of the mentioned requirements according to libvirt's GSoC FAQ page[3] is passing an interview. When does this interview typically take place, in the GSoC timeline? 5. A google-doc of this proposal can be found here[4]. Comments on the doc are welcomed. [1]: https://summerofcode.withgoogle.com/archive/2017/projects/5434523185577984/ [2]: https://www.redhat.com/archives/libvir-list/2020-March/msg01303.html [3]: https://wiki.libvirt.org/page/Google_Summer_of_Code_FAQ [4]: https://docs.google.com/document/d/1Js-yi1oNrl9fRhzvMJwBHyygYCAtr_q7Bby8k1j…

2 4

On the need to move to a merge request workflow
by Daniel P. Berrangé 31 Mar '20

31 Mar '20

We've discussed the idea of replacing our mailing list review workflow with a merge request workflow in various places, over the last 6 months or so, but never made a concrete decision. I understand that some people will not like the idea of using merge requests. It is ok to feel that way, however, we need to consider the bigger picture and be open to learning to make the most of the opportunities, even if we don't like certain things about the tools. We need to recognise that there are millions of open source developers who are successfully delivering code using the merge request workflow, and we are just as capable as them. To claim that merge requests won't/can't work for libvirt, means there is something unique about the libvirt project's needs, and/or all those other developers are doing a worse job than libvirt developers, and/or libvirt developers are incapable of using tools that everyone else copes with. I don't believe any of those points are true. While it is certainly possible to come up with a list of points why we might like mailing lists, on aggregate merge requests will be the better solution. There are examples of high profile projects moving to a git forge based workflow and new projects use them as a first choice. If mailing lists were truly the better approach, then there would be a notable flow of projects moving away from merge requests, back to mailing lists. There is no evidence of a trend towards mailing list workflows. Short summary ============= This has quickly become another very long email to read though, so I'll attempt a summary * The need to attract new contributors is critical to the long term health of the project. Since 2016 the number of new contributors has dropped 50% from 80-90 per year, down to just 40-45 in 2019. * The current libvirt mailing lists are suffering from unreliable delivery. Some contributors are unable to send. Other contributors are unable to receive. * The contributors affected by the problems have very limited ability to resolve the problem they have, aside from opening tickets or changing email providers entirely. * A mail workflow relies on all contributors agreeing on the conventions to use when sending & replying to messages. Many of these conventions are unwritten and impose a burden for new contributors, discouraging their participation. * A mail workflow has many problems even for long term contributors, most notably with keeping track of what mails are outstanding. Each person has invented their own solution to deal with the lack of central tracking and they are all flawed & duplicating time on triage. * A merge request workflow has a lower barrier to participation for new contributors to the project, by making libvirt use commonly found workflow for OSS projects. * A merge request workflow is technically capable of supporting projects of equal size, or greater, than libvirt which deliver features at an equivalent speed. There is nothing special or unique about libvirts needs. See KDE, GNOME, SystemD, Kubernetes, OpenShift, to name just a few * Trying to directly match each aspect of a developer's current mail setup to a merge request workflow is not practical. They are inherantly different tools with differing capabilities which will never map 1:1 in all cases. * The largest barrier to a change is not technical, but the relative lack of experience & familiarity with the tools. This can only be solved by using them in a real world environment. A period of productivity disruption is inevitable while learning to optimize use of the new tools. * A merge request workflow is better for new or infrequent contributors, and in the long term is certainly usable for frequent contributors. Switching to merge requests is thus better on aggregate, and with experience/hindsight may well turn out better for everyone. With the last few points in mind in particular, the idea is to not do a big bang switchover of everything at once, but instead split it into phases. Initially the focus is to be on all the non-core projects, which means the language bindings, application integrations, and supporting tools. After those are all switched successfully, highlighting any areas of difficulty and allowing for some learning/adaptation, the main libvirt.git would be switched over. The non-core projects can be switched more or less immediately as their review demands are much lower. It is anticipated that the timeframe for everything would be on the order of 3-6 months, at the max. The long story ============== The measurement question ------------------------ The key motivation behind this proposal is that it will make libvirt a more attractive project for new contributors. The quotes later illustrate real world cases where our use of email workflow has hurt contributors. These are just the cases we have become aware of from people who were motivated enough to continue their effort despite the barriers faced. It is an unknown how many more people faced similar barriers and just walked away without us knowing. It has been suggested in the past that we run both workflows in parallel as a way to test which is better. I don't believe such an approach will provide valid data. Splitting attention between two different tools will be detrimental to the effectiveness of both tools. It would be an unbalanced comparison because there is no practical way to compare both tools with the same data set unless we wish to review all patch series twice. In addition the timeframes needed for a meaningful comparison would be too long, spanning 1+ years to gather statistically significant data on contribution. If a merge request workflow was a new, unproven concept, then it would none the less be worth trying to do a comparison, however, difficult. This is not the case though, merge request workflows have been around many years & proven viable. There is nothing special about the libvirt project or developers skills that would invalidate this track record. Thus this mail will look at various aspects of the tools and consider how they impact our work, with a particular focus on issues which negatively impact new contributors, or which have a discriminatory effect on certain subsets of new or existing contributors. Contributors decline -------------------- Since 2016 libvirt has seen a significant decline in the number of new authors contributing patches to the project. This is illustrated in the 3rd slide from this KVM Forum presentation: http://people.redhat.com/berrange/kvm-forum-2019/kvm-forum-2019-libvirt.pdf For the data behind this graph, the commits to all GIT repos on libvirt.git were analysed, taking the year recorded for the git changeset author date. The email addresses were recorded each year, and a "new contributor" was considered to be someone who had never made a commit in any previous calendar year. We can see the project grew quite fast until about 2011 and then levelled out with a reasonably consistent number of long term vs new contributors. Since 2016, however, there has been a clear declining trend. The raw data shows for the last two years, the non-core git repos in particular saw a big decline, however, the same is also seen for libvirt.git itself. There is likely no single factor responsible for this decline. A combination of interest in containers instead of VMs, and maturity of the codebase likely play a fairly large part. None the less, the decline of new contributors is highly undesirable, whatever the reason, as there is still plenty of work that needs doing in libvirt. Thus steps need to be taken to make libvirt more attractive to new contributors. Lowering the barrier to entry for contributors is one key aspect to this. New contributor mistakes ------------------------ Some of the mistakes new users are liable to make when dealing with patch submissions * HTML mail instead of plain text * Mangled patches due to mail client breaking long lines * Incorrectly threaded patch series * Not labelling series with version numbers * Sending plain ‘diff’ output instead of a git patch * Not basing the patch on recent git master * Not subscribing to the list before posting * Corporate legal privacy / copyright signatures * Unintelligible mail quoting in replies (Outlook) We've tried to steer people towards git-publish, as that has encoded many of the conventions to prevent mistakes, but that is by no means a foolproof solution. It still requires setup and a working mail server, as well as following git best practice wrt branch usage. New contributor real experiences -------------------------------- Some quotes on this theme that I've collected from just the last three months. I'm removing the names as this isn't about the individuals involved, rather their first / early impressions & experience of libvirt: "I have sent the patches to the list. I had seen a while back that eventually merge requests might be fielded, so I figured it was worth a shot." "just not familiar with manual patch work, normally been used to gitlab, github. I installed the git-publish as per document, but not sure about the next step from this tool. And, I am not sure about how to connect my email with this tool either." "I'm happy to hear you are considering a switch to gitlab. I've never contributed to projects which are using email based submission" "Have you guys received an email from .... with the subject ..... I can't find it in the archives" "I don't know what has happened, but we seem to be missing this patch from the list. ... I have all the patches in my inbox from the cc, so have no idea what happened either. It was my first time using git-publish and it took a few tries to get anything done." There are a variety of reasons behind these problems, but the effects are clear. Contributing to libvirt via email is complex and error prone. Mailman lost delivery --------------------- For Mailman, we are entirely dependent on Red Hat IT support via a private ticketing system. The reliability of Mailman leaves alot to be desired. For the past 5 years or more there have been multiple periods when mail delivery either stopped entirely, or randomly lost a subset of mails. When this happens if often isn't obvious at first that we're missing mail, and once identified, it has usually taken 2-3 days between opening a ticket and having someone actively investigate and resolve it. In the worst case it was over 7 days with broken mail delivery. This is not a good situation to be in, but we've tolerated it as nothing was irretrievably lost, just delayed by days, and every subscriber was equally affected. No service is perfectly reliable and we have seen both GitLab and GitHub have downtime periodically. A key difference though is how the problems are handled. For the git forges, service downtime is a business critical problem, and so gets the prioritized attention that it demands. Mailing list delivery for libvirt is NOT considered a business critical problem for Red Hat, and so the low priorization of fixing mailman problems reflects this. MX server content mangling -------------------------- More recently we've faced worse problems with the mailing list. The new service acting as redhat.com border MX gateway is mangling mails in a way that breaks DKIM signatures. Thus any time someone sends a message with a DKIM signature, there are a large number of subscribers to the list whose mail server will bounce the delivery from mailan due to DKIM validation failures. We tried to fix this by removing the subject prefix modification and body text footer in mailman, but that merely reduced the frequency of the problem by a small amount. In theory it can be mitigated by having mailman replace the "From" field with the list server's address. qemu-devel did this originally before they switched to removing the subject prefix/body footer. The reason it worked for QEMU was because only mailman was mangling their messages, whereas for libvirt, both mailman and the redhat.com MX gateway are mangling. The old version of mailman on redhat.com doesn't appear to support From header rewriting. Similar to DKIM problems, there are the same problems with ARC headers, though we lack definitive proof on the cause. The effect is that when any SUSE contributor sends a mail, deliveries to all other SUSE subscribers will be bounced. We believe it affects some other domains, but SUSE is the most obvious one. Both these problems are pretty serious and discriminate against certain subscribers depending on how their mail service configures their incoming filters. Even redhat.com was rejecting messages with broken DKIM signatures for a time, until enough people complained about missing valid emails. Many other contributors are not lucky enough to have an IT staff who would respond to such complaints. MX server anti-spam blackholing ------------------------------- A further problem has impacted mails sent by one contributor, which have been silently dropped by redhat.com MX servers, with no bounce at all. After two months we tracked this down to a bogus hostname in the From field of the messages which caused redhat.com to consider them a spammer spoofing the sender address & so blackhole it. This is actually a case where I probably agree with the redhat.com MX server policy, but it is none the less incredibly unhelpful for the unlucky contributor(s) affected by it, as it is hard for them to discover what they did wrong. We were lucky this contributor noticed they had a problem and was very persistent over months in talking to us about it to rather than walking away, as I expect most people would. Loosing members through attrition --------------------------------- Even without any of the above problems, the mailing list workflow still has the problem of being yet another account for people to keep track of. Every week I have to purge multiple subscribers from libvirt lists due to repeated bounced delivery attempts. Most commonly this is when their MX server starts rejecting messages claiming the address no longer exists (due to leaving a job). IOW, when someone has changed their job, and thus changed their email address, they have to re-register with any projects they are using. In some cases this is ok, as they may no longer care about the project after switching jobs, but it means we lack any channel to attempt to keep their interest. If another contributor tries to contact them via their old email address, they'll just get bounces too. With Git Forges, users have a login identity that is distinct from their email address, and thus they one need update one place when changing jobs, and interactions with other users are via this persistent identifier. Mail diagnosis / resolution --------------------------- The difficulty in all of these cases is that the project contributors who are affected have very limited means to either diagnose or resolve the problem. They are dependent on raising tickets with their own IT admin staff, who might then have to raise tickets with support from a company they outsourced to, and or talk to libvirt mailman admins. The libvirt mailman admins are similarly dependent on raising tickets with Red Hat IT and an external company. Depending on the level of outsourcing, the problem can span across IT support staff from 4/5 different companies. This has a predictably bad effect on the chances of resolving problems. Mail lack of recovery --------------------- Many of the problems result in permanent loss of messages to the subscriber affected. Even if the problem was eventually solved, there is often no straightforward way to get back the messages that were lost in the mean time. One the mail server has a hard bounce for that person, it will stop retrying delivery. The only option is to visit the mailman archive page and download the mbox and re-import messages. This is a result of email being a push based communication mechanism, with only a weak delivery assurance. If the push fails and isn't retried, the information is gone for good. Contrast with a Git Forge, where the primary communication mechanism is a pull based model. If there is a transient problem with the contributors network connectivity, or the hosted service has an outage, the user will be unable to pull information for a period of time. Once the problem is resolved, the next attempt to pull information will include everything, with no loss from the end user's POV. Mail list providers ------------------- Moving the libvirt mailing lists to another provider is not a magic bullet solution. qemu-devel is hosted on nongnu.org and has suffered bounces due to DKIM breakage, though at least their more modern mailman let them workaround it better. nongnu.org though has had similar problems with mail delivery getting stopped for periods of time, not as bad as libvirt suffered, but still dependant on waiting until the US wakes up to get anyone to investigate. I know other projects hosting lists on groups.io, which have also had serious problems of late with mails getting silently discarded, or mangled such that 'git am' fails. There are other providers The impact on contributors -------------------------- All this conspires to negatively impact the ability of people to participate in the libvirt project. If you can't reliably send & receive patches to libvir-list you are effectively excluded from the project, given that email is the core of our workflow. It hasn't had a huge visible impact on libvirt, primarily because the Red Hat contributions have escaped the worst effects. This "luck" doesn't make me at all happy, because it is important that anyone involved the project has an equal ability to contribute, regardless of whether they are Red Hat people or not. This is not the case There are many conceptual reasons to like a distributed messaging system based on open standards. The reality of the implementation of email though is quite different from the theory. The distributed nature of email, combined with the plethora of implementations which don't agree on what the minimum acceptable standards are, is the direct cause of the problems we have with reliable operation of the libvirt list, and mail in general. The problems with email don't seem to be getting better, if anything they are worse, as the broader world increasingly shifts away from email, sadly often to closed protocols, or closed applications. Overall though, I struggle the with idea of continuing to recommend email as the best choice for collaboration since it is clearly failing & excluding or harming some of our contributors. Mail usage for new contributors ------------------------------- For those of us who have been involved in libvirt for any length of time, the usage of email feels quite straightforward and natural. Our familiarity and experience can be quite different from that of new contribtors to the project. The usage of email as a development workflow relies on a large number of, often undocumented, conventions. If a contributor gets the conventions wrong they'll have poor first experience with the project. In the early days of libvirt those new contributors with existing open source experiance would already be familiar with email conventions, but we had plenty of contributors from the corporate world for which open source was a completely new experiance. Over the years we've sent nasty-gram responses to plenty of contributors who missed the conventions, though thankfully we're getting more polite and friendly these days in how we point out these kind of mistakes. It would be better to use a system that doesn't need this to the same degree. These days open source is a well known development model even among corporate developers from the closed source world, but their OSS knowledge is almost always based on a GitForge workflow, not an email workflow. Maintainer patch submission overload ------------------------------------ Any long term contributors to libvirt will have become familiar with the mail based development workflow, however, long term usage and familiarity does not imply that the solution used is the optional one, rather that the chosen solution has been optimized. With the volume of patches submitted to libvirt there is always pressure on reviewer bandwidth. The imbalance between incoming patches and reviewer time is common across all major open source projects, regardless of development workflow and tools. What matters is thus how well the project deals with the overload, to priortize the right aspects. The efficiency with which developers can perform reviews is one factor and is typically the area where email is said to be most beneficial. I personally find email is efficient for writing comments inline to patches, but that is largely due to the use of a text based user interface (mutt), rather than the inherent use of email as a messaging platform. There are other aspects to the use of email which harm our productivity as reviewers. Personal patch tracking ----------------------- To review a patch you first have to realize and/or remember that it exists, and this is an area where email is quite poor. It is easy for patches to go unattended for a prolonged period of time, drowned out in the volume of patches on the list. We encourage users to send a "ping" if they think their patch has been ignored for too long. This is a poor workaround for our inability to keep track of what patches are pending. New contributors won't even know they're expected to send a "ping", or may wonder how long they should wait. Essentially the mail folder needs to be thought of as a mixture of signal and noise, where 'signal' refers to patches which need reviewer attention, and 'noise' refers to patches which are already processed in some way. The most recent mails in an folder have a high signal component, turning increasingly to noise as they age. The key task for email processing is thus to distinguish signal from noise, such that we never miss any valid messages. The supposed positive of using email is that contributors have the flexibility to customize their way of working to enable them to keep track of pending work in whatever way suits them best. People come up with clever mail filtering practices / rules / scripts to organize their incoming mail stream. Instead of considering this a benefit, we should be asking why our tools are so ill-suited to the task that every contributor has to spend (waste) time reinventing the wheel to distinguish signal from noise when processing email, duplicating that same work across all contributors ? This has a particularly high burden on contributors who don't engage with the project on a daily basis, as they get a firehose of emails, many of which are already obsolete by the time they look at their inbox. IOW, in-frequent contributors experiance high noise, low signal, when interacting with the libvirt mailing list. At first glance merge requests may feel like they are no better, since there would be the same number of patches arriving each day. The key difference is that there is good structure and metadata to the merge requests. Multiple versions of the same series, appear as a single entity. Merge requests which have been merged or abandoned no longer appear. Active merge requests can be tagged with labels & users to organize them. Thus looking at the list of merge requests gives you information with a high signal content, and little noise content. This is good for both regular contributors and infrequent or new contributors. Patch tracking tools -------------------- With every contributor organizing their own personal incoming stream, there is no visibility / interaction between contributors on pending work. There is no way of knowing whether any given patch series is on the to do list for another person to deal with. There have been tools created which attempt to fill the gap by providing a centralized view of incoming patches. To name just a few, there are patchwork, patches, patchew, and patchecker. We have tried many of the tools to some degree or another with libvirt, but none have had success. Some are also in use in QEMU but see periodic breakage in consuming the mail stream for a variety of reasons. First and foremost, they suffer from the difficulty of turning free format mail threads into well structured data. This can only be done reliably if all contributors follow a set of well defined conventions for sending patches, which immediately puts a burden on contributors, and is a barrier to new contributors. These tools typically assume that all patches can apply against git master and if this isn't possible drop them with an error. Contributors rarely intentionally send patches against old versions of the code, but with the rate of commits, git master can still conflict with a newly posted patch series, requiring human intervention. Some support special magic comments in the mail to indicate what git version the patch is based on, but this is more secret sauce for contributors to learn. The problem of patch conflict resolution also creates challenges for the tools to determine when a series has been merged & can thus be considered complete. Then there is the matter of correlating different versions of the same patch series. This again largely relies on contributors following a convention of using the same subject line for the leading patch / cover letter each time it is posted. Some people post URLs pointing to previous versions of the same series, but this is yet more manual work to work around the limits of email when used for patch submission. Keeping a fixed subject does not always make sense. This again makes it hard for the tools to determine whether a patch series has been merged or obsoleted. So overall, while it is possible to write tools to turn incoming patch series emails into structured data, their reliability is poor, which in turn makes it difficult to consider relying on them. These same problems are why it is difficult to have a bi-directional email gateway between a mailing list and a merge request system. Sending mails from a merge request is easy. Parsing contextual replies and getting them back into the merge request is incredibly hard, often impossible. Attaching CI to submissions --------------------------- Without an ability to reliably process incoming patches in an automated manner, it is impractical to automate downstream tasks. It is generally considered best practice to run tests on all code before it is accepted for merge. Libvirt CI testing is currently all done post-merge. Contributors are generally expected to make sure code compiles and passes tests before posting it. The testing done this way rarely has the same breadth of coverage as that done by post-merge CI and may be done against an outdated git master. Reviewers may or may not take the time to actually apply the patches and run builds and tests. Where this is done, the coverage is usually just one or two platforms, a small subset of post-merge CI. The result of this is the frequent build & test breakage of git master, which has to be addressed through "brown paper bag" commits, mostly pushed without review under a "build breaker" rule. This is a prudent way to fix the breakage, however, it would be better if the breakage was prevented in the first place. If automation can catch the build problems before merge, there ceases to be any need for having special exceptions to allow pushing code without review. The result will be a higher quality output overall, with less time wasted on manually pointing out silly mistakes, or fixing them up after the fact. We know there is insufficient reviewer time to handle all the incoming patches submitted, and thus we should not expect them to spend time on tasks that can be automated. Reviewers should never be building code or running tests in general, or spending time pointing out problems in the code that can be caught by the tests. The tools should do all testing the moment the code is submitted, with reviewers only spending time once CI has passed & the submitted had a chance to re-upload any obvious fixes. The patchew tool attempts to do this kind of automation, but as noted above it suffers from the hard problem of reliably parsing email, determining what git master patches apply to, and needs secret comment syntax to be used by contributors for cases where it can't do the right thing. Barriers to new contributors ---------------------------- The only real solution to contributor overload is to spread the work across more people. This in turn implies a need to attract new contributors to the project. There need to be interesting problems to attract their attention. The task is then need to turn them into regular contributors, and this is where first impressions of a project are important. Simply put, the first interaction needs to be a positive experience. This might be via a bug tracker or via a code submission, or something else. Anything which may hurt first impressions needs to be eliminate or mitigated as much as practical. A need to learn unusual workflows, or configure new tools, or learn about project specific (unwritteN) conventions, are all things which stand in the way of succesful participation. The key value of the merge request workflow is the standardization across projects, such that it has immediate familiarity enabling people to contribution without having to read docs. This is a bit of an over simplication, since there is always some project specific knowledge required. Ideally this knowledge will be primarily around the code and not on the development process. I've increasingly recognised this in my own interactions with projects. Since the widespread adoption of Git, I find it a significant turn off to find a project is still using CVS, Subversion, or any other non-Git SCM. Increasingly I feel the same way about development workflow and the git forge. If I can fork a project on GitLab/GitHub, and open a pull request, I'm more likely to send a patch upstream, than if I have to register for a new account on a custom bug tracker or mailing list. On the flip side, while one of my own personal projects still has a mailing list, it is more enjoyable dealing with contributors if they open a pull request, as I see the CI results and know the patch can be applied with 1 click if desired. The more I use the tools, the more effective they become for me. Keeping new contributors interested ----------------------------------- The response to a new contributor is also important. The earlier someone engages with them, the better. With this in mind it is useful to be able to quickly identify new contributor and prioritize a response to them over other work. Automation (CI) can help in this respect by picking up & reporting problems without needing human attention. None the less, triage of incoming requests will be needed, primarily though tagging to classify incoming requests, and nominating certain people as reviewers. The power of the merge request model is that such triage is centralized & thus visible to participates, as opposed to being repeated by every individual when using email. People can see this triage and more effectively direct their attention where it is needed. The Web UI problem ------------------ The use of a web UI is often seen as the biggest downside to using a Git Forge, especially amongst people who are used to an email based code review workflow. This is a position I have great sympathy with, as I do largely prefer text based tools with strong keyboard navigation, over graphical tools with strong mouse navigation. The downsides of the web UI for merge requests becomes more apparent the larger the change is, especially if split across multiple patches. While common, this viewpoint on the merits of text UI over graphical UI is not universally held. The popularity of Git Forges amongst the open souce world demonstrates that many developers have no trouble with the web UI, or at least are willing to accept it in order to benefit from the other features offered. My preference for a text based UI has lead me to spend time investigating the API support for GitLab and from there developing a custom application for interacting with GitLab merge requests. https://gitlab.com/bichon-project/bichon The goal of the tool is to provide a user interface for merge requests that is familiar to users of the mutt email client. It is not especially advanced in its impl yet, and certainly has rough edges, but for me it has proved the general point that we can build useful tools to integrate with GitLab, which can mitigate the worst aspects of a Web UI. The need to build such a tool, however, has a cost as it diverts time away from working on libvirt itself, which negates some of the benefits of adopting GitLab in the first place. It is hoped, however, that this is a relatively short term cost that could ultimately be amoritized across multiple developers who use GitLab for their projects, while the benefits are repaid continuously over the long term. The review comment model ------------------------ Those familiar with a email based workflow using clients like mutt will often cherish the deeply threaded discussion model. It is worth bearing in mind that not all email clients will follow this, with many turning the threaded discussion into a flat discussion. The GitLab review comment system certainly doesn't offer the kind of threading that mutt does, but it is a step above what many email clients do. Against any single patch, it is possible to one or more standalone comments, and one or more discussion threads, attached to specific lines of code. The distinction between the two is whether replies are permitted. The threads are, however, flat, not deeply nested. There are two interesting and perhaps useful things to be aware of. First each discussion thread on a patch has a notion of whether it has been "resolved" or not. It is possible to (optionally) have threads auto-resolve when a new version of the patch series is posted to the merge request, or they can be resolved manually by a contributor. This can be valuable in keeping track of whether feedback on v1 was addressed in changes for v2, which is a challenge with email review workflows. The second interesting thing is that threads can be "rebased". This is both useful and annoying at the same time. What appears to happen behind the scenes is that the (commit hash, file, line num) that is associated with a comment thread can be auto-updated to point to the latest commit that contains the matching (file, line num). This is useful when a v2 is posted, as the comments from v1 are moved to v2, helping identify if the problem was addressed. It is annoying when dealing with patch series though, as it appears that a comment created on patch 3, might be reported against patch 15 when later queried, if patch 15 has context covering this same source file location. This makes some sense when considering the web UI, because by default it will show the combined diff of all patches in a series. It is less helpful for my bichon tool which is trying to present a per-patch view. In theory it should be possible to follow the diff context backwards to display the comment against every single patch which has context for the same line of code. This would in fact make it quite useful, but until that is done it is quite annoying. More generally, comments have nice integration with the rest of the toolset making it easy to refer to issue trackers, merge requests via magic markdown extensions, and to tag individual contributors to get their opinion on a question. 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 :|

8 25

Re: GSoC'20 Interested Student: Adding support to Jailhouse Hypervisor
by Jan Kiszka 31 Mar '20

31 Mar '20

Hi Prakhar, On 23.03.20 07:53, PRAKHAR BANSAL wrote: > Hello All, > > My name is Prakhar Bansal and I am a graduate student in Computer > Engineering at Iowa State University, US. > I have experience with Analysing Performance of Applications running > inside multiple virtual machines hosted by the libvirt QEMU-KVM through > virt-manager. > > I am interested in working on the project to develop a Libvirt driver > for the Jailhouse hypervisor. I looked into the initial attempt on the > Jailhouse driver which seems to be based on the Jailhouse command-line > interface. I am currently looking into learning and understanding the > kernel APIs for jailhouse hypervisor. Thanks for your interest! > I followed the below articles mentioned by Valentine Sinitsyn to begin > learning about the Jailhouse hypervisor. > > https://lwn.net/Articles/578295/ > https://lwn.net/Articles/578852/ > > I have a few questions regarding this project, please let me know if > someone can help me out. Sure, go ahead. Depending on the scope of the question, libvirt might be the better community to ask. Therefore, I'm adding its list to this thread. Jan > > Thanks & Regards, > Prakhar Bansal > -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux

3 10

[libvirt PATCH] travis: delete all Linux jobs
by Daniel P. Berrangé 31 Mar '20

31 Mar '20

The Fedora rawhide job started failing with the latest container build. Since we now have broad CI coverage on GitLab CI, there's not a strong reason to continue using Travis for Linux jobs. Deleting the redundant jobs is a better use of time than trying to debug the failure. Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- .travis.yml | 47 ----------------------------------------------- 1 file changed, 47 deletions(-) diff --git a/.travis.yml b/.travis.yml index f400f76118..0548b28b01 100644 --- a/.travis.yml +++ b/.travis.yml @@ -18,53 +18,6 @@ addons: matrix: include: - - services: - - docker - env: - - IMAGE="ubuntu-1804" - - MAKE_ARGS="syntax-check distcheck" - script: - - make -C ci/ ci-build@$IMAGE CI_MAKE_ARGS="$MAKE_ARGS" - - services: - - docker - env: - - IMAGE="centos-7" - - MAKE_ARGS="syntax-check distcheck" - script: - - make -C ci/ ci-build@$IMAGE CI_MAKE_ARGS="$MAKE_ARGS" - - services: - - docker - env: - - IMAGE="debian-9" - - MAKE_ARGS="syntax-check distcheck" - script: - - make -C ci/ ci-build@$IMAGE CI_MAKE_ARGS="$MAKE_ARGS" - - services: - - docker - env: - - IMAGE="fedora-31" - - MAKE_ARGS="syntax-check distcheck" - script: - - make -C ci/ ci-build@$IMAGE CI_MAKE_ARGS="$MAKE_ARGS" - - services: - - docker - env: - - IMAGE="fedora-rawhide" - - MAKE_ARGS="syntax-check distcheck" - script: - - make -C ci/ ci-build@$IMAGE CI_MAKE_ARGS="$MAKE_ARGS" - - services: - - docker - env: - - IMAGE="fedora-30-cross-mingw32" - script: - - make -C ci/ ci-build@$IMAGE - - services: - - docker - env: - - IMAGE="fedora-30-cross-mingw64" - script: - - make -C ci/ ci-build@$IMAGE - compiler: clang language: c os: osx -- 2.24.1

2 4

[PATCH] Add blog for ARM Datacenter Project.
by Robert Foley 31 Mar '20

31 Mar '20

Our blog covers QEMU topics. Signed-off-by: Robert Foley <robert.foley(a)linaro.org> --- updater/virt-tools/config.ini | 3 +++ 1 file changed, 3 insertions(+) diff --git a/updater/virt-tools/config.ini b/updater/virt-tools/config.ini index 9375c82..4e53029 100644 --- a/updater/virt-tools/config.ini +++ b/updater/virt-tools/config.ini @@ -197,3 +197,6 @@ faceheight = 96 [https://fidencio.org/tags/virt/index.xml] name = Fabiano Fidêncio + +[https://futurewei-cloud.github.io/ARM-Datacenter/feed.xml] +name = ARM Datacenter Project -- 2.17.1

2 2

[PATCH v2 00/11] Another round of qemu:///embed fixes
by Michal Privoznik 30 Mar '20

30 Mar '20

v2 of: https://www.redhat.com/archives/libvir-list/2020-March/msg00992.html Basically, a lot of patches from v1 was ACKed, but there were some suggestions which I put into separate commits and now am resending as v2. diff to v1: - Renamed virDomainDriverHashRoot() to virDomainDriverGenerateRootHash() - Generate hashed path only if the base (prefix) would point outside of the root dir - Use "qemu" instead of "QEMU" when generating hashed path - New patches 2/11, 7/11 Michal Prívozník (11): tests: Fix virQEMUDriverConfigNew() calling with respect to @root qemu: Drop two layers of nesting of memoryBackingDir conf: Move virDomainGenerateMachineName to hypervisor/ virDomainDriverGenerateMachineName: Factor out embed path hashing qemu: Introduce virQEMUDriverGetEmbedRoot qemuDomainGetMachineName: Access embeddedRoot from driver rather than cfg qemu: use virQEMUDriverGetEmbedRoot() to access embeddedRoot Revert "qemu_conf: Track embed root dir" qemu: Make hugepages path generation embed driver aware qemu: Make memory path generation embed driver aware qemu: Make auto dump path generation embed driver aware src/conf/domain_conf.c | 72 --------------- src/conf/domain_conf.h | 7 -- src/hypervisor/domain_driver.c | 88 +++++++++++++++++++ src/hypervisor/domain_driver.h | 11 +++ src/libvirt_private.syms | 3 +- src/lxc/lxc_domain.c | 3 +- src/qemu/qemu_command.c | 19 ++-- src/qemu/qemu_conf.c | 69 +++++++++------ src/qemu/qemu_conf.h | 23 +++-- src/qemu/qemu_domain.c | 9 +- src/qemu/qemu_driver.c | 26 +++--- src/qemu/qemu_process.c | 9 +- tests/domaincapstest.c | 2 +- .../qemuxml2argvdata/cpu-numa-memshared.args | 8 +- .../fd-memory-no-numa-topology.args | 2 +- .../fd-memory-numa-topology.args | 4 +- .../fd-memory-numa-topology2.args | 8 +- .../fd-memory-numa-topology3.args | 12 +-- .../hugepages-memaccess2.args | 12 +-- .../qemuxml2argvdata/pages-dimm-discard.args | 4 +- ...vhost-user-fs-fd-memory.x86_64-latest.args | 2 +- tests/testutilsqemu.c | 2 +- tests/virsystemdtest.c | 5 +- 23 files changed, 217 insertions(+), 183 deletions(-) -- 2.24.1

3 25

[PATCH v2 0/4] add support for QEMU 9pfs 'multidevs' option
by Christian Schoenebeck 30 Mar '20

30 Mar '20

QEMU 4.2 added a new option 'multidevs' for 9pfs. The following patch adds support for this new option to libvirt. In short, what is this about: to distinguish files uniquely from each other in general, numeric file IDs are typically used for comparison, which in practice is the combination of a file's device ID and the file's inode number. Unfortunately 9p protocol's QID field used for this purpose, currently is too small to fit both the device ID and inode number in, which hence is a problem if one 9pfs export contains multiple devices and may thus lead to misbheaviours on guest (e.g. with SAMBA file servers) in that case due to potential file ID collisions. To mitigate this problem with 9pfs a 'multidevs' option was introduced in QEMU 4.2 for defining how to deal with this, e.g. multidevs=remap will cause QEMU's 9pfs implementation to remap all inodes from host side to different inode numbers on guest side in a way that prevents file ID collisions. NOTE: In the libvirt docs changes of this libvirt patch I simply assumed "since 6.2.0". So the final libvirt version number would need to be adjusted in that text if necessary. See QEMU discussion with following Message-ID for details: 8a2ffe17fda3a86b9a5a437e1245276881f1e235.1567680121.git.qemu_oss(a)crudebyte.com v1->v2: * Unrelated docs/formatdomain.html.in changes to separate patch. [patch 1] * Added new capability QEMU_CAPS_VIRTFS_MULTIDEVS. [patch 2] * XML changes as isolated patch. [patch 3] * Code style fix. [patch 3] * QEMU 'multidevs' command handling as isolated patch. [patch 4] * Error out if not QEMU_CAPS_VIRTFS_MULTIDEVS capability. [patch 4] * Error out on virtiofs (since it does not have the 'multidevs' option). [patch 4] TODO: * Capabilities test cases would fail if <flag name='virtfs-multidevs'/> was added to the other architectures' test case xml files, why? [patch 2] * The requested test cases to add: Sorry, the libvirt test case environment is yet a mystery to me, I would not even know where to start here. Message-ID of v1: E1jEFpL-00028n-Qj(a)lizzy.crudebyte.com Christian Schoenebeck (4): docs: virtfs: add section separators qemu: capabilities: add QEMU_CAPS_VIRTFS_MULTIDEVS conf: add 'multidevs' option qemu: add support for 'multidevs' option docs/formatdomain.html.in | 47 ++++++++++++++++++- docs/schemas/domaincommon.rng | 10 ++++ src/conf/domain_conf.c | 29 ++++++++++++ src/conf/domain_conf.h | 13 +++++ src/qemu/qemu_capabilities.c | 5 ++ src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 7 +++ src/qemu/qemu_domain.c | 12 +++++ .../caps_4.2.0.x86_64.xml | 1 + .../caps_5.0.0.aarch64.xml | 1 + .../caps_5.0.0.x86_64.xml | 1 + 11 files changed, 126 insertions(+), 1 deletion(-) -- 2.20.1

2 11

RFC: qemu: use uuid instead of name for misc filenames
by Nikolay Shirokovskiy 30 Mar '20

30 Mar '20

Hi, everyone. I'm working on supporting domain renaming when it has snapshots which is not supported now. And it strikes me things will be much simplier to manage on renaming if we use uuid in filenames instead of domain names. 1. Renaming will only involve saving updated config. The saving is atomic thanx to tmp file and rename(2) approach. In constast current renaming on error paths can leave config with old or new name. Thus on libvirt restart extra VM will appear. And we don't need to rename autostart links, snapshot directories etc. 2. Renaming will be possible for running domains with no efforts. We only need to pass uuid instead of name in '-name guest=...' command line. 3. Mgmt can stop using autogenerated names for domains. I guess openstack for example uses names like instance-000002ff because we have many limitations on domain renaming. And if these limitations are removed then openstack can just use user supplied names for domains. 4. No issues with long domain names and filename length limit If the above conversion makes sense I guess the good time to apply it is on domain start (and rename to support renaming with snapshots). I guess we can also have tool (some virsh command) for developers to generate symlinks so one can access logs, configs etc by name instead of uuid. Nikolay

3 8

[PATCH v2 0/4] Preserve query component of path for HTTP disks
by Peter Krempa 30 Mar '20

30 Mar '20

v2: - fixed docs to mention http/ftp/tftp protocols - query part is stored separately to prevent ambiguity in using of the '?' sign - added checks that query is valid only for http - added tests for pre-blockdev configurations Peter Krempa (4): docs: formatdomain: Mention missing protocols conf: Add support for http(s) query strings qemuBlockStorageSourceGetURI: Pass through query component virStorageSourceParseBackingURI: Preserve query string of URI for http(s) docs/formatdomain.html.in | 14 ++++++++++---- docs/schemas/domaincommon.rng | 6 ++++++ src/conf/domain_conf.c | 5 +++++ src/qemu/qemu_block.c | 2 ++ src/qemu/qemu_domain.c | 9 +++++++++ src/util/virstoragefile.c | 14 +++++++++++--- src/util/virstoragefile.h | 1 + tests/qemuxml2argvdata/disk-cdrom-network.args | 4 ++-- .../disk-cdrom-network.x86_64-2.12.0.args | 4 ++-- .../disk-cdrom-network.x86_64-latest.args | 3 ++- tests/qemuxml2argvdata/disk-cdrom-network.xml | 2 +- .../disk-network-http.x86_64-latest.args | 5 +++-- tests/qemuxml2argvdata/disk-network-http.xml | 2 +- .../disk-network-http.x86_64-latest.xml | 2 +- tests/virstoragetest.c | 4 ++-- 15 files changed, 58 insertions(+), 19 deletions(-) -- 2.24.1

2 10

[PATCH] qemu-shim: add a --with-config option
by marcandre.lureau＠redhat.com 30 Mar '20

30 Mar '20

From: Marc-André Lureau <marcandre.lureau(a)redhat.com> Add an option to ease setting up a VM with existing libvirt qemu.conf. Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1817776 Signed-off-by: Marc-André Lureau <marcandre.lureau(a)redhat.com> --- docs/manpages/virt-qemu-run.rst | 6 ++++++ src/libvirt_private.syms | 1 - src/qemu/qemu_shim.c | 36 +++++++++++++++++++++++++++++++++ 3 files changed, 42 insertions(+), 1 deletion(-) diff --git a/docs/manpages/virt-qemu-run.rst b/docs/manpages/virt-qemu-run.rst index b06c311b1d..3196b4c8f4 100644 --- a/docs/manpages/virt-qemu-run.rst +++ b/docs/manpages/virt-qemu-run.rst @@ -71,6 +71,12 @@ is a path to the XML description of the secret, whose UUID should match a secret referenced in the guest domain XML. The ``VALUE-FILE`` is a path containing the raw value of the secret. +``-c``, ``--with-config`` + +Copy the libvirt qemu.conf configuration to the root directory. If +there is already a qemu.conf file in the $ROOT/etc directory, exit +with failure. + EXIT STATUS =========== diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms index 88fea4fc43..cb2b279401 100644 --- a/src/libvirt_private.syms +++ b/src/libvirt_private.syms @@ -1899,7 +1899,6 @@ virConfWalk; virConfWriteFile; virConfWriteMem; - # util/vircrypto.h virCryptoEncryptData; virCryptoHashBuf; diff --git a/src/qemu/qemu_shim.c b/src/qemu/qemu_shim.c index 7e87b8fb96..553a37ab60 100644 --- a/src/qemu/qemu_shim.c +++ b/src/qemu/qemu_shim.c @@ -24,6 +24,7 @@ #include <stdbool.h> #include <unistd.h> +#include "virconf.h" #include "virfile.h" #include "virstring.h" #include "virgettext.h" @@ -99,6 +100,7 @@ int main(int argc, char **argv) g_auto(GStrv) secrets = NULL; gboolean verbose = false; gboolean debug = false; + gboolean with_config = false; GStrv tmpsecrets; GOptionContext *ctx; GOptionEntry entries[] = { @@ -106,6 +108,7 @@ int main(int argc, char **argv) { "root", 'r', 0, G_OPTION_ARG_STRING, &root, "Root directory", "DIR" }, { "debug", 'd', 0, G_OPTION_ARG_NONE, &debug, "Debug output", NULL }, { "verbose", 'v', 0, G_OPTION_ARG_NONE, &verbose, "Verbose output", NULL }, + { "with-config", 'c', 0, G_OPTION_ARG_NONE, &with_config, "Use system/home qemu.conf", NULL }, { 0 } }; int quitfd[2] = {-1, -1}; @@ -167,6 +170,39 @@ int main(int argc, char **argv) } } + if (with_config) { + g_autofree char *src = virConfLoadConfigPath("qemu.conf"); + g_autofree char *dir = g_build_filename(root, "etc", NULL); + g_autofree char *dst = g_build_filename(dir, "qemu.conf", NULL); + g_autofree char *contents = NULL; + gsize len; + + if (g_mkdir_with_parents(dir, 0755) < 0) { + g_printerr("%s: cannot create %s dir: %s\n", + argv[0], dir, g_strerror(errno)); + goto cleanup; + } + + + if (g_file_test(dst, G_FILE_TEST_EXISTS)) { + g_printerr("%s: %s file already exists\n", + argv[0], dst); + goto cleanup; + } + + if (!g_file_get_contents(src, &contents, &len, &error)) { + g_printerr("%s: cannot read %s: %s\n", + argv[0], src, error->message); + goto cleanup; + } + + if (!g_file_set_contents(dst, contents, len, &error)) { + g_printerr("%s: cannot write %s: %s\n", + argv[0], dst, error->message); + goto cleanup; + } + } + virFileActivateDirOverrideForProg(argv[0]); if (verbose) -- 2.26.0.rc2.42.g98cedd0233

3 2

[PATCH 0/2] qemu: Fix --keep-relative for block-commit/pull with blockdev
by Peter Krempa 30 Mar '20

30 Mar '20

Peter Krempa (2): qemu: block: Support VIR_DOMAIN_BLOCK_COMMIT/PULL/REBASE_RELATIVE with blockdev qemuDomainSnapshotDiskPrepareOne: Don't load the relative path with blockdev src/qemu/qemu_block.c | 46 ++++++++++++++++++++++++++++++++++++++++++ src/qemu/qemu_block.h | 5 +++++ src/qemu/qemu_driver.c | 13 ++++++++++-- 3 files changed, 62 insertions(+), 2 deletions(-) -- 2.24.1

2 3

[libvirt-dockerfiles PATCH] Refresh after recent changes
by Andrea Bolognani 30 Mar '20

30 Mar '20

Paths to commands such as $MAKE and $NINJA are now exposed in the container's environment, and the symlinks necessary to make ccache work transparently are also included. The corresponding libvirt-jenkins-ci commit is 2563aebb6c5c. Signed-off-by: Andrea Bolognani <abologna(a)redhat.com> --- Pushed under the Dockerfile update rule. Plain text diff included for your convenience. buildenv-libosinfo-centos-7.zip | Bin 1665 -> 1782 bytes buildenv-libosinfo-centos-8.zip | Bin 594 -> 716 bytes buildenv-libosinfo-debian-10.zip | Bin 663 -> 783 bytes buildenv-libosinfo-debian-9.zip | Bin 683 -> 804 bytes buildenv-libosinfo-debian-sid.zip | Bin 663 -> 783 bytes ...denv-libosinfo-fedora-30-cross-mingw32.zip | Bin 629 -> 754 bytes ...denv-libosinfo-fedora-30-cross-mingw64.zip | Bin 631 -> 757 bytes buildenv-libosinfo-fedora-30.zip | Bin 544 -> 668 bytes buildenv-libosinfo-fedora-31.zip | Bin 544 -> 668 bytes buildenv-libosinfo-fedora-rawhide.zip | Bin 564 -> 688 bytes buildenv-libosinfo-opensuse-151.zip | Bin 570 -> 694 bytes buildenv-libosinfo-ubuntu-1604.zip | Bin 686 -> 808 bytes buildenv-libosinfo-ubuntu-1804.zip | Bin 686 -> 808 bytes buildenv-libvirt-centos-7.zip | Bin 1888 -> 2006 bytes buildenv-libvirt-centos-8.zip | Bin 802 -> 928 bytes buildenv-libvirt-debian-10-cross-aarch64.zip | Bin 982 -> 1110 bytes buildenv-libvirt-debian-10-cross-armv6l.zip | Bin 974 -> 1102 bytes buildenv-libvirt-debian-10-cross-armv7l.zip | Bin 983 -> 1108 bytes buildenv-libvirt-debian-10-cross-i686.zip | Bin 981 -> 1105 bytes buildenv-libvirt-debian-10-cross-mips.zip | Bin 974 -> 1103 bytes buildenv-libvirt-debian-10-cross-mips64el.zip | Bin 985 -> 1114 bytes buildenv-libvirt-debian-10-cross-mipsel.zip | Bin 982 -> 1105 bytes buildenv-libvirt-debian-10-cross-ppc64le.zip | Bin 985 -> 1115 bytes buildenv-libvirt-debian-10-cross-s390x.zip | Bin 977 -> 1105 bytes buildenv-libvirt-debian-10.zip | Bin 908 -> 1032 bytes buildenv-libvirt-debian-9-cross-aarch64.zip | Bin 1018 -> 1143 bytes buildenv-libvirt-debian-9-cross-armv6l.zip | Bin 1009 -> 1134 bytes buildenv-libvirt-debian-9-cross-armv7l.zip | Bin 1014 -> 1140 bytes buildenv-libvirt-debian-9-cross-mips.zip | Bin 1010 -> 1134 bytes buildenv-libvirt-debian-9-cross-mips64el.zip | Bin 1021 -> 1145 bytes buildenv-libvirt-debian-9-cross-mipsel.zip | Bin 1014 -> 1137 bytes buildenv-libvirt-debian-9-cross-ppc64le.zip | Bin 1017 -> 1147 bytes buildenv-libvirt-debian-9-cross-s390x.zip | Bin 1013 -> 1137 bytes buildenv-libvirt-debian-9.zip | Bin 938 -> 1063 bytes buildenv-libvirt-debian-sid-cross-aarch64.zip | Bin 986 -> 1110 bytes buildenv-libvirt-debian-sid-cross-armv6l.zip | Bin 978 -> 1102 bytes buildenv-libvirt-debian-sid-cross-armv7l.zip | Bin 982 -> 1108 bytes buildenv-libvirt-debian-sid-cross-i686.zip | Bin 981 -> 1104 bytes ...denv-libvirt-debian-sid-cross-mips64el.zip | Bin 985 -> 1114 bytes buildenv-libvirt-debian-sid-cross-mipsel.zip | Bin 974 -> 1102 bytes buildenv-libvirt-debian-sid-cross-ppc64le.zip | Bin 986 -> 1115 bytes buildenv-libvirt-debian-sid-cross-s390x.zip | Bin 977 -> 1105 bytes buildenv-libvirt-debian-sid.zip | Bin 908 -> 1032 bytes buildenv-libvirt-fedora-30-cross-mingw32.zip | Bin 897 -> 1031 bytes buildenv-libvirt-fedora-30-cross-mingw64.zip | Bin 899 -> 1034 bytes buildenv-libvirt-fedora-30.zip | Bin 776 -> 904 bytes buildenv-libvirt-fedora-31.zip | Bin 776 -> 904 bytes buildenv-libvirt-fedora-rawhide.zip | Bin 796 -> 925 bytes buildenv-libvirt-opensuse-151.zip | Bin 785 -> 914 bytes buildenv-libvirt-ubuntu-1604.zip | Bin 942 -> 1069 bytes buildenv-libvirt-ubuntu-1804.zip | Bin 943 -> 1069 bytes 51 files changed, 0 insertions(+), 0 deletions(-) diff --git a/buildenv-libosinfo-centos-7.zip b/buildenv-libosinfo-centos-7.zip index e4f5b87..185f258 100644 --- a/buildenv-libosinfo-centos-7.zip +++ b/buildenv-libosinfo-centos-7.zip @@ -80,9 +80,18 @@ WEiJKtQrZDJloqtyi/mmRa1VsV7RYR0VPJjhK/R8EQ7Ysshy\n\ vala \ vim && \ yum autoremove -y && \ - yum clean all -y + yum clean all -y && \ + mkdir -p /usr/libexec/ccache-wrappers && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/cc && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/$(basename /usr/bin/gcc) RUN pip3 install \ meson==0.49.0 ENV LANG "en_US.UTF-8" + +ENV MAKE "/usr/bin/make" +ENV NINJA "/usr/bin/ninja-build" +ENV PYTHON "/usr/bin/python3" + +ENV CCACHE_WRAPPERSDIR "/usr/libexec/ccache-wrappers" diff --git a/buildenv-libosinfo-centos-8.zip b/buildenv-libosinfo-centos-8.zip index 53a49d0..ce7c071 100644 --- a/buildenv-libosinfo-centos-8.zip +++ b/buildenv-libosinfo-centos-8.zip @@ -52,6 +52,15 @@ RUN dnf install 'dnf-command(config-manager)' -y && \ vala \ vim && \ dnf autoremove -y && \ - dnf clean all -y + dnf clean all -y && \ + mkdir -p /usr/libexec/ccache-wrappers && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/cc && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/$(basename /usr/bin/gcc) ENV LANG "en_US.UTF-8" + +ENV MAKE "/usr/bin/make" +ENV NINJA "/usr/bin/ninja" +ENV PYTHON "/usr/bin/python3" + +ENV CCACHE_WRAPPERSDIR "/usr/libexec/ccache-wrappers" diff --git a/buildenv-libosinfo-debian-10.zip b/buildenv-libosinfo-debian-10.zip index 2592910..c97187e 100644 --- a/buildenv-libosinfo-debian-10.zip +++ b/buildenv-libosinfo-debian-10.zip @@ -53,6 +53,15 @@ RUN export DEBIAN_FRONTEND=noninteractive && \ apt-get autoremove -y && \ apt-get autoclean -y && \ sed -Ei 's,^# (en_US\.UTF-8 .*)$,\1,' /etc/locale.gen && \ - dpkg-reconfigure locales + dpkg-reconfigure locales && \ + mkdir -p /usr/libexec/ccache-wrappers && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/cc && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/$(basename /usr/bin/gcc) ENV LANG "en_US.UTF-8" + +ENV MAKE "/usr/bin/make" +ENV NINJA "/usr/bin/ninja" +ENV PYTHON "/usr/bin/python3" + +ENV CCACHE_WRAPPERSDIR "/usr/libexec/ccache-wrappers" diff --git a/buildenv-libosinfo-debian-9.zip b/buildenv-libosinfo-debian-9.zip index 72b04a2..16243b9 100644 --- a/buildenv-libosinfo-debian-9.zip +++ b/buildenv-libosinfo-debian-9.zip @@ -53,9 +53,18 @@ RUN export DEBIAN_FRONTEND=noninteractive && \ apt-get autoremove -y && \ apt-get autoclean -y && \ sed -Ei 's,^# (en_US\.UTF-8 .*)$,\1,' /etc/locale.gen && \ - dpkg-reconfigure locales + dpkg-reconfigure locales && \ + mkdir -p /usr/libexec/ccache-wrappers && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/cc && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/$(basename /usr/bin/gcc) RUN pip3 install \ meson==0.49.0 ENV LANG "en_US.UTF-8" + +ENV MAKE "/usr/bin/make" +ENV NINJA "/usr/bin/ninja" +ENV PYTHON "/usr/bin/python3" + +ENV CCACHE_WRAPPERSDIR "/usr/libexec/ccache-wrappers" diff --git a/buildenv-libosinfo-debian-sid.zip b/buildenv-libosinfo-debian-sid.zip index f81f758..ddb2598 100644 --- a/buildenv-libosinfo-debian-sid.zip +++ b/buildenv-libosinfo-debian-sid.zip @@ -53,6 +53,15 @@ RUN export DEBIAN_FRONTEND=noninteractive && \ apt-get autoremove -y && \ apt-get autoclean -y && \ sed -Ei 's,^# (en_US\.UTF-8 .*)$,\1,' /etc/locale.gen && \ - dpkg-reconfigure locales + dpkg-reconfigure locales && \ + mkdir -p /usr/libexec/ccache-wrappers && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/cc && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/$(basename /usr/bin/gcc) ENV LANG "en_US.UTF-8" + +ENV MAKE "/usr/bin/make" +ENV NINJA "/usr/bin/ninja" +ENV PYTHON "/usr/bin/python3" + +ENV CCACHE_WRAPPERSDIR "/usr/libexec/ccache-wrappers" diff --git a/buildenv-libosinfo-fedora-30-cross-mingw32.zip b/buildenv-libosinfo-fedora-30-cross-mingw32.zip index ff8776c..01cc808 100644 --- a/buildenv-libosinfo-fedora-30-cross-mingw32.zip +++ b/buildenv-libosinfo-fedora-30-cross-mingw32.zip @@ -50,7 +50,10 @@ RUN dnf update -y && \ vala \ vim && \ dnf autoremove -y && \ - dnf clean all -y + dnf clean all -y && \ + mkdir -p /usr/libexec/ccache-wrappers && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/i686-w64-mingw32-cc && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/i686-w64-mingw32-$(basename /usr/bin/gcc) RUN dnf install -y \ mingw32-glib2 \ @@ -64,5 +67,11 @@ RUN dnf install -y \ ENV LANG "en_US.UTF-8" +ENV MAKE "/usr/bin/make" +ENV NINJA "/usr/bin/ninja" +ENV PYTHON "/usr/bin/python3" + +ENV CCACHE_WRAPPERSDIR "/usr/libexec/ccache-wrappers" + ENV ABI "i686-w64-mingw32" ENV CONFIGURE_OPTS "--host=i686-w64-mingw32" diff --git a/buildenv-libosinfo-fedora-30-cross-mingw64.zip b/buildenv-libosinfo-fedora-30-cross-mingw64.zip index 24f38bc..a67bf61 100644 --- a/buildenv-libosinfo-fedora-30-cross-mingw64.zip +++ b/buildenv-libosinfo-fedora-30-cross-mingw64.zip @@ -50,7 +50,10 @@ RUN dnf update -y && \ vala \ vim && \ dnf autoremove -y && \ - dnf clean all -y + dnf clean all -y && \ + mkdir -p /usr/libexec/ccache-wrappers && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/x86_64-w64-mingw32-cc && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/x86_64-w64-mingw32-$(basename /usr/bin/gcc) RUN dnf install -y \ mingw64-glib2 \ @@ -64,5 +67,11 @@ RUN dnf install -y \ ENV LANG "en_US.UTF-8" +ENV MAKE "/usr/bin/make" +ENV NINJA "/usr/bin/ninja" +ENV PYTHON "/usr/bin/python3" + +ENV CCACHE_WRAPPERSDIR "/usr/libexec/ccache-wrappers" + ENV ABI "x86_64-w64-mingw32" ENV CONFIGURE_OPTS "--host=x86_64-w64-mingw32" diff --git a/buildenv-libosinfo-fedora-30.zip b/buildenv-libosinfo-fedora-30.zip index 69ea788..9d3773d 100644 --- a/buildenv-libosinfo-fedora-30.zip +++ b/buildenv-libosinfo-fedora-30.zip @@ -50,6 +50,15 @@ RUN dnf update -y && \ vala \ vim && \ dnf autoremove -y && \ - dnf clean all -y + dnf clean all -y && \ + mkdir -p /usr/libexec/ccache-wrappers && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/cc && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/$(basename /usr/bin/gcc) ENV LANG "en_US.UTF-8" + +ENV MAKE "/usr/bin/make" +ENV NINJA "/usr/bin/ninja" +ENV PYTHON "/usr/bin/python3" + +ENV CCACHE_WRAPPERSDIR "/usr/libexec/ccache-wrappers" diff --git a/buildenv-libosinfo-fedora-31.zip b/buildenv-libosinfo-fedora-31.zip index 4462104..22bb401 100644 --- a/buildenv-libosinfo-fedora-31.zip +++ b/buildenv-libosinfo-fedora-31.zip @@ -50,6 +50,15 @@ RUN dnf update -y && \ vala \ vim && \ dnf autoremove -y && \ - dnf clean all -y + dnf clean all -y && \ + mkdir -p /usr/libexec/ccache-wrappers && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/cc && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/$(basename /usr/bin/gcc) ENV LANG "en_US.UTF-8" + +ENV MAKE "/usr/bin/make" +ENV NINJA "/usr/bin/ninja" +ENV PYTHON "/usr/bin/python3" + +ENV CCACHE_WRAPPERSDIR "/usr/libexec/ccache-wrappers" diff --git a/buildenv-libosinfo-fedora-rawhide.zip b/buildenv-libosinfo-fedora-rawhide.zip index 6d6cefd..6ec74e8 100644 --- a/buildenv-libosinfo-fedora-rawhide.zip +++ b/buildenv-libosinfo-fedora-rawhide.zip @@ -51,6 +51,15 @@ RUN dnf update -y --nogpgcheck fedora-gpg-keys && \ vala \ vim && \ dnf autoremove -y && \ - dnf clean all -y + dnf clean all -y && \ + mkdir -p /usr/libexec/ccache-wrappers && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/cc && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/$(basename /usr/bin/gcc) ENV LANG "en_US.UTF-8" + +ENV MAKE "/usr/bin/make" +ENV NINJA "/usr/bin/ninja" +ENV PYTHON "/usr/bin/python3" + +ENV CCACHE_WRAPPERSDIR "/usr/libexec/ccache-wrappers" diff --git a/buildenv-libosinfo-opensuse-151.zip b/buildenv-libosinfo-opensuse-151.zip index 689344b..0998af6 100644 --- a/buildenv-libosinfo-opensuse-151.zip +++ b/buildenv-libosinfo-opensuse-151.zip @@ -49,9 +49,18 @@ RUN zypper update -y && \ sudo \ vala \ vim && \ - zypper clean --all + zypper clean --all && \ + mkdir -p /usr/libexec/ccache-wrappers && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/cc && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/$(basename /usr/bin/gcc) RUN pip3 install \ meson==0.49.0 ENV LANG "en_US.UTF-8" + +ENV MAKE "/usr/bin/make" +ENV NINJA "/usr/bin/ninja" +ENV PYTHON "/usr/bin/python3" + +ENV CCACHE_WRAPPERSDIR "/usr/libexec/ccache-wrappers" diff --git a/buildenv-libosinfo-ubuntu-1604.zip b/buildenv-libosinfo-ubuntu-1604.zip index 5e3bc10..261edc5 100644 --- a/buildenv-libosinfo-ubuntu-1604.zip +++ b/buildenv-libosinfo-ubuntu-1604.zip @@ -53,9 +53,18 @@ RUN export DEBIAN_FRONTEND=noninteractive && \ apt-get autoremove -y && \ apt-get autoclean -y && \ sed -Ei 's,^# (en_US\.UTF-8 .*)$,\1,' /etc/locale.gen && \ - dpkg-reconfigure locales + dpkg-reconfigure locales && \ + mkdir -p /usr/libexec/ccache-wrappers && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/cc && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/$(basename /usr/bin/gcc) RUN pip3 install \ meson==0.49.0 ENV LANG "en_US.UTF-8" + +ENV MAKE "/usr/bin/make" +ENV NINJA "/usr/bin/ninja" +ENV PYTHON "/usr/bin/python3" + +ENV CCACHE_WRAPPERSDIR "/usr/libexec/ccache-wrappers" diff --git a/buildenv-libosinfo-ubuntu-1804.zip b/buildenv-libosinfo-ubuntu-1804.zip index ff8df9a..0ccfade 100644 --- a/buildenv-libosinfo-ubuntu-1804.zip +++ b/buildenv-libosinfo-ubuntu-1804.zip @@ -53,9 +53,18 @@ RUN export DEBIAN_FRONTEND=noninteractive && \ apt-get autoremove -y && \ apt-get autoclean -y && \ sed -Ei 's,^# (en_US\.UTF-8 .*)$,\1,' /etc/locale.gen && \ - dpkg-reconfigure locales + dpkg-reconfigure locales && \ + mkdir -p /usr/libexec/ccache-wrappers && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/cc && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/$(basename /usr/bin/gcc) RUN pip3 install \ meson==0.49.0 ENV LANG "en_US.UTF-8" + +ENV MAKE "/usr/bin/make" +ENV NINJA "/usr/bin/ninja" +ENV PYTHON "/usr/bin/python3" + +ENV CCACHE_WRAPPERSDIR "/usr/libexec/ccache-wrappers" diff --git a/buildenv-libvirt-centos-7.zip b/buildenv-libvirt-centos-7.zip index 96cd758..d6dc2e6 100644 --- a/buildenv-libvirt-centos-7.zip +++ b/buildenv-libvirt-centos-7.zip @@ -118,9 +118,18 @@ WEiJKtQrZDJloqtyi/mmRa1VsV7RYR0VPJjhK/R8EQ7Ysshy\n\ xfsprogs-devel \ yajl-devel && \ yum autoremove -y && \ - yum clean all -y + yum clean all -y && \ + mkdir -p /usr/libexec/ccache-wrappers && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/cc && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/$(basename /usr/bin/gcc) RUN pip3 install \ meson==0.49.0 ENV LANG "en_US.UTF-8" + +ENV MAKE "/usr/bin/make" +ENV NINJA "/usr/bin/ninja-build" +ENV PYTHON "/usr/bin/python3" + +ENV CCACHE_WRAPPERSDIR "/usr/libexec/ccache-wrappers" diff --git a/buildenv-libvirt-centos-8.zip b/buildenv-libvirt-centos-8.zip index a63524b..a83cd07 100644 --- a/buildenv-libvirt-centos-8.zip +++ b/buildenv-libvirt-centos-8.zip @@ -91,6 +91,15 @@ RUN dnf install 'dnf-command(config-manager)' -y && \ xfsprogs-devel \ yajl-devel && \ dnf autoremove -y && \ - dnf clean all -y + dnf clean all -y && \ + mkdir -p /usr/libexec/ccache-wrappers && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/cc && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/$(basename /usr/bin/gcc) ENV LANG "en_US.UTF-8" + +ENV MAKE "/usr/bin/make" +ENV NINJA "/usr/bin/ninja" +ENV PYTHON "/usr/bin/python3" + +ENV CCACHE_WRAPPERSDIR "/usr/libexec/ccache-wrappers" diff --git a/buildenv-libvirt-debian-10-cross-aarch64.zip b/buildenv-libvirt-debian-10-cross-aarch64.zip index 9bdfe9c..65c1169 100644 --- a/buildenv-libvirt-debian-10-cross-aarch64.zip +++ b/buildenv-libvirt-debian-10-cross-aarch64.zip @@ -58,7 +58,10 @@ RUN export DEBIAN_FRONTEND=noninteractive && \ apt-get autoremove -y && \ apt-get autoclean -y && \ sed -Ei 's,^# (en_US\.UTF-8 .*)$,\1,' /etc/locale.gen && \ - dpkg-reconfigure locales + dpkg-reconfigure locales && \ + mkdir -p /usr/libexec/ccache-wrappers && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/aarch64-linux-gnu-cc && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/aarch64-linux-gnu-$(basename /usr/bin/gcc) RUN export DEBIAN_FRONTEND=noninteractive && \ dpkg --add-architecture arm64 && \ @@ -108,5 +111,11 @@ RUN export DEBIAN_FRONTEND=noninteractive && \ ENV LANG "en_US.UTF-8" +ENV MAKE "/usr/bin/make" +ENV NINJA "/usr/bin/ninja" +ENV PYTHON "/usr/bin/python3" + +ENV CCACHE_WRAPPERSDIR "/usr/libexec/ccache-wrappers" + ENV ABI "aarch64-linux-gnu" ENV CONFIGURE_OPTS "--host=aarch64-linux-gnu" diff --git a/buildenv-libvirt-debian-10-cross-armv6l.zip b/buildenv-libvirt-debian-10-cross-armv6l.zip index 84df535..0291ad7 100644 --- a/buildenv-libvirt-debian-10-cross-armv6l.zip +++ b/buildenv-libvirt-debian-10-cross-armv6l.zip @@ -58,7 +58,10 @@ RUN export DEBIAN_FRONTEND=noninteractive && \ apt-get autoremove -y && \ apt-get autoclean -y && \ sed -Ei 's,^# (en_US\.UTF-8 .*)$,\1,' /etc/locale.gen && \ - dpkg-reconfigure locales + dpkg-reconfigure locales && \ + mkdir -p /usr/libexec/ccache-wrappers && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/arm-linux-gnueabi-cc && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/arm-linux-gnueabi-$(basename /usr/bin/gcc) RUN export DEBIAN_FRONTEND=noninteractive && \ dpkg --add-architecture armel && \ @@ -106,5 +109,11 @@ RUN export DEBIAN_FRONTEND=noninteractive && \ ENV LANG "en_US.UTF-8" +ENV MAKE "/usr/bin/make" +ENV NINJA "/usr/bin/ninja" +ENV PYTHON "/usr/bin/python3" + +ENV CCACHE_WRAPPERSDIR "/usr/libexec/ccache-wrappers" + ENV ABI "arm-linux-gnueabi" ENV CONFIGURE_OPTS "--host=arm-linux-gnueabi" diff --git a/buildenv-libvirt-debian-10-cross-armv7l.zip b/buildenv-libvirt-debian-10-cross-armv7l.zip index fa1b9ce..3a804ce 100644 --- a/buildenv-libvirt-debian-10-cross-armv7l.zip +++ b/buildenv-libvirt-debian-10-cross-armv7l.zip @@ -58,7 +58,10 @@ RUN export DEBIAN_FRONTEND=noninteractive && \ apt-get autoremove -y && \ apt-get autoclean -y && \ sed -Ei 's,^# (en_US\.UTF-8 .*)$,\1,' /etc/locale.gen && \ - dpkg-reconfigure locales + dpkg-reconfigure locales && \ + mkdir -p /usr/libexec/ccache-wrappers && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/arm-linux-gnueabihf-cc && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/arm-linux-gnueabihf-$(basename /usr/bin/gcc) RUN export DEBIAN_FRONTEND=noninteractive && \ dpkg --add-architecture armhf && \ @@ -107,5 +110,11 @@ RUN export DEBIAN_FRONTEND=noninteractive && \ ENV LANG "en_US.UTF-8" +ENV MAKE "/usr/bin/make" +ENV NINJA "/usr/bin/ninja" +ENV PYTHON "/usr/bin/python3" + +ENV CCACHE_WRAPPERSDIR "/usr/libexec/ccache-wrappers" + ENV ABI "arm-linux-gnueabihf" ENV CONFIGURE_OPTS "--host=arm-linux-gnueabihf" diff --git a/buildenv-libvirt-debian-10-cross-i686.zip b/buildenv-libvirt-debian-10-cross-i686.zip index 22903cf..7ae41c0 100644 --- a/buildenv-libvirt-debian-10-cross-i686.zip +++ b/buildenv-libvirt-debian-10-cross-i686.zip @@ -58,7 +58,10 @@ RUN export DEBIAN_FRONTEND=noninteractive && \ apt-get autoremove -y && \ apt-get autoclean -y && \ sed -Ei 's,^# (en_US\.UTF-8 .*)$,\1,' /etc/locale.gen && \ - dpkg-reconfigure locales + dpkg-reconfigure locales && \ + mkdir -p /usr/libexec/ccache-wrappers && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/i686-linux-gnu-cc && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/i686-linux-gnu-$(basename /usr/bin/gcc) RUN export DEBIAN_FRONTEND=noninteractive && \ dpkg --add-architecture i386 && \ @@ -107,5 +110,11 @@ RUN export DEBIAN_FRONTEND=noninteractive && \ ENV LANG "en_US.UTF-8" +ENV MAKE "/usr/bin/make" +ENV NINJA "/usr/bin/ninja" +ENV PYTHON "/usr/bin/python3" + +ENV CCACHE_WRAPPERSDIR "/usr/libexec/ccache-wrappers" + ENV ABI "i686-linux-gnu" ENV CONFIGURE_OPTS "--host=i686-linux-gnu" diff --git a/buildenv-libvirt-debian-10-cross-mips.zip b/buildenv-libvirt-debian-10-cross-mips.zip index 2beba75..e09c5b8 100644 --- a/buildenv-libvirt-debian-10-cross-mips.zip +++ b/buildenv-libvirt-debian-10-cross-mips.zip @@ -58,7 +58,10 @@ RUN export DEBIAN_FRONTEND=noninteractive && \ apt-get autoremove -y && \ apt-get autoclean -y && \ sed -Ei 's,^# (en_US\.UTF-8 .*)$,\1,' /etc/locale.gen && \ - dpkg-reconfigure locales + dpkg-reconfigure locales && \ + mkdir -p /usr/libexec/ccache-wrappers && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/mips-linux-gnu-cc && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/mips-linux-gnu-$(basename /usr/bin/gcc) RUN export DEBIAN_FRONTEND=noninteractive && \ dpkg --add-architecture mips && \ @@ -107,5 +110,11 @@ RUN export DEBIAN_FRONTEND=noninteractive && \ ENV LANG "en_US.UTF-8" +ENV MAKE "/usr/bin/make" +ENV NINJA "/usr/bin/ninja" +ENV PYTHON "/usr/bin/python3" + +ENV CCACHE_WRAPPERSDIR "/usr/libexec/ccache-wrappers" + ENV ABI "mips-linux-gnu" ENV CONFIGURE_OPTS "--host=mips-linux-gnu" diff --git a/buildenv-libvirt-debian-10-cross-mips64el.zip b/buildenv-libvirt-debian-10-cross-mips64el.zip index c900d7a..bb4b78c 100644 --- a/buildenv-libvirt-debian-10-cross-mips64el.zip +++ b/buildenv-libvirt-debian-10-cross-mips64el.zip @@ -58,7 +58,10 @@ RUN export DEBIAN_FRONTEND=noninteractive && \ apt-get autoremove -y && \ apt-get autoclean -y && \ sed -Ei 's,^# (en_US\.UTF-8 .*)$,\1,' /etc/locale.gen && \ - dpkg-reconfigure locales + dpkg-reconfigure locales && \ + mkdir -p /usr/libexec/ccache-wrappers && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/mips64el-linux-gnuabi64-cc && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/mips64el-linux-gnuabi64-$(basename /usr/bin/gcc) RUN export DEBIAN_FRONTEND=noninteractive && \ dpkg --add-architecture mips64el && \ @@ -107,5 +110,11 @@ RUN export DEBIAN_FRONTEND=noninteractive && \ ENV LANG "en_US.UTF-8" +ENV MAKE "/usr/bin/make" +ENV NINJA "/usr/bin/ninja" +ENV PYTHON "/usr/bin/python3" + +ENV CCACHE_WRAPPERSDIR "/usr/libexec/ccache-wrappers" + ENV ABI "mips64el-linux-gnuabi64" ENV CONFIGURE_OPTS "--host=mips64el-linux-gnuabi64" diff --git a/buildenv-libvirt-debian-10-cross-mipsel.zip b/buildenv-libvirt-debian-10-cross-mipsel.zip index ae436b6..3b26f2d 100644 --- a/buildenv-libvirt-debian-10-cross-mipsel.zip +++ b/buildenv-libvirt-debian-10-cross-mipsel.zip @@ -58,7 +58,10 @@ RUN export DEBIAN_FRONTEND=noninteractive && \ apt-get autoremove -y && \ apt-get autoclean -y && \ sed -Ei 's,^# (en_US\.UTF-8 .*)$,\1,' /etc/locale.gen && \ - dpkg-reconfigure locales + dpkg-reconfigure locales && \ + mkdir -p /usr/libexec/ccache-wrappers && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/mipsel-linux-gnu-cc && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/mipsel-linux-gnu-$(basename /usr/bin/gcc) RUN export DEBIAN_FRONTEND=noninteractive && \ dpkg --add-architecture mipsel && \ @@ -107,5 +110,11 @@ RUN export DEBIAN_FRONTEND=noninteractive && \ ENV LANG "en_US.UTF-8" +ENV MAKE "/usr/bin/make" +ENV NINJA "/usr/bin/ninja" +ENV PYTHON "/usr/bin/python3" + +ENV CCACHE_WRAPPERSDIR "/usr/libexec/ccache-wrappers" + ENV ABI "mipsel-linux-gnu" ENV CONFIGURE_OPTS "--host=mipsel-linux-gnu" diff --git a/buildenv-libvirt-debian-10-cross-ppc64le.zip b/buildenv-libvirt-debian-10-cross-ppc64le.zip index 475681a..ff3eabb 100644 --- a/buildenv-libvirt-debian-10-cross-ppc64le.zip +++ b/buildenv-libvirt-debian-10-cross-ppc64le.zip @@ -58,7 +58,10 @@ RUN export DEBIAN_FRONTEND=noninteractive && \ apt-get autoremove -y && \ apt-get autoclean -y && \ sed -Ei 's,^# (en_US\.UTF-8 .*)$,\1,' /etc/locale.gen && \ - dpkg-reconfigure locales + dpkg-reconfigure locales && \ + mkdir -p /usr/libexec/ccache-wrappers && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/powerpc64le-linux-gnu-cc && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/powerpc64le-linux-gnu-$(basename /usr/bin/gcc) RUN export DEBIAN_FRONTEND=noninteractive && \ dpkg --add-architecture ppc64el && \ @@ -107,5 +110,11 @@ RUN export DEBIAN_FRONTEND=noninteractive && \ ENV LANG "en_US.UTF-8" +ENV MAKE "/usr/bin/make" +ENV NINJA "/usr/bin/ninja" +ENV PYTHON "/usr/bin/python3" + +ENV CCACHE_WRAPPERSDIR "/usr/libexec/ccache-wrappers" + ENV ABI "powerpc64le-linux-gnu" ENV CONFIGURE_OPTS "--host=powerpc64le-linux-gnu" diff --git a/buildenv-libvirt-debian-10-cross-s390x.zip b/buildenv-libvirt-debian-10-cross-s390x.zip index 6e88d47..3a2dd96 100644 --- a/buildenv-libvirt-debian-10-cross-s390x.zip +++ b/buildenv-libvirt-debian-10-cross-s390x.zip @@ -58,7 +58,10 @@ RUN export DEBIAN_FRONTEND=noninteractive && \ apt-get autoremove -y && \ apt-get autoclean -y && \ sed -Ei 's,^# (en_US\.UTF-8 .*)$,\1,' /etc/locale.gen && \ - dpkg-reconfigure locales + dpkg-reconfigure locales && \ + mkdir -p /usr/libexec/ccache-wrappers && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/s390x-linux-gnu-cc && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/s390x-linux-gnu-$(basename /usr/bin/gcc) RUN export DEBIAN_FRONTEND=noninteractive && \ dpkg --add-architecture s390x && \ @@ -107,5 +110,11 @@ RUN export DEBIAN_FRONTEND=noninteractive && \ ENV LANG "en_US.UTF-8" +ENV MAKE "/usr/bin/make" +ENV NINJA "/usr/bin/ninja" +ENV PYTHON "/usr/bin/python3" + +ENV CCACHE_WRAPPERSDIR "/usr/libexec/ccache-wrappers" + ENV ABI "s390x-linux-gnu" ENV CONFIGURE_OPTS "--host=s390x-linux-gnu" diff --git a/buildenv-libvirt-debian-10.zip b/buildenv-libvirt-debian-10.zip index 4b4a6e2..56022ea 100644 --- a/buildenv-libvirt-debian-10.zip +++ b/buildenv-libvirt-debian-10.zip @@ -97,6 +97,15 @@ RUN export DEBIAN_FRONTEND=noninteractive && \ apt-get autoremove -y && \ apt-get autoclean -y && \ sed -Ei 's,^# (en_US\.UTF-8 .*)$,\1,' /etc/locale.gen && \ - dpkg-reconfigure locales + dpkg-reconfigure locales && \ + mkdir -p /usr/libexec/ccache-wrappers && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/cc && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/$(basename /usr/bin/gcc) ENV LANG "en_US.UTF-8" + +ENV MAKE "/usr/bin/make" +ENV NINJA "/usr/bin/ninja" +ENV PYTHON "/usr/bin/python3" + +ENV CCACHE_WRAPPERSDIR "/usr/libexec/ccache-wrappers" diff --git a/buildenv-libvirt-debian-9-cross-aarch64.zip b/buildenv-libvirt-debian-9-cross-aarch64.zip index 37752fc..204b547 100644 --- a/buildenv-libvirt-debian-9-cross-aarch64.zip +++ b/buildenv-libvirt-debian-9-cross-aarch64.zip @@ -59,7 +59,10 @@ RUN export DEBIAN_FRONTEND=noninteractive && \ apt-get autoremove -y && \ apt-get autoclean -y && \ sed -Ei 's,^# (en_US\.UTF-8 .*)$,\1,' /etc/locale.gen && \ - dpkg-reconfigure locales + dpkg-reconfigure locales && \ + mkdir -p /usr/libexec/ccache-wrappers && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/aarch64-linux-gnu-cc && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/aarch64-linux-gnu-$(basename /usr/bin/gcc) RUN export DEBIAN_FRONTEND=noninteractive && \ dpkg --add-architecture arm64 && \ @@ -112,5 +115,11 @@ RUN pip3 install \ ENV LANG "en_US.UTF-8" +ENV MAKE "/usr/bin/make" +ENV NINJA "/usr/bin/ninja" +ENV PYTHON "/usr/bin/python3" + +ENV CCACHE_WRAPPERSDIR "/usr/libexec/ccache-wrappers" + ENV ABI "aarch64-linux-gnu" ENV CONFIGURE_OPTS "--host=aarch64-linux-gnu" diff --git a/buildenv-libvirt-debian-9-cross-armv6l.zip b/buildenv-libvirt-debian-9-cross-armv6l.zip index 66c50ae..97787a3 100644 --- a/buildenv-libvirt-debian-9-cross-armv6l.zip +++ b/buildenv-libvirt-debian-9-cross-armv6l.zip @@ -59,7 +59,10 @@ RUN export DEBIAN_FRONTEND=noninteractive && \ apt-get autoremove -y && \ apt-get autoclean -y && \ sed -Ei 's,^# (en_US\.UTF-8 .*)$,\1,' /etc/locale.gen && \ - dpkg-reconfigure locales + dpkg-reconfigure locales && \ + mkdir -p /usr/libexec/ccache-wrappers && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/arm-linux-gnueabi-cc && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/arm-linux-gnueabi-$(basename /usr/bin/gcc) RUN export DEBIAN_FRONTEND=noninteractive && \ dpkg --add-architecture armel && \ @@ -110,5 +113,11 @@ RUN pip3 install \ ENV LANG "en_US.UTF-8" +ENV MAKE "/usr/bin/make" +ENV NINJA "/usr/bin/ninja" +ENV PYTHON "/usr/bin/python3" + +ENV CCACHE_WRAPPERSDIR "/usr/libexec/ccache-wrappers" + ENV ABI "arm-linux-gnueabi" ENV CONFIGURE_OPTS "--host=arm-linux-gnueabi" diff --git a/buildenv-libvirt-debian-9-cross-armv7l.zip b/buildenv-libvirt-debian-9-cross-armv7l.zip index 8102db9..52f4e2f 100644 --- a/buildenv-libvirt-debian-9-cross-armv7l.zip +++ b/buildenv-libvirt-debian-9-cross-armv7l.zip @@ -59,7 +59,10 @@ RUN export DEBIAN_FRONTEND=noninteractive && \ apt-get autoremove -y && \ apt-get autoclean -y && \ sed -Ei 's,^# (en_US\.UTF-8 .*)$,\1,' /etc/locale.gen && \ - dpkg-reconfigure locales + dpkg-reconfigure locales && \ + mkdir -p /usr/libexec/ccache-wrappers && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/arm-linux-gnueabihf-cc && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/arm-linux-gnueabihf-$(basename /usr/bin/gcc) RUN export DEBIAN_FRONTEND=noninteractive && \ dpkg --add-architecture armhf && \ @@ -111,5 +114,11 @@ RUN pip3 install \ ENV LANG "en_US.UTF-8" +ENV MAKE "/usr/bin/make" +ENV NINJA "/usr/bin/ninja" +ENV PYTHON "/usr/bin/python3" + +ENV CCACHE_WRAPPERSDIR "/usr/libexec/ccache-wrappers" + ENV ABI "arm-linux-gnueabihf" ENV CONFIGURE_OPTS "--host=arm-linux-gnueabihf" diff --git a/buildenv-libvirt-debian-9-cross-mips.zip b/buildenv-libvirt-debian-9-cross-mips.zip index 739fc5e..16f1b91 100644 --- a/buildenv-libvirt-debian-9-cross-mips.zip +++ b/buildenv-libvirt-debian-9-cross-mips.zip @@ -59,7 +59,10 @@ RUN export DEBIAN_FRONTEND=noninteractive && \ apt-get autoremove -y && \ apt-get autoclean -y && \ sed -Ei 's,^# (en_US\.UTF-8 .*)$,\1,' /etc/locale.gen && \ - dpkg-reconfigure locales + dpkg-reconfigure locales && \ + mkdir -p /usr/libexec/ccache-wrappers && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/mips-linux-gnu-cc && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/mips-linux-gnu-$(basename /usr/bin/gcc) RUN export DEBIAN_FRONTEND=noninteractive && \ dpkg --add-architecture mips && \ @@ -111,5 +114,11 @@ RUN pip3 install \ ENV LANG "en_US.UTF-8" +ENV MAKE "/usr/bin/make" +ENV NINJA "/usr/bin/ninja" +ENV PYTHON "/usr/bin/python3" + +ENV CCACHE_WRAPPERSDIR "/usr/libexec/ccache-wrappers" + ENV ABI "mips-linux-gnu" ENV CONFIGURE_OPTS "--host=mips-linux-gnu" diff --git a/buildenv-libvirt-debian-9-cross-mips64el.zip b/buildenv-libvirt-debian-9-cross-mips64el.zip index 3d38e7c..8090a60 100644 --- a/buildenv-libvirt-debian-9-cross-mips64el.zip +++ b/buildenv-libvirt-debian-9-cross-mips64el.zip @@ -59,7 +59,10 @@ RUN export DEBIAN_FRONTEND=noninteractive && \ apt-get autoremove -y && \ apt-get autoclean -y && \ sed -Ei 's,^# (en_US\.UTF-8 .*)$,\1,' /etc/locale.gen && \ - dpkg-reconfigure locales + dpkg-reconfigure locales && \ + mkdir -p /usr/libexec/ccache-wrappers && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/mips64el-linux-gnuabi64-cc && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/mips64el-linux-gnuabi64-$(basename /usr/bin/gcc) RUN export DEBIAN_FRONTEND=noninteractive && \ dpkg --add-architecture mips64el && \ @@ -111,5 +114,11 @@ RUN pip3 install \ ENV LANG "en_US.UTF-8" +ENV MAKE "/usr/bin/make" +ENV NINJA "/usr/bin/ninja" +ENV PYTHON "/usr/bin/python3" + +ENV CCACHE_WRAPPERSDIR "/usr/libexec/ccache-wrappers" + ENV ABI "mips64el-linux-gnuabi64" ENV CONFIGURE_OPTS "--host=mips64el-linux-gnuabi64" diff --git a/buildenv-libvirt-debian-9-cross-mipsel.zip b/buildenv-libvirt-debian-9-cross-mipsel.zip index d8af5f5..a7829ee 100644 --- a/buildenv-libvirt-debian-9-cross-mipsel.zip +++ b/buildenv-libvirt-debian-9-cross-mipsel.zip @@ -59,7 +59,10 @@ RUN export DEBIAN_FRONTEND=noninteractive && \ apt-get autoremove -y && \ apt-get autoclean -y && \ sed -Ei 's,^# (en_US\.UTF-8 .*)$,\1,' /etc/locale.gen && \ - dpkg-reconfigure locales + dpkg-reconfigure locales && \ + mkdir -p /usr/libexec/ccache-wrappers && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/mipsel-linux-gnu-cc && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/mipsel-linux-gnu-$(basename /usr/bin/gcc) RUN export DEBIAN_FRONTEND=noninteractive && \ dpkg --add-architecture mipsel && \ @@ -111,5 +114,11 @@ RUN pip3 install \ ENV LANG "en_US.UTF-8" +ENV MAKE "/usr/bin/make" +ENV NINJA "/usr/bin/ninja" +ENV PYTHON "/usr/bin/python3" + +ENV CCACHE_WRAPPERSDIR "/usr/libexec/ccache-wrappers" + ENV ABI "mipsel-linux-gnu" ENV CONFIGURE_OPTS "--host=mipsel-linux-gnu" diff --git a/buildenv-libvirt-debian-9-cross-ppc64le.zip b/buildenv-libvirt-debian-9-cross-ppc64le.zip index b53581c..8707f80 100644 --- a/buildenv-libvirt-debian-9-cross-ppc64le.zip +++ b/buildenv-libvirt-debian-9-cross-ppc64le.zip @@ -59,7 +59,10 @@ RUN export DEBIAN_FRONTEND=noninteractive && \ apt-get autoremove -y && \ apt-get autoclean -y && \ sed -Ei 's,^# (en_US\.UTF-8 .*)$,\1,' /etc/locale.gen && \ - dpkg-reconfigure locales + dpkg-reconfigure locales && \ + mkdir -p /usr/libexec/ccache-wrappers && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/powerpc64le-linux-gnu-cc && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/powerpc64le-linux-gnu-$(basename /usr/bin/gcc) RUN export DEBIAN_FRONTEND=noninteractive && \ dpkg --add-architecture ppc64el && \ @@ -111,5 +114,11 @@ RUN pip3 install \ ENV LANG "en_US.UTF-8" +ENV MAKE "/usr/bin/make" +ENV NINJA "/usr/bin/ninja" +ENV PYTHON "/usr/bin/python3" + +ENV CCACHE_WRAPPERSDIR "/usr/libexec/ccache-wrappers" + ENV ABI "powerpc64le-linux-gnu" ENV CONFIGURE_OPTS "--host=powerpc64le-linux-gnu" diff --git a/buildenv-libvirt-debian-9-cross-s390x.zip b/buildenv-libvirt-debian-9-cross-s390x.zip index 2c9273f..503828f 100644 --- a/buildenv-libvirt-debian-9-cross-s390x.zip +++ b/buildenv-libvirt-debian-9-cross-s390x.zip @@ -59,7 +59,10 @@ RUN export DEBIAN_FRONTEND=noninteractive && \ apt-get autoremove -y && \ apt-get autoclean -y && \ sed -Ei 's,^# (en_US\.UTF-8 .*)$,\1,' /etc/locale.gen && \ - dpkg-reconfigure locales + dpkg-reconfigure locales && \ + mkdir -p /usr/libexec/ccache-wrappers && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/s390x-linux-gnu-cc && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/s390x-linux-gnu-$(basename /usr/bin/gcc) RUN export DEBIAN_FRONTEND=noninteractive && \ dpkg --add-architecture s390x && \ @@ -111,5 +114,11 @@ RUN pip3 install \ ENV LANG "en_US.UTF-8" +ENV MAKE "/usr/bin/make" +ENV NINJA "/usr/bin/ninja" +ENV PYTHON "/usr/bin/python3" + +ENV CCACHE_WRAPPERSDIR "/usr/libexec/ccache-wrappers" + ENV ABI "s390x-linux-gnu" ENV CONFIGURE_OPTS "--host=s390x-linux-gnu" diff --git a/buildenv-libvirt-debian-9.zip b/buildenv-libvirt-debian-9.zip index 66ca52f..b4cf4c9 100644 --- a/buildenv-libvirt-debian-9.zip +++ b/buildenv-libvirt-debian-9.zip @@ -98,9 +98,18 @@ RUN export DEBIAN_FRONTEND=noninteractive && \ apt-get autoremove -y && \ apt-get autoclean -y && \ sed -Ei 's,^# (en_US\.UTF-8 .*)$,\1,' /etc/locale.gen && \ - dpkg-reconfigure locales + dpkg-reconfigure locales && \ + mkdir -p /usr/libexec/ccache-wrappers && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/cc && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/$(basename /usr/bin/gcc) RUN pip3 install \ meson==0.49.0 ENV LANG "en_US.UTF-8" + +ENV MAKE "/usr/bin/make" +ENV NINJA "/usr/bin/ninja" +ENV PYTHON "/usr/bin/python3" + +ENV CCACHE_WRAPPERSDIR "/usr/libexec/ccache-wrappers" diff --git a/buildenv-libvirt-debian-sid-cross-aarch64.zip b/buildenv-libvirt-debian-sid-cross-aarch64.zip index 79262a1..bb3edc2 100644 --- a/buildenv-libvirt-debian-sid-cross-aarch64.zip +++ b/buildenv-libvirt-debian-sid-cross-aarch64.zip @@ -58,7 +58,10 @@ RUN export DEBIAN_FRONTEND=noninteractive && \ apt-get autoremove -y && \ apt-get autoclean -y && \ sed -Ei 's,^# (en_US\.UTF-8 .*)$,\1,' /etc/locale.gen && \ - dpkg-reconfigure locales + dpkg-reconfigure locales && \ + mkdir -p /usr/libexec/ccache-wrappers && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/aarch64-linux-gnu-cc && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/aarch64-linux-gnu-$(basename /usr/bin/gcc) RUN export DEBIAN_FRONTEND=noninteractive && \ dpkg --add-architecture arm64 && \ @@ -108,5 +111,11 @@ RUN export DEBIAN_FRONTEND=noninteractive && \ ENV LANG "en_US.UTF-8" +ENV MAKE "/usr/bin/make" +ENV NINJA "/usr/bin/ninja" +ENV PYTHON "/usr/bin/python3" + +ENV CCACHE_WRAPPERSDIR "/usr/libexec/ccache-wrappers" + ENV ABI "aarch64-linux-gnu" ENV CONFIGURE_OPTS "--host=aarch64-linux-gnu" diff --git a/buildenv-libvirt-debian-sid-cross-armv6l.zip b/buildenv-libvirt-debian-sid-cross-armv6l.zip index 682334f..d7ba3d1 100644 --- a/buildenv-libvirt-debian-sid-cross-armv6l.zip +++ b/buildenv-libvirt-debian-sid-cross-armv6l.zip @@ -58,7 +58,10 @@ RUN export DEBIAN_FRONTEND=noninteractive && \ apt-get autoremove -y && \ apt-get autoclean -y && \ sed -Ei 's,^# (en_US\.UTF-8 .*)$,\1,' /etc/locale.gen && \ - dpkg-reconfigure locales + dpkg-reconfigure locales && \ + mkdir -p /usr/libexec/ccache-wrappers && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/arm-linux-gnueabi-cc && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/arm-linux-gnueabi-$(basename /usr/bin/gcc) RUN export DEBIAN_FRONTEND=noninteractive && \ dpkg --add-architecture armel && \ @@ -106,5 +109,11 @@ RUN export DEBIAN_FRONTEND=noninteractive && \ ENV LANG "en_US.UTF-8" +ENV MAKE "/usr/bin/make" +ENV NINJA "/usr/bin/ninja" +ENV PYTHON "/usr/bin/python3" + +ENV CCACHE_WRAPPERSDIR "/usr/libexec/ccache-wrappers" + ENV ABI "arm-linux-gnueabi" ENV CONFIGURE_OPTS "--host=arm-linux-gnueabi" diff --git a/buildenv-libvirt-debian-sid-cross-armv7l.zip b/buildenv-libvirt-debian-sid-cross-armv7l.zip index 529676e..532722b 100644 --- a/buildenv-libvirt-debian-sid-cross-armv7l.zip +++ b/buildenv-libvirt-debian-sid-cross-armv7l.zip @@ -58,7 +58,10 @@ RUN export DEBIAN_FRONTEND=noninteractive && \ apt-get autoremove -y && \ apt-get autoclean -y && \ sed -Ei 's,^# (en_US\.UTF-8 .*)$,\1,' /etc/locale.gen && \ - dpkg-reconfigure locales + dpkg-reconfigure locales && \ + mkdir -p /usr/libexec/ccache-wrappers && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/arm-linux-gnueabihf-cc && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/arm-linux-gnueabihf-$(basename /usr/bin/gcc) RUN export DEBIAN_FRONTEND=noninteractive && \ dpkg --add-architecture armhf && \ @@ -107,5 +110,11 @@ RUN export DEBIAN_FRONTEND=noninteractive && \ ENV LANG "en_US.UTF-8" +ENV MAKE "/usr/bin/make" +ENV NINJA "/usr/bin/ninja" +ENV PYTHON "/usr/bin/python3" + +ENV CCACHE_WRAPPERSDIR "/usr/libexec/ccache-wrappers" + ENV ABI "arm-linux-gnueabihf" ENV CONFIGURE_OPTS "--host=arm-linux-gnueabihf" diff --git a/buildenv-libvirt-debian-sid-cross-i686.zip b/buildenv-libvirt-debian-sid-cross-i686.zip index 46abb22..1fcde39 100644 --- a/buildenv-libvirt-debian-sid-cross-i686.zip +++ b/buildenv-libvirt-debian-sid-cross-i686.zip @@ -58,7 +58,10 @@ RUN export DEBIAN_FRONTEND=noninteractive && \ apt-get autoremove -y && \ apt-get autoclean -y && \ sed -Ei 's,^# (en_US\.UTF-8 .*)$,\1,' /etc/locale.gen && \ - dpkg-reconfigure locales + dpkg-reconfigure locales && \ + mkdir -p /usr/libexec/ccache-wrappers && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/i686-linux-gnu-cc && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/i686-linux-gnu-$(basename /usr/bin/gcc) RUN export DEBIAN_FRONTEND=noninteractive && \ dpkg --add-architecture i386 && \ @@ -107,5 +110,11 @@ RUN export DEBIAN_FRONTEND=noninteractive && \ ENV LANG "en_US.UTF-8" +ENV MAKE "/usr/bin/make" +ENV NINJA "/usr/bin/ninja" +ENV PYTHON "/usr/bin/python3" + +ENV CCACHE_WRAPPERSDIR "/usr/libexec/ccache-wrappers" + ENV ABI "i686-linux-gnu" ENV CONFIGURE_OPTS "--host=i686-linux-gnu" diff --git a/buildenv-libvirt-debian-sid-cross-mips64el.zip b/buildenv-libvirt-debian-sid-cross-mips64el.zip index 799c6f1..4ef667d 100644 --- a/buildenv-libvirt-debian-sid-cross-mips64el.zip +++ b/buildenv-libvirt-debian-sid-cross-mips64el.zip @@ -58,7 +58,10 @@ RUN export DEBIAN_FRONTEND=noninteractive && \ apt-get autoremove -y && \ apt-get autoclean -y && \ sed -Ei 's,^# (en_US\.UTF-8 .*)$,\1,' /etc/locale.gen && \ - dpkg-reconfigure locales + dpkg-reconfigure locales && \ + mkdir -p /usr/libexec/ccache-wrappers && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/mips64el-linux-gnuabi64-cc && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/mips64el-linux-gnuabi64-$(basename /usr/bin/gcc) RUN export DEBIAN_FRONTEND=noninteractive && \ dpkg --add-architecture mips64el && \ @@ -107,5 +110,11 @@ RUN export DEBIAN_FRONTEND=noninteractive && \ ENV LANG "en_US.UTF-8" +ENV MAKE "/usr/bin/make" +ENV NINJA "/usr/bin/ninja" +ENV PYTHON "/usr/bin/python3" + +ENV CCACHE_WRAPPERSDIR "/usr/libexec/ccache-wrappers" + ENV ABI "mips64el-linux-gnuabi64" ENV CONFIGURE_OPTS "--host=mips64el-linux-gnuabi64" diff --git a/buildenv-libvirt-debian-sid-cross-mipsel.zip b/buildenv-libvirt-debian-sid-cross-mipsel.zip index 2cfbe46..15e3674 100644 --- a/buildenv-libvirt-debian-sid-cross-mipsel.zip +++ b/buildenv-libvirt-debian-sid-cross-mipsel.zip @@ -58,7 +58,10 @@ RUN export DEBIAN_FRONTEND=noninteractive && \ apt-get autoremove -y && \ apt-get autoclean -y && \ sed -Ei 's,^# (en_US\.UTF-8 .*)$,\1,' /etc/locale.gen && \ - dpkg-reconfigure locales + dpkg-reconfigure locales && \ + mkdir -p /usr/libexec/ccache-wrappers && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/mipsel-linux-gnu-cc && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/mipsel-linux-gnu-$(basename /usr/bin/gcc) RUN export DEBIAN_FRONTEND=noninteractive && \ dpkg --add-architecture mipsel && \ @@ -106,5 +109,11 @@ RUN export DEBIAN_FRONTEND=noninteractive && \ ENV LANG "en_US.UTF-8" +ENV MAKE "/usr/bin/make" +ENV NINJA "/usr/bin/ninja" +ENV PYTHON "/usr/bin/python3" + +ENV CCACHE_WRAPPERSDIR "/usr/libexec/ccache-wrappers" + ENV ABI "mipsel-linux-gnu" ENV CONFIGURE_OPTS "--host=mipsel-linux-gnu" diff --git a/buildenv-libvirt-debian-sid-cross-ppc64le.zip b/buildenv-libvirt-debian-sid-cross-ppc64le.zip index da70b99..314d5f7 100644 --- a/buildenv-libvirt-debian-sid-cross-ppc64le.zip +++ b/buildenv-libvirt-debian-sid-cross-ppc64le.zip @@ -58,7 +58,10 @@ RUN export DEBIAN_FRONTEND=noninteractive && \ apt-get autoremove -y && \ apt-get autoclean -y && \ sed -Ei 's,^# (en_US\.UTF-8 .*)$,\1,' /etc/locale.gen && \ - dpkg-reconfigure locales + dpkg-reconfigure locales && \ + mkdir -p /usr/libexec/ccache-wrappers && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/powerpc64le-linux-gnu-cc && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/powerpc64le-linux-gnu-$(basename /usr/bin/gcc) RUN export DEBIAN_FRONTEND=noninteractive && \ dpkg --add-architecture ppc64el && \ @@ -107,5 +110,11 @@ RUN export DEBIAN_FRONTEND=noninteractive && \ ENV LANG "en_US.UTF-8" +ENV MAKE "/usr/bin/make" +ENV NINJA "/usr/bin/ninja" +ENV PYTHON "/usr/bin/python3" + +ENV CCACHE_WRAPPERSDIR "/usr/libexec/ccache-wrappers" + ENV ABI "powerpc64le-linux-gnu" ENV CONFIGURE_OPTS "--host=powerpc64le-linux-gnu" diff --git a/buildenv-libvirt-debian-sid-cross-s390x.zip b/buildenv-libvirt-debian-sid-cross-s390x.zip index d5b1174..a765a13 100644 --- a/buildenv-libvirt-debian-sid-cross-s390x.zip +++ b/buildenv-libvirt-debian-sid-cross-s390x.zip @@ -58,7 +58,10 @@ RUN export DEBIAN_FRONTEND=noninteractive && \ apt-get autoremove -y && \ apt-get autoclean -y && \ sed -Ei 's,^# (en_US\.UTF-8 .*)$,\1,' /etc/locale.gen && \ - dpkg-reconfigure locales + dpkg-reconfigure locales && \ + mkdir -p /usr/libexec/ccache-wrappers && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/s390x-linux-gnu-cc && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/s390x-linux-gnu-$(basename /usr/bin/gcc) RUN export DEBIAN_FRONTEND=noninteractive && \ dpkg --add-architecture s390x && \ @@ -107,5 +110,11 @@ RUN export DEBIAN_FRONTEND=noninteractive && \ ENV LANG "en_US.UTF-8" +ENV MAKE "/usr/bin/make" +ENV NINJA "/usr/bin/ninja" +ENV PYTHON "/usr/bin/python3" + +ENV CCACHE_WRAPPERSDIR "/usr/libexec/ccache-wrappers" + ENV ABI "s390x-linux-gnu" ENV CONFIGURE_OPTS "--host=s390x-linux-gnu" diff --git a/buildenv-libvirt-debian-sid.zip b/buildenv-libvirt-debian-sid.zip index 46b1f52..b1daf91 100644 --- a/buildenv-libvirt-debian-sid.zip +++ b/buildenv-libvirt-debian-sid.zip @@ -97,6 +97,15 @@ RUN export DEBIAN_FRONTEND=noninteractive && \ apt-get autoremove -y && \ apt-get autoclean -y && \ sed -Ei 's,^# (en_US\.UTF-8 .*)$,\1,' /etc/locale.gen && \ - dpkg-reconfigure locales + dpkg-reconfigure locales && \ + mkdir -p /usr/libexec/ccache-wrappers && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/cc && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/$(basename /usr/bin/gcc) ENV LANG "en_US.UTF-8" + +ENV MAKE "/usr/bin/make" +ENV NINJA "/usr/bin/ninja" +ENV PYTHON "/usr/bin/python3" + +ENV CCACHE_WRAPPERSDIR "/usr/libexec/ccache-wrappers" diff --git a/buildenv-libvirt-fedora-30-cross-mingw32.zip b/buildenv-libvirt-fedora-30-cross-mingw32.zip index df8f7a7..ba90aa6 100644 --- a/buildenv-libvirt-fedora-30-cross-mingw32.zip +++ b/buildenv-libvirt-fedora-30-cross-mingw32.zip @@ -94,7 +94,10 @@ RUN dnf update -y && \ yajl-devel \ zfs-fuse && \ dnf autoremove -y && \ - dnf clean all -y + dnf clean all -y && \ + mkdir -p /usr/libexec/ccache-wrappers && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/i686-w64-mingw32-cc && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/i686-w64-mingw32-$(basename /usr/bin/gcc) RUN dnf install -y \ mingw32-curl \ @@ -114,5 +117,11 @@ RUN dnf install -y \ ENV LANG "en_US.UTF-8" +ENV MAKE "/usr/bin/make" +ENV NINJA "/usr/bin/ninja" +ENV PYTHON "/usr/bin/python3" + +ENV CCACHE_WRAPPERSDIR "/usr/libexec/ccache-wrappers" + ENV ABI "i686-w64-mingw32" ENV CONFIGURE_OPTS "--host=i686-w64-mingw32" diff --git a/buildenv-libvirt-fedora-30-cross-mingw64.zip b/buildenv-libvirt-fedora-30-cross-mingw64.zip index d2b79b8..ade62a8 100644 --- a/buildenv-libvirt-fedora-30-cross-mingw64.zip +++ b/buildenv-libvirt-fedora-30-cross-mingw64.zip @@ -94,7 +94,10 @@ RUN dnf update -y && \ yajl-devel \ zfs-fuse && \ dnf autoremove -y && \ - dnf clean all -y + dnf clean all -y && \ + mkdir -p /usr/libexec/ccache-wrappers && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/x86_64-w64-mingw32-cc && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/x86_64-w64-mingw32-$(basename /usr/bin/gcc) RUN dnf install -y \ mingw64-curl \ @@ -114,5 +117,11 @@ RUN dnf install -y \ ENV LANG "en_US.UTF-8" +ENV MAKE "/usr/bin/make" +ENV NINJA "/usr/bin/ninja" +ENV PYTHON "/usr/bin/python3" + +ENV CCACHE_WRAPPERSDIR "/usr/libexec/ccache-wrappers" + ENV ABI "x86_64-w64-mingw32" ENV CONFIGURE_OPTS "--host=x86_64-w64-mingw32" diff --git a/buildenv-libvirt-fedora-30.zip b/buildenv-libvirt-fedora-30.zip index ccc549e..dc31603 100644 --- a/buildenv-libvirt-fedora-30.zip +++ b/buildenv-libvirt-fedora-30.zip @@ -94,6 +94,15 @@ RUN dnf update -y && \ yajl-devel \ zfs-fuse && \ dnf autoremove -y && \ - dnf clean all -y + dnf clean all -y && \ + mkdir -p /usr/libexec/ccache-wrappers && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/cc && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/$(basename /usr/bin/gcc) ENV LANG "en_US.UTF-8" + +ENV MAKE "/usr/bin/make" +ENV NINJA "/usr/bin/ninja" +ENV PYTHON "/usr/bin/python3" + +ENV CCACHE_WRAPPERSDIR "/usr/libexec/ccache-wrappers" diff --git a/buildenv-libvirt-fedora-31.zip b/buildenv-libvirt-fedora-31.zip index 638a89f..10968af 100644 --- a/buildenv-libvirt-fedora-31.zip +++ b/buildenv-libvirt-fedora-31.zip @@ -94,6 +94,15 @@ RUN dnf update -y && \ yajl-devel \ zfs-fuse && \ dnf autoremove -y && \ - dnf clean all -y + dnf clean all -y && \ + mkdir -p /usr/libexec/ccache-wrappers && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/cc && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/$(basename /usr/bin/gcc) ENV LANG "en_US.UTF-8" + +ENV MAKE "/usr/bin/make" +ENV NINJA "/usr/bin/ninja" +ENV PYTHON "/usr/bin/python3" + +ENV CCACHE_WRAPPERSDIR "/usr/libexec/ccache-wrappers" diff --git a/buildenv-libvirt-fedora-rawhide.zip b/buildenv-libvirt-fedora-rawhide.zip index 5a53c70..cfb5ca9 100644 --- a/buildenv-libvirt-fedora-rawhide.zip +++ b/buildenv-libvirt-fedora-rawhide.zip @@ -95,6 +95,15 @@ RUN dnf update -y --nogpgcheck fedora-gpg-keys && \ yajl-devel \ zfs-fuse && \ dnf autoremove -y && \ - dnf clean all -y + dnf clean all -y && \ + mkdir -p /usr/libexec/ccache-wrappers && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/cc && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/$(basename /usr/bin/gcc) ENV LANG "en_US.UTF-8" + +ENV MAKE "/usr/bin/make" +ENV NINJA "/usr/bin/ninja" +ENV PYTHON "/usr/bin/python3" + +ENV CCACHE_WRAPPERSDIR "/usr/libexec/ccache-wrappers" diff --git a/buildenv-libvirt-opensuse-151.zip b/buildenv-libvirt-opensuse-151.zip index 1a835c5..0103270 100644 --- a/buildenv-libvirt-opensuse-151.zip +++ b/buildenv-libvirt-opensuse-151.zip @@ -91,9 +91,18 @@ RUN zypper update -y && \ wireshark-devel \ xen-devel \ xfsprogs-devel && \ - zypper clean --all + zypper clean --all && \ + mkdir -p /usr/libexec/ccache-wrappers && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/cc && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/$(basename /usr/bin/gcc) RUN pip3 install \ meson==0.49.0 ENV LANG "en_US.UTF-8" + +ENV MAKE "/usr/bin/make" +ENV NINJA "/usr/bin/ninja" +ENV PYTHON "/usr/bin/python3" + +ENV CCACHE_WRAPPERSDIR "/usr/libexec/ccache-wrappers" diff --git a/buildenv-libvirt-ubuntu-1604.zip b/buildenv-libvirt-ubuntu-1604.zip index 0713bf8..a4910a6 100644 --- a/buildenv-libvirt-ubuntu-1604.zip +++ b/buildenv-libvirt-ubuntu-1604.zip @@ -99,9 +99,18 @@ RUN export DEBIAN_FRONTEND=noninteractive && \ apt-get autoremove -y && \ apt-get autoclean -y && \ sed -Ei 's,^# (en_US\.UTF-8 .*)$,\1,' /etc/locale.gen && \ - dpkg-reconfigure locales + dpkg-reconfigure locales && \ + mkdir -p /usr/libexec/ccache-wrappers && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/cc && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/$(basename /usr/bin/gcc) RUN pip3 install \ meson==0.49.0 ENV LANG "en_US.UTF-8" + +ENV MAKE "/usr/bin/make" +ENV NINJA "/usr/bin/ninja" +ENV PYTHON "/usr/bin/python3" + +ENV CCACHE_WRAPPERSDIR "/usr/libexec/ccache-wrappers" diff --git a/buildenv-libvirt-ubuntu-1804.zip b/buildenv-libvirt-ubuntu-1804.zip index a18c97a..a52fcfb 100644 --- a/buildenv-libvirt-ubuntu-1804.zip +++ b/buildenv-libvirt-ubuntu-1804.zip @@ -99,9 +99,18 @@ RUN export DEBIAN_FRONTEND=noninteractive && \ apt-get autoremove -y && \ apt-get autoclean -y && \ sed -Ei 's,^# (en_US\.UTF-8 .*)$,\1,' /etc/locale.gen && \ - dpkg-reconfigure locales + dpkg-reconfigure locales && \ + mkdir -p /usr/libexec/ccache-wrappers && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/cc && \ + ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/$(basename /usr/bin/gcc) RUN pip3 install \ meson==0.49.0 ENV LANG "en_US.UTF-8" + +ENV MAKE "/usr/bin/make" +ENV NINJA "/usr/bin/ninja" +ENV PYTHON "/usr/bin/python3" + +ENV CCACHE_WRAPPERSDIR "/usr/libexec/ccache-wrappers" -- 2.25.1

1 0

[GSoC] Interested Student for the Project: 'Introducing job control to the storage driver'
by Prathamesh Chavan 30 Mar '20

30 Mar '20

Hi Everyone, I'm Prathamesh Chavan, a final year student at studying Computer Science and Engineering at IIT Kharagpur. I've been part of GSoC'17 under the Git Organization and have an internship experience at Nutanix, India during last summer. I'm also currently working on a tired file system with software wear management for nvm technologies as my master project. I was interested in contributing to the project: "Introducing job control to the storage driver" under Google Summer of Code - 2020. I was currently going through the codebase and also was successfully able to build it. It would be great if I was assigned a byte-task regarding the same which could help me understand the project better, Thanks, Prathamesh Chavan

3 5

[PATCH 0/5] Introduce getHost support for ARM cpus
by Zhenyu Zheng 30 Mar '20

30 Mar '20

Introduce getHost support for ARM cpus. First add some common ARM server models to cpu_map, then add some helper methods to parse and load them. The 'lscpu' command from 'util-linux' provides very good data for cpu information, we can parse them directly. Zhenyu Zheng (5): cpu_map: Introduce arm CPU models cpu: Introduce virCPUarmData to virCPUData cpu: Introduce arm related structs cpu: Add helper functions to parse vendor and model for ARM cpu: Introduce getHost supoort for ARM src/cpu/cpu.h | 2 + src/cpu/cpu_arm.c | 412 +++++++++++++++++++++++++++++- src/cpu/cpu_arm_data.h | 32 +++ src/cpu_map/Makefile.inc.am | 7 + src/cpu_map/arm_Falkor.xml | 15 ++ src/cpu_map/arm_Kunpeng-920.xml | 23 ++ src/cpu_map/arm_ThunderX299xx.xml | 15 ++ src/cpu_map/arm_cortex-a53.xml | 15 ++ src/cpu_map/arm_cortex-a57.xml | 14 + src/cpu_map/arm_cortex-a72.xml | 14 + src/cpu_map/arm_vendors.xml | 14 + src/cpu_map/index.xml | 16 ++ 12 files changed, 577 insertions(+), 2 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 8

[libvirt-jenkins-ci PATCH 0/3] lcitool: Include some paths in the generated Dockerfiles
by Andrea Bolognani 30 Mar '20

30 Mar '20

Andrea Bolognani (3): lcitool: Include paths in the inventory lcitool: Refactor varmap generation a bit lcitool: Include some paths in the generated Dockerfiles guests/host_vars/libvirt-centos-7/main.yml | 9 +++ guests/host_vars/libvirt-centos-8/main.yml | 9 +++ guests/host_vars/libvirt-debian-10/main.yml | 9 +++ guests/host_vars/libvirt-debian-9/main.yml | 9 +++ guests/host_vars/libvirt-debian-sid/main.yml | 9 +++ guests/host_vars/libvirt-fedora-30/main.yml | 9 +++ guests/host_vars/libvirt-fedora-31/main.yml | 9 +++ .../host_vars/libvirt-fedora-rawhide/main.yml | 9 +++ guests/host_vars/libvirt-freebsd-11/main.yml | 9 +++ guests/host_vars/libvirt-freebsd-12/main.yml | 9 +++ .../libvirt-freebsd-current/main.yml | 9 +++ .../host_vars/libvirt-opensuse-151/main.yml | 9 +++ guests/host_vars/libvirt-ubuntu-1604/main.yml | 9 +++ guests/host_vars/libvirt-ubuntu-1804/main.yml | 9 +++ guests/lcitool | 22 ++++-- guests/playbooks/update/main.yml | 1 - guests/playbooks/update/tasks/paths.yml | 71 ------------------- 17 files changed, 142 insertions(+), 78 deletions(-) delete mode 100644 guests/playbooks/update/tasks/paths.yml -- 2.25.1

2 6

[PATCH 0/3] Preserve query component of path for HTTP disks
by Peter Krempa 30 Mar '20

30 Mar '20

Peter Krempa (3): virStorageSourceParseBackingURI: Preserve query parts of URI qemuBlockStorageSourceGetURI: Properly preserve query component qemuxml2argv: Test the query portion for HTTP disks src/qemu/qemu_block.c | 6 ++++++ src/util/virstoragefile.c | 15 +++++++++++---- .../disk-network-http.x86_64-latest.args | 5 +++-- tests/qemuxml2argvdata/disk-network-http.xml | 2 +- .../disk-network-http.x86_64-latest.xml | 2 +- tests/virstoragetest.c | 4 ++-- 6 files changed, 24 insertions(+), 10 deletions(-) -- 2.24.1

3 5

[PATCH 0/3] Random almost trivial fixes
by Michal Privoznik 30 Mar '20

30 Mar '20

*** BLURB HERE *** Michal Prívozník (3): Don't pass NULL to yajl_free() virQEMUCapsNewBinary: Avoid NULL dereference virSecurityDeviceLabelDefNew: Avoid NULL dereference src/qemu/qemu_capabilities.c | 3 ++- src/util/virjson.c | 2 +- src/util/virseclabel.c | 2 +- tools/nss/libvirt_nss_leases.c | 3 ++- tools/nss/libvirt_nss_macs.c | 3 ++- 5 files changed, 8 insertions(+), 5 deletions(-) -- 2.24.1

2 6

[PATCH python] tox: Test with Python 3.6, 3.7 and 3.8
by Radostin Stoyanov 30 Mar '20

30 Mar '20

Support for Python 2.X has been dropped with commit b22e4f2. Signed-off-by: Radostin Stoyanov <rstoyanov(a)fedoraproject.org> --- tox.ini | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tox.ini b/tox.ini index e8c33f1..de683b9 100644 --- a/tox.ini +++ b/tox.ini @@ -1,5 +1,5 @@ [tox] -envlist = py26,py27,py34 +envlist = py36,py37,py38 [testenv] deps= -- 2.25.1

2 1

[libvirt PATCH v3 00/12] gitlab: expand the CI job coverage
by Daniel P. Berrangé 30 Mar '20

30 Mar '20

The main goals with this series are: - Introduce a minimal job building the website and publishing an artifact which can be deployed onto libvirt.org - Introduce a minimal job building the libvirt.pot for import into Weblate (only runs on git master branch) - Introduce a signed-off-by check. We can add a rule to block direct pushes without a SoB, but this will be needed to block merge requests without a SoB. - Expanding CI jobs to get coverage closer to Travis/Jenkins - Reducing cross-build jobs to just interesting variants, since the full set hasn't shown value in detecting failures The Linux native job coverage is now a superset of that achieved by Travis/Jenkins. For post-merge testing the full set of jobs are run on git master. This measured approx 50 minutes total duration. For pre-merge testing the job count is reduced for quicker turnaround time for developers Measured ~35 minutes total duration for a cold cache, vs ~20 minutes for warm cache. Changed in v3: - Add job for validating Signed-off-by - Add job for validating code style - Use ccache for native/cross build jobs - Eliminated the extra build stage and put all native jobs in the same place, but with filters - Keep all cross build jobs, but filter them based on branch Changed in v2: - Add more native test jobs to run on git master - Restrict git clone depth - User variable for "make" command name - Add test job to build the master pot file - Remove extra configure args for website job - Re-ordered patches to reduce repeated changes Daniel P. Berrangé (12): gitlab: add variable for make command name gitlab: restrict git history to 100 commits gitlab: create an explicit stage for cross build jobs gitlab: use CI for building website contents gitlab: reduce number of cross build jobs run by default gitlab: rename the cross build jobs gitlab: add mingw cross build CI jobs gitlab: add x86_64 native CI jobs gitlab: add job for building latest potfile gitlab: introduce use of ccache for speeding up rebuilds gitlab: introduce a check for validate DCO sign-off gitlab: add explicit early job for syntax-check .gitlab-ci.yml | 234 +++++++++++++++++++++++++++++++++++++---- scripts/require-dco.py | 96 +++++++++++++++++ 2 files changed, 307 insertions(+), 23 deletions(-) create mode 100755 scripts/require-dco.py -- 2.24.1

3 39

[libvirt PATCH] tools: explain that '^' means 'Ctrl' for console escape sequence
by Daniel P. Berrangé 30 Mar '20

30 Mar '20

Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- tools/virsh-domain.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/tools/virsh-domain.c b/tools/virsh-domain.c index 8591e483a5..ada0189685 100644 --- a/tools/virsh-domain.c +++ b/tools/virsh-domain.c @@ -3002,7 +3002,11 @@ cmdRunConsole(vshControl *ctl, virDomainPtr dom, } vshPrintExtra(ctl, _("Connected to domain %s\n"), virDomainGetName(dom)); - vshPrintExtra(ctl, _("Escape character is %s\n"), priv->escapeChar); + vshPrintExtra(ctl, _("Escape character is %s"), priv->escapeChar); + if (priv->escapeChar[0] == '^') { + vshPrintExtra(ctl, " (Ctrl + %c)", priv->escapeChar[1]); + } + vshPrintExtra(ctl, "\n"); fflush(stdout); if (virshRunConsole(ctl, dom, name, flags) == 0) return true; -- 2.24.1

3 5

[libvirt PATCH] docs: Clarify semantics of model/@usable attribute in dom caps
by Jiri Denemark 30 Mar '20

30 Mar '20

The documentation could confuse people to expect that CPU models with usable='no' attribute are not usable at all on the current host. But they cannot be only used without explicitly disabling some features. Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com> --- docs/formatdomaincaps.html.in | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/docs/formatdomaincaps.html.in b/docs/formatdomaincaps.html.in index 66e758501b..4056e0bd31 100644 --- a/docs/formatdomaincaps.html.in +++ b/docs/formatdomaincaps.html.in @@ -249,9 +249,11 @@ The <code>mode</code> element contains a list of supported CPU models, each described by a dedicated <code>model</code> element. The <code>usable</code> attribute specifies whether the model can - be used on the host. A special value <code>unknown</code> indicates - libvirt does not have enough information to provide the usability - data. + be used directly on the host. When usable='no' the corresponding model + cannot be used without disabling some features that the CPU of such + model is expected to have. A special value <code>unknown</code> + indicates libvirt does not have enough information to provide the + usability data. </dd> </dl> -- 2.26.0

2 1

[PATCH] util: virdaemon: fix compilation on mingw
by Rafael Fonseca 30 Mar '20

30 Mar '20

The daemons are not supported on Win32 and therefore were not compiled in that platform. However, with the daemon code sharing, all the code in utils *is* compiled and it failed because `waitpid`, `fork`, and `setsid` are not available. So, as before, let's not build them on Win32 and make the code more portable by using existing vir* wrappers. Signed-off-by: Rafael Fonseca <r4f4rfs(a)gmail.com> --- src/util/virdaemon.c | 46 +++++++++++++++++++++++++++++++++++++++----- 1 file changed, 41 insertions(+), 5 deletions(-) diff --git a/src/util/virdaemon.c b/src/util/virdaemon.c index 789adc6c50..5d92c7def7 100644 --- a/src/util/virdaemon.c +++ b/src/util/virdaemon.c @@ -20,9 +20,7 @@ #include <config.h> -#include <sys/types.h> #include <sys/stat.h> -#include <sys/wait.h> #include <fcntl.h> #include <unistd.h> #include <stdbool.h> @@ -32,9 +30,13 @@ #include "virfile.h" #include "virlog.h" #include "viralloc.h" +#include "virprocess.h" +#include "vircommand.h" #include "configmake.h" +#ifndef WIN32 + int virDaemonForkIntoBackground(const char *argv0) { @@ -42,7 +44,7 @@ virDaemonForkIntoBackground(const char *argv0) if (virPipeQuiet(statuspipe) < 0) return -1; - pid_t pid = fork(); + pid_t pid = virFork(); switch (pid) { case 0: { @@ -71,7 +73,7 @@ virDaemonForkIntoBackground(const char *argv0) if (setsid() < 0) goto cleanup; - nextpid = fork(); + nextpid = virFork(); switch (nextpid) { case 0: /* grandchild */ return statuspipe[1]; @@ -102,7 +104,7 @@ virDaemonForkIntoBackground(const char *argv0) VIR_FORCE_CLOSE(statuspipe[1]); /* We wait to make sure the first child forked successfully */ - if ((got = waitpid(pid, &exitstatus, 0)) < 0 || + if ((got = virProcessWait(pid, &exitstatus, 0)) < 0 || got != pid || exitstatus != 0) { goto error; @@ -250,3 +252,37 @@ virDaemonUnixSocketPaths(const char *sock_prefix, VIR_FREE(rundir); return ret; } + +#else /* WIN32 */ + +int virDaemonForkIntoBackground(const char *argv0 G_GNUC_UNUSED) +{ + errno = ENOTSUP; + return -1; +} + +void virDaemonSetupLogging(const char *daemon_name G_GNUC_UNUSED, + unsigned int log_level G_GNUC_UNUSED, + char *log_filters G_GNUC_UNUSED, + char *log_outputs G_GNUC_UNUSED, + bool privileged G_GNUC_UNUSED, + bool verbose G_GNUC_UNUSED, + bool godaemon G_GNUC_UNUSED) +{ + /* NOOP */ + errno = ENOTSUP; + return; +} + +int virDaemonUnixSocketPaths(const char *sock_prefix G_GNUC_UNUSED, + bool privileged G_GNUC_UNUSED, + char *unix_sock_dir G_GNUC_UNUSED, + char **sockfile G_GNUC_UNUSED, + char **rosockfile G_GNUC_UNUSED, + char **adminSockfile G_GNUC_UNUSED) +{ + errno = ENOTSUP; + return -1; +} + +#endif /* WIN32 */ -- 2.25.1

3 2

[libvirt PATCH v2 0/5] QEMU: support QEMU built without TCG
by Tobin Feldman-Fitzthum 28 Mar '20

28 Mar '20

Edit: left out one line from v1. Since version 2.10, QEMU can be built without TCG. This patch adds capabillity QEMU_CAPS_TCG_DISABLED that allows libvirt to use a QEMU built without TCG. Rather than create a capability that is set whenever TCG is enabled (almost always), QEMU_CAPS_TCG_DISABLED is set only when the TCG is not available. This avoids some issues with backwards compatability. For a domain that was created using QEMU >= 2.10 with KVM, there is no information in the cached XML file that says whether or not TCG was enabled. Versions of QEMU older than 2.10 do not have a QMP interface for determining whether QEMU is available. Since QEMU_CAPS_TCG_DISABLED is set only when TCG is disabled, we do not have to do any extra work to infer an appropriate value in either of these cases. QEMU_CAPS_TCG_DISABLED is set via QMP command qom-list-types. Tobin Feldman-Fitzthum (5): add QEMU_CAPS_TCG_DISABLED and probe conditionally add virQEMUCapsGetVirtType convenience function add virQEMUCapsProbeQMPTCGState function to set QEMU_CAPS_TCG_DISABLED use new functions when probing Add second qom-list-types call to test data. src/qemu/qemu_capabilities.c | 81 +- src/qemu/qemu_capabilities.h | 3 + .../caps_2.10.0.aarch64.replies | 2695 ++- .../caps_2.10.0.ppc64.replies | 2799 ++- .../caps_2.10.0.s390x.replies | 1027 +- .../caps_2.10.0.x86_64.replies | 1702 +- .../caps_2.11.0.s390x.replies | 1063 +- .../caps_2.11.0.x86_64.replies | 1688 +- .../caps_2.12.0.aarch64.replies | 2960 +++- .../caps_2.12.0.ppc64.replies | 2947 +++- .../caps_2.12.0.s390x.replies | 1087 +- .../caps_2.12.0.x86_64.replies | 1827 +- .../caps_3.0.0.ppc64.replies | 2979 +++- .../caps_3.0.0.s390x.replies | 1117 +- .../caps_3.0.0.x86_64.replies | 1843 +- .../caps_3.1.0.ppc64.replies | 2999 +++- .../caps_3.1.0.x86_64.replies | 1863 +- .../caps_4.0.0.aarch64.replies | 3223 +++- .../caps_4.0.0.ppc64.replies | 3211 +++- .../caps_4.0.0.s390x.replies | 1259 +- .../caps_4.0.0.x86_64.replies | 1975 ++- .../caps_4.1.0.x86_64.replies | 2207 ++- .../caps_4.2.0.aarch64.replies | 3409 +++- .../caps_4.2.0.ppc64.replies | 3248 +++- .../caps_4.2.0.s390x.replies | 1259 +- .../caps_4.2.0.x86_64.replies | 2296 ++- .../caps_5.0.0.aarch64.replies | 3445 +++- .../caps_5.0.0.ppc64.replies | 14002 +++++++++------- .../qemucapabilitiesdata/caps_5.0.0.ppc64.xml | 1220 +- .../caps_5.0.0.x86_64.replies | 2319 ++- 30 files changed, 65236 insertions(+), 8517 deletions(-) -- 2.20.1 (Apple Git-117)

1 5

Entering freeze for libvirt-6.2.0
by Daniel Veillard 27 Mar '20

27 Mar '20

I forgot to announce plans, sorry about this, entering freeze now I hope there isn't too many pending patchestargetting this release. The plan would be to push the RC2 on Tuesday with a release on April 2nd if everything goes fine. You can find the signed tarball and source rpm at the usual place: https://libvirt.org/sources/ the rc1 is also tagged in git. Please give it a try, so we can have a normal release, in those time of pandemy, take care, stay safe, 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/

1 0

[libvirt PATCH 0/5] QEMU: support QEMU built without TCG
by Tobin Feldman-Fitzthum 27 Mar '20

27 Mar '20

Since version 2.10, QEMU can be built without TCG. This patch adds capabillity QEMU_CAPS_TCG_DISABLED that allows libvirt to use a QEMU built without TCG. Rather than create a capability that is set whenever TCG is enabled (almost always), QEMU_CAPS_TCG_DISABLED is set only when the TCG is not available. This avoids some issues with backwards compatability. For a domain that was created using QEMU >= 2.10 with KVM, there is no information in the cached XML file that says whether or not TCG was enabled. Versions of QEMU older than 2.10 do not have a QMP interface for determining whether QEMU is available. Since QEMU_CAPS_TCG_DISABLED is set only when TCG is disabled, we do not have to do any extra work to infer an appropriate value in either of these cases. QEMU_CAPS_TCG_DISABLED is set via QMP command qom-list-types. Tobin Feldman-Fitzthum (5): add QEMU_CAPS_TCG_DISABLED and probe conditionally add virQEMUCapsGetVirtType convenience function add virQEMUCapsProbeQMPTCGState function to set QEMU_CAPS_TCG_DISABLED use new functions when probing Add second qom-list-types call to test data. src/qemu/qemu_capabilities.c | 80 +- src/qemu/qemu_capabilities.h | 3 + .../caps_2.10.0.aarch64.replies | 2695 ++- .../caps_2.10.0.ppc64.replies | 2799 ++- .../caps_2.10.0.s390x.replies | 1027 +- .../caps_2.10.0.x86_64.replies | 1702 +- .../caps_2.11.0.s390x.replies | 1063 +- .../caps_2.11.0.x86_64.replies | 1688 +- .../caps_2.12.0.aarch64.replies | 2960 +++- .../caps_2.12.0.ppc64.replies | 2947 +++- .../caps_2.12.0.s390x.replies | 1087 +- .../caps_2.12.0.x86_64.replies | 1827 +- .../caps_3.0.0.ppc64.replies | 2979 +++- .../caps_3.0.0.s390x.replies | 1117 +- .../caps_3.0.0.x86_64.replies | 1843 +- .../caps_3.1.0.ppc64.replies | 2999 +++- .../caps_3.1.0.x86_64.replies | 1863 +- .../caps_4.0.0.aarch64.replies | 3223 +++- .../caps_4.0.0.ppc64.replies | 3211 +++- .../caps_4.0.0.s390x.replies | 1259 +- .../caps_4.0.0.x86_64.replies | 1975 ++- .../caps_4.1.0.x86_64.replies | 2207 ++- .../caps_4.2.0.aarch64.replies | 3409 +++- .../caps_4.2.0.ppc64.replies | 3248 +++- .../caps_4.2.0.s390x.replies | 1259 +- .../caps_4.2.0.x86_64.replies | 2296 ++- .../caps_5.0.0.aarch64.replies | 3445 +++- .../caps_5.0.0.ppc64.replies | 14002 +++++++++------- .../qemucapabilitiesdata/caps_5.0.0.ppc64.xml | 1220 +- .../caps_5.0.0.x86_64.replies | 2319 ++- 30 files changed, 65235 insertions(+), 8517 deletions(-) -- 2.20.1 (Apple Git-117)

1 5

[libvirt PATCH 0/2] gitlab: Improve make handling
by Andrea Bolognani 27 Mar '20

27 Mar '20

Andrea Bolognani (2): gitlab: Add and use 'environment' template gitlab: Define $MAKEFLAGS in environment .gitlab-ci.yml | 28 ++++++++++++++++++++-------- 1 file changed, 20 insertions(+), 8 deletions(-) -- 2.25.1

2 4

[PATCH 0/2] Two trivial syntax-check fixes
by Michal Privoznik 27 Mar '20

27 Mar '20

While reviewing patches [1] I've found two problems with syntax-check which are trivial to fix. These are the patches I've pushed. 1: https://www.redhat.com/archives/libvir-list/2020-March/msg01124.html Michal Prívozník (2): syntax-check: Disallow plain fork() in src/libvirt.c syntax-check.mk: Drop needless _src2 variable build-aux/syntax-check.mk | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) -- 2.24.1

2 4

[PATCH 0/4] Introduce shared daemon startup code
by Rafael Fonseca 27 Mar '20

27 Mar '20

Libvirt ships several daemons (libvirtd, virtlogd, virtlockd) that all have similar code around general daemon startup. Right now the code is duplicated for each daemon, but it could be shared, like in a new file src/util/virdaemon.c. Rafael Fonseca (4): util: introduce shared daemon startup code locking: use shared daemon startup code logging: use shared daemon startup code remote: use shared daemon startup code src/libvirt_private.syms | 6 + src/locking/lock_daemon.c | 251 ++++------------------------------- src/logging/log_daemon.c | 239 ++++----------------------------- src/remote/remote_daemon.c | 263 +++---------------------------------- src/util/Makefile.inc.am | 2 + src/util/virdaemon.c | 255 +++++++++++++++++++++++++++++++++++ src/util/virdaemon.h | 74 +++++++++++ 7 files changed, 410 insertions(+), 680 deletions(-) create mode 100644 src/util/virdaemon.c create mode 100644 src/util/virdaemon.h -- 2.25.1

2 6

[libvirt PATCH] scripts: avoid error in DCO check on empty branches
by Daniel P. Berrangé 27 Mar '20

27 Mar '20

If the DCO check is run on an empty branch (ie one which has no commits different from master), it throws an error due to trying to interpret the empty string as a git commit SHA. Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- scripts/require-dco.py | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/scripts/require-dco.py b/scripts/require-dco.py index 9fe13823a9..ae94393319 100755 --- a/scripts/require-dco.py +++ b/scripts/require-dco.py @@ -46,7 +46,10 @@ print("\nChecking for 'Signed-off-by: NAME <EMAIL>' on all commits since %s...\n log = subprocess.check_output(["git", "log", "--format=%H %s", ancestor + "..."], universal_newlines=True) -commits = [[c[0:40], c[41:]] for c in log.strip().split("\n")] +if log == "": + commits = [] +else: + commits = [[c[0:40], c[41:]] for c in log.strip().split("\n")] for sha, subject in commits: -- 2.24.1

2 1

[libvirt PATCH] gitlab: don't run the DCO check on git master
by Daniel P. Berrangé 27 Mar '20

27 Mar '20

The "only: branches" does not in fact exclude "master", so it must be excluded explicitly. Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- Pushed as a build fix since the DCO check fails on master .gitlab-ci.yml | 1 + 1 file changed, 1 insertion(+) diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml index d8b316d618..1e3675ace0 100644 --- a/.gitlab-ci.yml +++ b/.gitlab-ci.yml @@ -228,3 +228,4 @@ dco: - branches except: - /^v.*-maint$/ + - master -- 2.24.1

1 0

[PATCH 1/1] qemu_domain.c: remove unneeded size check in NVDIMM alignment
by Daniel Henrique Barboza 27 Mar '20

27 Mar '20

Commit 5540acb9a2b added a minimum size verification for the target size of ppc64 NVDIMMs but forgot to remove a MAX() size check that was being used in earlier reviews of that commit. The size verification makes this check unneeded since we're making sure that guestArea will always be at least equal to ppc64AlignSize. Fixes: 5540acb9a2bd33fb97a7446a610b602c9e8629a3 Signed-off-by: Daniel Henrique Barboza <danielhb413(a)gmail.com> --- src/qemu/qemu_domain.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c index 2c9fb47d17..2c52778515 100644 --- a/src/qemu/qemu_domain.c +++ b/src/qemu/qemu_domain.c @@ -12639,8 +12639,6 @@ qemuDomainNVDimmAlignSizePseries(virDomainDefPtr def, } guestArea = (guestArea/ppc64AlignSize) * ppc64AlignSize; - guestArea = MAX(guestArea, ppc64AlignSize); - mem->size = guestArea + mem->labelsize; return 0; -- 2.25.1

2 1

[PATCH 0/2] Accept http cookies with quoted value
by Peter Krempa 27 Mar '20

27 Mar '20

The validator didn't accept the quoted version of the cookie value. Add a test and fix the issue. Peter Krempa (2): qemuxml2xmltest: Wire up 'disk-network-http' case virStorageSourceNetCookieValidate: Accept quoted cookie value docs/schemas/domaincommon.rng | 2 +- src/util/virstoragefile.c | 19 ++++- .../disk-network-http.x86_64-latest.args | 4 +- tests/qemuxml2argvdata/disk-network-http.xml | 4 +- .../disk-network-http.x86_64-latest.xml | 71 +++++++++++++++++++ tests/qemuxml2xmltest.c | 2 + 6 files changed, 96 insertions(+), 6 deletions(-) create mode 100644 tests/qemuxml2xmloutdata/disk-network-http.x86_64-latest.xml -- 2.24.1

2 3

[PATCHv2 1/1] qemu_agent.c: Use g_autofree in qemu_agent.c
by Seeteena Thoufeek 27 Mar '20

27 Mar '20

This is the only instance of g_autofree change applicable for qemu_agent.c Signed-off-by: Seeteena Thoufeek <s1seetee(a)linux.vnet.ibm.com> --- src/qemu/qemu_agent.c | 12 ++++-------- 1 file changed, 4 insertions(+), 8 deletions(-) diff --git a/src/qemu/qemu_agent.c b/src/qemu/qemu_agent.c index 95a7d9b..d7fcc86 100644 --- a/src/qemu/qemu_agent.c +++ b/src/qemu/qemu_agent.c @@ -332,9 +332,8 @@ static int qemuAgentIOProcessData(qemuAgentPtr agent, size_t i = 0; #if DEBUG_IO # if DEBUG_RAW_IO - char *str1 = qemuAgentEscapeNonPrintable(data); + g_autofree char *str1 = qemuAgentEscapeNonPrintable(data); VIR_ERROR(_("[%s]"), str1); - VIR_FREE(str1); # else VIR_DEBUG("Data %zu bytes [%s]", len, data); # endif @@ -377,12 +376,10 @@ qemuAgentIOProcess(qemuAgentPtr agent) #if DEBUG_IO # if DEBUG_RAW_IO - char *str1 = qemuAgentEscapeNonPrintable(msg ? msg->txBuffer : ""); - char *str2 = qemuAgentEscapeNonPrintable(agent->buffer); + g_autofree char *str1 = qemuAgentEscapeNonPrintable(msg ? msg->txBuffer : ""); + g_autofree char *str2 = qemuAgentEscapeNonPrintable(agent->buffer); VIR_ERROR(_("Process %zu %p %p [[[%s]]][[[%s]]]"), agent->bufferOffset, agent->msg, msg, str1, str2); - VIR_FREE(str1); - VIR_FREE(str2); # else VIR_DEBUG("Process %zu", agent->bufferOffset); # endif @@ -1083,7 +1080,7 @@ qemuAgentCommandFull(qemuAgentPtr agent, { int ret = -1; qemuAgentMessage msg; - char *cmdstr = NULL; + g_autofree char *cmdstr = NULL; int await_event = agent->await_event; *reply = NULL; @@ -1133,7 +1130,6 @@ qemuAgentCommandFull(qemuAgentPtr agent, ret = qemuAgentCheckError(cmd, *reply, report_unsupported); cleanup: - VIR_FREE(cmdstr); VIR_FREE(msg.txBuffer); agent->await_event = QEMU_AGENT_EVENT_NONE; -- 1.8.3.1

2 2

[PATCH 0/5] Introduce getHost support for ARM cpus
by Zhenyu Zheng 27 Mar '20

27 Mar '20

Introduce getHost support for ARM cpus. First add some common ARM server models to cpu_map, then add some helper methods to parse and load them. The 'lscpu' command from 'util-linux' provides very good data for cpu information, we can parse them directly. Signed-of-by: Zhenyu Zheng <zhengzhenyulixi(a)gmail.com> Zhenyu Zheng (5): cpu_map: Introduce arm CPU models cpu: Introduce virCPUarmData to virCPUData cpu: Introduce arm related structs cpu: Add helper functions to parse vendor and model for ARM cpu: Introduce getHost supoort for ARM src/cpu/cpu.h | 2 + src/cpu/cpu_arm.c | 412 +++++++++++++++++++++++++++++- src/cpu/cpu_arm_data.h | 32 +++ src/cpu_map/Makefile.inc.am | 7 + src/cpu_map/arm_Falkor.xml | 15 ++ src/cpu_map/arm_Kunpeng-920.xml | 23 ++ src/cpu_map/arm_ThunderX299xx.xml | 15 ++ src/cpu_map/arm_cortex-a53.xml | 15 ++ src/cpu_map/arm_cortex-a57.xml | 14 + src/cpu_map/arm_cortex-a72.xml | 14 + src/cpu_map/arm_vendors.xml | 14 + src/cpu_map/index.xml | 16 ++ 12 files changed, 577 insertions(+), 2 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

1 1

[PATCH 0/5] Introduce getHost support for ARM cpus
by Zhenyu Zheng 27 Mar '20

27 Mar '20

Introduce getHost support for ARM cpus. First add some common ARM server models to cpu_map, then add some helper methods to parse and load them. The 'lscpu' command from 'util-linux' provides very good data for cpu information, we can parse them directly. Zhenyu Zheng (5): cpu_map: Introduce arm CPU models cpu: Introduce virCPUarmData to virCPUData cpu: Introduce arm related structs cpu: Add helper functions to parse vendor and model for ARM cpu: Introduce getHost supoort for ARM src/cpu/cpu.h | 2 + src/cpu/cpu_arm.c | 412 +++++++++++++++++++++++++++++- src/cpu/cpu_arm_data.h | 32 +++ src/cpu_map/Makefile.inc.am | 7 + src/cpu_map/arm_Falkor.xml | 15 ++ src/cpu_map/arm_Kunpeng-920.xml | 23 ++ src/cpu_map/arm_ThunderX299xx.xml | 15 ++ src/cpu_map/arm_cortex-a53.xml | 15 ++ src/cpu_map/arm_cortex-a57.xml | 14 + src/cpu_map/arm_cortex-a72.xml | 14 + src/cpu_map/arm_vendors.xml | 14 + src/cpu_map/index.xml | 16 ++ 12 files changed, 577 insertions(+), 2 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

1 1

[PATCH 0/5] Introduce getHost support for ARM cpus
by KevinZ 27 Mar '20

27 Mar '20

Introduce getHost support for ARM cpus. First add some common ARM server models to cpu_map, then add some helper methods to parse and load them. The 'lscpu' command from 'util-linux' provides very good data for cpu information, we can parse them directly. Zhenyu Zheng (5):   cpu_map: Introduce arm CPU models   cpu: Introduce virCPUarmData to virCPUData   cpu: Introduce arm related structs   cpu: Add helper functions to parse vendor and model for ARM   cpu: Introduce getHost supoort for ARM  src/cpu/cpu.h                     |   2 +  src/cpu/cpu_arm.c                 | 412 +++++++++++++++++++++++++++++-  src/cpu/cpu_arm_data.h            |  32 +++  src/cpu_map/Makefile.inc.am       |   7 +  src/cpu_map/arm_Falkor.xml        |  15 ++  src/cpu_map/arm_Kunpeng-920.xml   |  23 ++  src/cpu_map/arm_ThunderX299xx.xml |  15 ++  src/cpu_map/arm_cortex-a53.xml    |  15 ++  src/cpu_map/arm_cortex-a57.xml    |  14 +  src/cpu_map/arm_cortex-a72.xml    |  14 +  src/cpu_map/arm_vendors.xml       |  14 +  src/cpu_map/index.xml             |  16 ++  12 files changed, 577 insertions(+), 2 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

1 0

[libvirt] [PATCH 0/3] qemu: support -overcommit cpu-pm=on|off
by Menno Lageman 27 Mar '20

27 Mar '20

QEMU introduced a CPU power management feature with commit 6f131f13e68d ("kvm: support -overcommit cpu-pm=on|off"). With this flag, kvm allows guest to control host CPU power state. This increases latency for other processes using same host CPU in an unpredictable way, but if decreases idle entry/exit times for the running VCPU, so to use it QEMU needs a hint about whether host CPU is overcommitted, hence the flag name. This patch series adds a new kvm feature 'cpu-pm' for controlling "-overcommit cpu-pm=[on|off]" <features> <kvm> <cpu-pm state='on'/> </kvm> </features> Menno Lageman (2): qemu: introduce qemuBuildOvercommitCommandLine() tests: add tests for cpu-pm feature Wim ten Have (1): qemu: add hypervisor feature cpu-pm support for kvm docs/formatdomain.html.in | 7 ++++ docs/schemas/domaincommon.rng | 5 +++ src/conf/domain_conf.c | 4 ++ src/conf/domain_conf.h | 1 + src/libvirt_private.syms | 1 + src/qemu/qemu_command.c | 39 +++++++++++++++++-- src/qemu/qemu_domain.c | 25 ++++++++---- tests/qemuxml2argvdata/kvm-features-off.args | 2 +- tests/qemuxml2argvdata/kvm-features-off.xml | 1 + tests/qemuxml2argvdata/kvm-features.args | 2 +- tests/qemuxml2argvdata/kvm-features.xml | 1 + tests/qemuxml2argvtest.c | 4 +- tests/qemuxml2xmloutdata/kvm-features-off.xml | 1 + tests/qemuxml2xmloutdata/kvm-features.xml | 1 + 14 files changed, 79 insertions(+), 15 deletions(-) -- 2.21.0

3 7

[PATCH] qemu_agent.c: Use g_autofree in qemu_agent.c
by Seeteena Thoufeek 26 Mar '20

26 Mar '20

This is the only instance of g_autofree change applicable for qemu_agent.c Signed-off-by: Seeteena Thoufeek <s1seetee(a)linux.vnet.ibm.com> --- src/qemu/qemu_agent.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/src/qemu/qemu_agent.c b/src/qemu/qemu_agent.c index 95a7d9b..c74bd0e 100644 --- a/src/qemu/qemu_agent.c +++ b/src/qemu/qemu_agent.c @@ -1083,7 +1083,7 @@ qemuAgentCommandFull(qemuAgentPtr agent, { int ret = -1; qemuAgentMessage msg; - char *cmdstr = NULL; + g_autofree char *cmdstr = NULL; int await_event = agent->await_event; *reply = NULL; @@ -1133,7 +1133,6 @@ qemuAgentCommandFull(qemuAgentPtr agent, ret = qemuAgentCheckError(cmd, *reply, report_unsupported); cleanup: - VIR_FREE(cmdstr); VIR_FREE(msg.txBuffer); agent->await_event = QEMU_AGENT_EVENT_NONE; -- 1.8.3.1

2 1

[PATCH] bhyve: fix typo in struct field accessor
by Daniel P. Berrangé 26 Mar '20

26 Mar '20

This fixes a FreeBSD build error from commit a11a0e6e8473fec6127b263a33f892135097648f Author: Rafael Fonseca <r4f4rfs(a)gmail.com> Date: Tue Mar 24 17:14:30 2020 +0100 bhyve: move video default logic to driver Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- Pushed as build fix src/bhyve/bhyve_domain.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/bhyve/bhyve_domain.c b/src/bhyve/bhyve_domain.c index 40ee461b19..95d6ffd31c 100644 --- a/src/bhyve/bhyve_domain.c +++ b/src/bhyve/bhyve_domain.c @@ -162,8 +162,8 @@ bhyveDomainDeviceDefPostParse(virDomainDeviceDefPtr dev, } if (dev->type == VIR_DOMAIN_DEVICE_VIDEO && - dev->data.video.type == VIR_DOMAIN_VIDEO_TYPE_DEFAULT) { - dev->data.video.type = VIR_DOMAIN_VIDEO_TYPE_GOP; + dev->data.video->type == VIR_DOMAIN_VIDEO_TYPE_DEFAULT) { + dev->data.video->type = VIR_DOMAIN_VIDEO_TYPE_GOP; } return 0; -- 2.24.1

1 0

[PATCH] qemuCheckpointCreateXML: Check VM liveness first
by Peter Krempa 26 Mar '20

26 Mar '20

Move the liveness check prior to the capability check. If the VM is offline the capabilities are not initialized and thus we'd report the wrong error. https://bugzilla.redhat.com/show_bug.cgi?id=1812531 Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- src/qemu/qemu_checkpoint.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/qemu/qemu_checkpoint.c b/src/qemu/qemu_checkpoint.c index 62b6e87b53..3a510c9780 100644 --- a/src/qemu/qemu_checkpoint.c +++ b/src/qemu/qemu_checkpoint.c @@ -647,15 +647,15 @@ qemuCheckpointCreateXML(virDomainPtr domain, update_current = false; } - if (!virQEMUCapsGet(priv->qemuCaps, QEMU_CAPS_INCREMENTAL_BACKUP)) { + if (!virDomainObjIsActive(vm)) { virReportError(VIR_ERR_OPERATION_UNSUPPORTED, "%s", - _("incremental backup is not supported yet")); + _("cannot create checkpoint for inactive domain")); return NULL; } - if (!virDomainObjIsActive(vm)) { + if (!virQEMUCapsGet(priv->qemuCaps, QEMU_CAPS_INCREMENTAL_BACKUP)) { virReportError(VIR_ERR_OPERATION_UNSUPPORTED, "%s", - _("cannot create checkpoint for inactive domain")); + _("incremental backup is not supported yet")); return NULL; } -- 2.24.1

2 2

[PATCH 0/2] Two incremental backup related fixes
by Peter Krempa 26 Mar '20

26 Mar '20

Peter Krempa (2): qemuCheckpointDelete: Check VM liveness first qemuBackupBegin: Fix monitor access when rolling back due to failure src/qemu/qemu_backup.c | 2 +- src/qemu/qemu_checkpoint.c | 8 ++++---- 2 files changed, 5 insertions(+), 5 deletions(-) -- 2.24.1

2 5

[libvirt-dockerfiles PATCH] trigger: Fetch Dockerfiles from GitLab
by Andrea Bolognani 26 Mar '20

26 Mar '20

We're moving libvirt development to GitLab, so it makes sense that we'd fetch Dockerfiles from there rather than GitHub going forward. Signed-off-by: Andrea Bolognani <abologna(a)redhat.com> --- trigger | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/trigger b/trigger index d2e853d..4e71d32 100755 --- a/trigger +++ b/trigger @@ -16,7 +16,7 @@ test "$outfile" || usage while read zip do repository="${zip%.zip}" - url="https://github.com/libvirt/libvirt-dockerfiles/raw/master/$zip" + url="https://gitlab.com/libvirt/libvirt-dockerfiles/-/raw/master/$zip" "$QUAYADMIN" create-build libvirt "$repository" "$url" -- 2.25.1

2 1

[libvirt-dockerfiles PATCH] Refresh after adding ccache and dwarves to CentOS
by Andrea Bolognani 26 Mar '20

26 Mar '20

The corresponding libvirt-jenkins-ci commit is cb8a5cc98818. Signed-off-by: Andrea Bolognani <abologna(a)redhat.com> --- Pushed under the Dockerfile refresh rule. buildenv-libosinfo-centos-7.zip | Bin 1659 -> 1665 bytes buildenv-libosinfo-centos-8.zip | Bin 589 -> 594 bytes buildenv-libvirt-centos-7.zip | Bin 1878 -> 1888 bytes buildenv-libvirt-centos-8.zip | Bin 793 -> 802 bytes 4 files changed, 0 insertions(+), 0 deletions(-) diff --git a/buildenv-libosinfo-centos-7.zip b/buildenv-libosinfo-centos-7.zip index 454ce5c..e4f5b87 100644 --- a/buildenv-libosinfo-centos-7.zip +++ b/buildenv-libosinfo-centos-7.zip @@ -38,6 +38,7 @@ WEiJKtQrZDJloqtyi/mmRa1VsV7RYR0VPJjhK/R8EQ7Ysshy\n\ bash \ bash-completion \ ca-certificates \ + ccache \ check-devel \ chrony \ gcc \ diff --git a/buildenv-libosinfo-centos-8.zip b/buildenv-libosinfo-centos-8.zip index 11621ba..53a49d0 100644 --- a/buildenv-libosinfo-centos-8.zip +++ b/buildenv-libosinfo-centos-8.zip @@ -10,6 +10,7 @@ RUN dnf install 'dnf-command(config-manager)' -y && \ bash \ bash-completion \ ca-certificates \ + ccache \ check-devel \ chrony \ gcc \ diff --git a/buildenv-libvirt-centos-7.zip b/buildenv-libvirt-centos-7.zip index c50693d..96cd758 100644 --- a/buildenv-libvirt-centos-7.zip +++ b/buildenv-libvirt-centos-7.zip @@ -41,11 +41,13 @@ WEiJKtQrZDJloqtyi/mmRa1VsV7RYR0VPJjhK/R8EQ7Ysshy\n\ bash \ bash-completion \ ca-certificates \ + ccache \ chrony \ cyrus-sasl-devel \ dbus-devel \ device-mapper-devel \ dnsmasq \ + dwarves \ ebtables \ fuse-devel \ gcc \ diff --git a/buildenv-libvirt-centos-8.zip b/buildenv-libvirt-centos-8.zip index a81abce..a63524b 100644 --- a/buildenv-libvirt-centos-8.zip +++ b/buildenv-libvirt-centos-8.zip @@ -13,11 +13,13 @@ RUN dnf install 'dnf-command(config-manager)' -y && \ bash \ bash-completion \ ca-certificates \ + ccache \ chrony \ cyrus-sasl-devel \ dbus-devel \ device-mapper-devel \ dnsmasq \ + dwarves \ ebtables \ fuse-devel \ gcc \ -- 2.25.1

1 0

[libvirt PATCH v2 0/9] gitlab: expand the CI job coverage (RESEND)
by Daniel P. Berrangé 26 Mar '20

26 Mar '20

There are main goals with this series - Introduce a minimal job building the website and publishing an artifact which can be deployed onto libvirt.org - Introduce a minimal job building the libvirt.pot for import into Weblate (only runs on git master branch) - Expanding CI jobs to get coverage closer to Travis/Jenkins - Reducing cross-build jobs to just interesting variants, since the full set hasn't shown value in detecting failures The Linux native job coverage is now a superset of that achieved by Travis/Jenkins. For post-merge testing the full set of jobs are run on git master (measured approx 50 minutes total duration) For pre-merge testing the Linux job count is reduced for quicker turnaround time for developers (measured ~35 minutes total duration) Changed in v2: - Add more native test jobs to run on git master - Restrict git clone depth - User variable for "make" command name - Add test job to build the master pot file - Remove extra configure args for website job - Re-ordered patches to reduce repeated changes Daniel P. Berrangé (9): gitlab: use CI for building website contents gitlab: reduce number of cross-build CI jobs gitlab: group jobs into stages gitlab: rename the cross build jobs gitlab: add mingw cross build CI jobs gitlab: add x86_64 native CI jobs gitlab: add variable for make command name gitlab: restrict git history to 100 commits gitlab: add job for building latest potfile .gitlab-ci.yml | 178 ++++++++++++++++++++++++++++++++++++++++--------- 1 file changed, 148 insertions(+), 30 deletions(-) -- 2.24.1

3 44

Question: building libvirt into the buildroot. Error *** No rule to make target `keycodemapdb/data/keymaps.csv'
by Komarov Egor 26 Mar '20

26 Mar '20

Hello! I'm tying to build libvirt into the buildroot project. When I build libvirt I have an error make[3]: Entering directory `/home/zoadmin/BRAIN4NET/buildroot/buildroot-2018.02.2/output/build/libvirt-v6.1.0/src' make[3]: *** No rule to make target `keycodemapdb/data/keymaps.csv', needed by `util/virkeycodetable_linux.h'. Stop. Please, Help me) What I do incorrect ? I tried build branch 6.1 and master. Completely build.log in attach. Thank you! P.S. My package/libvirt/libvirt.mk into the buildroot [zoadmin@BuildPC-SPECOS buildroot-2018.02.2]$ cat package/libvirt/libvirt.mk ###################################################################### # # # libvirt # # ##################################################################### LIBVIRT_VERSION = v6.1.0 #LIBVIRT_SOURCE = LIBVIRT_SITE = https://github.com/libvirt/libvirt LIBVIRT_SITE_METHOD = git LIBVIRT_AUTORECONF = YES LIBVIRT_CONF_OPTS = -prefix=/usr --sysconfdir=/etc --localstatedir=/var --with-storage-mpath=no LIBVIRT_INSTALL_TARGET = YES LIBVIRT_DEPENDENCIES = gnutls kvmtool qemu linux libxml2 libpciaccess libxslt libnl host-libxslt host-python-rst2html5 host-python-docutils host-python3 define LIBVIRT_PRE_CONFIGURE_GNU cd $(@D); ./bootstrap endef define LIBVIRT_PRE_CONFIGURE_DELETE_STRING cd $(@D); sed -i "21,24d" ./configure.ac # sed -i "3413,3416d" ./configure endef #LIBVIRT_PRE_CONFIGURE_HOOKS += LIBVIRT_PRE_CONFIGURE_GNU LIBVIRT_PRE_CONFIGURE_HOOKS += LIBVIRT_PRE_CONFIGURE_DELETE_STRING $(eval $(autotools-package)) fd ______________________________________________________________________________________ С уважением, Комаров Егор Инженер Департамента специальных работ (ДСР), АО <ЭЛВИС-ПЛЮС> тел. +7 (495) 276-02-11 доб.175 [cid:image003.jpg@01D602B6.5C6B7D20] www.elvis.ru<http://www.elvis.ru/>

2 5

[jenkins-ci PATCH] guests: enable ccache on CentOS installs
by Daniel P. Berrangé 26 Mar '20

26 Mar '20

Since we enabled use of EPEL in our CentOS installs, we should pull in the ccache package to speed up builds. Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- guests/vars/mappings.yml | 1 - 1 file changed, 1 deletion(-) diff --git a/guests/vars/mappings.yml b/guests/vars/mappings.yml index 9833856..0f7af48 100644 --- a/guests/vars/mappings.yml +++ b/guests/vars/mappings.yml @@ -111,7 +111,6 @@ mappings: ccache: default: ccache - CentOS: check: default: check -- 2.24.1

2 1

[PATCH] rng: Interleave elements in source
by Han Han 26 Mar '20

26 Mar '20

Signed-off-by: Han Han <hhan(a)redhat.com> --- docs/schemas/domaincommon.rng | 350 ++++++++++++++++++---------------- 1 file changed, 186 insertions(+), 164 deletions(-) diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng index d79dee65..96eccaad 100644 --- a/docs/schemas/domaincommon.rng +++ b/docs/schemas/domaincommon.rng @@ -1642,21 +1642,23 @@ </optional> <optional> <element name="source"> - <optional> - <attribute name="file"> - <ref name="absFilePath"/> - </attribute> - </optional> - <ref name="diskSourceCommon"/> - <optional> - <ref name="storageStartupPolicy"/> - </optional> - <optional> - <ref name="encryption"/> - </optional> - <zeroOrMore> - <ref name='devSeclabel'/> - </zeroOrMore> + <interleave> + <optional> + <attribute name="file"> + <ref name="absFilePath"/> + </attribute> + </optional> + <ref name="diskSourceCommon"/> + <optional> + <ref name="storageStartupPolicy"/> + </optional> + <optional> + <ref name="encryption"/> + </optional> + <zeroOrMore> + <ref name='devSeclabel'/> + </zeroOrMore> + </interleave> </element> </optional> </define> @@ -1667,24 +1669,26 @@ </attribute> <optional> <element name="source"> - <optional> - <attribute name="dev"> - <ref name="absFilePath"/> - </attribute> - </optional> - <ref name="diskSourceCommon"/> - <optional> - <ref name="storageStartupPolicy"/> - </optional> - <optional> - <ref name="encryption"/> - </optional> - <optional> - <ref name="reservations"/> - </optional> - <zeroOrMore> - <ref name='devSeclabel'/> - </zeroOrMore> + <interleave> + <optional> + <attribute name="dev"> + <ref name="absFilePath"/> + </attribute> + </optional> + <ref name="diskSourceCommon"/> + <optional> + <ref name="storageStartupPolicy"/> + </optional> + <optional> + <ref name="encryption"/> + </optional> + <optional> + <ref name="reservations"/> + </optional> + <zeroOrMore> + <ref name='devSeclabel'/> + </zeroOrMore> + </interleave> </element> </optional> </define> @@ -1695,17 +1699,19 @@ </attribute> <optional> <element name="source"> - <attribute name="dir"> - <ref name="absFilePath"/> - </attribute> - <ref name="diskSourceCommon"/> - <optional> - <ref name="storageStartupPolicy"/> - </optional> - <optional> - <ref name="encryption"/> - </optional> - <empty/> + <interleave> + <attribute name="dir"> + <ref name="absFilePath"/> + </attribute> + <ref name="diskSourceCommon"/> + <optional> + <ref name="storageStartupPolicy"/> + </optional> + <optional> + <ref name="encryption"/> + </optional> + <empty/> + </interleave> </element> </optional> </define> @@ -1856,138 +1862,152 @@ <define name="diskSourceNetworkProtocolHTTPS"> <element name="source"> - <attribute name="protocol"> - <choice> - <value>https</value> - </choice> - </attribute> - <attribute name="name"/> - <ref name="diskSourceCommon"/> - <ref name="diskSourceNetworkHost"/> - <optional> - <ref name="encryption"/> - </optional> - <optional> - <ref name="diskSourceNetworkProtocolSSLVerify"/> - </optional> - <optional> - <ref name="diskSourceNetworkProtocolHTTPCookies"/> - </optional> - <ref name="diskSourceNetworkProtocolPropsCommon"/> + <interleave> + <attribute name="protocol"> + <choice> + <value>https</value> + </choice> + </attribute> + <attribute name="name"/> + <ref name="diskSourceCommon"/> + <ref name="diskSourceNetworkHost"/> + <optional> + <ref name="encryption"/> + </optional> + <optional> + <ref name="diskSourceNetworkProtocolSSLVerify"/> + </optional> + <optional> + <ref name="diskSourceNetworkProtocolHTTPCookies"/> + </optional> + <ref name="diskSourceNetworkProtocolPropsCommon"/> + </interleave> </element> </define> <define name="diskSourceNetworkProtocolHTTP"> <element name="source"> - <attribute name="protocol"> - <choice> - <value>http</value> - </choice> - </attribute> - <attribute name="name"/> - <ref name="diskSourceCommon"/> - <ref name="diskSourceNetworkHost"/> - <optional> - <ref name="encryption"/> - </optional> - <optional> - <ref name="diskSourceNetworkProtocolHTTPCookies"/> - </optional> - <ref name="diskSourceNetworkProtocolPropsCommon"/> + <interleave> + <attribute name="protocol"> + <choice> + <value>http</value> + </choice> + </attribute> + <attribute name="name"/> + <ref name="diskSourceCommon"/> + <ref name="diskSourceNetworkHost"/> + <optional> + <ref name="encryption"/> + </optional> + <optional> + <ref name="diskSourceNetworkProtocolHTTPCookies"/> + </optional> + <ref name="diskSourceNetworkProtocolPropsCommon"/> + </interleave> </element> </define> <define name="diskSourceNetworkProtocolFTPS"> <element name="source"> - <attribute name="protocol"> - <choice> - <value>ftps</value> - </choice> - </attribute> - <attribute name="name"/> - <ref name="diskSourceCommon"/> - <ref name="diskSourceNetworkHost"/> - <optional> - <ref name="encryption"/> - </optional> - <optional> - <ref name="diskSourceNetworkProtocolSSLVerify"/> - </optional> - <ref name="diskSourceNetworkProtocolPropsCommon"/> + <interleave> + <attribute name="protocol"> + <choice> + <value>ftps</value> + </choice> + </attribute> + <attribute name="name"/> + <ref name="diskSourceCommon"/> + <ref name="diskSourceNetworkHost"/> + <optional> + <ref name="encryption"/> + </optional> + <optional> + <ref name="diskSourceNetworkProtocolSSLVerify"/> + </optional> + <ref name="diskSourceNetworkProtocolPropsCommon"/> + </interleave> </element> </define> <define name="diskSourceNetworkProtocolSimple"> <element name="source"> - <attribute name="protocol"> - <choice> - <value>sheepdog</value> - <value>ftp</value> - <value>tftp</value> - </choice> - </attribute> - <attribute name="name"/> - <ref name="diskSourceCommon"/> - <ref name="diskSourceNetworkHost"/> - <optional> - <ref name="encryption"/> - </optional> - <ref name="diskSourceNetworkProtocolPropsCommon"/> + <interleave> + <attribute name="protocol"> + <choice> + <value>sheepdog</value> + <value>ftp</value> + <value>tftp</value> + </choice> + </attribute> + <attribute name="name"/> + <ref name="diskSourceCommon"/> + <ref name="diskSourceNetworkHost"/> + <optional> + <ref name="encryption"/> + </optional> + <ref name="diskSourceNetworkProtocolPropsCommon"/> + </interleave> </element> </define> <define name="diskSourceNetworkProtocolNBD"> <element name="source"> - <attribute name="protocol"> - <value>nbd</value> - </attribute> - <optional> - <attribute name="name"/> - </optional> - <optional> - <attribute name="tls"> - <ref name="virYesNo"/> + <interleave> + <attribute name="protocol"> + <value>nbd</value> </attribute> - </optional> - <ref name="diskSourceCommon"/> - <ref name="diskSourceNetworkHost"/> - <optional> - <ref name="encryption"/> - </optional> + <optional> + <attribute name="name"/> + </optional> + <optional> + <attribute name="tls"> + <ref name="virYesNo"/> + </attribute> + </optional> + <ref name="diskSourceCommon"/> + <ref name="diskSourceNetworkHost"/> + <optional> + <ref name="encryption"/> + </optional> + </interleave> </element> </define> <define name="diskSourceNetworkProtocolGluster"> <element name="source"> - <attribute name="protocol"> - <value>gluster</value> - </attribute> - <attribute name="name"/> - <ref name="diskSourceCommon"/> - <oneOrMore> - <ref name="diskSourceNetworkHost"/> - </oneOrMore> - <optional> - <ref name="encryption"/> - </optional> + <interleave> + <attribute name="protocol"> + <value>gluster</value> + </attribute> + <attribute name="name"/> + <ref name="diskSourceCommon"/> + <oneOrMore> + <ref name="diskSourceNetworkHost"/> + </oneOrMore> + <optional> + <ref name="encryption"/> + </optional> + </interleave> </element> </define> <define name="diskSourceNetworkProtocolVxHS"> <element name="source"> - <attribute name="protocol"> - <choice> - <value>vxhs</value> - </choice> - </attribute> - <attribute name="name"/> - <ref name="diskSourceCommon"/> - <optional> - <attribute name="tls"> - <ref name="virYesNo"/> + <interleave> + <attribute name="protocol"> + <choice> + <value>vxhs</value> + </choice> </attribute> - </optional> - <ref name="diskSourceNetworkHost"/> + <attribute name="name"/> + <ref name="diskSourceCommon"/> + <optional> + <attribute name="tls"> + <ref name="virYesNo"/> + </attribute> + </optional> + <ref name="diskSourceNetworkHost"/> + </interleave> </element> </define> @@ -2048,27 +2068,29 @@ </attribute> <optional> <element name="source"> - <attribute name="type"> - <value>pci</value> - </attribute> - <attribute name="namespace"> - <ref name="uint32"/> - </attribute> - <optional> - <attribute name="managed"> - <ref name="virYesNo"/> + <interleave> + <attribute name="type"> + <value>pci</value> </attribute> - </optional> - <element name="address"> - <ref name="pciaddress"/> - </element> - <ref name="diskSourceCommon"/> - <optional> - <ref name="storageStartupPolicy"/> - </optional> - <optional> - <ref name="encryption"/> - </optional> + <attribute name="namespace"> + <ref name="uint32"/> + </attribute> + <optional> + <attribute name="managed"> + <ref name="virYesNo"/> + </attribute> + </optional> + <element name="address"> + <ref name="pciaddress"/> + </element> + <ref name="diskSourceCommon"/> + <optional> + <ref name="storageStartupPolicy"/> + </optional> + <optional> + <ref name="encryption"/> + </optional> + </interleave> </element> </optional> </define> -- 2.25.0

2 1

[PATCH 0/9] Another round of qemu:///embed fixes
by Michal Privoznik 26 Mar '20

26 Mar '20

After my first round of patches got merged [1], some new problems arose. They are not as serious (except maybe for 7/9) but they are still problematic for sure. Mostly in scenarios where a mgmt application uses the embedded driver and has multiple forks/instances sharing essentially the same config (e.g. it writes the same qemu.conf into different roots). Thing is, we may generate conflicting paths across these instances. What I've done here is, I looked at what paths can be set from qemu.conf and on their usage. Then I've grepped for virDomainDefGetShortName() and looked at its usages, because that has proven to be common denominator in patches 7-9. Some usages of the function are safe though. When the usage involves a path that is derived from the root and can't be overridden in qemu.conf it is safe. For instance, qemuDBusGetAddress() calls virDomainDefGetShortName() to construct a path to a UNIX socket. But the path has cfg->dbusStateDir prefix which is derived from cfg->stateDir which in turn is derived from the root. At the same time, neither of these paths can be overridden in qemu.conf. Therefore, no conflicts can occur. Michal Prívozník (9): tests: Fix virQEMUDriverConfigNew() calling with respect to @root conf: Move virDomainGenerateMachineName to hypervisor/ virDomainDriverGenerateMachineName: Factor out embed path hashing qemu: Introduce virQEMUDriverGetEmbedRoot qemuDomainGetMachineName: Access embeddedRoot from driver rather than cfg Revert "qemu_conf: Track embed root dir" qemu: Make hugepages path generation embed driver aware qemu: Make memory path generation embed driver aware qemu: Make auto dump path generation embed driver aware src/conf/domain_conf.c | 72 ---------------------------- src/conf/domain_conf.h | 7 --- src/hypervisor/domain_driver.c | 88 ++++++++++++++++++++++++++++++++++ src/hypervisor/domain_driver.h | 11 +++++ src/libvirt_private.syms | 3 +- src/lxc/lxc_domain.c | 3 +- src/qemu/qemu_command.c | 19 ++++---- src/qemu/qemu_conf.c | 64 ++++++++++++++++++------- src/qemu/qemu_conf.h | 23 ++++----- src/qemu/qemu_domain.c | 9 ++-- src/qemu/qemu_driver.c | 10 +++- src/qemu/qemu_process.c | 7 ++- tests/domaincapstest.c | 2 +- tests/testutilsqemu.c | 2 +- tests/virsystemdtest.c | 5 +- 15 files changed, 191 insertions(+), 134 deletions(-) -- 2.24.1

4 18

[PATCH] docs: fix typo in domcaps host-model CPU description
by Jim Fehlig 25 Mar '20

25 Mar '20

The domain capabilities documentation contains a small but confusing error in the host-model CPU description, referencing the element <mode> instead of <model>. Fix this small typo. Signed-off-by: Jim Fehlig <jfehlig(a)suse.com> --- I only found this small typo (well, I'm pretty sure it's a typo :-)) by tring to understand a more confusing observation. On a machine where capabilities reports CascaseLake-Server, domcapabilities reports <mode name='host-model' supported='yes'> <model fallback='forbid'>Cascadelake-Server</model> <vendor>Intel</vendor> <feature policy='require' name='ss'/> <feature policy='require' name='hypervisor'/> <feature policy='require' name='tsc_adjust'/> <feature policy='require' name='umip'/> <feature policy='require' name='pku'/> <feature policy='require' name='md-clear'/> <feature policy='require' name='stibp'/> <feature policy='require' name='arch-capabilities'/> <feature policy='require' name='xsaves'/> <feature policy='require' name='invtsc'/> </mode> <mode name='custom' supported='yes'> ... <model usable='no'>Cascadelake-Server</model> </mode> So using host-model will result in a CascadeLake-Server CPU, but it is not supported when specifying a custom CPU? Interestingly, I see something similar from domcapabilities on machine where capabilities reports Skylake-Server-IBRS <mode name='host-model' supported='yes'> <model fallback='forbid'>Cascadelake-Server</model> <vendor>Intel</vendor> <feature policy='require' name='ss'/> <feature policy='require' name='hypervisor'/> <feature policy='require' name='tsc_adjust'/> <feature policy='require' name='umip'/> <feature policy='require' name='md-clear'/> <feature policy='require' name='stibp'/> <feature policy='require' name='arch-capabilities'/> <feature policy='require' name='xsaves'/> <feature policy='require' name='invtsc'/> <feature policy='disable' name='pku'/> <feature policy='disable' name='avx512vnni'/> </mode> <mode name='custom' supported='yes'> ... <model usable='no'>Skylake-Server-IBRS</model> <model usable='no'>Skylake-Server</model> <model usable='no'>Cascadelake-Server</model> </mode> This seems contradictory to me but perhaps I'm overlooking something? docs/formatdomaincaps.html.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/formatdomaincaps.html.in b/docs/formatdomaincaps.html.in index 66e758501b..7fd1f91f73 100644 --- a/docs/formatdomaincaps.html.in +++ b/docs/formatdomaincaps.html.in @@ -232,7 +232,7 @@ <dt><code>host-model</code></dt> <dd> If <code>host-model</code> is supported by the hypervisor, the - <code>mode</code> describes the guest CPU which will be used when + <code>model</code> describes the guest CPU which will be used when starting a domain with <code>host-model</code> CPU. The hypervisor specifics (such as unsupported CPU models or features, machine type, etc.) may be accounted for in this guest CPU specification and thus -- 2.25.0

2 4

[PATCH 1/2] gobject: Fix typo in documentation of gvir_domain_save_to_file_async
by Felipe Borges 25 Mar '20

25 Mar '20

Signed-off-by: Felipe Borges <feborges(a)redhat.com> --- libvirt-gobject/libvirt-gobject-domain.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libvirt-gobject/libvirt-gobject-domain.c b/libvirt-gobject/libvirt-gobject-domain.c index 399b118..0a16cb4 100644 --- a/libvirt-gobject/libvirt-gobject-domain.c +++ b/libvirt-gobject/libvirt-gobject-domain.c @@ -777,7 +777,7 @@ gvir_domain_save_to_file_helper(GTask *task, * @filename: path to output file * @custom_conf: (allow-none): configuration for domain or NULL * @flags: the flags - * @cancellable: (allow-none) (transfer none): cancallation object + * @cancellable: (allow-none) (transfer none): cancellation object * @callback: (scope async): completion callback * @user_data: (closure): opaque data for callback * -- 2.24.1

3 3

[PATCH] qemu: capabilities: update qemu-4.2 capabilities for s390x
by Bjoern Walk 25 Mar '20

25 Mar '20

Update s390x capabilities for QEMU 4.2 with the actual GA version for QEMU and on the latest z15 machine. This picks up the new blockdev capability, so we need to refresh a bunch of test cases as well. Reviewed-by: Boris Fiuczynski <fiuczy(a)linux.ibm.com> Signed-off-by: Bjoern Walk <bwalk(a)linux.ibm.com> --- I have stripped the replies file to save some bandwidth on the mailing list. Full patch can be found here: https://gitlab.com/bwalk/libvirt/-/commit/5fc05853f2cc6d191a07f897cdd4e12fa… tests/domaincapsdata/qemu_4.2.0.s390x.xml | 47 +- .../caps_4.2.0.s390x.replies | 3230 +++++++++-------- .../qemucapabilitiesdata/caps_4.2.0.s390x.xml | 216 +- ...default-video-type-s390x.s390x-latest.args | 8 +- .../fs9p-ccw.s390x-latest.args | 7 +- ...othreads-virtio-scsi-ccw.s390x-latest.args | 14 +- ...t-cpu-kvm-ccw-virtio-4.2.s390x-latest.args | 8 +- .../s390x-ccw-graphics.s390x-latest.args | 8 +- .../s390x-ccw-headless.s390x-latest.args | 8 +- .../vhost-vsock-ccw-auto.s390x-latest.args | 7 +- .../vhost-vsock-ccw.s390x-latest.args | 7 +- 11 files changed, 1871 insertions(+), 1689 deletions(-) diff --git a/tests/domaincapsdata/qemu_4.2.0.s390x.xml b/tests/domaincapsdata/qemu_4.2.0.s390x.xml index fbb3905f..6b87e450 100644 --- a/tests/domaincapsdata/qemu_4.2.0.s390x.xml +++ b/tests/domaincapsdata/qemu_4.2.0.s390x.xml @@ -27,9 +27,17 @@ <cpu> <mode name='host-passthrough' supported='yes'/> <mode name='host-model' supported='yes'> - <model fallback='forbid'>z13.2-base</model> + <model fallback='forbid'>gen15a-base</model> <feature policy='require' name='aen'/> + <feature policy='require' name='cmmnt'/> + <feature policy='require' name='vxpdeh'/> <feature policy='require' name='aefsi'/> + <feature policy='require' name='csske'/> + <feature policy='require' name='mepoch'/> + <feature policy='require' name='msa9'/> + <feature policy='require' name='msa8'/> + <feature policy='require' name='msa7'/> + <feature policy='require' name='msa6'/> <feature policy='require' name='msa5'/> <feature policy='require' name='msa4'/> <feature policy='require' name='msa3'/> @@ -38,15 +46,26 @@ <feature policy='require' name='sthyi'/> <feature policy='require' name='edat'/> <feature policy='require' name='ri'/> + <feature policy='require' name='deflate'/> <feature policy='require' name='edat2'/> + <feature policy='require' name='etoken'/> <feature policy='require' name='vx'/> <feature policy='require' name='ipter'/> + <feature policy='require' name='mepochptff'/> <feature policy='require' name='ap'/> + <feature policy='require' name='vxeh'/> + <feature policy='require' name='vxpd'/> <feature policy='require' name='esop'/> + <feature policy='require' name='msa9_pckmo'/> + <feature policy='require' name='vxeh2'/> + <feature policy='require' name='esort'/> + <feature policy='require' name='apqi'/> <feature policy='require' name='apft'/> + <feature policy='require' name='iep'/> <feature policy='require' name='apqci'/> <feature policy='require' name='cte'/> <feature policy='require' name='bpb'/> + <feature policy='require' name='gs'/> <feature policy='require' name='ppa15'/> <feature policy='require' name='zpci'/> <feature policy='require' name='sea_esop2'/> @@ -58,8 +77,8 @@ <model usable='yes'>z890.2-base</model> <model usable='yes'>z9EC.2</model> <model usable='yes'>z13.2</model> - <model usable='yes'>z990.5-base</model> <model usable='yes'>z9BC-base</model> + <model usable='yes'>z990.5-base</model> <model usable='yes'>z890.2</model> <model usable='yes'>z890</model> <model usable='yes'>z9BC</model> @@ -69,9 +88,9 @@ <model usable='yes'>z990.3</model> <model usable='yes'>z13s-base</model> <model usable='yes'>z9EC</model> - <model usable='no'>gen15a</model> - <model usable='no'>z14ZR1-base</model> - <model usable='no'>z14.2-base</model> + <model usable='yes'>gen15a</model> + <model usable='yes'>z14ZR1-base</model> + <model usable='yes'>z14.2-base</model> <model usable='yes'>z900.3-base</model> <model usable='yes'>z13.2-base</model> <model usable='yes'>z196.2-base</model> @@ -86,18 +105,18 @@ <model usable='yes'>z10EC.2</model> <model usable='yes'>z10EC-base</model> <model usable='yes'>z900.3</model> - <model usable='no'>z14ZR1</model> + <model usable='yes'>z14ZR1</model> <model usable='yes'>z10BC</model> <model usable='yes'>z10BC.2-base</model> - <model usable='yes'>z9BC.2</model> <model usable='yes'>z990.2</model> + <model usable='yes'>z9BC.2</model> <model usable='yes'>z990</model> - <model usable='no'>z14</model> - <model usable='no'>gen15b-base</model> + <model usable='yes'>z14</model> + <model usable='yes'>gen15b-base</model> <model usable='yes'>z990.4</model> <model usable='yes'>max</model> <model usable='yes'>z10EC.2-base</model> - <model usable='no'>gen15a-base</model> + <model usable='yes'>gen15a-base</model> <model usable='yes'>z800</model> <model usable='yes'>zEC12.2</model> <model usable='yes'>z10EC</model> @@ -111,12 +130,12 @@ <model usable='yes'>z196-base</model> <model usable='yes'>z9EC.2-base</model> <model usable='yes'>z196.2</model> - <model usable='no'>z14.2</model> + <model usable='yes'>z14.2</model> <model usable='yes'>z990-base</model> <model usable='yes'>z900.2</model> <model usable='yes'>z890-base</model> <model usable='yes'>z10EC.3</model> - <model usable='no'>z14-base</model> + <model usable='yes'>z14-base</model> <model usable='yes'>z990.4-base</model> <model usable='yes'>z10EC.3-base</model> <model usable='yes'>z10BC-base</model> @@ -126,7 +145,7 @@ <model usable='yes'>zBC12</model> <model usable='yes'>z890.3-base</model> <model usable='yes'>z990.5</model> - <model usable='no'>gen15b</model> + <model usable='yes'>gen15b</model> <model usable='no'>qemu</model> </mode> </cpu> @@ -198,7 +217,7 @@ <gic supported='no'/> <vmcoreinfo supported='no'/> <genid supported='no'/> - <backingStoreInput supported='no'/> + <backingStoreInput supported='yes'/> <backup supported='no'/> <sev supported='no'/> </features> diff --git a/tests/qemucapabilitiesdata/caps_4.2.0.s390x.replies b/tests/qemucapabilitiesdata/caps_4.2.0.s390x.replies index be709b3c..82b60bf0 100644 --- a/tests/qemucapabilitiesdata/caps_4.2.0.s390x.replies +++ b/tests/qemucapabilitiesdata/caps_4.2.0.s390x.replies @@ -17,11 +17,11 @@ [...] diff --git a/tests/qemucapabilitiesdata/caps_4.2.0.s390x.xml b/tests/qemucapabilitiesdata/caps_4.2.0.s390x.xml index 37776e1b..e46259e6 100644 --- a/tests/qemucapabilitiesdata/caps_4.2.0.s390x.xml +++ b/tests/qemucapabilitiesdata/caps_4.2.0.s390x.xml @@ -8,12 +8,14 @@ <flag name='virtio-blk-pci.ioeventfd'/> <flag name='virtio-blk-pci.event_idx'/> <flag name='virtio-net-pci.event_idx'/> + <flag name='usb-redir'/> <flag name='virtio-blk-pci.scsi'/> <flag name='scsi-disk.channel'/> <flag name='scsi-block'/> <flag name='dump-guest-memory'/> <flag name='virtio-scsi-pci'/> <flag name='blockio'/> + <flag name='usb-redir.filter'/> <flag name='scsi-disk.wwn'/> <flag name='seccomp-sandbox'/> <flag name='reboot-timeout'/> @@ -49,6 +51,7 @@ <flag name='gic-version'/> <flag name='incoming-defer'/> <flag name='virtio-gpu'/> + <flag name='virtio-gpu.virgl'/> <flag name='virtio-keyboard'/> <flag name='virtio-mouse'/> <flag name='virtio-tablet'/> @@ -115,6 +118,7 @@ <flag name='chardev-fd-pass'/> <flag name='egl-headless'/> <flag name='vfio-pci.display'/> + <flag name='blockdev'/> <flag name='vfio-ap'/> <flag name='zpci'/> <flag name='memory-backend-memfd'/> @@ -134,18 +138,28 @@ <flag name='query-cpu-model-baseline'/> <flag name='query-cpu-model-comparison'/> <flag name='blockdev-file-dynamic-auto-read-only'/> + <flag name='savevm-monitor-nodes'/> <flag name='drive-nvme'/> <flag name='smp-dies'/> <flag name='rng-builtin'/> + <flag name='virtio-net.failover'/> <flag name='vhost-user-fs'/> - <version>4001050</version> + <version>4002000</version> <kvmVersion>0</kvmVersion> <microcodeVersion>39100242</microcodeVersion> - <package>v4.1.0-1686-g419af24e7e-dirty</package> + <package>qemu-4.2.0-20200115.0.1e4aa2da.fc31</package> <arch>s390x</arch> - <hostCPU type='kvm' model='z13.2-base' migratability='no'> + <hostCPU type='kvm' model='gen15a-base' migratability='no'> <property name='aen' type='boolean' value='true'/> + <property name='cmmnt' type='boolean' value='true'/> + <property name='vxpdeh' type='boolean' value='true'/> <property name='aefsi' type='boolean' value='true'/> + <property name='csske' type='boolean' value='true'/> + <property name='mepoch' type='boolean' value='true'/> + <property name='msa9' type='boolean' value='true'/> + <property name='msa8' type='boolean' value='true'/> + <property name='msa7' type='boolean' value='true'/> + <property name='msa6' type='boolean' value='true'/> <property name='msa5' type='boolean' value='true'/> <property name='msa4' type='boolean' value='true'/> <property name='msa3' type='boolean' value='true'/> @@ -154,15 +168,26 @@ <property name='sthyi' type='boolean' value='true'/> <property name='edat' type='boolean' value='true'/> <property name='ri' type='boolean' value='true'/> + <property name='deflate' type='boolean' value='true'/> <property name='edat2' type='boolean' value='true'/> + <property name='etoken' type='boolean' value='true'/> <property name='vx' type='boolean' value='true'/> <property name='ipter' type='boolean' value='true'/> + <property name='mepochptff' type='boolean' value='true'/> <property name='ap' type='boolean' value='true'/> + <property name='vxeh' type='boolean' value='true'/> + <property name='vxpd' type='boolean' value='true'/> <property name='esop' type='boolean' value='true'/> + <property name='msa9_pckmo' type='boolean' value='true'/> + <property name='vxeh2' type='boolean' value='true'/> + <property name='esort' type='boolean' value='true'/> + <property name='apqi' type='boolean' value='true'/> <property name='apft' type='boolean' value='true'/> + <property name='iep' type='boolean' value='true'/> <property name='apqci' type='boolean' value='true'/> <property name='cte' type='boolean' value='true'/> <property name='bpb' type='boolean' value='true'/> + <property name='gs' type='boolean' value='true'/> <property name='ppa15' type='boolean' value='true'/> <property name='zpci' type='boolean' value='true'/> <property name='sea_esop2' type='boolean' value='true'/> @@ -173,8 +198,8 @@ <cpu type='kvm' name='z890.2-base' typename='z890.2-base-s390x-cpu' usable='yes'/> <cpu type='kvm' name='z9EC.2' typename='z9EC.2-s390x-cpu' usable='yes'/> <cpu type='kvm' name='z13.2' typename='z13.2-s390x-cpu' usable='yes'/> - <cpu type='kvm' name='z990.5-base' typename='z990.5-base-s390x-cpu' usable='yes'/> <cpu type='kvm' name='z9BC-base' typename='z9BC-base-s390x-cpu' usable='yes'/> + <cpu type='kvm' name='z990.5-base' typename='z990.5-base-s390x-cpu' usable='yes'/> <cpu type='kvm' name='z890.2' typename='z890.2-s390x-cpu' usable='yes'/> <cpu type='kvm' name='z890' typename='z890-s390x-cpu' usable='yes'/> <cpu type='kvm' name='z9BC' typename='z9BC-s390x-cpu' usable='yes'/> @@ -185,46 +210,9 @@ <cpu type='kvm' name='z990.3' typename='z990.3-s390x-cpu' usable='yes'/> <cpu type='kvm' name='z13s-base' typename='z13s-base-s390x-cpu' usable='yes'/> <cpu type='kvm' name='z9EC' typename='z9EC-s390x-cpu' usable='yes'/> - <cpu type='kvm' name='gen15a' typename='gen15a-s390x-cpu' usable='no'> - <blocker name='etoken'/> - <blocker name='vxpdeh'/> - <blocker name='vxeh2'/> - <blocker name='mepoch'/> - <blocker name='vxeh'/> - <blocker name='vxpd'/> - <blocker name='gs'/> - <blocker name='iep'/> - <blocker name='minste3'/> - <blocker name='tsi'/> - <blocker name='sema'/> - <blocker name='minste2'/> - <blocker name='eec'/> - <blocker name='opc'/> - <blocker name='deflate'/> - <blocker name='mepochptff'/> - <blocker name='msa9_pckmo'/> - <blocker name='msa9'/> - <blocker name='msa8'/> - <blocker name='msa7'/> - <blocker name='msa6'/> - <blocker name='type'/> - </cpu> - <cpu type='kvm' name='z14ZR1-base' typename='z14ZR1-base-s390x-cpu' usable='no'> - <blocker name='tsi'/> - <blocker name='sema'/> - <blocker name='minste2'/> - <blocker name='eec'/> - <blocker name='opc'/> - <blocker name='type'/> - </cpu> - <cpu type='kvm' name='z14.2-base' typename='z14.2-base-s390x-cpu' usable='no'> - <blocker name='tsi'/> - <blocker name='sema'/> - <blocker name='minste2'/> - <blocker name='eec'/> - <blocker name='opc'/> - <blocker name='type'/> - </cpu> + <cpu type='kvm' name='gen15a' typename='gen15a-s390x-cpu' usable='yes'/> + <cpu type='kvm' name='z14ZR1-base' typename='z14ZR1-base-s390x-cpu' usable='yes'/> + <cpu type='kvm' name='z14.2-base' typename='z14.2-base-s390x-cpu' usable='yes'/> <cpu type='kvm' name='z900.3-base' typename='z900.3-base-s390x-cpu' usable='yes'/> <cpu type='kvm' name='z13.2-base' typename='z13.2-base-s390x-cpu' usable='yes'/> <cpu type='kvm' name='z196.2-base' typename='z196.2-base-s390x-cpu' usable='yes'/> @@ -239,66 +227,18 @@ <cpu type='kvm' name='z10EC.2' typename='z10EC.2-s390x-cpu' usable='yes'/> <cpu type='kvm' name='z10EC-base' typename='z10EC-base-s390x-cpu' usable='yes'/> <cpu type='kvm' name='z900.3' typename='z900.3-s390x-cpu' usable='yes'/> - <cpu type='kvm' name='z14ZR1' typename='z14ZR1-s390x-cpu' usable='no'> - <blocker name='mepoch'/> - <blocker name='vxeh'/> - <blocker name='vxpd'/> - <blocker name='gs'/> - <blocker name='iep'/> - <blocker name='tsi'/> - <blocker name='sema'/> - <blocker name='minste2'/> - <blocker name='eec'/> - <blocker name='opc'/> - <blocker name='mepochptff'/> - <blocker name='msa8'/> - <blocker name='msa7'/> - <blocker name='msa6'/> - <blocker name='type'/> - </cpu> + <cpu type='kvm' name='z14ZR1' typename='z14ZR1-s390x-cpu' usable='yes'/> <cpu type='kvm' name='z10BC' typename='z10BC-s390x-cpu' usable='yes'/> <cpu type='kvm' name='z10BC.2-base' typename='z10BC.2-base-s390x-cpu' usable='yes'/> - <cpu type='kvm' name='z9BC.2' typename='z9BC.2-s390x-cpu' usable='yes'/> <cpu type='kvm' name='z990.2' typename='z990.2-s390x-cpu' usable='yes'/> + <cpu type='kvm' name='z9BC.2' typename='z9BC.2-s390x-cpu' usable='yes'/> <cpu type='kvm' name='z990' typename='z990-s390x-cpu' usable='yes'/> - <cpu type='kvm' name='z14' typename='z14-s390x-cpu' usable='no'> - <blocker name='mepoch'/> - <blocker name='vxeh'/> - <blocker name='vxpd'/> - <blocker name='gs'/> - <blocker name='iep'/> - <blocker name='tsi'/> - <blocker name='sema'/> - <blocker name='minste2'/> - <blocker name='eec'/> - <blocker name='opc'/> - <blocker name='mepochptff'/> - <blocker name='msa8'/> - <blocker name='msa7'/> - <blocker name='msa6'/> - <blocker name='type'/> - </cpu> - <cpu type='kvm' name='gen15b-base' typename='gen15b-base-s390x-cpu' usable='no'> - <blocker name='minste3'/> - <blocker name='tsi'/> - <blocker name='sema'/> - <blocker name='minste2'/> - <blocker name='eec'/> - <blocker name='opc'/> - <blocker name='type'/> - </cpu> + <cpu type='kvm' name='z14' typename='z14-s390x-cpu' usable='yes'/> + <cpu type='kvm' name='gen15b-base' typename='gen15b-base-s390x-cpu' usable='yes'/> <cpu type='kvm' name='z990.4' typename='z990.4-s390x-cpu' usable='yes'/> <cpu type='kvm' name='max' typename='max-s390x-cpu' usable='yes'/> <cpu type='kvm' name='z10EC.2-base' typename='z10EC.2-base-s390x-cpu' usable='yes'/> - <cpu type='kvm' name='gen15a-base' typename='gen15a-base-s390x-cpu' usable='no'> - <blocker name='minste3'/> - <blocker name='tsi'/> - <blocker name='sema'/> - <blocker name='minste2'/> - <blocker name='eec'/> - <blocker name='opc'/> - <blocker name='type'/> - </cpu> + <cpu type='kvm' name='gen15a-base' typename='gen15a-base-s390x-cpu' usable='yes'/> <cpu type='kvm' name='z800' typename='z800-s390x-cpu' usable='yes'/> <cpu type='kvm' name='zEC12.2' typename='zEC12.2-s390x-cpu' usable='yes'/> <cpu type='kvm' name='z10EC' typename='z10EC-s390x-cpu' usable='yes'/> @@ -312,35 +252,12 @@ <cpu type='kvm' name='z196-base' typename='z196-base-s390x-cpu' usable='yes'/> <cpu type='kvm' name='z9EC.2-base' typename='z9EC.2-base-s390x-cpu' usable='yes'/> <cpu type='kvm' name='z196.2' typename='z196.2-s390x-cpu' usable='yes'/> - <cpu type='kvm' name='z14.2' typename='z14.2-s390x-cpu' usable='no'> - <blocker name='mepoch'/> - <blocker name='vxeh'/> - <blocker name='vxpd'/> - <blocker name='gs'/> - <blocker name='iep'/> - <blocker name='tsi'/> - <blocker name='sema'/> - <blocker name='minste2'/> - <blocker name='eec'/> - <blocker name='opc'/> - <blocker name='mepochptff'/> - <blocker name='msa8'/> - <blocker name='msa7'/> - <blocker name='msa6'/> - <blocker name='type'/> - </cpu> + <cpu type='kvm' name='z14.2' typename='z14.2-s390x-cpu' usable='yes'/> <cpu type='kvm' name='z990-base' typename='z990-base-s390x-cpu' usable='yes'/> <cpu type='kvm' name='z900.2' typename='z900.2-s390x-cpu' usable='yes'/> <cpu type='kvm' name='z890-base' typename='z890-base-s390x-cpu' usable='yes'/> <cpu type='kvm' name='z10EC.3' typename='z10EC.3-s390x-cpu' usable='yes'/> - <cpu type='kvm' name='z14-base' typename='z14-base-s390x-cpu' usable='no'> - <blocker name='tsi'/> - <blocker name='sema'/> - <blocker name='minste2'/> - <blocker name='eec'/> - <blocker name='opc'/> - <blocker name='type'/> - </cpu> + <cpu type='kvm' name='z14-base' typename='z14-base-s390x-cpu' usable='yes'/> <cpu type='kvm' name='z990.4-base' typename='z990.4-base-s390x-cpu' usable='yes'/> <cpu type='kvm' name='z10EC.3-base' typename='z10EC.3-base-s390x-cpu' usable='yes'/> <cpu type='kvm' name='z10BC-base' typename='z10BC-base-s390x-cpu' usable='yes'/> @@ -350,30 +267,7 @@ <cpu type='kvm' name='zBC12' typename='zBC12-s390x-cpu' usable='yes'/> <cpu type='kvm' name='z890.3-base' typename='z890.3-base-s390x-cpu' usable='yes'/> <cpu type='kvm' name='z990.5' typename='z990.5-s390x-cpu' usable='yes'/> - <cpu type='kvm' name='gen15b' typename='gen15b-s390x-cpu' usable='no'> - <blocker name='etoken'/> - <blocker name='vxpdeh'/> - <blocker name='vxeh2'/> - <blocker name='mepoch'/> - <blocker name='vxeh'/> - <blocker name='vxpd'/> - <blocker name='gs'/> - <blocker name='iep'/> - <blocker name='minste3'/> - <blocker name='tsi'/> - <blocker name='sema'/> - <blocker name='minste2'/> - <blocker name='eec'/> - <blocker name='opc'/> - <blocker name='deflate'/> - <blocker name='mepochptff'/> - <blocker name='msa9_pckmo'/> - <blocker name='msa9'/> - <blocker name='msa8'/> - <blocker name='msa7'/> - <blocker name='msa6'/> - <blocker name='type'/> - </cpu> + <cpu type='kvm' name='gen15b' typename='gen15b-s390x-cpu' usable='yes'/> <cpu type='kvm' name='qemu' typename='qemu-s390x-cpu' usable='no'> <blocker name='ais'/> </cpu> @@ -593,7 +487,7 @@ <blocker name='gen13ptff'/> <blocker name='tods'/> </cpu> - <cpu type='tcg' name='z990.5-base' typename='z990.5-base-s390x-cpu' usable='no'> + <cpu type='tcg' name='z9BC-base' typename='z9BC-base-s390x-cpu' usable='no'> <blocker name='klmd-sha-1'/> <blocker name='kimd-sha-1'/> <blocker name='km-tdea-192'/> @@ -605,9 +499,13 @@ <blocker name='kmac-tdea-192'/> <blocker name='kmac-tdea-128'/> <blocker name='kmac-dea'/> + <blocker name='dateh2'/> + <blocker name='hfpue'/> <blocker name='hfpm'/> + <blocker name='asnlxr'/> + <blocker name='tods'/> </cpu> - <cpu type='tcg' name='z9BC-base' typename='z9BC-base-s390x-cpu' usable='no'> + <cpu type='tcg' name='z990.5-base' typename='z990.5-base-s390x-cpu' usable='no'> <blocker name='klmd-sha-1'/> <blocker name='kimd-sha-1'/> <blocker name='km-tdea-192'/> @@ -619,11 +517,7 @@ <blocker name='kmac-tdea-192'/> <blocker name='kmac-tdea-128'/> <blocker name='kmac-dea'/> - <blocker name='dateh2'/> - <blocker name='hfpue'/> <blocker name='hfpm'/> - <blocker name='asnlxr'/> - <blocker name='tods'/> </cpu> <cpu type='tcg' name='z890.2' typename='z890.2-s390x-cpu' usable='no'> <blocker name='klmd-sha-1'/> @@ -1867,7 +1761,7 @@ <blocker name='asnlxr'/> <blocker name='tods'/> </cpu> - <cpu type='tcg' name='z9BC.2' typename='z9BC.2-s390x-cpu' usable='no'> + <cpu type='tcg' name='z990.2' typename='z990.2-s390x-cpu' usable='no'> <blocker name='klmd-sha-1'/> <blocker name='kimd-sha-1'/> <blocker name='km-tdea-192'/> @@ -1879,16 +1773,9 @@ <blocker name='kmac-tdea-192'/> <blocker name='kmac-tdea-128'/> <blocker name='kmac-dea'/> - <blocker name='cmm'/> - <blocker name='dateh2'/> - <blocker name='sthyi'/> - <blocker name='hfpue'/> <blocker name='hfpm'/> - <blocker name='asnlxr'/> - <blocker name='msa1'/> - <blocker name='tods'/> </cpu> - <cpu type='tcg' name='z990.2' typename='z990.2-s390x-cpu' usable='no'> + <cpu type='tcg' name='z9BC.2' typename='z9BC.2-s390x-cpu' usable='no'> <blocker name='klmd-sha-1'/> <blocker name='kimd-sha-1'/> <blocker name='km-tdea-192'/> @@ -1900,7 +1787,14 @@ <blocker name='kmac-tdea-192'/> <blocker name='kmac-tdea-128'/> <blocker name='kmac-dea'/> + <blocker name='cmm'/> + <blocker name='dateh2'/> + <blocker name='sthyi'/> + <blocker name='hfpue'/> <blocker name='hfpm'/> + <blocker name='asnlxr'/> + <blocker name='msa1'/> + <blocker name='tods'/> </cpu> <cpu type='tcg' name='z990' typename='z990-s390x-cpu' usable='no'> <blocker name='klmd-sha-1'/> diff --git a/tests/qemuxml2argvdata/default-video-type-s390x.s390x-latest.args b/tests/qemuxml2argvdata/default-video-type-s390x.s390x-latest.args index 934c5d59..47818085 100644 --- a/tests/qemuxml2argvdata/default-video-type-s390x.s390x-latest.args +++ b/tests/qemuxml2argvdata/default-video-type-s390x.s390x-latest.args @@ -13,9 +13,11 @@ QEMU_AUDIO_DRV=none \ -object secret,id=masterKey0,format=raw,\ file=/tmp/lib/domain--1-default-video-type-s/master-key.aes \ -machine s390-ccw-virtio,accel=kvm,usb=off,dump-guest-core=off \ --cpu z13.2-base,aen=on,aefsi=on,msa5=on,msa4=on,msa3=on,msa2=on,msa1=on,\ -sthyi=on,edat=on,ri=on,edat2=on,vx=on,ipter=on,ap=on,esop=on,apft=on,apqci=on,\ -cte=on,bpb=on,ppa15=on,zpci=on,sea_esop2=on,te=on,cmm=on \ +-cpu gen15a-base,aen=on,cmmnt=on,vxpdeh=on,aefsi=on,csske=on,mepoch=on,msa9=on,\ +msa8=on,msa7=on,msa6=on,msa5=on,msa4=on,msa3=on,msa2=on,msa1=on,sthyi=on,\ +edat=on,ri=on,deflate=on,edat2=on,etoken=on,vx=on,ipter=on,mepochptff=on,ap=on,\ +vxeh=on,vxpd=on,esop=on,msa9_pckmo=on,vxeh2=on,esort=on,apqi=on,apft=on,iep=on,\ +apqci=on,cte=on,bpb=on,gs=on,ppa15=on,zpci=on,sea_esop2=on,te=on,cmm=on \ -m 1024 \ -overcommit mem-lock=off \ -smp 1,sockets=1,cores=1,threads=1 \ diff --git a/tests/qemuxml2argvdata/fs9p-ccw.s390x-latest.args b/tests/qemuxml2argvdata/fs9p-ccw.s390x-latest.args index 4a93ee37..50d4bc42 100644 --- a/tests/qemuxml2argvdata/fs9p-ccw.s390x-latest.args +++ b/tests/qemuxml2argvdata/fs9p-ccw.s390x-latest.args @@ -26,8 +26,11 @@ file=/tmp/lib/domain--1-QEMUGuest1/master-key.aes \ -rtc base=utc \ -no-shutdown \ -boot strict=on \ --drive file=/dev/HostVG/QEMUGuest1,format=raw,if=none,id=drive-virtio-disk0 \ --device virtio-blk-ccw,scsi=off,devno=fe.0.0000,drive=drive-virtio-disk0,\ +-blockdev '{"driver":"host_device","filename":"/dev/HostVG/QEMUGuest1",\ +"node-name":"libvirt-1-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-1-format","read-only":false,"driver":"raw",\ +"file":"libvirt-1-storage"}' \ +-device virtio-blk-ccw,scsi=off,devno=fe.0.0000,drive=libvirt-1-format,\ id=virtio-disk0,bootindex=1 \ -fsdev local,security_model=passthrough,id=fsdev-fs0,path=/export/to/guest \ -device virtio-9p-ccw,id=fs0,fsdev=fsdev-fs0,mount_tag=/import/from/host,\ diff --git a/tests/qemuxml2argvdata/iothreads-virtio-scsi-ccw.s390x-latest.args b/tests/qemuxml2argvdata/iothreads-virtio-scsi-ccw.s390x-latest.args index bdc060aa..20288f2a 100644 --- a/tests/qemuxml2argvdata/iothreads-virtio-scsi-ccw.s390x-latest.args +++ b/tests/qemuxml2argvdata/iothreads-virtio-scsi-ccw.s390x-latest.args @@ -29,12 +29,18 @@ file=/tmp/lib/domain--1-QEMUGuest1/master-key.aes \ -no-shutdown \ -boot strict=on \ -device virtio-scsi-ccw,iothread=iothread2,id=scsi0,devno=fe.0.0001 \ --drive file=/dev/HostVG/QEMUGuest1,format=raw,if=none,id=drive-virtio-disk0 \ +-blockdev '{"driver":"host_device","filename":"/dev/HostVG/QEMUGuest1",\ +"node-name":"libvirt-2-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-2-format","read-only":false,"driver":"raw",\ +"file":"libvirt-2-storage"}' \ -device virtio-blk-ccw,iothread=iothread1,scsi=off,devno=fe.0.0000,\ -drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 \ --drive file=/dev/HostVG/QEMUGuest2,format=raw,if=none,id=drive-scsi0-0-2-0 \ +drive=libvirt-2-format,id=virtio-disk0,bootindex=1 \ +-blockdev '{"driver":"host_device","filename":"/dev/HostVG/QEMUGuest2",\ +"node-name":"libvirt-1-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-1-format","read-only":false,"driver":"raw",\ +"file":"libvirt-1-storage"}' \ -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=2,lun=0,\ -device_id=drive-scsi0-0-2-0,drive=drive-scsi0-0-2-0,id=scsi0-0-2-0 \ +device_id=drive-scsi0-0-2-0,drive=libvirt-1-format,id=scsi0-0-2-0 \ -device virtio-balloon-ccw,id=balloon0,devno=fe.0.000a \ -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,\ resourcecontrol=deny \ diff --git a/tests/qemuxml2argvdata/s390-default-cpu-kvm-ccw-virtio-4.2.s390x-latest.args b/tests/qemuxml2argvdata/s390-default-cpu-kvm-ccw-virtio-4.2.s390x-latest.args index 03860194..35093d4f 100644 --- a/tests/qemuxml2argvdata/s390-default-cpu-kvm-ccw-virtio-4.2.s390x-latest.args +++ b/tests/qemuxml2argvdata/s390-default-cpu-kvm-ccw-virtio-4.2.s390x-latest.args @@ -13,9 +13,11 @@ QEMU_AUDIO_DRV=none \ -object secret,id=masterKey0,format=raw,\ file=/tmp/lib/domain--1-test/master-key.aes \ -machine s390-ccw-virtio-4.2,accel=kvm,usb=off,dump-guest-core=off \ --cpu z13.2-base,aen=on,aefsi=on,msa5=on,msa4=on,msa3=on,msa2=on,msa1=on,\ -sthyi=on,edat=on,ri=on,edat2=on,vx=on,ipter=on,ap=on,esop=on,apft=on,apqci=on,\ -cte=on,bpb=on,ppa15=on,zpci=on,sea_esop2=on,te=on,cmm=on \ +-cpu gen15a-base,aen=on,cmmnt=on,vxpdeh=on,aefsi=on,csske=on,mepoch=on,msa9=on,\ +msa8=on,msa7=on,msa6=on,msa5=on,msa4=on,msa3=on,msa2=on,msa1=on,sthyi=on,\ +edat=on,ri=on,deflate=on,edat2=on,etoken=on,vx=on,ipter=on,mepochptff=on,ap=on,\ +vxeh=on,vxpd=on,esop=on,msa9_pckmo=on,vxeh2=on,esort=on,apqi=on,apft=on,iep=on,\ +apqci=on,cte=on,bpb=on,gs=on,ppa15=on,zpci=on,sea_esop2=on,te=on,cmm=on \ -m 256 \ -overcommit mem-lock=off \ -smp 1,sockets=1,cores=1,threads=1 \ diff --git a/tests/qemuxml2argvdata/s390x-ccw-graphics.s390x-latest.args b/tests/qemuxml2argvdata/s390x-ccw-graphics.s390x-latest.args index 8f72b20b..5850b265 100644 --- a/tests/qemuxml2argvdata/s390x-ccw-graphics.s390x-latest.args +++ b/tests/qemuxml2argvdata/s390x-ccw-graphics.s390x-latest.args @@ -26,9 +26,11 @@ file=/tmp/lib/domain--1-guest/master-key.aes \ -no-shutdown \ -boot strict=on \ -device virtio-serial-ccw,id=virtio-serial0,devno=fe.0.0003 \ --drive file=/var/lib/libvirt/images/guest.qcow2,format=qcow2,if=none,\ -id=drive-virtio-disk0 \ --device virtio-blk-ccw,scsi=off,devno=fe.0.0000,drive=drive-virtio-disk0,\ +-blockdev '{"driver":"file","filename":"/var/lib/libvirt/images/guest.qcow2",\ +"node-name":"libvirt-1-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-1-format","read-only":false,"driver":"qcow2",\ +"file":"libvirt-1-storage"}' \ +-device virtio-blk-ccw,scsi=off,devno=fe.0.0000,drive=libvirt-1-format,\ id=virtio-disk0,bootindex=1 \ -netdev user,id=hostnet0 \ -device virtio-net-ccw,netdev=hostnet0,id=net0,mac=52:54:00:09:1a:29,\ diff --git a/tests/qemuxml2argvdata/s390x-ccw-headless.s390x-latest.args b/tests/qemuxml2argvdata/s390x-ccw-headless.s390x-latest.args index 95caf9e9..211cc24b 100644 --- a/tests/qemuxml2argvdata/s390x-ccw-headless.s390x-latest.args +++ b/tests/qemuxml2argvdata/s390x-ccw-headless.s390x-latest.args @@ -27,9 +27,11 @@ file=/tmp/lib/domain--1-guest/master-key.aes \ -no-shutdown \ -boot strict=on \ -device virtio-serial-ccw,id=virtio-serial0,devno=fe.0.0002 \ --drive file=/var/lib/libvirt/images/guest.qcow2,format=qcow2,if=none,\ -id=drive-virtio-disk0 \ --device virtio-blk-ccw,scsi=off,devno=fe.0.0000,drive=drive-virtio-disk0,\ +-blockdev '{"driver":"file","filename":"/var/lib/libvirt/images/guest.qcow2",\ +"node-name":"libvirt-1-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-1-format","read-only":false,"driver":"qcow2",\ +"file":"libvirt-1-storage"}' \ +-device virtio-blk-ccw,scsi=off,devno=fe.0.0000,drive=libvirt-1-format,\ id=virtio-disk0,bootindex=1 \ -netdev user,id=hostnet0 \ -device virtio-net-ccw,netdev=hostnet0,id=net0,mac=52:54:00:09:a4:37,\ diff --git a/tests/qemuxml2argvdata/vhost-vsock-ccw-auto.s390x-latest.args b/tests/qemuxml2argvdata/vhost-vsock-ccw-auto.s390x-latest.args index 17b5ded6..4c5542d8 100644 --- a/tests/qemuxml2argvdata/vhost-vsock-ccw-auto.s390x-latest.args +++ b/tests/qemuxml2argvdata/vhost-vsock-ccw-auto.s390x-latest.args @@ -26,8 +26,11 @@ file=/tmp/lib/domain--1-QEMUGuest1/master-key.aes \ -rtc base=utc \ -no-shutdown \ -boot strict=on \ --drive file=/dev/HostVG/QEMUGuest1,format=raw,if=none,id=drive-virtio-disk0 \ --device virtio-blk-ccw,scsi=off,devno=fe.0.0000,drive=drive-virtio-disk0,\ +-blockdev '{"driver":"host_device","filename":"/dev/HostVG/QEMUGuest1",\ +"node-name":"libvirt-1-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-1-format","read-only":false,"driver":"raw",\ +"file":"libvirt-1-storage"}' \ +-device virtio-blk-ccw,scsi=off,devno=fe.0.0000,drive=libvirt-1-format,\ id=virtio-disk0,bootindex=1 \ -device virtio-balloon-ccw,id=balloon0,devno=fe.0.0001 \ -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,\ diff --git a/tests/qemuxml2argvdata/vhost-vsock-ccw.s390x-latest.args b/tests/qemuxml2argvdata/vhost-vsock-ccw.s390x-latest.args index 81a6b8cb..de229bd0 100644 --- a/tests/qemuxml2argvdata/vhost-vsock-ccw.s390x-latest.args +++ b/tests/qemuxml2argvdata/vhost-vsock-ccw.s390x-latest.args @@ -26,8 +26,11 @@ file=/tmp/lib/domain--1-QEMUGuest1/master-key.aes \ -rtc base=utc \ -no-shutdown \ -boot strict=on \ --drive file=/dev/HostVG/QEMUGuest1,format=raw,if=none,id=drive-virtio-disk0 \ --device virtio-blk-ccw,scsi=off,devno=fe.0.0000,drive=drive-virtio-disk0,\ +-blockdev '{"driver":"host_device","filename":"/dev/HostVG/QEMUGuest1",\ +"node-name":"libvirt-1-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-1-format","read-only":false,"driver":"raw",\ +"file":"libvirt-1-storage"}' \ +-device virtio-blk-ccw,scsi=off,devno=fe.0.0000,drive=libvirt-1-format,\ id=virtio-disk0,bootindex=1 \ -device virtio-balloon-ccw,id=balloon0,devno=fe.0.0001 \ -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,\ -- 2.24.1

3 2

[PATCH v2 0/4] APIC-EOI, pvspinlock, hyperv and PMU changes
by Daniel Henrique Barboza 25 Mar '20

25 Mar '20

Changes in v2: - changed patch series name to reflect the new approach - Make APIC-EIO exclusive to x86 - Make pvspinlock exclusive to x86 - Make hyperv exclusive to x86 and aarch64 - allow PMU to be declared as 'on' for ppc64 - previous version: https://www.redhat.com/archives/libvir-list/2020-March/msg00718.html Daniel Henrique Barboza (4): qemu: avoid launching non-x86 guests with APIC-EOI setting qemu: avoid launching non-x86 guests with 'pvspinlock' setting qemu: make Hyperv settings exclusive to x86 and aarch64 qemu: allow PMU feature to be enabled for ppc64 guests src/qemu/qemu_command.c | 4 ++- src/qemu/qemu_domain.c | 55 ++++++++++++++++++++++++++++++++++++++--- 2 files changed, 54 insertions(+), 5 deletions(-) -- 2.25.1

2 8

[PATCH 00/12] qemu: More fixes for qemuDomainGetGuestInfo
by Peter Krempa 25 Mar '20

25 Mar '20

This fixes other issues pointed out in the review of my previous fix for crash in qemuDomainGetGuestInfo. Peter Krempa (12): qemuDomainGetGuestInfo: don't assign NULL hostname qemuDomainGetGuestInfo: Validate supported information types qemuAgentCheckError: use g_autofree qemuAgentCommand: Wire up suppressing of error reporting for unsupported commands qemuAgentGetUsers: Fix return value on success qemuAgentGetHostname: Refactor to remove cleanup section qemuAgentGetHostname: expose 'report_unsupported' argument qemuAgentGetUsers: expose 'report_unsupported' argument qemuAgentGetOSInfo: expose 'report_unsupported' argument qemuAgentGetTimezone: expose 'report_unsupported' argument qemuAgentGetFSInfo: expose 'report_unsupported' argument qemuDomainGetGuestInfo: Suppress non-fatal errors src/qemu/qemu_agent.c | 194 ++++++++++++++++++++--------------------- src/qemu/qemu_agent.h | 16 ++-- src/qemu/qemu_driver.c | 89 ++++++++++--------- tests/qemuagenttest.c | 14 +-- 4 files changed, 162 insertions(+), 151 deletions(-) -- 2.24.1

2 24

[PATCH 0/7] Move video default logic to individual drivers
by Rafael Fonseca 25 Mar '20

25 Mar '20

The logic setting a device default should be in the post parse function of individual driver code, not in `src/conf/domain_conf.c`. Rafael Fonseca (7): bhyve: move video default logic to driver libxl: move video default logic to driver vz: openvz: move video default logic to driver vmx: vmware: move video default logic to driver test: move video default logic to driver vbox: move video default logic to driver conf: domain_conf: remove virDomainVideoDefaultType src/bhyve/bhyve_domain.c | 5 ++++ src/conf/domain_conf.c | 52 +++------------------------------ src/conf/domain_conf.h | 1 - src/libvirt_private.syms | 1 - src/libxl/libxl_domain.c | 60 +++++++++++++++++++++++--------------- src/openvz/openvz_conf.c | 8 +++++ src/test/test_driver.c | 23 +++++++++++++++ src/vbox/vbox_common.c | 16 ++++++++++ src/vmware/vmware_driver.c | 4 +++ src/vmx/vmx.c | 4 +++ src/vz/vz_driver.c | 8 +++++ 11 files changed, 108 insertions(+), 74 deletions(-) -- 2.25.1

2 8

[libvirt PATCH] util: keep the pidfile locked
by marcandre.lureau＠redhat.com 25 Mar '20

25 Mar '20

From: Marc-André Lureau <marcandre.lureau(a)redhat.com> Unfortunately, advisory record locking lose the lock if any fd refering to the file is closed. There doesn't seem to be a way to preserve the lock atomically. We could eventually retake the lock if low pidfilefd is required. This fixes processes being leaked, as they are not killed in virPidFileForceCleanupPath() if the lock can be taken. Here also, we may consider this is not good enough, as a process may leak by simply closing the pidfilefd. Fixes commit d146105f1e4a9e0ab179f0b78c070ea38b9d5334 ("virCommand: Actually acquire pidfile instead of just writing it") Signed-off-by: Marc-André Lureau <marcandre.lureau(a)redhat.com> --- src/util/vircommand.c | 12 ++---------- tests/commanddata/test4.log | 2 +- 2 files changed, 3 insertions(+), 11 deletions(-) diff --git a/src/util/vircommand.c b/src/util/vircommand.c index 77078d09fb..b84fb40948 100644 --- a/src/util/vircommand.c +++ b/src/util/vircommand.c @@ -797,8 +797,7 @@ virExec(virCommandPtr cmd) virProcessSetMaxCoreSize(0, cmd->maxCore) < 0) goto fork_error; if (cmd->pidfile) { - VIR_AUTOCLOSE pidfilefd = -1; - int newpidfilefd = -1; + int pidfilefd = -1; char c; pidfilefd = virPidFileAcquirePath(cmd->pidfile, false, getpid()); @@ -818,14 +817,7 @@ virExec(virCommandPtr cmd) VIR_FORCE_CLOSE(pipesync[0]); VIR_FORCE_CLOSE(pipesync[1]); - /* This is here only to move the pidfilefd - * to the lowest possible number. */ - if ((newpidfilefd = dup(pidfilefd)) < 0) { - virReportSystemError(errno, "%s", _("Unable to dup FD")); - goto fork_error; - } - - /* newpidfilefd is intentionally leaked. */ + /* pidfilefd is intentionally leaked. */ } if (cmd->hook) { diff --git a/tests/commanddata/test4.log b/tests/commanddata/test4.log index 5820f28307..24a37a7e96 100644 --- a/tests/commanddata/test4.log +++ b/tests/commanddata/test4.log @@ -9,7 +9,7 @@ ENV:USER=test FD:0 FD:1 FD:2 -FD:3 +FD:5 DAEMON:yes CWD:/ UMASK:0022 -- 2.26.0.rc2.42.g98cedd0233

2 1

[libvirt] [PATCH v4 0/2] introduction of migration_version attribute for VFIO live migration
by Yan Zhao 25 Mar '20

25 Mar '20

This patchset introduces a migration_version attribute under sysfs of VFIO Mediated devices. This migration_version attribute is used to check migration compatibility between two mdev devices of the same mdev type. Patch 1 defines migration_version attribute in Documentation/vfio-mediated-device.txt Patch 2 uses GVT as an example to show how to expose migration_version attribute and check migration compatibility in vendor driver. v4: 1. fixed indentation/spell errors, reworded several error messages 2. added a missing memory free for error handling in patch 2 v3: 1. renamed version to migration_version 2. let errno to be freely defined by vendor driver 3. let checking mdev_type be prerequisite of migration compatibility check 4. reworded most part of patch 1 5. print detailed error log in patch 2 and generate migration_version string at init time v2: 1. renamed patched 1 2. made definition of device version string completely private to vendor driver 3. reverted changes to sample mdev drivers 4. described intent and usage of version attribute more clearly. Yan Zhao (2): vfio/mdev: add migration_version attribute for mdev device drm/i915/gvt: export migration_version to mdev sysfs for Intel vGPU Documentation/vfio-mediated-device.txt | 113 +++++++++++++ drivers/gpu/drm/i915/gvt/Makefile | 2 +- drivers/gpu/drm/i915/gvt/gvt.c | 39 +++++ drivers/gpu/drm/i915/gvt/gvt.h | 5 + drivers/gpu/drm/i915/gvt/migration_version.c | 168 +++++++++++++++++++ drivers/gpu/drm/i915/gvt/vgpu.c | 13 +- 6 files changed, 337 insertions(+), 3 deletions(-) create mode 100644 drivers/gpu/drm/i915/gvt/migration_version.c -- 2.17.1

3 9

[libvirt PATCH] docs: news: fix typo
by Ján Tomko 24 Mar '20

24 Mar '20

s/ommited/omitted/ Signed-off-by: Ján Tomko <jtomko(a)redhat.com> --- Pushed as trivial docs/news.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/news.xml b/docs/news.xml index 504cf52738..bcec1d81e9 100644 --- a/docs/news.xml +++ b/docs/news.xml @@ -51,7 +51,7 @@ <description> QEMU 5.0 implements NVDIMM memory support for pSeries guests. This is done by adding an 'uuid' element in the memory XML, which can - either be provided in the XML or, if ommited, generated + either be provided in the XML or, if omitted, generated automatically. </description> </change> -- 2.25.1

1 0

[PATCH] qemu: softfail for TCG capabilities probe
by Tobin Feldman-Fitzthum 24 Mar '20

24 Mar '20

As of version 2.10, QEMU can be built without the TCG. When libvirt determines that capabilities of a QEMU binary using QMP, it launches a QEMU process with KVM acceleration and TCG as a fallback. If QEMU supports KVM, a second probe is performed, forcing QEMU to use only TCG. This causes an error if the QEMU binary was built without TCG. This patch allows execution to continue when the second probe fails. Thus libvirt can be used with QEMU built without TCG. First patch. Feedback appreciated. If better solution, please advise. Signed-off-by: Tobin Feldman-Fitzthum <tobin(a)linux.vnet.ibm.com> --- src/qemu/qemu_capabilities.c | 12 +++++------- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c index a95a60c36a..f303171cc4 100644 --- a/src/qemu/qemu_capabilities.c +++ b/src/qemu/qemu_capabilities.c @@ -5100,9 +5100,6 @@ virQEMUCapsInitQMPSingle(virQEMUCapsPtr qemuCaps, ret = virQEMUCapsInitQMPMonitor(qemuCaps, proc->mon); cleanup: - if (ret < 0) - virQEMUCapsLogProbeFailure(qemuCaps->binary); - qemuProcessQMPFree(proc); return ret; } @@ -5114,17 +5111,18 @@ virQEMUCapsInitQMP(virQEMUCapsPtr qemuCaps, uid_t runUid, gid_t runGid) { - if (virQEMUCapsInitQMPSingle(qemuCaps, libDir, runUid, runGid, false) < 0) + if (virQEMUCapsInitQMPSingle(qemuCaps, libDir, runUid, runGid, false) < 0) { + virQEMUCapsLogProbeFailure(qemuCaps->binary); return -1; + } /* * If KVM was enabled during the first probe, we need to explicitly probe * for TCG capabilities by asking the same binary again and turning KVM * off. */ - if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_KVM) && - virQEMUCapsInitQMPSingle(qemuCaps, libDir, runUid, runGid, true) < 0) - return -1; + if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_KVM)) + virQEMUCapsInitQMPSingle(qemuCaps, libDir, runUid, runGid, true); return 0; } -- 2.20.1 (Apple Git-117)

2 1

[libvirt PATCH 0/5] gitlab: expand the CI job coverage (RESEND)
by Daniel P. Berrangé 24 Mar '20

24 Mar '20

There are two main goals with this series - Introduce a minimal job building the website and publishing an artifact which can be deployed onto libvirt.org - Expanding CI jobs to get coverage closer to Travis/Jenkins Previous posting lost last two mails due to transient SMTP problem Daniel P. Berrangé (5): gitlab: use CI for building website contents gitlab: reduce number of cross-build CI jobs gitlab: group jobs into stages gitlab: add several native CI jobs gitlab: rename the cross build jobs .gitlab-ci.yml | 105 +++++++++++++++++++++++++++++++++++-------------- 1 file changed, 75 insertions(+), 30 deletions(-) -- 2.24.1

3 29

[PATCH v1 0/4] Prevent ppc64 guest launch with broken features
by Daniel Henrique Barboza 24 Mar '20

24 Mar '20

Hi, This work was intended to fix a bug with APIC-EOI setting only (patch 1). I decided to take a closer look and ended up handling more cases. I consider the first 3 patches to be straightforward: those are conditions that QEMU will complain about and I'm simply refusing to launch while giving a better error message than the one QEMU provides. Patch 4 is more debatable. <hyperv><hyperv/> declaration in the XML is benign, but any of the 14 features being declared will cause QEMU errors. Instead of putting more code (i.e. a switch with 14 features in the middle of the code) to prevent any of those features to be enabled, I made a call to simply refuse to launch with any <hyperv> setting in the XML. This is not because I have a beef with Windows or MS or anything. This is about making an educated guess that it's highly unlikable that anyone is running ppc64 guests with <hyperv> declared in the XML, and it's not worth all the code to support it. But I'm all ears to hear otherwise. After this series, these are the features that aren't supported by ppc64 but can be declared in a ppc64 guest without resulting in a failed launch: <features> <acpi/> <apic/> (without 'eoi' setting) <pae/> <hap state='on|off'/> <viridian/> </features> Daniel Henrique Barboza (4): qemu_domain.c: do not launch ppc64 guests with APIC-EOI setting qemu_domain.c: do not launch ppc64 guests with 'pvspinlock' setting qemu_domain.c: do not launch ppc64 guests with 'pmu' setting qemu_domain.c: do not launch ppc64 guests with Hyperv settings src/qemu/qemu_domain.c | 49 ++++++++++++++++++++++++++++++++++++++---- 1 file changed, 45 insertions(+), 4 deletions(-) -- 2.25.1

3 18

[PATCH] qemu_monitor_text.c: Use g_autofree
by Seeteena Thoufeek 24 Mar '20

24 Mar '20

Signed-off-by: Seeteena Thoufeek <s1seetee(a)linux.vnet.ibm.com> --- src/qemu/qemu_monitor_text.c | 85 ++++++++++++++++---------------------------- 1 file changed, 30 insertions(+), 55 deletions(-) diff --git a/src/qemu/qemu_monitor_text.c b/src/qemu/qemu_monitor_text.c index 9135a11..5a890af 100644 --- a/src/qemu/qemu_monitor_text.c +++ b/src/qemu/qemu_monitor_text.c @@ -36,27 +36,26 @@ VIR_LOG_INIT("qemu.qemu_monitor_text"); int qemuMonitorTextAddDrive(qemuMonitorPtr mon, const char *drivestr) { - char *cmd = NULL; - char *reply = NULL; - int ret = -1; + g_autofree char *cmd = NULL; + g_autofree char *reply = NULL; /* 'dummy' here is just a placeholder since there is no PCI * address required when attaching drives to a controller */ cmd = g_strdup_printf("drive_add dummy %s", drivestr); if (qemuMonitorJSONHumanCommand(mon, cmd, &reply) < 0) - goto cleanup; + return -1; if (strstr(reply, "unknown command:")) { virReportError(VIR_ERR_OPERATION_FAILED, "%s", _("drive hotplug is not supported")); - goto cleanup; + return -1; } if (strstr(reply, "could not open disk image")) { virReportError(VIR_ERR_OPERATION_FAILED, "%s", _("open disk image file failed")); - goto cleanup; + return -1; } if (strstr(reply, "Could not open")) { @@ -66,48 +65,41 @@ int qemuMonitorTextAddDrive(qemuMonitorPtr mon, virReportError(VIR_ERR_OPERATION_FAILED, "%s", reply); - goto cleanup; + return -1; } if (strstr(reply, "Image is not in")) { virReportError(VIR_ERR_OPERATION_FAILED, "%s", _("Incorrect disk format")); - goto cleanup; + return -1; } if (strstr(reply, "IOMMU") || strstr(reply, "VFIO")) { virReportError(VIR_ERR_OPERATION_FAILED, "%s", reply); - goto cleanup; + return -1; } - ret = 0; - - cleanup: - VIR_FREE(cmd); - VIR_FREE(reply); - return ret; + return 0; } int qemuMonitorTextDriveDel(qemuMonitorPtr mon, const char *drivestr) { - char *cmd = NULL; - char *reply = NULL; - int ret = -1; + g_autofree char *cmd = NULL; + g_autofree char *reply = NULL; cmd = g_strdup_printf("drive_del %s", drivestr); if (qemuMonitorJSONHumanCommand(mon, cmd, &reply) < 0) - goto cleanup; + return -1; if (strstr(reply, "unknown command:")) { VIR_ERROR(_("deleting drive is not supported. " "This may leak data if disk is reassigned")); - ret = 1; - goto cleanup; + return 1; /* (qemu) drive_del wark * Device 'wark' not found */ @@ -117,15 +109,10 @@ int qemuMonitorTextDriveDel(qemuMonitorPtr mon, } else if (STRNEQ(reply, "")) { virReportError(VIR_ERR_OPERATION_FAILED, _("deleting %s drive failed: %s"), drivestr, reply); - goto cleanup; + return -1; } - ret = 0; - - cleanup: - VIR_FREE(cmd); - VIR_FREE(reply); - return ret; + return 0; } int @@ -159,28 +146,27 @@ qemuMonitorTextCreateSnapshot(qemuMonitorPtr mon, int qemuMonitorTextLoadSnapshot(qemuMonitorPtr mon, const char *name) { - char *cmd = NULL; - char *reply = NULL; - int ret = -1; + g_autofree char *cmd = NULL; + g_autofree char *reply = NULL; cmd = g_strdup_printf("loadvm \"%s\"", name); if (qemuMonitorJSONHumanCommand(mon, cmd, &reply)) - goto cleanup; + return -1; if (strstr(reply, "No block device supports snapshots")) { virReportError(VIR_ERR_OPERATION_INVALID, "%s", _("this domain does not have a device to load snapshots")); - goto cleanup; + return -1; } else if (strstr(reply, "Could not find snapshot")) { virReportError(VIR_ERR_OPERATION_INVALID, _("the snapshot '%s' does not exist, and was not loaded"), name); - goto cleanup; + return -1; } else if (strstr(reply, "Snapshots not supported on device")) { virReportError(VIR_ERR_OPERATION_INVALID, _("Failed to load snapshot: %s"), reply); - goto cleanup; + return -1; } else if (strstr(reply, "Could not open VM state file") || strstr(reply, "Error: ") || (strstr(reply, "Error") && @@ -188,46 +174,35 @@ int qemuMonitorTextLoadSnapshot(qemuMonitorPtr mon, const char *name) strstr(reply, "while activating snapshot on")))) { virReportError(VIR_ERR_OPERATION_FAILED, _("Failed to load snapshot: %s"), reply); - goto cleanup; + return -1; } - ret = 0; - - cleanup: - VIR_FREE(cmd); - VIR_FREE(reply); - return ret; + return 0; } int qemuMonitorTextDeleteSnapshot(qemuMonitorPtr mon, const char *name) { - char *cmd = NULL; - char *reply = NULL; - int ret = -1; + g_autofree char *cmd = NULL; + g_autofree char *reply = NULL; cmd = g_strdup_printf("delvm \"%s\"", name); if (qemuMonitorJSONHumanCommand(mon, cmd, &reply)) - goto cleanup; + return -1; if (strstr(reply, "No block device supports snapshots")) { virReportError(VIR_ERR_OPERATION_INVALID, "%s", _("this domain does not have a device to delete snapshots")); - goto cleanup; + return -1; } else if (strstr(reply, "Snapshots not supported on device")) { virReportError(VIR_ERR_OPERATION_INVALID, "%s", reply); - goto cleanup; + return -1; } else if (strstr(reply, "Error: ") || (strstr(reply, "Error") && strstr(reply, "while deleting snapshot"))) { virReportError(VIR_ERR_OPERATION_FAILED, _("Failed to delete snapshot: %s"), reply); - goto cleanup; + return -1; } - ret = 0; - - cleanup: - VIR_FREE(cmd); - VIR_FREE(reply); - return ret; + return 0; } -- 1.8.3.1

3 2

[PATCH] commandtest: Fix test28 error detection
by Michal Privoznik 24 Mar '20

24 Mar '20

As a part of c799d150d5e9dae I've introduced a test case that tests whether passing error object between processes works. The test spawns a child which reports a system error, parent process then reads the error and compares with expected output. Problem with this approach is that error message contains stringified errno which is not portable. FreeBSD has generally different messages than Linux. Therefore, use g_strerror() to do the errno to string translation for us. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- tests/commandtest.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/tests/commandtest.c b/tests/commandtest.c index f4a2c67c05..d5092b7dd0 100644 --- a/tests/commandtest.c +++ b/tests/commandtest.c @@ -1272,6 +1272,7 @@ test28(const void *unused G_GNUC_UNUSED) /* Not strictly a virCommand test, but this is the easiest place * to test this lower-level interface. */ virErrorPtr err; + g_autofree char *msg = g_strdup_printf("some error message: %s", g_strerror(ENODATA)); if (virProcessRunInFork(test28Callback, NULL) != -1) { fprintf(stderr, "virProcessRunInFork did not fail\n"); @@ -1285,10 +1286,10 @@ test28(const void *unused G_GNUC_UNUSED) if (!(err->code == VIR_ERR_SYSTEM_ERROR && err->domain == 0 && - STREQ(err->message, "some error message: No data available") && + STREQ(err->message, msg) && err->level == VIR_ERR_ERROR && STREQ(err->str1, "%s") && - STREQ(err->str2, "some error message: No data available") && + STREQ(err->str2, msg) && err->int1 == ENODATA && err->int2 == -1)) { fprintf(stderr, "Unexpected error object\n"); -- 2.24.1

2 1

[PATCH 0/6] Couple of qemu NS improvements
by Michal Privoznik 24 Mar '20

24 Mar '20

The most important patch is 6/6 which relies on 5/6. The rest is just a few small nits I've noticed and had stuck on my local branch. Michal Prívozník (6): qemuDomainCreateDeviceRecursive: Report error if mkdir() fails qemuDomainBuildNamespace: Try harder to remove temp directories qemuDomainBuildNamespace: Make @devPath const virfile: Handle directories in virFileBindMountDevice() virprocess: Passthru error from virProcessRunInForkHelper security: Try harder to run transactions build-aux/syntax-check.mk | 2 +- src/qemu/qemu_domain.c | 13 +++++++-- src/security/security_dac.c | 16 ++++++++--- src/security/security_selinux.c | 16 ++++++++--- src/util/virfile.c | 13 +++++++-- src/util/virprocess.c | 51 ++++++++++++++++++++++++++++++--- tests/commandtest.c | 43 +++++++++++++++++++++++++++ 7 files changed, 136 insertions(+), 18 deletions(-) -- 2.24.1

6 16

[PATCH 00/14] qemu: Fix 'backing store' string generator for -blockdev
by Peter Krempa 24 Mar '20

24 Mar '20

QEMU doesn't like the backing store string generated by libvirt with -blockdev. Luckily we are able to parse them back and with blockdev they would no longer be used by qemu directly. Fix the generator an da few issues noticed along. Peter Krempa (14): conf: rename 'namespace' property of struct _virStorageSourceNVMeDef qemublocktest: xml->json: Add test for NVMe virDomainDiskSourceNVMeFormat: Format only valid 'managed' values qemublocktest: xml->json: Refactor cleanup in test case functions testQemuDiskXMLToPropsValidateFileSrcOnly: Move together with rest of xml->json code qemuBlockGetBackingStoreString: Add 'pretty' argument testQemuDiskXMLToProps: Store all per-image data in one structure qemublocktest: Test backing store strings qemuBlockGetBackingStoreString: Remove 'ret' variable storage: Implement backing store support for "fat:" prefix qemuBlockGetBackingStoreString: Add extra wrapping object to JSON strings qemu: block: Extract formatting of cookie string qemuBlockGetBackingStoreString: Properly handle 'http/s' with cookies and others storage: Parse 'nvme' disk source properties from json:{} pseudo-uri src/conf/domain_conf.c | 17 +- src/hypervisor/virhostdev.c | 2 +- src/qemu/qemu_block.c | 64 +++-- src/qemu/qemu_block.h | 6 +- src/qemu/qemu_domain.c | 13 +- src/qemu/qemu_driver.c | 4 +- src/util/virstoragefile.c | 43 +++- src/util/virstoragefile.h | 2 +- tests/qemublocktest.c | 232 ++++++++++-------- .../qcow2-backing-qcow2-slice.json | 2 +- .../imagecreate/qcow2-backing-raw-slice.json | 2 +- .../xml2json/block-raw-noopts-srconly.json | 13 +- .../block-raw-reservations-srconly.json | 13 +- .../xml2json/dir-fat-cache-srconly.json | 15 +- .../xml2json/dir-fat-floppy-srconly.json | 15 +- .../xml2json/dir-fat-readonly-srconly.json | 15 +- ...ile-backing_basic-aio_threads-srconly.json | 68 +++-- ...acking_basic-cache-directsync-srconly.json | 68 +++-- ...file-backing_basic-cache-none-srconly.json | 68 +++-- ...le-backing_basic-cache-unsafe-srconly.json | 68 +++-- ...backing_basic-cache-writeback-srconly.json | 68 +++-- ...king_basic-cache-writethrough-srconly.json | 68 +++-- .../file-backing_basic-detect-srconly.json | 68 +++-- .../file-backing_basic-noopts-srconly.json | 52 ++-- ...le-backing_basic-unmap-detect-srconly.json | 68 +++-- ...le-backing_basic-unmap-ignore-srconly.json | 68 +++-- .../file-backing_basic-unmap-srconly.json | 68 +++-- .../xml2json/file-bochs-noopts-srconly.json | 13 +- .../xml2json/file-cloop-noopts-srconly.json | 13 +- .../xml2json/file-dmg-noopts-srconly.json | 13 +- .../xml2json/file-ploop-noopts-srconly.json | 13 +- ...cow2-backing-chain-encryption-srconly.json | 26 +- ...le-qcow2-backing-chain-noopts-srconly.json | 130 +++++++--- ...w2-backing-chain-unterminated-srconly.json | 26 +- .../xml2json/file-raw-aio_native-srconly.json | 13 +- .../xml2json/file-raw-luks-srconly.json | 13 +- .../xml2json/file-raw-noopts-srconly.json | 13 +- .../xml2json/file-vdi-noopts-srconly.json | 13 +- .../xml2json/file-vhd-noopts-srconly.json | 13 +- .../xml2json/file-vpc-noopts-srconly.json | 13 +- .../network-http-curlopts-srconly.json | 17 ++ .../xml2json/network-http-curlopts.json | 15 ++ .../xml2json/network-http-curlopts.xml | 20 ++ .../xml2json/network-http-noopts-srconly.json | 9 + .../xml2json/network-http-noopts.json | 14 ++ .../xml2json/network-http-noopts.xml | 15 ++ .../xml2json/network-nbd-tls-srconly.json | 19 +- ...w2-backing-chain-cache-unsafe-srconly.json | 69 ++++-- ...backing-chain-encryption_auth-srconly.json | 69 ++++-- .../xml2json/nvme-raw-noopts-srconly.json | 15 ++ .../xml2json/nvme-raw-noopts.json | 14 ++ .../xml2json/nvme-raw-noopts.xml | 13 + tests/virstoragetest.c | 10 + 53 files changed, 1226 insertions(+), 575 deletions(-) create mode 100644 tests/qemublocktestdata/xml2json/network-http-curlopts-srconly.json create mode 100644 tests/qemublocktestdata/xml2json/network-http-curlopts.json create mode 100644 tests/qemublocktestdata/xml2json/network-http-curlopts.xml create mode 100644 tests/qemublocktestdata/xml2json/network-http-noopts-srconly.json create mode 100644 tests/qemublocktestdata/xml2json/network-http-noopts.json create mode 100644 tests/qemublocktestdata/xml2json/network-http-noopts.xml create mode 100644 tests/qemublocktestdata/xml2json/nvme-raw-noopts-srconly.json create mode 100644 tests/qemublocktestdata/xml2json/nvme-raw-noopts.json create mode 100644 tests/qemublocktestdata/xml2json/nvme-raw-noopts.xml -- 2.24.1

2 17

[PATCH RESEND 0/5] virCommand: fix approach to pidfiles
by Michal Privoznik 24 Mar '20

24 Mar '20

The original series doesn't apply cleanly anymore: https://www.redhat.com/archives/libvir-list/2020-March/msg00499.html Here's the rebased one. Michal Prívozník (5): virCommand: Actually acquire pidfile instead of just writing it qemuProcessStartManagedPRDaemon: Don't pass -f pidfile to the daemon qemuSlirpStop: Simplify helper kill qemuVirtioFSStop: Simplify daemon kill bridge_driver: Replace and drop networkKillDaemon docs/internals/command.html.in | 4 +- src/network/bridge_driver.c | 106 ++++++--------------------------- src/qemu/qemu_process.c | 9 --- src/qemu/qemu_slirp.c | 16 ++--- src/qemu/qemu_virtiofs.c | 21 +++---- src/util/vircommand.c | 56 ++++++++++++++--- tests/commanddata/test4.log | 1 + 7 files changed, 81 insertions(+), 132 deletions(-) -- 2.24.1

3 12