[PATCH 1/3] libxl: Use the name 'Xen' in driver tables

[Jim Fehlig]

The libxl driver declares its name as 'Xen' through the public
virConnectGetType() API. In the virHypervisorDriver table the name is
set to 'xenlight'. To add more confusion, the name is set to 'LIBXL'
in the virStateDriver. For consistency, use the same name in the driver
tables as reported in the public virConnectGetType() API.

Signed-off-by: Jim Fehlig 
---
 src/libxl/libxl_conf.h   | 1 +
 src/libxl/libxl_driver.c | 6 +++---
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/src/libxl/libxl_conf.h b/src/libxl/libxl_conf.h
index 07b3373170..11a922b10a 100644
--- a/src/libxl/libxl_conf.h
+++ b/src/libxl/libxl_conf.h
@@ -38,6 +38,7 @@
 #include "libxl_capabilities.h"
 #include "libxl_logger.h"
 
+#define LIBXL_DRIVER_EXTERNAL_NAME "Xen"
 #define LIBXL_DRIVER_NAME "xenlight"
 #define LIBXL_VNC_PORT_MIN  5900
 #define LIBXL_VNC_PORT_MAX  65535
diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c
index 980984b199..ebeb91af3c 100644
--- a/src/libxl/libxl_driver.c
+++ b/src/libxl/libxl_driver.c
@@ -911,7 +911,7 @@ libxlConnectGetType(virConnectPtr conn)
 if (virConnectGetTypeEnsureACL(conn) < 0)
 return NULL;
 
-return "Xen";
+return LIBXL_DRIVER_EXTERNAL_NAME;
 }
 
 static int
@@ -6608,7 +6608,7 @@ libxlDomainGetMetadata(virDomainPtr dom,
 }
 
 static virHypervisorDriver libxlHypervisorDriver = {
-.name = LIBXL_DRIVER_NAME,
+.name = LIBXL_DRIVER_EXTERNAL_NAME,
 .connectURIProbe = libxlConnectURIProbe,
 .connectOpen = libxlConnectOpen, /* 0.9.0 */
 .connectClose = libxlConnectClose, /* 0.9.0 */
@@ -6732,7 +6732,7 @@ static virConnectDriver libxlConnectDriver = {
 };
 
 static virStateDriver libxlStateDriver = {
-.name = "LIBXL",
+.name = LIBXL_DRIVER_EXTERNAL_NAME,
 .stateInitialize = libxlStateInitialize,
 .stateCleanup = libxlStateCleanup,
 .stateReload = libxlStateReload,
-- 
2.26.0

[PATCH 2/3] libxl: Clarify that 'xenlight' should only be used internally

[Jim Fehlig]

The libxl driver has suffered an identity crisis since its introduction.
It took on the name 'libxl' since at the time libvirt already contained
a 'xen' driver for the old Xen toolstack implementation. 'libxl' is short
for libxenlight, which is often called xenlight. Unfortunately all forms
of the name are used in the libxl driver.

The only remaining use of the 'xenlight' form is when interacting with
the host device manager, which is difficult to change since it would
cause problems when upgrading the driver.

Rename the #define to make it clear the 'xenlight' form is internal and
add a comment describing why the name exists and that its use should be
discouraged.

Signed-off-by: Jim Fehlig 
---
 src/libxl/libxl_conf.h   |  7 ++-
 src/libxl/libxl_domain.c |  4 ++--
 src/libxl/libxl_driver.c | 14 +++---
 3 files changed, 15 insertions(+), 10 deletions(-)

diff --git a/src/libxl/libxl_conf.h b/src/libxl/libxl_conf.h
index 11a922b10a..b057a9e4ba 100644
--- a/src/libxl/libxl_conf.h
+++ b/src/libxl/libxl_conf.h
@@ -39,7 +39,12 @@
 #include "libxl_logger.h"
 
 #define LIBXL_DRIVER_EXTERNAL_NAME "Xen"
-#define LIBXL_DRIVER_NAME "xenlight"
+/*
+ * We are stuck with the 'xenlight' name since it is used by the hostdev
+ * manager. Changing it would break management of any host devices previously
+ * managed under the name 'xenlight'.
+ */
+#define LIBXL_DRIVER_INTERNAL_NAME "xenlight"
 #define LIBXL_VNC_PORT_MIN  5900
 #define LIBXL_VNC_PORT_MAX  65535
 
diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
index cc53a765e1..d9fcde4364 100644
--- a/src/libxl/libxl_domain.c
+++ b/src/libxl/libxl_domain.c
@@ -873,7 +873,7 @@ libxlDomainCleanup(libxlDriverPrivatePtr driver,
 VIR_FREE(xml);
 }
 
-virHostdevReAttachDomainDevices(hostdev_mgr, LIBXL_DRIVER_NAME,
+virHostdevReAttachDomainDevices(hostdev_mgr, LIBXL_DRIVER_INTERNAL_NAME,
 vm->def, hostdev_flags, NULL);
 
 VIR_FREE(priv->lockState);
@@ -1370,7 +1370,7 @@ libxlDomainStart(libxlDriverPrivatePtr driver,
 if (cfg->autoballoon && libxlDomainFreeMem(cfg->ctx, &d_config) < 0)
 goto cleanup_dom;
 
-if (virHostdevPrepareDomainDevices(hostdev_mgr, LIBXL_DRIVER_NAME,
+if (virHostdevPrepareDomainDevices(hostdev_mgr, LIBXL_DRIVER_INTERNAL_NAME,
vm->def, hostdev_flags) < 0)
 goto cleanup_dom;
 
diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c
index ebeb91af3c..63ec0a2188 100644
--- a/src/libxl/libxl_driver.c
+++ b/src/libxl/libxl_driver.c
@@ -431,7 +431,7 @@ libxlReconnectDomain(virDomainObjPtr vm,
 libxlLoggerOpenFile(cfg->logger, vm->def->id, vm->def->name, NULL);
 
 /* Update hostdev state */
-if (virHostdevUpdateActiveDomainDevices(hostdev_mgr, LIBXL_DRIVER_NAME,
+if (virHostdevUpdateActiveDomainDevices(hostdev_mgr, 
LIBXL_DRIVER_INTERNAL_NAME,
 vm->def, hostdev_flags) < 0)
 goto error;
 
@@ -3127,7 +3127,7 @@ libxlDomainAttachHostPCIDevice(libxlDriverPrivatePtr 
driver,
 if (VIR_REALLOC_N(vm->def->hostdevs, vm->def->nhostdevs + 1) < 0)
 goto cleanup;
 
-if (virHostdevPreparePCIDevices(hostdev_mgr, LIBXL_DRIVER_NAME,
+if (virHostdevPreparePCIDevices(hostdev_mgr, LIBXL_DRIVER_INTERNAL_NAME,
 vm->def->name, vm->def->uuid,
 &hostdev, 1, 0) < 0)
 goto cleanup;
@@ -3149,7 +3149,7 @@ libxlDomainAttachHostPCIDevice(libxlDriverPrivatePtr 
driver,
 goto cleanup;
 
  error:
-virHostdevReAttachPCIDevices(hostdev_mgr, LIBXL_DRIVER_NAME,
+virHostdevReAttachPCIDevices(hostdev_mgr, LIBXL_DRIVER_INTERNAL_NAME,
  vm->def->name, &hostdev, 1, NULL);
 
  cleanup:
@@ -3264,7 +3264,7 @@ libxlDomainAttachHostUSBDevice(libxlDriverPrivatePtr 
driver,
 if (VIR_REALLOC_N(vm->def->hostdevs, vm->def->nhostdevs + 1) < 0)
 goto cleanup;
 
-if (virHostdevPrepareUSBDevices(hostdev_mgr, LIBXL_DRIVER_NAME,
+if (virHostdevPrepareUSBDevices(hostdev_mgr, LIBXL_DRIVER_INTERNAL_NAME,
 vm->def->name, &hostdev, 1, 0) < 0)
 goto cleanup;
 
@@ -3284,7 +3284,7 @@ libxlDomainAttachHostUSBDevice(libxlDriverPrivatePtr 
driver,
 goto cleanup;
 
  reattach:
-virHostdevReAttachUSBDevices(hostdev_mgr, LIBXL_DRIVER_NAME,
+virHostdevReAttachUSBDevices(hostdev_mgr, LIBXL_DRIVER_INTERNAL_NAME,
  vm->def->name, &hostdev, 1);
 
  cleanup:
@@ -3689,7 +3689,7 @@ libxlDomainDetachHostPCIDevice(libxlDriverPrivatePtr 
driver,
 
 virDomainHostdevRemove(vm->def, idx);
 
-virHostdevReAttachPCIDevices(hostdev_mgr, LIBXL_DRIVER_NAME,
+virHostdevReAttachPCIDevices(hostdev_mgr, LIBXL_DRIVER_INTERNAL_NAME,
  vm->def->name, &hostdev, 1, NULL);
 
 ret = 0;
@@ -3811,7 +3811,7 @@ libxlDomainDetachHostUSBDevice(libxlD

[PATCH 3/3] docs: Xen improvements

[Jim Fehlig]

In formatdomain, using 'libxl' and 'xen' is redundant since they now
both refer to the same driver. 'xen' predates 'libxl' and unambiguously
identifies the Xen hypervisor, so drop the use of 'libxl'.

In aclpolkit, the connection URI was erroneously identified as 'libxl'
and the name 'xenlight'. Change the URI to 'xen' and driver name to 'Xen'.

Signed-off-by: Jim Fehlig 
---
 docs/aclpolkit.html.in| 4 ++--
 docs/formatdomain.html.in | 6 +++---
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/docs/aclpolkit.html.in b/docs/aclpolkit.html.in
index 04cb39006a..3e5d30a5dd 100644
--- a/docs/aclpolkit.html.in
+++ b/docs/aclpolkit.html.in
@@ -342,8 +342,8 @@
   interface
 
 
-  libxl
-  xenlight
+  xen
+  Xen
 
 
   lxc
diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
index 91d6f6c0d3..23eb029234 100644
--- a/docs/formatdomain.html.in
+++ b/docs/formatdomain.html.in
@@ -2533,8 +2533,8 @@
 The name attribute selects which timer is
 being modified, and can be one of
 "platform" (currently unsupported),
-"hpet" (libxl, xen, qemu, lxc), "kvmclock" (qemu),
-"pit" (qemu), "rtc" (qemu, lxc), "tsc" (libxl, qemu -
+"hpet" (xen, qemu, lxc), "kvmclock" (qemu),
+"pit" (qemu), "rtc" (qemu, lxc), "tsc" (xen, qemu -
 since 3.2.0), "hypervclock"
 (qemu - since 1.2.2) or
 "armvtimer" (qemu - since 6.1.0).
@@ -7518,7 +7518,7 @@ qemu-kvm -net nic,model=? /dev/null
 
   You can provide the amount of video memory in kibibytes (blocks of
   1024 bytes) using vram. This is supported only for guest
-  type of "libxl", "vz", "qemu", "vbox", "vmx" and "xen". If no
+  type of "vz", "qemu", "vbox", "vmx" and "xen". If no
   value is provided the default is used. If the size is not a power of
   two it will be rounded to closest one.
 
-- 
2.26.0

[PATCH 0/3] Xen: Improve the naming mess

[Jim Fehlig]

Let's hope it's an improvement :-). See individual patches for details.

Jim Fehlig (3):
  libxl: Use the name 'Xen' in driver tables
  libxl: Clarify that 'xenlight' should only be used internally
  docs: Xen improvements

 docs/aclpolkit.html.in|  4 ++--
 docs/formatdomain.html.in |  6 +++---
 src/libxl/libxl_conf.h|  8 +++-
 src/libxl/libxl_domain.c  |  4 ++--
 src/libxl/libxl_driver.c  | 20 ++--
 5 files changed, 24 insertions(+), 18 deletions(-)

-- 
2.26.0

Re: [PATCH v5 for-5.0? 0/7] Tighten qemu-img rules on missing backing format

[Eric Blake]

On 4/3/20 12:58 PM, Eric Blake wrote:

v4 was here:
https://lists.gnu.org/archive/html/qemu-devel/2020-03/msg03775.html
In v5:
- fix 'qemu-img convert -B' to actually warn [Kashyap]
- squash in followups
- a couple more iotest improvements

If we decide this is not 5.0 material, then patches 4 and 7 need a
tweak to s/5.0/5.1/ as the start of the deprecation clock.


Ping.  I've already made the 5.1 change in my local tree, does anyone 
want to review the rest of this series before I post a v6?




Eric Blake (7):
   sheepdog: Add trivial backing_fmt support
   vmdk: Add trivial backing_fmt support
   qcow: Tolerate backing_fmt=, but warn on backing_fmt=raw
   qcow2: Deprecate use of qemu-img amend to change backing file
   iotests: Specify explicit backing format where sensible
   block: Add support to warn on backing file change without format
   qemu-img: Deprecate use of -b without -F



--
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

Re: [libvirt PATCH v2] remote: fix driver name check for libxl driver

[Jim Fehlig]

On 5/4/20 11:45 AM, Daniel P. Berrangé wrote:

The virConnectGetType() returns "Xen" for libxl, not "LIBXL".

This prevents users opening a connection to the libxl driver when using
the modular daemons.

Signed-off-by: Daniel P. Berrangé 


Reviewed-by: Jim Fehlig 

Regards,
Jim


---
  src/remote/remote_daemon_dispatch.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/remote/remote_daemon_dispatch.c 
b/src/remote/remote_daemon_dispatch.c
index 5d1c6971c0..6f67d2fb30 100644
--- a/src/remote/remote_daemon_dispatch.c
+++ b/src/remote/remote_daemon_dispatch.c
@@ -2111,7 +2111,7 @@ remoteDispatchConnectOpen(virNetServerPtr server 
G_GNUC_UNUSED,
  
  VIR_DEBUG("Primary driver type is '%s'", type);

  if (STREQ(type, "QEMU") ||
-STREQ(type, "LIBXL") ||
+STREQ(type, "Xen") ||
  STREQ(type, "LXC") ||
  STREQ(type, "VBOX") ||
  STREQ(type, "bhyve") ||

Re: [libvirt PATCH] remote: fix driver name check for libxl driver

[Jim Fehlig]

On 5/4/20 11:43 AM, Daniel P. Berrangé wrote:

On Mon, May 04, 2020 at 11:33:46AM -0600, Jim Fehlig wrote:

On 5/4/20 10:48 AM, Daniel P. Berrangé wrote:

The virConnectGetType() returns "xenlight" for libxl, not "LIBXL".


The libxl driver implements connectGetType, where it returns "Xen"

https://gitlab.com/libvirt/libvirt/-/blob/master/src/libxl/libxl_driver.c#L909

Is the driver function table not initialized, in which case
virConnectGetType returns the driver's name? Either way, I'm really
lamenting my choice of names and inconsistent use of them in the libxl
driver :-(. But I don't think it is possible to change the type returned
through virConnectGetType, as that could break existing users.


Doh, I missed that. So we have virHypervisorDriver using "xenlight",
and virStateDriver using  "LIBXL" and virConnectGetType using "Xen".

Can we changes the driver tables to use "Xen" too, now that we got
rid of the old Xen driver. I can't remember if the driver tables
names leak out anywhere important ?


It doesn't appear to be the case, but I only looked quickly and could have 
missed something.


I'll send a patch to change 'name' in the driver tables. With the old Xen driver 
gone Andrea and I also discussed renaming the libxl driver to xen, but I'm not 
sure it is worth the effort. It seems difficult to remove all references to 
libxl. E.g. changing the '--with-libxl' configure option would break external 
users/scripts.


Regards,
Jim

[libvirt PATCH v2] remote: fix driver name check for libxl driver

[Daniel P . Berrangé]

The virConnectGetType() returns "Xen" for libxl, not "LIBXL".

This prevents users opening a connection to the libxl driver when using
the modular daemons.

Signed-off-by: Daniel P. Berrangé 
---
 src/remote/remote_daemon_dispatch.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/remote/remote_daemon_dispatch.c 
b/src/remote/remote_daemon_dispatch.c
index 5d1c6971c0..6f67d2fb30 100644
--- a/src/remote/remote_daemon_dispatch.c
+++ b/src/remote/remote_daemon_dispatch.c
@@ -2111,7 +2111,7 @@ remoteDispatchConnectOpen(virNetServerPtr server 
G_GNUC_UNUSED,
 
 VIR_DEBUG("Primary driver type is '%s'", type);
 if (STREQ(type, "QEMU") ||
-STREQ(type, "LIBXL") ||
+STREQ(type, "Xen") ||
 STREQ(type, "LXC") ||
 STREQ(type, "VBOX") ||
 STREQ(type, "bhyve") ||
-- 
2.26.2

Re: [libvirt PATCH] remote: fix driver name check for libxl driver

[Daniel P . Berrangé]

On Mon, May 04, 2020 at 11:33:46AM -0600, Jim Fehlig wrote:
> On 5/4/20 10:48 AM, Daniel P. Berrangé wrote:
> > The virConnectGetType() returns "xenlight" for libxl, not "LIBXL".
> 
> The libxl driver implements connectGetType, where it returns "Xen"
> 
> https://gitlab.com/libvirt/libvirt/-/blob/master/src/libxl/libxl_driver.c#L909
> 
> Is the driver function table not initialized, in which case
> virConnectGetType returns the driver's name? Either way, I'm really
> lamenting my choice of names and inconsistent use of them in the libxl
> driver :-(. But I don't think it is possible to change the type returned
> through virConnectGetType, as that could break existing users.

Doh, I missed that. So we have virHypervisorDriver using "xenlight",
and virStateDriver using  "LIBXL" and virConnectGetType using "Xen".

Can we changes the driver tables to use "Xen" too, now that we got
rid of the old Xen driver. I can't remember if the driver tables
names leak out anywhere important ?

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

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 :|

[libvirt-php 6/6] gitlab: add CONTRIBUTING.rst file to indicate use of merge requests

[Daniel P . Berrangé]

With the introduction of automated CI pipelines, we are now ready to switch
to using merge requests for the project. With this switch we longer wish
to have patches sent to the mailing list, and thus the git-publish
config is removed.

Signed-off-by: Daniel P. Berrangé 
---
 .gitpublish  |  4 
 CONTRIBUTING.rst | 28 
 2 files changed, 28 insertions(+), 4 deletions(-)
 delete mode 100644 .gitpublish
 create mode 100644 CONTRIBUTING.rst

diff --git a/.gitpublish b/.gitpublish
deleted file mode 100644
index 2aa35a2..000
--- a/.gitpublish
+++ /dev/null
@@ -1,4 +0,0 @@
-[gitpublishprofile "default"]
-base = master
-to = libvir-list@redhat.com
-prefix = libvirt-php PATCH
diff --git a/CONTRIBUTING.rst b/CONTRIBUTING.rst
new file mode 100644
index 000..5bf29a6
--- /dev/null
+++ b/CONTRIBUTING.rst
@@ -0,0 +1,28 @@
+===
+Contributing to libvirt-php
+===
+
+The libvirt PHP API binding accepts code contributions via merge requests
+on the GitLab project:
+
+https://gitlab.com/libvirt/libvirt-php/-/merge_requests
+
+It is required that automated CI pipelines succeed before a merge request
+will be accepted. The global pipeline status for the ``master`` branch is
+visible at:
+
+https://gitlab.com/libvirt/libvirt-php/pipelines
+
+CI pipeline results for merge requests will be visible via the contributors'
+own private repository fork:
+
+https://gitlab.com/yourusername/libvirt-php/pipelines
+
+Contributions submitted to the project must be in compliance with the
+Developer Certificate of Origin Version 1.1. This is documented at:
+
+https://developercertificate.org/
+
+To indicate compliance, each commit in a series must have a "Signed-off-by"
+tag with the submitter's name and email address. This can be added by passing
+the ``-s`` flag to ``git commit`` when creating the patches.
-- 
2.26.2

[libvirt-php 3/6] tests: mark skipped tests with exit status 77

[Daniel P . Berrangé]

Skipped tests should be distinguished from failed tests. Exit code
77 is a standard from autoconf.

Signed-off-by: Daniel P. Berrangé 
---
 tests/functions.phpt.in | 2 +-
 tests/runtests.sh   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/tests/functions.phpt.in b/tests/functions.phpt.in
index 47dba2d..2ec3d79 100644
--- a/tests/functions.phpt.in
+++ b/tests/functions.phpt.in
@@ -26,7 +26,7 @@
bail("Invalid test name!");
 
printf("Test $name SKIPPED\n");
-   exit(1);
+   exit(77);
}
 
 $abs_srcdir = '@abs_srcdir@' ?: getcwd();
diff --git a/tests/runtests.sh b/tests/runtests.sh
index 8280be7..2674475 100755
--- a/tests/runtests.sh
+++ b/tests/runtests.sh
@@ -18,7 +18,7 @@ run_test()
ret=0
 
php -n -c "${srcdir}/php.ini" "${srcdir}/${name}.phpt"
-   if [ "x$?" != "x0" ]; then
+   if [ "x$?" != "x0" && "x$?" != "x77" ]; then
if [ "x$nf" == 'x1' ]; then
ret=1
else
-- 
2.26.2

[libvirt-php 5/6] gitlab: add CI jobs for validating build across platforms

[Daniel P . Berrangé]

This introduces CI jobs that replace the current jobs used on Jenkins
for every platform except FreeBSD.

A merge request workflow requires the user to fork the primary git
repo into their personal namespace. In general the changes need to
be tested against the current libvirt git master. If the user has a
fork of the main libvirt repo, we don't want to use that by default
as it may be out of date.

The general goal is that the CI jobs are self-contained and don't
depend on the build artifacts from the libvirt repo. We also want
to avoid having an explicit dependency on the libvirt-ci repo, or
on the Quay.io service. Contributors to the PHP module need to be
able to make code changes which imply CI environment changes and
be able to test them in isolation.

Thus, the dockerfile recipes for each distro are added in the ci/
sub-directory. The first stage of the CI jobs is to use these
recipes to build and publish a container image. These images are
then used in the second stage to perform the actual build.

The container image build is cached, inheriting from both the
primary libvirt project namespace, and the user's private project
namespace. Thus the performance hit of building container images
will only be felt the first time the project is forked, or when
the parent Docker images are rebuilt.

The dockerfiles were originally generated using lcitool, but if
the user makes a change that introduces new build dependencies,
the corresponding packages can be added to the dockerfile recipes
directly in the same commit. The change can be propagated back
into the libvirt-ci.git repo asynchronously.

The build job will do a minimal(-ish) build of libvirt git master
and then build the rest of the code against that. Ideally the main
libvirt configure script would have a way to request a minimal
build of just the API and test driver, but for now we settle for
just --without-libvirt which culls a large number of the drivers
fairly easily.

The CentOS-8 distro is skipped as it dropped the required PHP
module.

Signed-off-by: Daniel P. Berrangé 
---
 .gitlab-ci.yml   | 146 +++
 ci/README.rst|  12 +++
 ci/libvirt-centos-7.Dockerfile   |  92 +
 ci/libvirt-debian-10.Dockerfile  |  64 
 ci/libvirt-debian-9.Dockerfile   |  67 
 ci/libvirt-debian-sid.Dockerfile |  64 
 ci/libvirt-fedora-31.Dockerfile  |  60 +++
 ci/libvirt-fedora-32.Dockerfile  |  60 +++
 ci/libvirt-fedora-rawhide.Dockerfile |  61 +++
 ci/libvirt-opensuse-151.Dockerfile   |  62 
 ci/libvirt-ubuntu-1804.Dockerfile|  67 
 ci/libvirt-ubuntu-2004.Dockerfile|  64 
 ci/refresh   |  22 
 13 files changed, 841 insertions(+)
 create mode 100644 ci/README.rst
 create mode 100644 ci/libvirt-centos-7.Dockerfile
 create mode 100644 ci/libvirt-debian-10.Dockerfile
 create mode 100644 ci/libvirt-debian-9.Dockerfile
 create mode 100644 ci/libvirt-debian-sid.Dockerfile
 create mode 100644 ci/libvirt-fedora-31.Dockerfile
 create mode 100644 ci/libvirt-fedora-32.Dockerfile
 create mode 100644 ci/libvirt-fedora-rawhide.Dockerfile
 create mode 100644 ci/libvirt-opensuse-151.Dockerfile
 create mode 100644 ci/libvirt-ubuntu-1804.Dockerfile
 create mode 100644 ci/libvirt-ubuntu-2004.Dockerfile
 create mode 100755 ci/refresh

diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 50dae92..a8fb4f9 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -1,6 +1,51 @@
 
 stages:
   - prebuild
+  - containers
+  - builds
+
+.container_job_template: &container_job_definition
+  image: docker:stable
+  stage: containers
+  services:
+- docker:dind
+  before_script:
+- export TAG="$CI_REGISTRY_IMAGE/ci-$NAME:latest"
+- export COMMON_TAG="$CI_REGISTRY/libvirt/libvirt-php/ci-$NAME:latest"
+- docker info
+- docker login registry.gitlab.com -u "$CI_REGISTRY_USER" -p 
"$CI_REGISTRY_PASSWORD"
+  script:
+- docker pull "$TAG" || docker pull "$COMMON_TAG" || true
+- docker build --cache-from "$TAG" --cache-from "$COMMON_TAG" --tag "$TAG" 
-f "ci/libvirt-$NAME.Dockerfile" ci
+- docker push "$TAG"
+  after_script:
+- docker logout
+
+.git_build_job_template: &git_build_job_definition
+  image: $CI_REGISTRY_IMAGE/ci-$NAME:latest
+  stage: builds
+  before_script:
+- export MAKEFLAGS="-j$(getconf _NPROCESSORS_ONLN)"
+- export SCRATCH_DIR="/tmp/scratch"
+- export VROOT="$SCRATCH_DIR/vroot"
+- export LD_LIBRARY_PATH="$VROOT/lib"
+- export PATH="$VROOT/bin:$PATH"
+- export PKG_CONFIG_PATH="$VROOT/lib/pkgconfig"
+- export TEST_MAINTAINER=1
+  script:
+- pushd "$PWD"
+- mkdir -p "$SCRATCH_DIR"
+- cd "$SCRATCH_DIR"
+- git clone --depth 1 https://gitlab.com/libvirt/libvirt.git
+- mkdir libvirt/build
+- cd libvirt/build
+- ../autogen.sh --prefix="$VROOT" --without-libvirtd
+- $MAKE instal

[libvirt-php 1/6] m4: ignore --php-binary if it doesn't exist

[Daniel P . Berrangé]

On OpenSUSE 151,  "php-config --php-binary" reports a name of
"/usr/bin/php-cgi", but this binary doesn't actually exist. We
need to fallback to the plain "/usr/bin/php" command.

Signed-off-by: Daniel P. Berrangé 
---
 m4/virt-php-extension.m4 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/m4/virt-php-extension.m4 b/m4/virt-php-extension.m4
index 5aa3cb7..2a97e74 100644
--- a/m4/virt-php-extension.m4
+++ b/m4/virt-php-extension.m4
@@ -26,7 +26,7 @@ AC_DEFUN([LIBVIRT_CHECK_PHP_EXTENSION],[
   AC_MSG_CHECKING([for php module $1])
 
   phpbinary="$($PHPCONFIG --php-binary)"
-  if test "x$phpbinary" = "x"; then
+  if test "x$phpbinary" = "x" || test ! -x "$phpbinary" ; then
 phpbinary="$($PHPCONFIG --prefix)/bin/php"
   fi
 
-- 
2.26.2

[libvirt-php 2/6] src: don't declare global variables in header files

[Daniel P . Berrangé]

In Fedora 32 and later the linker will no longer merge duplicate global
variables. Thus headers need fixing to properly use "extern" and put the
actual declaration in the source files.

Signed-off-by: Daniel P. Berrangé 
---
 src/libvirt-connection.c | 2 ++
 src/libvirt-connection.h | 2 +-
 src/libvirt-domain.c | 2 ++
 src/libvirt-domain.h | 2 +-
 src/libvirt-network.c| 2 ++
 src/libvirt-network.h| 2 +-
 src/libvirt-nodedev.c| 2 ++
 src/libvirt-nodedev.h| 2 +-
 src/libvirt-nwfilter.c   | 2 ++
 src/libvirt-nwfilter.h   | 2 +-
 src/libvirt-php.c| 2 ++
 src/libvirt-php.h| 2 +-
 src/libvirt-snapshot.c   | 2 ++
 src/libvirt-snapshot.h   | 2 +-
 src/libvirt-storage.c| 3 +++
 src/libvirt-storage.h| 4 ++--
 src/libvirt-stream.c | 2 ++
 src/libvirt-stream.h | 2 +-
 18 files changed, 29 insertions(+), 10 deletions(-)

diff --git a/src/libvirt-connection.c b/src/libvirt-connection.c
index 9e70031..adc0045 100644
--- a/src/libvirt-connection.c
+++ b/src/libvirt-connection.c
@@ -11,6 +11,8 @@
 
 DEBUG_INIT("connection");
 
+int le_libvirt_connection;
+
 /*
  * Private function name:   free_resources_on_connection
  * Since version:   0.4.2
diff --git a/src/libvirt-connection.h b/src/libvirt-connection.h
index 0cae5ec..20f79e0 100644
--- a/src/libvirt-connection.h
+++ b/src/libvirt-connection.h
@@ -46,7 +46,7 @@
 RETURN_FALSE;  
\
 } while (0)
 
-int le_libvirt_connection;
+extern int le_libvirt_connection;
 
 typedef struct _php_libvirt_connection {
 virConnectPtr conn;
diff --git a/src/libvirt-domain.c b/src/libvirt-domain.c
index f594253..419630b 100644
--- a/src/libvirt-domain.c
+++ b/src/libvirt-domain.c
@@ -15,6 +15,8 @@
 
 DEBUG_INIT("domain");
 
+int le_libvirt_domain;
+
 void
 php_libvirt_domain_dtor(virt_resource *rsrc TSRMLS_DC)
 {
diff --git a/src/libvirt-domain.h b/src/libvirt-domain.h
index 8b80c9c..8640df8 100644
--- a/src/libvirt-domain.h
+++ b/src/libvirt-domain.h
@@ -120,7 +120,7 @@
 PHP_FE(libvirt_list_active_domains,  arginfo_libvirt_conn) 
\
 PHP_FE(libvirt_list_inactive_domains,arginfo_libvirt_conn)
 
-int le_libvirt_domain;
+extern int le_libvirt_domain;
 
 typedef struct _php_libvirt_domain {
 virDomainPtr domain;
diff --git a/src/libvirt-network.c b/src/libvirt-network.c
index 673790a..3888780 100644
--- a/src/libvirt-network.c
+++ b/src/libvirt-network.c
@@ -11,6 +11,8 @@
 
 DEBUG_INIT("network");
 
+int le_libvirt_network;
+
 void
 php_libvirt_network_dtor(virt_resource *rsrc TSRMLS_DC)
 {
diff --git a/src/libvirt-network.h b/src/libvirt-network.h
index 604b803..634c681 100644
--- a/src/libvirt-network.h
+++ b/src/libvirt-network.h
@@ -45,7 +45,7 @@
 PHP_FE(libvirt_list_all_networks,   arginfo_libvirt_conn_optflags) 
\
 PHP_FE(libvirt_list_networks,   arginfo_libvirt_conn_optflags)
 
-int le_libvirt_network;
+extern int le_libvirt_network;
 
 typedef struct _php_libvirt_network {
 virNetworkPtr network;
diff --git a/src/libvirt-nodedev.c b/src/libvirt-nodedev.c
index 5cfe428..e7a8535 100644
--- a/src/libvirt-nodedev.c
+++ b/src/libvirt-nodedev.c
@@ -11,6 +11,8 @@
 
 DEBUG_INIT("nodedev");
 
+int le_libvirt_nodedev;
+
 void
 php_libvirt_nodedev_dtor(virt_resource *rsrc TSRMLS_DC)
 {
diff --git a/src/libvirt-nodedev.h b/src/libvirt-nodedev.h
index 350b213..1357037 100644
--- a/src/libvirt-nodedev.h
+++ b/src/libvirt-nodedev.h
@@ -35,7 +35,7 @@
 RETURN_FALSE;  
\
 } while (0)
 
-int le_libvirt_nodedev;
+extern int le_libvirt_nodedev;
 
 typedef struct _php_libvirt_nodedev {
 virNodeDevicePtr device;
diff --git a/src/libvirt-nwfilter.c b/src/libvirt-nwfilter.c
index d949052..fa824cb 100644
--- a/src/libvirt-nwfilter.c
+++ b/src/libvirt-nwfilter.c
@@ -11,6 +11,8 @@
 
 DEBUG_INIT("nwfilter");
 
+int le_libvirt_nwfilter;
+
 void
 php_libvirt_nwfilter_dtor(virt_resource *rsrc TSRMLS_DC)
 {
diff --git a/src/libvirt-nwfilter.h b/src/libvirt-nwfilter.h
index c0cebb3..b450419 100644
--- a/src/libvirt-nwfilter.h
+++ b/src/libvirt-nwfilter.h
@@ -42,7 +42,7 @@
 RETURN_FALSE;  
\
 } while (0)
\
 
-int le_libvirt_nwfilter;
+extern int le_libvirt_nwfilter;
 
 typedef struct _php_libvirt_nwfilter {
 virNWFilterPtr nwfilter;
diff --git a/src/libvirt-php.c b/src/libvirt-php.c
index 75cbf68..04f73d9 100644
--- a/src/libvirt-php.c
+++ b/src/libvirt-php.c
@@ -31,6 +31,8 @@
 
 DEBUG_INIT("core");
 
+ZEND_DECLARE_MODULE_GLOBALS(libvirt)
+
 #ifndef EXTWIN
 /* Additional binaries */
 const char *features[] = { "screenshot", "create-image", "screenshot-convert", 
NULL };
diff --git a/src/libvirt-php.h b/src/libvirt-php.h
index d6e61c5..f0c77ce 100644
--- a/src/libvirt-php.h
+++ b/src/libvirt-php.h
@@ -155,

[libvirt-php 4/6] tests: skip test if not running on host with running libvirtd

[Daniel P . Berrangé]

Signed-off-by: Daniel P. Berrangé 
---
 tests/test-get-models.phpt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tests/test-get-models.phpt b/tests/test-get-models.phpt
index 60af7fa..3ed6ec5 100644
--- a/tests/test-get-models.phpt
+++ b/tests/test-get-models.phpt
@@ -1,9 +1,9 @@
 

[libvirt-php 0/6] introduce GitLab CI and merge requests

[Daniel P . Berrangé]

This series introduces use of GitLab CI and merge requests. In doing
so several current build problems are fixes.

Daniel P. Berrangé (6):
  m4: ignore --php-binary if it doesn't exist
  src: don't declare global variables in header files
  tests: mark skipped tests with exit status 77
  tests: skip test if not running on host with running libvirtd
  gitlab: add CI jobs for validating build across platforms
  gitlab: add CONTRIBUTING.rst file to indicate use of merge requests

 .gitlab-ci.yml   | 146 +++
 .gitpublish  |   4 -
 CONTRIBUTING.rst |  28 +
 ci/README.rst|  12 +++
 ci/libvirt-centos-7.Dockerfile   |  92 +
 ci/libvirt-debian-10.Dockerfile  |  64 
 ci/libvirt-debian-9.Dockerfile   |  67 
 ci/libvirt-debian-sid.Dockerfile |  64 
 ci/libvirt-fedora-31.Dockerfile  |  60 +++
 ci/libvirt-fedora-32.Dockerfile  |  60 +++
 ci/libvirt-fedora-rawhide.Dockerfile |  61 +++
 ci/libvirt-opensuse-151.Dockerfile   |  62 
 ci/libvirt-ubuntu-1804.Dockerfile|  67 
 ci/libvirt-ubuntu-2004.Dockerfile|  64 
 ci/refresh   |  22 
 m4/virt-php-extension.m4 |   2 +-
 src/libvirt-connection.c |   2 +
 src/libvirt-connection.h |   2 +-
 src/libvirt-domain.c |   2 +
 src/libvirt-domain.h |   2 +-
 src/libvirt-network.c|   2 +
 src/libvirt-network.h|   2 +-
 src/libvirt-nodedev.c|   2 +
 src/libvirt-nodedev.h|   2 +-
 src/libvirt-nwfilter.c   |   2 +
 src/libvirt-nwfilter.h   |   2 +-
 src/libvirt-php.c|   2 +
 src/libvirt-php.h|   2 +-
 src/libvirt-snapshot.c   |   2 +
 src/libvirt-snapshot.h   |   2 +-
 src/libvirt-storage.c|   3 +
 src/libvirt-storage.h|   4 +-
 src/libvirt-stream.c |   2 +
 src/libvirt-stream.h |   2 +-
 tests/functions.phpt.in  |   2 +-
 tests/runtests.sh|   2 +-
 tests/test-get-models.phpt   |   4 +-
 37 files changed, 903 insertions(+), 19 deletions(-)
 delete mode 100644 .gitpublish
 create mode 100644 CONTRIBUTING.rst
 create mode 100644 ci/README.rst
 create mode 100644 ci/libvirt-centos-7.Dockerfile
 create mode 100644 ci/libvirt-debian-10.Dockerfile
 create mode 100644 ci/libvirt-debian-9.Dockerfile
 create mode 100644 ci/libvirt-debian-sid.Dockerfile
 create mode 100644 ci/libvirt-fedora-31.Dockerfile
 create mode 100644 ci/libvirt-fedora-32.Dockerfile
 create mode 100644 ci/libvirt-fedora-rawhide.Dockerfile
 create mode 100644 ci/libvirt-opensuse-151.Dockerfile
 create mode 100644 ci/libvirt-ubuntu-1804.Dockerfile
 create mode 100644 ci/libvirt-ubuntu-2004.Dockerfile
 create mode 100755 ci/refresh

-- 
2.26.2

[libvirt-python PATCH v2] gitlab: add CONTRIBUTING.rst file to indicate use of merge requests

[Daniel P . Berrangé]

With the introduction of automated CI pipelines, we are now ready to switch
to using merge requests for the project. With this switch we longer wish
to have patches sent to the mailing list, and thus the git-publish
config is removed.

Signed-off-by: Daniel P. Berrangé 
---
 .gitpublish  |  4 
 CONTRIBUTING.rst | 28 
 2 files changed, 28 insertions(+), 4 deletions(-)
 delete mode 100644 .gitpublish
 create mode 100644 CONTRIBUTING.rst

diff --git a/.gitpublish b/.gitpublish
deleted file mode 100644
index dced716..000
--- a/.gitpublish
+++ /dev/null
@@ -1,4 +0,0 @@
-[gitpublishprofile "default"]
-base = master
-to = libvir-list@redhat.com
-prefix = libvirt-python PATCH
diff --git a/CONTRIBUTING.rst b/CONTRIBUTING.rst
new file mode 100644
index 000..3472318
--- /dev/null
+++ b/CONTRIBUTING.rst
@@ -0,0 +1,28 @@
+==
+Contributing to libvirt-python
+==
+
+The libvirt Python API binding accepts code contributions via merge requests
+on the GitLab project:
+
+https://gitlab.com/libvirt/libvirt-python/-/merge_requests
+
+It is required that automated CI pipelines succeed before a merge request
+will be accepted. The global pipeline status for the ``master`` branch is
+visible at:
+
+https://gitlab.com/libvirt/libvirt-python/pipelines
+
+CI pipeline results for merge requests will be visible via the contributors'
+own private repository fork:
+
+https://gitlab.com/yourusername/libvirt-python/pipelines
+
+Contributions submitted to the project must be in compliance with the
+Developer Certificate of Origin Version 1.1. This is documented at:
+
+https://developercertificate.org/
+
+To indicate compliance, each commit in a series must have a "Signed-off-by"
+tag with the submitter's name and email address. This can be added by passing
+the ``-s`` flag to ``git commit`` when creating the patches.
-- 
2.26.2

Re: [libvirt PATCH] remote: fix driver name check for libxl driver

[Jim Fehlig]

On 5/4/20 10:48 AM, Daniel P. Berrangé wrote:

The virConnectGetType() returns "xenlight" for libxl, not "LIBXL".


The libxl driver implements connectGetType, where it returns "Xen"

https://gitlab.com/libvirt/libvirt/-/blob/master/src/libxl/libxl_driver.c#L909

Is the driver function table not initialized, in which case virConnectGetType 
returns the driver's name? Either way, I'm really lamenting my choice of names 
and inconsistent use of them in the libxl driver :-(. But I don't think it is 
possible to change the type returned through virConnectGetType, as that could 
break existing users.


Regards,
Jim


This prevents users opening a connection to the libxl driver when using
the modular daemons.

Signed-off-by: Daniel P. Berrangé 
---
  src/remote/remote_daemon_dispatch.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/remote/remote_daemon_dispatch.c 
b/src/remote/remote_daemon_dispatch.c
index 5d1c6971c0..a8ac795d71 100644
--- a/src/remote/remote_daemon_dispatch.c
+++ b/src/remote/remote_daemon_dispatch.c
@@ -2111,7 +2111,7 @@ remoteDispatchConnectOpen(virNetServerPtr server 
G_GNUC_UNUSED,
  
  VIR_DEBUG("Primary driver type is '%s'", type);

  if (STREQ(type, "QEMU") ||
-STREQ(type, "LIBXL") ||
+STREQ(type, "xenlight") ||
  STREQ(type, "LXC") ||
  STREQ(type, "VBOX") ||
  STREQ(type, "bhyve") ||

Re: [libvirt-python PATCH] gitlab: add CONTRIBUTING.rst file to indicate use of merge requests

[Andrea Bolognani]

On Fri, 2020-05-01 at 14:13 +0100, Daniel P. Berrangé wrote:
> +++ b/CONTRIBUTING.rst
> @@ -0,0 +1,28 @@
> +==
> +Contributing to libvirt-python
> +==
> +
> +The libvirt Python API binding accepts code contributions via merge requests
> +on the GitLab project:
> +
> +   https://gitlab.com/libvirt/libvirt-python/-/merge_requests

Indenting the link will result in reStructuredText interpreting it as
a block quote, which I don't think is what we want. libvirt's own
README.rst file doesn't indent link, which doesn't look too good in
text format but is okay once rendered to HTML.

> +It is required that automated CI pipelines succeed before a merge request
> +will be accepted. The global pipeline status for the ``master`` branch is
> +visible at:
> +
> +   https://gitlab.com/libvirt/libvirt-python/pipelines
> +
> +CI pipline results for merge requests will be visible via the contributors'

s/pipline/pipeline/

> +own private repository fork:
> +
> +   https://gitlab.com/::YOUR-USER-NAME::/libvirt-python/pipelines

I think the shouting is unnecessary, how about

  https://gitlab.com/yourusername/libvirt-python/pipeline

instead?

> +Contributions submitted to the project must be in compliance with the
> +Developer Certificate of Origin Version 1.1. This is documented at:
> +
> +   https://developercertificate.org/
> +
> +In indicate compliance, each commit in a series must have a "Signed-off-by"

s/In/To/

> +tag with the submittor's name and email address. This can be added by passing

s/submittor/submitter/

-- 
Andrea Bolognani / Red Hat / Virtualization

Re: [libvirt PATCH 2/2] CONTRIBUTING: Include note about build system tools

[Daniel P . Berrangé]

On Mon, Apr 27, 2020 at 02:01:44PM +0200, Andrea Bolognani wrote:
> On Mon, 2020-04-27 at 12:19 +0100, Daniel P. Berrangé wrote:
> > On Mon, Apr 27, 2020 at 01:15:08PM +0200, Andrea Bolognani wrote:
> > > I expect most people doing development work on libvirt are using
> > > Fedora rather than RHEL, and I really don't want this document to
> > > become too verbose or duplicate too much information that's already
> > > available elsewhere... If we can cover ~90% of potential users with
> > > just a few commands, I think that's preferable.
> > 
> > Just listing the extra packages is simpler than the group name.
> > 
> >dnf install gcc make automake libtool autoconf rpm-build
> 
> Point taken, the list is short and unlikely to change much.
> 
> Can I have your Reviewed-by for the series if I squash your version
> in?

Yep, with that change added

  Reviewed-by: Daniel P. Berrangé 

And this is fine for freeze.

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 :|

Re: [libvirt PATCH 1/2] CONTRIBUTING: Indent command by three spaces

[Daniel P . Berrangé]

On Mon, Apr 27, 2020 at 12:54:20PM +0200, Andrea Bolognani wrote:
> This is the proper way to do it according to our reStructuredText
> style guidelines.
> 
> Signed-off-by: Andrea Bolognani 
> ---
>  CONTRIBUTING.rst | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)

Reviewed-by: Daniel P. Berrangé 


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 :|

[libvirt PATCH] remote: fix driver name check for libxl driver

[Daniel P . Berrangé]

The virConnectGetType() returns "xenlight" for libxl, not "LIBXL".

This prevents users opening a connection to the libxl driver when using
the modular daemons.

Signed-off-by: Daniel P. Berrangé 
---
 src/remote/remote_daemon_dispatch.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/remote/remote_daemon_dispatch.c 
b/src/remote/remote_daemon_dispatch.c
index 5d1c6971c0..a8ac795d71 100644
--- a/src/remote/remote_daemon_dispatch.c
+++ b/src/remote/remote_daemon_dispatch.c
@@ -2111,7 +2111,7 @@ remoteDispatchConnectOpen(virNetServerPtr server 
G_GNUC_UNUSED,
 
 VIR_DEBUG("Primary driver type is '%s'", type);
 if (STREQ(type, "QEMU") ||
-STREQ(type, "LIBXL") ||
+STREQ(type, "xenlight") ||
 STREQ(type, "LXC") ||
 STREQ(type, "VBOX") ||
 STREQ(type, "bhyve") ||
-- 
2.26.2

Re: [libvirt PATCH] tests: Mock virGetUserRuntimeDirectory() for qemuhotplug

[Daniel P . Berrangé]

On Fri, May 01, 2020 at 03:22:22PM +0200, Andrea Bolognani wrote:
> On Fri, 2020-05-01 at 14:09 +0100, Daniel P. Berrangé wrote:
> > On Fri, May 01, 2020 at 02:30:16PM +0200, Andrea Bolognani wrote:
> > > Not mocking this function results in files being created in the
> > > user's home directory when running the test and in the build
> > > failing altogether inside a constrained environment such as the
> > > one used by pbuilder:
> > 
> > What's pbuilder ?
> 
> It's a tool used in Debian to verify that packages can be built
> successfully in a minimal environment that only contains the build
> dependencies that have been explicitly declared and where access to
> the network and the filesystem outside of the working directory is
> forbidden.
> 
> I think the equivalent in the Fedora world is mock, but I haven't
> used the latter in person so I might be off-base :)
> 
> > I wonder if we can make it so that in our
> > containers $HOME points to a non-writable directory such that
> > we can see this failure (and others) in our GitLab CI ?
> 
> Yeah, I was thinking the same, and it definitely sounds like a good
> idea.

Turns out this can be done very nicely even outside of CI:

  https://www.redhat.com/archives/libvir-list/2020-May/msg00058.html

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 :|

Re: [libvirt PATCH] tests: Mock virGetUserRuntimeDirectory() for qemuhotplug

[Andrea Bolognani]

On Mon, 2020-05-04 at 13:44 +0200, Michal Privoznik wrote:
> On 5/1/20 2:30 PM, Andrea Bolognani wrote:
> > +char *
> > +virGetUserRuntimeDirectory(void)
> > +{
> > +return g_build_filename(g_getenv("LIBVIRT_FAKE_ROOT_DIR"),
> > +"user-runtime-directory", NULL);
> > +}
> 
> While the qemuhotplugtest is (currently) the only one that actually uses 
> the runtimedir, this function is called basically from every qemu* test 
> because (almost?) every qemu* test calls virQEMUDriverConfigNew(). 
> Therefore I think we need to fix qemuTestDriverInit() too so that after 
> it call ConfigNew() the path is replaced with some known value.

Good point! I'll look into making this more generic.

-- 
Andrea Bolognani / Red Hat / Virtualization

[libvirt-ci PATCH] guests: add libvirt-php project packages

[Daniel P . Berrangé]

Signed-off-by: Daniel P. Berrangé 
---
 guests/vars/mappings.yml | 11 +++
 guests/vars/projects/libvirt-php.yml |  6 ++
 2 files changed, 17 insertions(+)
 create mode 100644 guests/vars/projects/libvirt-php.yml

diff --git a/guests/vars/mappings.yml b/guests/vars/mappings.yml
index 4808b12..4fec6f4 100644
--- a/guests/vars/mappings.yml
+++ b/guests/vars/mappings.yml
@@ -831,6 +831,17 @@ mappings:
 OpenSUSE:
 CentOS7:
 
+  php:
+default: php
+FreeBSD: php74
+
+  php-imagick:
+default: php-imagick
+FreeBSD: php74-pecl-imagick
+Fedora: php-pecl-imagick
+CentOS: php-pecl-imagick
+CentOS8:
+
   pkg-config:
 default: pkgconf
 rpm: pkgconfig
diff --git a/guests/vars/projects/libvirt-php.yml 
b/guests/vars/projects/libvirt-php.yml
new file mode 100644
index 000..c911dc6
--- /dev/null
+++ b/guests/vars/projects/libvirt-php.yml
@@ -0,0 +1,6 @@
+---
+packages:
+  - php
+  - php-imagick
+  - xmllint
+  - xsltproc
-- 
2.26.2

[libvirt RFC PATCH] network: NetworkManager script to monitor for conflicts with new interfaces

[Laine Stump]

There has been a problem for several years with libvirt's default
network conflicting with the host network connection on new installs,
particularly when the "host" is actually virtual machine that is,
itself, connected to the libvirt default network on its respective
host. If the two default networks use the same subnet, and if the
nested host's libvirtd happens to start its network before the system
networking connects to the toplevel host, then network connectivity to
the guest is just silently non-working.

We've tried several things over the years to eliminate this problem,
including:

1) Checking for conflicting routes/interfaces during installation of
the libvirt-daemon-config-network package (the one containing the
default network config file) which tries different subnets until it
finds one that doesn't conflict. This helps in some cases, but fails
on 2 points: a) if the installation environment is different from the
environment where the system is actually run (e.g. a "live CD" image
of a distro, which is built in a container by the distro maintainers,
then could be run in any number of places, and b) it modifies the
installed files during the rpm installation post_install script, which
is now discouraged because people building container images don't like
dealing with that.

2) When starting a libvirt network, we now check for any route or
interface that conflicts with the new network's IP's and routes. This
doesn't fix the problem, but does notify the user of the problem *as
long as libvirt starts its networks after the host has started its
system networks*.

Neither of these help in the situation where libvirt's networks are
started first. The script in this patch uses a NetworkManager facility
(dispatcher.d scripts, which are run whenever any interface is
brought up or down) to check for any libvirt networks that conflict
with the new NetworkManager interface, and if it finds a conflict it
logs a message and destroys the libvirt network. So as with case (2)
above, it doesn't solve the problem, but it does make it more obvious,
and also makes sure the host networking isn't borked, so you can still
ssh into the machine and fix it.

There are a few caveats/misgivings with the script I've come up with,
which cause me to post it as just an RFC:

1) It's written in python, and uses libxml2

When I first sat down to make this script (following a suggestion by
danpb during an IRC discussion), I immediately put #!/bin/bash at the
top of the file, because it's supposed to be a script. But then I
remembered that we're trying to narrow down the usage of languages in
libvirt, and anyway it would be nice to be able to properly parse the
XML to get the IP addresses/netmasks/prefixes. So I instead wrote it
in python. This makes for a less ugly program, but it does mean that
the daemon-config-network package is now dependent on python3-libxml
(and python3 of course), which pulls in a bunch of other packages.

Everybody's dev systems already have these packages and their
dependencies installed (since both are required to build) and many
other users systems already have them (they are required by
virt-install and virt-manager, among others), including the Fedora
live CD, for example. But not *all* systems have them. There has been
a lot of work to reduce package bloat caused by pulling in more and
more packages, so I'm reluctant to contribute to that. On the other
hand, someone who is looking to minimize their system footprint will
also probably not be installing the libvirt default network, so maybe
it's acceptable (I'm leaning towards "not", but want to know if anyone
else has a different opinion)

2) As delivered, it checks for conflicts with *all* libvirt
networks.

While that was fun to write, and in theory is the right
thing to do, in practice it may be / probably is overkill. As we
discussed in IRC, the main time when this is a problem is just after
the first boot of a new OS / libvirt installation, and the only
libvirt network that's going to exist at that time is the default
network. So while having a loop that scans all libvirt networks is
more complete, in almost all cases it is just wasting time. (I did
provide a bool at the top of the script that can be modified to tell
it to only check the default network, but of course the script is
installed in /usr/lib, and it's not proper to modify files in
/usr/lib, so that isn't a real-world solution, but more a way to allow
people (i.e. "me") right now to test out the different behaviors.

3) This only works if NetworkManager is enabled.

I brought this up when danpb first mentioned the idea, and he rightly
pointed out that every report of this problem we've had has been from
the first boot of a new install on a system that used Network Manager
- anybody using any other method of networking config on their host
has had to manually intervene to get it setup, but NM tries to do
everything auto-magically. So while there may still be a very
occasional rare occu

Re: [libvirt PATCH] gitlab: update list of distros used to use latest versions

[Andrea Bolognani]

On Mon, 2020-05-04 at 13:51 +0100, Daniel P. Berrangé wrote:
> Replace Fedora 30 with Fedora 32
> Replace Ubuntu 16.04 with Ubuntu 20.04
> Switch generic jobs from Fedora 31 to Fedora 32
> 
> Signed-off-by: Daniel P. Berrangé 
> ---
>  .gitlab-ci.yml | 32 
>  1 file changed, 16 insertions(+), 16 deletions(-)

Welp, should have done this myself before deleting the old container
images from quay.io :/

> @@ -172,7 +172,7 @@ website:
>  - $MAKE -C docs install
>  - cd ..
>  - mv vroot/share/doc/libvirt/html/ website
> -  image: quay.io/libvirt/buildenv-libvirt-fedora-31:latest
> +  image: quay.io/libvirt/buildenv-libvirt-fedora-32:latest

I thought the idea was to use CentOS 8 for these jobs to avoid the
constant churn?

Either way, the Fedora 31 images are still available, so these
changes are not even necessary to fix the CI.

To all the hunks before this one,

  Reviewed-by: Andrea Bolognani 

and safe for freeze.

-- 
Andrea Bolognani / Red Hat / Virtualization

Kata needs for device addressing (was Re: libvirt-devaddr: a new library for device address assignment)

[Christophe de Dinechin]

> On 4 Mar 2020, at 13:50, Daniel P. Berrangé  wrote:
> 
> We've been doing alot of refactoring of code in recent times, and also
> have plans for significant infrastructure changes. We still need to
> spend time delivering interesting features to users / applications.
> This mail is to introduce an idea for a solution to an specific
> area applications have had long term pain with libvirt's current
> "mechanism, not policy" approach - device addressing. This is a way
> for us to show brand new ideas & approaches for what the libvirt
> project can deliver in terms of management APIs.
> 
> To set expectations straight: I have written no code for this yet,
> merely identified the gap & conceptual solution.
> 
> 
> The device addressing problem
> =
> 
> One of the key jobs libvirt does when processing a new domain XML
> configuration is to assign addresses to all devices that are present.
> This involves adding various device controllers (PCI bridges, PCI root
> ports, IDE/SCSI buses, USB controllers, etc) if they are not already
> present, and then assigning PCI, USB, IDE, SCSI, etc, addresses to each
> device so they are associated with controllers. When libvirt spawns a
> QEMU guest, it will pass full address information to QEMU.
> 
> Libvirt, as a general rule, aims to avoid defining and implementing
> policy around expansion of guest configuration / defaults, however, it
> is inescapable in the case of device addressing due to the need to
> guarantee a stable hardware ABI to make live migration and save/restore
> to disk work.  The policy that libvirt has implemented for device
> addressing is, as much as possible, the same as the addressing scheme
> QEMU would apply itself.
> 
> While libvirt succeeds in its goal of providing a stable hardware API,
> the addressing scheme used is not well suited to all deployment
> scenarios of QEMU. This is an inevitable result of having a specific
> assignment policy implemented in libvirt which has to trade off mutually
> incompatible use cases/goals.
> 
> When the libvirt addressing policy is not been sufficient, management
> applications are forced to take on address assignment themselves,
> which is a massive non-trivial job with many subtle problems to
> consider.
> 
> Places where libvirt's addressing is insufficient for PCI include
> 
> * Setting up multiple guest NUMA nodes and associating devices to
>   specific nodes
> * Pre-emptive creation of extra PCIe root ports, to allow for later
>   device hotplug on PCIe topologies
> * Determining whether to place a device on a PCI or PCIe bridge
> * Controlling whether a device is placed into a hotpluggable slot
> * Controlling whether a PCIe root port supports hotplug or not
> * Determining whether to places all devices on distinct slots or
>   buses, vs grouping them all into functions on the same slot
> * Ability to expand the device addressing without being on the
>   hypervisor host
> 
> Libvirt wishes to avoid implementing many different address assignment
> policies. It also wishes to keep the domain XML as a representation
> of the virtual hardware, not add a bunch of properties to it which
> merely serve as tunable input parameters for device addressing
> algorithms.
> 
> There is thus a dilemma here. Management applications increasingly
> need fine grained control over device addressing, while libvirt
> doesn't want to expose fine grained policy controls via the XML.
> 
> 
> The new libvirt-devaddr API
> ===
> 
> The way out of this is to define a brand new virt management API
> which tackles this specific problem in a way that addresses all the
> problems mgmt apps have with device addressing and explicitly
> provides a variety of policy impls with tunable behaviour.
> 
> By "new API", I actually mean an entirely new library, completely
> distinct from libvirt.so, or anything else we've delivered so
> far. The closest we've come to delivering something at this kind
> of conceptual level, would be the abortive attempt we made with
> "libvirt-builder" to deliver a policy-driven API instead of mechanism
> based. This proposal is still quite different from that attempt.
> 
> At a high level
> 
> * The new API is "libvirt-devaddr" - short for "libvirt device addressing"
> 
> * As input it will take
> 
>   1. The guest CPU architecture and machine type
>   2. A list of global tunables specifying desired behaviour of the
>  address assignment policy
>   3. A minimal list of devices needed in the virtual machine, with
>  optional addresses and optional per-device tunables to override
>  the global tunables
> 
> * As output it will emit
> 
>   1. fully expanded list of devices needed in the virtual machine,
>  with addressing information sufficient to ensure stable hardware ABI
> 
> Initially the API would implement something that behaves the same
> way as libvirt's current address assignment API.
> 
> The intended usage would be
> 
> * Mgmt ap

[PATCH] Drop needless variable

[Michal Privoznik]

Instead of the following pattern:

  type ret;
  ...
  ret = func();
  return ret;

we can use:

  return func()

directly.

Signed-off-by: Michal Privoznik 
---
 src/conf/domain_addr.c   |  8 +---
 src/conf/domain_conf.c   |  8 +++-
 src/conf/network_conf.c  |  5 +
 src/conf/virnetworkportdef.c |  5 +
 src/qemu/qemu_capabilities.c |  5 +
 src/qemu/qemu_command.c  |  8 ++--
 src/qemu/qemu_conf.c |  9 ++---
 src/qemu/qemu_domain.c   | 12 +++-
 src/qemu/qemu_driver.c   | 18 ++
 src/qemu/qemu_tpm.c  | 11 ++-
 src/security/security_apparmor.c |  5 +
 src/security/security_util.c |  9 +++--
 src/storage/storage_driver.c |  7 ++-
 src/util/vircgroup.c |  5 +
 src/util/virmdev.c   | 10 ++
 src/util/virresctrl.c|  6 +-
 src/util/virsocketaddr.c |  5 +
 src/util/virutil.c   |  8 +++-
 tests/qemuxml2argvtest.c |  6 +-
 19 files changed, 37 insertions(+), 113 deletions(-)

diff --git a/src/conf/domain_addr.c b/src/conf/domain_addr.c
index 5652bc9a33..8623e79daf 100644
--- a/src/conf/domain_addr.c
+++ b/src/conf/domain_addr.c
@@ -1392,13 +1392,7 @@ virDomainPCIAddressSetAllMulti(virDomainDefPtr def)
 static char*
 virDomainCCWAddressAsString(virDomainDeviceCCWAddressPtr addr)
 {
-char *addrstr = NULL;
-
-addrstr = g_strdup_printf("%x.%x.%04x",
-  addr->cssid,
-  addr->ssid,
-  addr->devno);
-return addrstr;
+return g_strdup_printf("%x.%x.%04x", addr->cssid, addr->ssid, addr->devno);
 }
 
 static int
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index 8a87586936..83748354b0 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -31316,54 +31316,52 @@ char *
 virDomainDefGetShortName(const virDomainDef *def)
 {
 wchar_t wshortname[VIR_DOMAIN_SHORT_NAME_MAX + 1] = {0};
 size_t len = 0;
-char *ret = NULL;
 g_autofree char *shortname = NULL;
 
 /* No need to do the whole conversion thing when there are no multibyte
  * characters.  The same applies for illegal sequences as they can occur
  * with incompatible locales. */
 len = mbstowcs(NULL, def->name, 0);
 if ((len == (size_t) -1 && errno == EILSEQ) ||
 len == strlen(def->name)) {
-ret = g_strdup_printf("%d-%.*s", def->id, VIR_DOMAIN_SHORT_NAME_MAX, 
def->name);
-return ret;
+return g_strdup_printf("%d-%.*s", def->id, VIR_DOMAIN_SHORT_NAME_MAX,
+   def->name);
 }
 
 if (len == (size_t) -1) {
 virReportSystemError(errno, "%s",
  _("Cannot convert domain name to "
"wide character string"));
 return NULL;
 }
 
 if (mbstowcs(wshortname, def->name, VIR_DOMAIN_SHORT_NAME_MAX) == (size_t) 
-1) {
 virReportSystemError(errno, "%s",
  _("Cannot convert domain name to "
"wide character string"));
 return NULL;
 }
 
 len = wcstombs(NULL, wshortname, 0);
 if (len == (size_t) -1) {
 virReportSystemError(errno, "%s",
  _("Cannot convert wide character string "
"back to multi-byte domain name"));
 return NULL;
 }
 
 if (VIR_ALLOC_N(shortname, len + 1) < 0)
 return NULL;
 
 if (wcstombs(shortname, wshortname, len) == (size_t) -1) {
 virReportSystemError(errno, "%s",
  _("Cannot convert wide character string "
"back to multi-byte domain name"));
 return NULL;
 }
 
-ret = g_strdup_printf("%d-%s", def->id, shortname);
-return ret;
+return g_strdup_printf("%d-%s", def->id, shortname);
 }
 
 #undef VIR_DOMAIN_SHORT_NAME_MAX
diff --git a/src/conf/network_conf.c b/src/conf/network_conf.c
index a7c177f8db..dc64ce6959 100644
--- a/src/conf/network_conf.c
+++ b/src/conf/network_conf.c
@@ -2892,10 +2892,7 @@ char *
 virNetworkConfigFile(const char *dir,
  const char *name)
 {
-char *ret = NULL;
-
-ret = g_strdup_printf("%s/%s.xml", dir, name);
-return ret;
+return g_strdup_printf("%s/%s.xml", dir, name);
 }
 
 
diff --git a/src/conf/virnetworkportdef.c b/src/conf/virnetworkportdef.c
index a4cffea8b6..2013e11dff 100644
--- a/src/conf/virnetworkportdef.c
+++ b/src/conf/virnetworkportdef.c
@@ -432,10 +432,7 @@ static char *
 virNetworkPortDefConfigFile(const char *dir,
 const char *name)
 {
-char *ret = NULL;
-
-ret = g_strdup_printf("%s/%s.xml", dir, name);
-return ret;
+return g_strdup_printf("%s/%s.xml", dir, name);
 }
 
 
diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities

[libvirt PATCH] tests: poison $HOME and $XDG_RUNTIME_DIR env variables

[Daniel P . Berrangé]

To attempt to catch unit tests which accidentally create files in $HOME,
or $XDG_RUNTIME_DIR, poison these env vars by pointing them to
directories which don't exist. This should give easier to debug test
failures. For example:

$ VIR_TEST_DEBUG=1 ./qemuhotplugtest
Could not initialize HostdevManager - operation failed: Failed to create state 
dir '/bad-test-used-env-xdg-runtime-dir/libvirt/hostdevmgr'

Signed-off-by: Daniel P. Berrangé 
---
 tests/testutils.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/tests/testutils.c b/tests/testutils.c
index 5fd81b70a2..8533a02d73 100644
--- a/tests/testutils.c
+++ b/tests/testutils.c
@@ -767,6 +767,9 @@ int virTestMain(int argc,
 preloads[npreloads] = NULL;
 }
 
+setenv("HOME", "/bad-test-used-env-home", 1);
+setenv("XDG_RUNTIME_DIR", "/bad-test-used-env-xdg-runtime-dir", 1);
+
 va_start(ap, func);
 while ((lib = va_arg(ap, const char *))) {
 if (!virFileIsExecutable(lib)) {
-- 
2.26.2

[libvirt PATCH] gitlab: update list of distros used to use latest versions

[Daniel P . Berrangé]

Replace Fedora 30 with Fedora 32
Replace Ubuntu 16.04 with Ubuntu 20.04
Switch generic jobs from Fedora 31 to Fedora 32

Signed-off-by: Daniel P. Berrangé 
---
 .gitlab-ci.yml | 32 
 1 file changed, 16 insertions(+), 16 deletions(-)

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

[libvirt PATCH] docs: introduce a page showing a overall CI dashboard

[Daniel P . Berrangé]

With the move to GitLab CI one of the things we miss from Jenkins is a
single page dashboard showing CI status across all projects. This is a
very simple replacement that uses badges for CI pipeline status.

Signed-off-by: Daniel P. Berrangé 
---
 docs/ci.rst   | 408 ++
 docs/docs.html.in |   3 +
 2 files changed, 411 insertions(+)
 create mode 100644 docs/ci.rst

diff --git a/docs/ci.rst b/docs/ci.rst
new file mode 100644
index 00..2b997a9115
--- /dev/null
+++ b/docs/ci.rst
@@ -0,0 +1,408 @@
+==
+Libvirt Continuous Integration
+==
+
+The libvirt project primarily uses GitLab CI for automated testing of Linux
+builds, and cross-compiled Windows builds. `Travis 
`_
+is used for validating macOS builds, and `Jenkins 
`_
+is temporarily used for validating FreeBSD builds.
+
+GitLab CI Dashboard
+===
+
+The dashboard below shows the current status of the GitLab CI jobs for each
+repository:
+
+.. raw:: html
+
+   
+ 
+   
+ Project
+ Pipeline
+   
+ 
+ 
+   
+ Core
+   
+   
+ libvirt
+ 
+   https://gitlab.com/libvirt/libvirt/pipelines";>
+ https://gitlab.com/libvirt/libvirt/badges/master/pipeline.svg"/>
+   
+ 
+   
+   
+ Language bindings
+   
+   
+ libvirt-csharp
+ 
+   https://gitlab.com/libvirt/libvirt-csharp/pipelines";>
+ https://gitlab.com/libvirt/libvirt-csharp/badges/master/pipeline.svg"/>
+   
+ 
+   
+   
+ libvirt-go
+ 
+   https://gitlab.com/libvirt/libvirt-go/pipelines";>
+ https://gitlab.com/libvirt/libvirt-go/badges/master/pipeline.svg"/>
+   
+ 
+   
+   
+ libvirt-java
+ 
+   https://gitlab.com/libvirt/libvirt-java/pipelines";>
+ https://gitlab.com/libvirt/libvirt-java/badges/master/pipeline.svg"/>
+   
+ 
+   
+   
+ libvirt-ocaml
+ 
+   https://gitlab.com/libvirt/libvirt-ocaml/pipelines";>
+ https://gitlab.com/libvirt/libvirt-ocaml/badges/master/pipeline.svg"/>
+   
+ 
+   
+   
+ libvirt-perl
+ 
+   https://gitlab.com/libvirt/libvirt-perl/pipelines";>
+ https://gitlab.com/libvirt/libvirt-perl/badges/master/pipeline.svg"/>
+   
+ 
+   
+   
+ libvirt-php
+ 
+   https://gitlab.com/libvirt/libvirt-php/pipelines";>
+ https://gitlab.com/libvirt/libvirt-php/badges/master/pipeline.svg"/>
+   
+ 
+   
+   
+ libvirt-python
+ 
+   https://gitlab.com/libvirt/libvirt-python/pipelines";>
+ https://gitlab.com/libvirt/libvirt-python/badges/master/pipeline.svg"/>
+   
+ 
+   
+   
+ libvirt-rust
+ 
+   https://gitlab.com/libvirt/libvirt-rust/pipelines";>
+ https://gitlab.com/libvirt/libvirt-rust/badges/master/pipeline.svg"/>
+   
+ 
+   
+   
+ ruby-libvirt
+ 
+   https://gitlab.com/libvirt/ruby-libvirt/pipelines";>
+ https://gitlab.com/libvirt/ruby-libvirt/badges/master/pipeline.svg"/>
+   
+ 
+   
+   
+ Object mappings
+   
+   
+ libvirt-cim
+ 
+   https://gitlab.com/libvirt/libvirt-cim/pipelines";>
+ https://gitlab.com/libvirt/libvirt-cim/badges/master/pipeline.svg"/>
+   
+ 
+   
+   
+ libvirt-dbus
+ 
+   https://gitlab.com/libvirt/libvirt-dbus/pipelines";>
+ https://gitlab.com/libvirt/libvirt-dbus/badges/master/pipeline.svg"/>
+   
+ 
+   
+   
+ libvirt-glib
+ 
+   https://gitlab.com/libvirt/libvirt-glib/pipelines";>
+ https://gitlab.com/libvirt/libvirt-glib/badges/master/pipeline.svg"/>
+   
+ 
+   
+   
+ libvirt-go-xml
+ 
+   https://gitlab.com/libvirt/libvirt-go-xml/pipelines";>
+ https://gitlab.com/libvirt/libvirt-go-xml/badges/master/pipeline.svg"/>
+   
+ 
+   
+   
+ libvirt-snmp
+ 
+   https://gitlab.com/libvirt/libvirt-snmp/pipelines";>
+ https://gitlab.com/libvirt/libvirt-snmp/badges/master/pipeline.svg"/>
+   
+ 
+   
+   
+ Testing
+   
+   
+ libvirt-ci
+ 
+   https://gitlab.com/libvirt/libvirt-ci/pipelines";>
+ https://gitlab.com/libvirt/libvirt-ci/badges/master/pipeline.svg"/>
+   
+ 
+   
+   
+ libvirt-dockerfiles
+ 

Re: [PATCH] virsh: Fix return code for dump

[Andrea Bolognani]

On Mon, 2020-05-04 at 14:19 +0200, Michal Privoznik wrote:
> I'm in the middle of review too. But I find !data.ret a bit confusing. 
> The function is returning a boolean and not a pointer or an int. So how 
> about 'return data.ret != 0'? I know John was against using 'if (!int)' 
> and it kind of makes sense.
> 
> Or even better, we can use our regular pattern and keep @ret, and do 
> something like:
> 
> if (data.ret < 0)
>goto cleanup;
> 
> vshPrintExtra()
> ret = true;
> ...
> return ret;

Yeah I don't like it either, but if you look at the rest of the file
there are multiple occurrences of the same pattern, which we should
address as well.

I will push the minimal fix for now, so that it can make it into
6.3.0; afterwards, someone can post a patch that removes the pattern
from the entire file.

-- 
Andrea Bolognani / Red Hat / Virtualization

Re: [PATCH] virsh: Fix return code for dump

[Michal Privoznik]

On 5/4/20 2:09 PM, Andrea Bolognani wrote:

On Mon, 2020-05-04 at 09:48 +, Xuyandong (Yandong Xu) wrote:

+++ b/tools/virsh-domain.c
@@ -5522,7 +5522,6 @@ static bool
  cmdDump(vshControl *ctl, const vshCmd *cmd)
  {
  virDomainPtr dom;
-bool ret = false;
  bool verbose = false;
  const char *name = NULL;
  const char *to = NULL;
@@ -5556,12 +,12 @@ cmdDump(vshControl *ctl, const vshCmd *cmd)
  
  virThreadJoin(&workerThread);
  
-if (!ret)

+if (!data.ret)
  vshPrintExtra(ctl, _("\nDomain %s dumped to %s\n"), name, to);
  
   cleanup:

  virshDomainFree(dom);
-return !ret;
+return !data.ret;
  }


This is in the same vein as fbc4e81a36d1, and I think we should
definitely squeeze it in before release, so that's a

   Signed-off-by: Andrea Bolognani 

from me. Dan, what do you think?



I'm in the middle of review too. But I find !data.ret a bit confusing. 
The function is returning a boolean and not a pointer or an int. So how 
about 'return data.ret != 0'? I know John was against using 'if (!int)' 
and it kind of makes sense.


Or even better, we can use our regular pattern and keep @ret, and do 
something like:


if (data.ret < 0)
  goto cleanup;

vshPrintExtra()
ret = true;
...
return ret;


This is something that is perfectly fixable by committer, so no need to 
resend. I too agree that this is something that needs fixing and the 
sooner we fix it the better.


Reviewed-by: Michal Privoznik 

Michal

Re: [PATCH] virsh: Fix return code for dump

[Daniel P . Berrangé]

On Mon, May 04, 2020 at 02:09:02PM +0200, Andrea Bolognani wrote:
> On Mon, 2020-05-04 at 09:48 +, Xuyandong (Yandong Xu) wrote:
> > +++ b/tools/virsh-domain.c
> > @@ -5522,7 +5522,6 @@ static bool
> >  cmdDump(vshControl *ctl, const vshCmd *cmd)
> >  {
> >  virDomainPtr dom;
> > -bool ret = false;
> >  bool verbose = false;
> >  const char *name = NULL;
> >  const char *to = NULL;
> > @@ -5556,12 +,12 @@ cmdDump(vshControl *ctl, const vshCmd *cmd)
> >  
> >  virThreadJoin(&workerThread);
> >  
> > -if (!ret)
> > +if (!data.ret)
> >  vshPrintExtra(ctl, _("\nDomain %s dumped to %s\n"), name, to);
> >  
> >   cleanup:
> >  virshDomainFree(dom);
> > -return !ret;
> > +return !data.ret;
> >  }
> 
> This is in the same vein as fbc4e81a36d1, and I think we should
> definitely squeeze it in before release, so that's a
> 
>   Signed-off-by: Andrea Bolognani 
> 
> from me. Dan, what do you think?

Agreed,

Reviewed-by: Daniel P. Berrangé 

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 :|

Re: [PATCH] virsh: Fix return code for dump

[Andrea Bolognani]

On Mon, 2020-05-04 at 09:48 +, Xuyandong (Yandong Xu) wrote:
> +++ b/tools/virsh-domain.c
> @@ -5522,7 +5522,6 @@ static bool
>  cmdDump(vshControl *ctl, const vshCmd *cmd)
>  {
>  virDomainPtr dom;
> -bool ret = false;
>  bool verbose = false;
>  const char *name = NULL;
>  const char *to = NULL;
> @@ -5556,12 +,12 @@ cmdDump(vshControl *ctl, const vshCmd *cmd)
>  
>  virThreadJoin(&workerThread);
>  
> -if (!ret)
> +if (!data.ret)
>  vshPrintExtra(ctl, _("\nDomain %s dumped to %s\n"), name, to);
>  
>   cleanup:
>  virshDomainFree(dom);
> -return !ret;
> +return !data.ret;
>  }

This is in the same vein as fbc4e81a36d1, and I think we should
definitely squeeze it in before release, so that's a

  Signed-off-by: Andrea Bolognani 

from me. Dan, what do you think?

-- 
Andrea Bolognani / Red Hat / Virtualization

Re: [libvirt PATCH] tests: Mock virGetUserRuntimeDirectory() for qemuhotplug

[Michal Privoznik]

On 5/1/20 2:30 PM, Andrea Bolognani wrote:

Not mocking this function results in files being created in the
user's home directory when running the test and in the build
failing altogether inside a constrained environment such as the
one used by pbuilder:

   Could not initialize HostdevManager - operation failed: Failed
   to create state dir '/nonexistent/.cache/libvirt/hostdevmgr'

Signed-off-by: Andrea Bolognani 
---
  tests/qemuhotplugmock.c | 9 +
  1 file changed, 9 insertions(+)

diff --git a/tests/qemuhotplugmock.c b/tests/qemuhotplugmock.c
index d2324913cf..27c81670a3 100644
--- a/tests/qemuhotplugmock.c
+++ b/tests/qemuhotplugmock.c
@@ -27,6 +27,7 @@
  
  static int (*real_virGetDeviceID)(const char *path, int *maj, int *min);

  static bool (*real_virFileExists)(const char *path);
+static char *(*real_virGetUserRuntimeDirectory)(void);
  
  static void

  init_syms(void)
@@ -36,6 +37,7 @@ init_syms(void)
  
  VIR_MOCK_REAL_INIT(virGetDeviceID);

  VIR_MOCK_REAL_INIT(virFileExists);
+VIR_MOCK_REAL_INIT(virGetUserRuntimeDirectory);
  }
  
  unsigned long long

@@ -106,3 +108,10 @@ void
  qemuProcessKillManagedPRDaemon(virDomainObjPtr vm G_GNUC_UNUSED)
  {
  }
+
+char *
+virGetUserRuntimeDirectory(void)
+{
+return g_build_filename(g_getenv("LIBVIRT_FAKE_ROOT_DIR"),
+"user-runtime-directory", NULL);
+}



While the qemuhotplugtest is (currently) the only one that actually uses 
the runtimedir, this function is called basically from every qemu* test 
because (almost?) every qemu* test calls virQEMUDriverConfigNew(). 
Therefore I think we need to fix qemuTestDriverInit() too so that after 
it call ConfigNew() the path is replaced with some known value.


Michal

[PATCH] virsh: Fix return code for dump

[Xuyandong (Yandong Xu)]

>From 4899d04fab878d5a0e13f01b8b137af233bc7d33 Mon Sep 17 00:00:00 2001
From: Xu Yandong 
Date: Mon, 4 May 2020 16:36:19 +0800
Subject: [PATCH] virsh: Fix return code for dump

After the commit dc0771c, ret variable no longer
represents the status of the return code, use
data->ret replace it.

Signed-off-by: Xu Yandong 
---
 tools/virsh-domain.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/tools/virsh-domain.c b/tools/virsh-domain.c
index 0704529458..61cd72f714 100644
--- a/tools/virsh-domain.c
+++ b/tools/virsh-domain.c
@@ -5522,7 +5522,6 @@ static bool
 cmdDump(vshControl *ctl, const vshCmd *cmd)
 {
 virDomainPtr dom;
-bool ret = false;
 bool verbose = false;
 const char *name = NULL;
 const char *to = NULL;
@@ -5556,12 +,12 @@ cmdDump(vshControl *ctl, const vshCmd *cmd)
 
 virThreadJoin(&workerThread);
 
-if (!ret)
+if (!data.ret)
 vshPrintExtra(ctl, _("\nDomain %s dumped to %s\n"), name, to);
 
  cleanup:
 virshDomainFree(dom);
-return !ret;
+return !data.ret;
 }
 
 static const vshCmdInfo info_screenshot[] = {
-- 
2.21.0

Re: [PATCH 0/2] qemucapabilitiesdata: Update qemu-5.0 data after release and add qemu-5.1

[Ján Tomko]

On a Thursday in 2020, Peter Krempa wrote:

Peter Krempa (2):
 qemucapabilitiesdata: Update x86_64 capabilities to 5.0.0 release
 qemucapabilitiesdata: Add test data for x86_64 for the qemu-5.1 dev
   cycle

.../domaincapsdata/qemu_5.1.0-q35.x86_64.xml  |   194 +
.../domaincapsdata/qemu_5.1.0-tcg.x86_64.xml  |   197 +
tests/domaincapsdata/qemu_5.1.0.x86_64.xml|   194 +
.../caps_5.0.0.x86_64.replies | 8 +-
.../caps_5.0.0.x86_64.xml | 4 +-
.../caps_5.1.0.x86_64.replies | 28830 
.../caps_5.1.0.x86_64.xml |  3016 ++
7 files changed, 32437 insertions(+), 6 deletions(-)
create mode 100644 tests/domaincapsdata/qemu_5.1.0-q35.x86_64.xml
create mode 100644 tests/domaincapsdata/qemu_5.1.0-tcg.x86_64.xml
create mode 100644 tests/domaincapsdata/qemu_5.1.0.x86_64.xml
create mode 100644 tests/qemucapabilitiesdata/caps_5.1.0.x86_64.replies
create mode 100644 tests/qemucapabilitiesdata/caps_5.1.0.x86_64.xml



Reviewed-by: Ján Tomko 

Jano


signature.asc
Description: PGP signature

Re: Backup of vm disk images

[Kashyap Chamarthy]

On Fri, May 01, 2020 at 04:05:47PM +0100, Stefan Hajnoczi wrote:
> On Wed, Apr 22, 2020 at 07:51:09AM +0200, Anders Östling wrote:

Hi Anders,

> > I am fighting to understand the difference between backing up a VM by
> > using a regular copy vs using the virsh blockcopy command.

tl;dr: While 'blockcopy' is one way to do a full backup; there's a
   better way: 'blockcommit'; see below for a URL to an example.

To add to what Stefan says below, here's the difference: a regular 'cp'
is just that — an offline copy when your guest is shutdown or suspended.
However, libvirt's 'blockcopy' lets you create a "point-in-time snapshot
[or copy]" of your VM's disk _while_ the VM is running, and optionally,
lets your VM to "live-pivot" its storage to the just-created copy.

The use-case is "live storage migration".  

Say, your original storage of your VM is on NFS-A, but you want to do
some maintenance on NFS-A.  Here, 'blockcopy' lets you live-copy the
VM's storage from NFS-A to NFS-B, _and_ make the VM use the copy — all
this without causing any downtime to the users of the VM.  Now you can
freely do the maintenance on NFS-A.

A 'blockcopy' operation has two phases:

(1) It copies a VM's disk image, e.g. from 'orig.raw' to 'copy.qcow2',
while the VM is running.  And it will _keep_ copying as long as your
VM keeps writing new data.  This is called the "mirroring" phase.

(2) Once the copy.qcow2 has the same content as orig.raw, then you can
do two things, either (a) end the copying/mirroring, which results
in a point-in-time 'snapshot' of the orig.raw; or (b) you can
"live-pivot" the VM's disk image to just-created copy.qcow2.

Management tools like OpenStack (and possibly others) use libvirt's
'blockcopy' API under the hood to allow live storage migration.

There are other useful details here, but I'll skip them for brevity.
Read the "blockcopy" section in `man virsh`.  I admit it can be a little
hard to parse when you normally don't dwell on these matters, but taking
time to experiement gives a robust understanding.

> > What I want to do is to suspend the vm, copy the XML and .QCOW2 files
> > and then resume the vm again. What are your thoughts? What are the
> > drawbacks compared to other methods?

If your main goal is to take a full backup of your disk, *without* any
downtime to your VM, libvirt does provide some neat ways.

One of the most efficient methods to is the so-called "active
block-commit".  It uses a combination of libvirt commands: `virsh
snapshot-create-as`, `virsh blockcommit`, and `rsync`:
   
I've written up a full example here:

https://wiki.libvirt.org/page/Live-disk-backup-with-active-blockcommit

You might also want to refer to this page.

https://wiki.libvirt.org/page/Live-disk-backup-with-active-blockcommit

- - -

For libvirt-based incremental backup examples, I'll defer that to Eric
Blake (in Cc).

[...]

> A naive cp(1) command will be very slow because the entire disk image is
> copied to a new file.  The fastest solution with cp(1) is the --reflink
> flag which basically takes a snapshot of the file and shares the disk
> blocks (only available when the host file system supports it and not
> available across mounts).
> 
> Libvirt's backup commands are more powerful.  They can do things like
> copy out a point-in-time snapshot of the disk while the guest is
> running.  They also support incremental backup so you don't need to
> store a full copy of the disk image each time you take a backup.
> 
> I hope others will join the discussion and give examples of some of the
> available features.


-- 
/kashyap

Re: [PATCH] systemd: start libvirtd after firewalld/iptables services

[Daniel P . Berrangé]

On Mon, May 04, 2020 at 09:48:58AM +0200, Andrea Bolognani wrote:
> On Sun, 2020-05-03 at 15:14 -0400, Laine Stump wrote:
> > +++ b/src/remote/libvirtd.service.in
> > @@ -11,6 +11,9 @@ Wants=libvirtd-admin.socket
> >  Wants=systemd-machined.service
> >  Before=libvirt-guests.service
> >  After=network.target
> > +After=firewalld.service
> > +After=iptables.service
> > +After=ip6tables.service
> 
> This looks entirely reasonable to me, but shouldn't the same change
> be applied to src/network/virtnetworkd.service.in as well?

Yes.

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 :|

Re: [libvirt-ci PATCH 2/2] containers: add a standard container for running go fmt

[Daniel P . Berrangé]

On Mon, May 04, 2020 at 09:30:53AM +0200, Martin Kletzander wrote:
> On Fri, May 01, 2020 at 12:03:02PM +0100, Daniel P. Berrangé wrote:
> > On Fri, May 01, 2020 at 11:52:32AM +0100, Daniel P. Berrangé wrote:
> > > The "go fmt" code style checking tool is something we wish to run on all
> > > Go code, so it is useful to have a common container that can be used by
> > > all relevant projects.
> > > 
> > > Signed-off-by: Daniel P. Berrangé 
> > > ---
> > >  .gitlab-ci.yml   |  5 +
> > >  containers/go-fmt/Dockerfile |  9 +
> > >  containers/go-fmt/README.rst | 20 
> > >  containers/go-fmt/go-fmt.sh  | 24 
> > >  4 files changed, 58 insertions(+)
> > >  create mode 100644 containers/go-fmt/Dockerfile
> > >  create mode 100644 containers/go-fmt/README.rst
> > >  create mode 100755 containers/go-fmt/go-fmt.sh
> > > 
> > > diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
> > > index a1ac31a..080c8d1 100644
> > > --- a/.gitlab-ci.yml
> > > +++ b/.gitlab-ci.yml
> > > @@ -22,6 +22,11 @@ check-dco-container:
> > >variables:
> > >  NAME: check-dco
> > > 
> > > +go-fmt-container:
> > > +  <<: *build_container_definition
> > > +  variables:
> > > +NAME: go-fmt
> > > +
> > >  # Check that all commits are signed-off for the DCO. Skip
> > >  # on master branch and -maint branches, since we only need
> > >  # to test developer's personal branches.
> > > diff --git a/containers/go-fmt/Dockerfile b/containers/go-fmt/Dockerfile
> > > new file mode 100644
> > > index 000..9079fea
> > > --- /dev/null
> > > +++ b/containers/go-fmt/Dockerfile
> > > @@ -0,0 +1,9 @@
> > > +FROM golang:1.14
> > > +
> > > +RUN export DEBIAN_FRONTEND=noninteractive && \
> > > +apt-get update && \
> > > +apt-get install --no-install-recommends -y \
> > > +diffstat && \
> > > +apt-get autoclean -y
> > > +
> > > +COPY go-fmt.sh /go-fmt
> > > diff --git a/containers/go-fmt/README.rst b/containers/go-fmt/README.rst
> > > new file mode 100644
> > > index 000..0af6998
> > > --- /dev/null
> > > +++ b/containers/go-fmt/README.rst
> > > @@ -0,0 +1,20 @@
> > > +=
> > > +Container for running go fmt code style check
> > > +=
> > > +
> > > +This container provides a simple way to invoke ``go fmt`` to validate 
> > > code
> > > +style across a Golang codebase. It should be integrated into a CI by 
> > > adding
> > > +the following snippet to ``.gitlab-ci.yml``
> > > +
> > > +::
> > > +
> > > +   go-fmt:
> > > + stage: prebuild
> > > + image: registry.gitlab.com/libvirt/libvirt-ci/go-fmt:master
> > > + script:
> > > +   - /go-fmt
> > > + artifacts:
> > > +   paths:
> > > + - go-fmt.patch
> > > +   expire_in: 1 week
> > > +   when: on_failure
> > > diff --git a/containers/go-fmt/go-fmt.sh b/containers/go-fmt/go-fmt.sh
> > > new file mode 100755
> > > index 000..9fda79d
> > > --- /dev/null
> > > +++ b/containers/go-fmt/go-fmt.sh
> > > @@ -0,0 +1,24 @@
> > > +#!/bin/sh
> > > +
> > > +GOFMT=$(go env GOROOT)/bin/gofmt
> > > +
> > > +find -name '*.go' | xargs $GOFMT -d -e > go-fmt.patch
> > > +
> > > +if test -n go-fmt.patch
> > 
> > This was supposed to be "-z" not "-n" but I forgot to commit a chunk
> > 
> 
> You mean `-s`, right?  Because `-z` and `-n` operate on strings, not 
> filenames.

Sigh. Yes.  Non-zero file size is what it is supposed to be checking.

> 
> > > +then
> > > +echo
> > > +echo "❌ ERROR: some files failed go fmt code style check"
> > > +echo
> > > +diffstat go-fmt.patch
> > > +echo
> > > +echo "See the go-fmt patch artifact for full details of mistakes."
> > > +echo
> > > +echo "For guidance on how to configure Emacs or Vim to automatically"
> > > +echo "run go fmt when saving files read"
> > > +echo
> > > +echo " https://blog.golang.org/gofmt";
> > > +echo
> > > +exit 1
> > > +fi
> > > +
> > > +echo "✔ OK: all files passed go fmt code style check"
> > > --
> > > 2.25.4
> > > 
> > 
> > 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 
> > :|
> > 



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 :|

Re: [PATCH v4 00/34] Configurable policy for handling deprecated interfaces

[Peter Krempa]

On Tue, Mar 17, 2020 at 12:54:25 +0100, Markus Armbruster wrote:
> This series extends QMP introspection to cover deprecation.
> Additionally, new option -compat lets you configure what to do when
> deprecated interfaces get used.  This is intended for testing users of
> the management interfaces.  It is experimental.
> 
> -compat deprecated-input= configures what to do when
> deprecated input is received.  Available policies:
> 
> * accept: Accept deprecated commands and arguments (default)
> * reject: Reject them
> * crash: Crash

I've noticed that the 'crash' option doesn't manage to log the reason to
stderr. Relevant section of libvirt's log file which agregates the
stderr/out

2020-04-30 13:24:22.006+: 2072883: debug : virCommandHandshakeChild:418 : 
Handshake with parent is done
char device redirected to /dev/pts/0 (label charserial0)
2020-04-30 13:24:31.879+: Domain id=4 is tainted: custom-monitor
2020-04-30 13:24:32.330+: shutting down, reason=crashed

'handshake' line is last of libvirt's messages pre-start of the qemu
process. 'char device redirected' is reported by qemu. 'domain is
tainted' is added by libvirt when I've issued the deprecated API via
virsh qemu-monitor-command. 'reason=crashed' is added by libvirts VM
shutdown hanlder.

> 
> -compat deprecated-output= configures what to do when
> deprecated output is sent.  Available output policies:
> 
> * accept: Emit deprecated command results and events (default)
> * hide: Suppress them
> 
> For now, -compat covers only deprecated syntactic aspects of QMP.  We
> may want to extend it to cover semantic aspects, CLI, and experimental
> features.
> 
> PATCH 01-04: Documentation fixes
> PATCH 05-10: Test improvements
> PATCH 11-24: Add feature flags to remaining user-defined types and to
>struct members
> PATCH 25-26: New special feature 'deprecated', visible in
>introspection

These are cool. I've added support for verifying that any command
excercised by the libvirt unit test suite is not deprecated, or we at
least know that it is and have a replacement.

https://www.redhat.com/archives/libvir-list/2020-April/msg01444.html

> PATCH 27-34: New -compat to set policy for handling stuff marked with
>feature 'deprecated'

While implementing support for this feature I noticed that it's
impossible for libvirt to detect that it's available. The idea is to
make a developer-centred setting in our config which will enable the
compat setting if available and ignore it if not available to prevent us
having to fiddle with the settings when testing various qemu versions.

Thanks!

Peter

Re: [PATCH] conf: Add qemu_job_wait_time option

[Michal Privoznik]

On 5/4/20 10:07 AM, Peter Krempa wrote:

On Fri, May 01, 2020 at 16:09:04 +0900, MIKI Nobuhiro wrote:

The waiting time to acquire the lock times out, which leads to a segment fault.


Could you please elaborate here? Adding this band-aid is pointless if it
can timeout later. We do want to fix any locking issue but without
information we can't really.


In essence we should make improvements around locks, but as a workaround we
will change the timeout to allow the user to increase it.
This value was defined as 30 seconds, so use it as the default value.
The logs are as follows:

```
Timed out during operation: cannot acquire state change lock \
(held by monitor=remoteDispatchDomainCreateWithFlags)
libvirtd.service: main process exited, code=killed,status=11/SEGV
```


Unfortunately I don't consider this a proper justification for the
change below. Either re-state why you want this, e.g. saying that
shortening time may give users greater feedback, but mentioning that it
works around a crash is not acceptable as a justification for something
which doesn't fix the crash.


Agreed. Allowing users to configure the timeout makes sense - we already 
do that for other timeouts, but if it is masking a real bug we need to 
fix it first. Do you have any steps to reproduce the bug? Are you able 
to get the stack trace from the coredump?





Signed-off-by: MIKI Nobuhiro 
---
  docs/news.xml  | 9 +
  src/qemu/libvirtd_qemu.aug | 1 +
  src/qemu/qemu.conf | 3 +++
  src/qemu/qemu_conf.c   | 3 +++
  src/qemu/qemu_conf.h   | 2 ++
  src/qemu/qemu_domain.c | 7 ++-
  src/qemu/test_libvirtd_qemu.aug.in | 1 +
  7 files changed, 21 insertions(+), 5 deletions(-)

diff --git a/docs/news.xml b/docs/news.xml
index 80819ae..3755c49 100644
--- a/docs/news.xml
+++ b/docs/news.xml
@@ -119,6 +119,15 @@
Bounds Checking) and IBS (Indirect Branch Speculation).
  

+  
+
+  conf: Add job wait time setting to qemu.conf
+
+
+  How many seconds the new job waits for the existing job to finish.
+  This only affects if you are using qemu as driver.
+
+  
  
  
  


Changes to news.xml always must be in a separate commit.


Just a short explanation - this is to ease possible backports. For 
instance, if there is a bug fix in version X, but a distro wants to 
backport it to version X-1 then the news.xml looks completely different 
there and the cherry-pick won't apply cleanly.





diff --git a/src/qemu/libvirtd_qemu.aug b/src/qemu/libvirtd_qemu.aug
index 404498b..76c896e 100644
--- a/src/qemu/libvirtd_qemu.aug
+++ b/src/qemu/libvirtd_qemu.aug
@@ -97,6 +97,7 @@ module Libvirtd_qemu =
   | bool_entry "dump_guest_core"
   | str_entry "stdio_handler"
   | int_entry "max_threads_per_process"
+ | int_entry "qemu_job_wait_time"
  
 let device_entry = bool_entry "mac_filter"

   | bool_entry "relaxed_acs_check"
diff --git a/src/qemu/qemu.conf b/src/qemu/qemu.conf
index abdbf07..a05aaa5 100644
--- a/src/qemu/qemu.conf
+++ b/src/qemu/qemu.conf
@@ -612,6 +612,9 @@
  #
  #max_threads_per_process = 0
  
+# How many seconds the new job waits for the existing job to finish.

+#qemu_job_wait_time = 30
+
  # If max_core is set to a non-zero integer, then QEMU will be
  # permitted to create core dumps when it crashes, provided its
  # RAM size is smaller than the limit set.


Rest of the patch looks good code-wise.



Yes.

Michal

Re: [PATCH] conf: Add qemu_job_wait_time option

[Peter Krempa]

On Fri, May 01, 2020 at 16:09:04 +0900, MIKI Nobuhiro wrote:
> The waiting time to acquire the lock times out, which leads to a segment 
> fault.

Could you please elaborate here? Adding this band-aid is pointless if it
can timeout later. We do want to fix any locking issue but without
information we can't really.

> In essence we should make improvements around locks, but as a workaround we
> will change the timeout to allow the user to increase it.
> This value was defined as 30 seconds, so use it as the default value.
> The logs are as follows:
> 
> ```
> Timed out during operation: cannot acquire state change lock \
>(held by monitor=remoteDispatchDomainCreateWithFlags)
> libvirtd.service: main process exited, code=killed,status=11/SEGV
> ```

Unfortunately I don't consider this a proper justification for the
change below. Either re-state why you want this, e.g. saying that
shortening time may give users greater feedback, but mentioning that it
works around a crash is not acceptable as a justification for something
which doesn't fix the crash.

> Signed-off-by: MIKI Nobuhiro 
> ---
>  docs/news.xml  | 9 +
>  src/qemu/libvirtd_qemu.aug | 1 +
>  src/qemu/qemu.conf | 3 +++
>  src/qemu/qemu_conf.c   | 3 +++
>  src/qemu/qemu_conf.h   | 2 ++
>  src/qemu/qemu_domain.c | 7 ++-
>  src/qemu/test_libvirtd_qemu.aug.in | 1 +
>  7 files changed, 21 insertions(+), 5 deletions(-)
> 
> diff --git a/docs/news.xml b/docs/news.xml
> index 80819ae..3755c49 100644
> --- a/docs/news.xml
> +++ b/docs/news.xml
> @@ -119,6 +119,15 @@
>Bounds Checking) and IBS (Indirect Branch Speculation).
>  
>
> +  
> +
> +  conf: Add job wait time setting to qemu.conf
> +
> +
> +  How many seconds the new job waits for the existing job to finish.
> +  This only affects if you are using qemu as driver.
> +
> +  
>  
>  
>  

Changes to news.xml always must be in a separate commit.

> diff --git a/src/qemu/libvirtd_qemu.aug b/src/qemu/libvirtd_qemu.aug
> index 404498b..76c896e 100644
> --- a/src/qemu/libvirtd_qemu.aug
> +++ b/src/qemu/libvirtd_qemu.aug
> @@ -97,6 +97,7 @@ module Libvirtd_qemu =
>   | bool_entry "dump_guest_core"
>   | str_entry "stdio_handler"
>   | int_entry "max_threads_per_process"
> + | int_entry "qemu_job_wait_time"
>  
> let device_entry = bool_entry "mac_filter"
>   | bool_entry "relaxed_acs_check"
> diff --git a/src/qemu/qemu.conf b/src/qemu/qemu.conf
> index abdbf07..a05aaa5 100644
> --- a/src/qemu/qemu.conf
> +++ b/src/qemu/qemu.conf
> @@ -612,6 +612,9 @@
>  #
>  #max_threads_per_process = 0
>  
> +# How many seconds the new job waits for the existing job to finish.
> +#qemu_job_wait_time = 30
> +
>  # If max_core is set to a non-zero integer, then QEMU will be
>  # permitted to create core dumps when it crashes, provided its
>  # RAM size is smaller than the limit set.

Rest of the patch looks good code-wise.

Re: Backup of vm disk images

[Peter Krempa]

On Fri, May 01, 2020 at 16:05:47 +0100, Stefan Hajnoczi wrote:
> On Wed, Apr 22, 2020 at 07:51:09AM +0200, Anders Östling wrote:
> > I am fighting to understand the difference between backing up a VM by
> > using a regular copy vs using the virsh blockcopy command.
> > What I want to do is to suspend the vm, copy the XML and .QCOW2 files
> > and then resume the vm again. What are your thoughts? What are the
> > drawbacks compared to other methods?

The approaches have diffrerent kind of data integrity they provide and
downtime they require.

Assuming from the above that you don't want to shutdown the OS in the VM
you've got following options:

1) pause VM and copy images as described above
  I definitely don't recommend this approach at all. The drawback is
  that the QCOW2 file on the disk may have inconsistent metadata. Even
  if you ensure that the gues OS state is consistend and written to disk
  it's not guaranteed that qemu's buffers were flushed.

  Also the VM needs to be suspended during the whole copy, unless you
  have the image on a filesystem which has --reflink support as  pointed
  out by Stefan.

2) 'virsh blockcopy'
 The original idea of blockcopy is to move storage of an active VM to a
 different location. It can be used though to "copy" the active disk and
 ensure that the metadata is correct when combined with 'virsh blockjob
 --abort' to finish it. This still requires the guest OS in the VM to
 ensure that the filesystems on the backed-up disk are consistent.

 Also the API has one very severe limitation if your VM has multiple
 disks: There is no way to ensure that you cancel all the copies at the
 same time, so the 'backup' done this way is not taken at a single point
 in time. It's also worth noting that the point in time the backup is
 taken is when the job is --abort-ed.

3) virsh backup
 This is the newest set of APIs specifically designed to do disk backups
 of the VM, offers consistency of the image metadata, and taking of the
 backups of multiple disks at the same point in time. Also the point in
 time is when the API is started, regardless of how long the actual data
 handling takes.

 Your gues OS still needs to ensure filesystem consistency though.

 Additionally as mentioned by Stefan below you can also do incremental
 backups as well.

 One thing to note though is that the backup integration is not entirely
 finished in libvirt and thus in a 'tech-preview' state. Some
 interactions corrupt the state for incremental backups.

 If you are interested, I can give you specific info how to enable
 support for backups as well as the specifics of the current state of
 implementation.

4) snapshots
 Libvirt's snapshot implementation supports taking full VM snapshots
 including memory and disk image state. This sidesteps the problem of
 inconsistent filesystem state as the memory state contains also all the
 buffers.

 When an external snapshot is created, we add a new set of overlay files
 on top of the original disk images. This means that they become
 effectively read-only. You can then copy them aside if you want so. The
 memory image taken along can be then used to fully restore the state of
 the VM.

 There are a few caveats here as well. If the image chain created this
 way becomes too long it may negatively impact performance. Also
 reverting the memory image is a partially manual operation for now. I
 can give specifics if you want.

> 
> Hi Anders,
> The k...@vger.kernel.org mailing list is mostly for the discussion and
> development of the KVM kernel module so you may not get replies.  I have
> CCed libvir-list and developers who have been involved in libvirt backup
> features.
> 
> A naive cp(1) command will be very slow because the entire disk image is
> copied to a new file.  The fastest solution with cp(1) is the --reflink
> flag which basically takes a snapshot of the file and shares the disk
> blocks (only available when the host file system supports it and not
> available across mounts).
> 
> Libvirt's backup commands are more powerful.  They can do things like
> copy out a point-in-time snapshot of the disk while the guest is
> running.  They also support incremental backup so you don't need to
> store a full copy of the disk image each time you take a backup.
> 
> I hope others will join the discussion and give examples of some of the
> available features.
> 
> Stefan

Re: [libvirt PATCHv2] docs: note that was added in libvirt 5.6.0

[Andrea Bolognani]

On Sun, 2020-05-03 at 15:18 -0400, Laine Stump wrote:
> +++ b/docs/formatnetwork.html.in
> @@ -1124,9 +1124,11 @@
>  Network namespaces
>  
>  
> -  A special XML namespace is available for passing options directly to 
> the
> -  underlying dnsmasq configuration file. Usage of XML namespaces comes 
> with no
> -  support guarantees, so use at your own risk.
> +  A special XML namespace is available for passing options
> +  directly to the underlying dnsmasq configuration
> +  file Since 5.6.0. Usage of XML
> +  namespaces comes with no support guarantees, so use at your own
> +  risk.

I think s/Since/since/ would work better in this specific scenario.

Regardless,

  Reviewed-by: Andrea Bolognani 

and safe for freeze.

-- 
Andrea Bolognani / Red Hat / Virtualization

Re: [PATCH] systemd: start libvirtd after firewalld/iptables services

[Andrea Bolognani]

On Sun, 2020-05-03 at 15:14 -0400, Laine Stump wrote:
> +++ b/src/remote/libvirtd.service.in
> @@ -11,6 +11,9 @@ Wants=libvirtd-admin.socket
>  Wants=systemd-machined.service
>  Before=libvirt-guests.service
>  After=network.target
> +After=firewalld.service
> +After=iptables.service
> +After=ip6tables.service

This looks entirely reasonable to me, but shouldn't the same change
be applied to src/network/virtnetworkd.service.in as well?

-- 
Andrea Bolognani / Red Hat / Virtualization

Re: [PATCH] news: Update for libvirt 6.3.0

[Andrea Bolognani]

On Mon, 2020-05-04 at 09:16 +0200, Michal Privoznik wrote:
[...]
> +  
> +
> +  qemu: Allow checkpoint redefine for offline VMs
> +
> +
> +  Skip the liveness and capability checks when redefining 
> checkpoints as
> +  we don't need qemu interactions to update the metadata.

s/qemu/QEMU/

[...]
> +  
> +
> +  daemons: Improve timeout handling
> +
> +
> +  Daemons now support  --timeout 0  which suppresses 
> daemon
> +  killing after given time of inactivity.

Extra whitespace inside the  element.

[...]
> +  
> +
> +  qemu: add support for 'multidevs' option

s/add/Add/

[...]
> +  
> +
> +  Distinguish Cascadelake-Server from Skylake-Server

s/Distinguish/cpu: Distinguish/

[...]
> +  
> +
> +  node_device_udev: handle move events

s/handle/Handle/


With these nits addressed,

  Reviewed-by: Andrea Bolognani 

and safe for freeze.


Thank you *so much* for taking care of this!

-- 
Andrea Bolognani / Red Hat / Virtualization

Re: [PATCH] systemd: start libvirtd after firewalld/iptables services

[Michal Privoznik]

On 5/3/20 9:14 PM, Laine Stump wrote:

When a system has enabled the iptables/ip6tables services rather than
firewalld, there is no explicit ordering of the start of those
services vs. libvirtd. This creates a problem when libvirtd.service is
started before ip[6]tables, as the latter, when it finally is started,
will remove all of the iptables rules that had previously been added
by libvirt, including the custom chains where libvirt's rules are
kept. This results in an error message similar to the following when a
user subsequently tries to start a new libvirt network:

  "Error while activating network: Call to virNetworkCreate failed:
  internal error: Failed to apply firewall rules
  /usr/sbin/ip6tables -w --table filter --insert LIBVIRT_FWO \
--in-interface virbr2 --jump REJECT:
  ip6tables: No chain/target/match by that name."

(Prior to logging this error, it also would have caused failure to
forward (or block) traffic in some cases, e.g. for guests on a NATed
network, since libvirt's rules to forward/block had all been deleted
and libvirt didn't know about it, so it couldn't fix the problem)

When this happens, the problem can be remedied by simply restarting
libvirtd.service (which has the side-effect of reloading all
libvirt-generated firewall rules)

Instead, we can just explicitly stating in the libvirtd.service file
that libvirtd.service should start after ip6tables.service and
ip6tables.service, eliminating the race condition that leads to the
error.

There is also nothing (that I can see) in the systemd .service files
to guarantee that firewalld.service will be started (if enabled) prior
to libvirtd.service. The same error scenario given above would occur
if libvirtd.service started before firewalld.service.  Even before
that, though libvirtd would have detected that firewalld.service was
disabled, and then turn off all firewalld support. So, for example,
firewalld's libvirt zone wouldn't be used, and most likely traffic
from guests would therefore be blocked (all with no external
indication of the source of the problem other than a debug-level log
when libvirtd was started saying that firewalld wasn't in use); also
libvirtd wouldn't notice when firewalld reloaded its rules (which also
simultaneously deletes all of libvirt's rules).

I'm not aware of any reports that have been traced back to
libvirtd.service starting before firewalld.service, but have seen that
error reported multiple times, and also don't see an existing
dependency that would guarantee firewalld.service starts before
libvirtd.service, so it's possible it's been happening and we just
haven't gotten to the bottom of it.

This patch adds an After= line to the libvirtd.service file for each
of iptables.service, ip6tables.service, and firewalld.servicee, which
should guarantee that libvirtd.service isn't started until systemd has
started whichever of the others is enabled.

This race was diagnosed, and patch proposed, by Jason Montleon in
https://bugzilla.redhat.com/1723698 . At the time (April 2019) danpb
agreed with him that this change to libvirtd.service was a reasonable
thing to do, but I guess everyone thought someone else was going to
post a patch, so in the end nobody did.

Signed-off-by: Laine Stump 
---
  src/remote/libvirtd.service.in | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/src/remote/libvirtd.service.in b/src/remote/libvirtd.service.in
index 90b2cad5b0..cc0d4e3693 100644
--- a/src/remote/libvirtd.service.in
+++ b/src/remote/libvirtd.service.in
@@ -11,6 +11,9 @@ Wants=libvirtd-admin.socket
  Wants=systemd-machined.service
  Before=libvirt-guests.service
  After=network.target
+After=firewalld.service
+After=iptables.service
+After=ip6tables.service
  After=dbus.service
  After=iscsid.service
  After=apparmor.service



Reviewed-by: Michal Privoznik 

and safe for freeze.

Michal

Re: [libvirt-ci PATCH 2/2] containers: add a standard container for running go fmt

[Martin Kletzander]

On Fri, May 01, 2020 at 12:03:02PM +0100, Daniel P. Berrangé wrote:

On Fri, May 01, 2020 at 11:52:32AM +0100, Daniel P. Berrangé wrote:

The "go fmt" code style checking tool is something we wish to run on all
Go code, so it is useful to have a common container that can be used by
all relevant projects.

Signed-off-by: Daniel P. Berrangé 
---
 .gitlab-ci.yml   |  5 +
 containers/go-fmt/Dockerfile |  9 +
 containers/go-fmt/README.rst | 20 
 containers/go-fmt/go-fmt.sh  | 24 
 4 files changed, 58 insertions(+)
 create mode 100644 containers/go-fmt/Dockerfile
 create mode 100644 containers/go-fmt/README.rst
 create mode 100755 containers/go-fmt/go-fmt.sh

diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index a1ac31a..080c8d1 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -22,6 +22,11 @@ check-dco-container:
   variables:
 NAME: check-dco

+go-fmt-container:
+  <<: *build_container_definition
+  variables:
+NAME: go-fmt
+
 # Check that all commits are signed-off for the DCO. Skip
 # on master branch and -maint branches, since we only need
 # to test developer's personal branches.
diff --git a/containers/go-fmt/Dockerfile b/containers/go-fmt/Dockerfile
new file mode 100644
index 000..9079fea
--- /dev/null
+++ b/containers/go-fmt/Dockerfile
@@ -0,0 +1,9 @@
+FROM golang:1.14
+
+RUN export DEBIAN_FRONTEND=noninteractive && \
+apt-get update && \
+apt-get install --no-install-recommends -y \
+diffstat && \
+apt-get autoclean -y
+
+COPY go-fmt.sh /go-fmt
diff --git a/containers/go-fmt/README.rst b/containers/go-fmt/README.rst
new file mode 100644
index 000..0af6998
--- /dev/null
+++ b/containers/go-fmt/README.rst
@@ -0,0 +1,20 @@
+=
+Container for running go fmt code style check
+=
+
+This container provides a simple way to invoke ``go fmt`` to validate code
+style across a Golang codebase. It should be integrated into a CI by adding
+the following snippet to ``.gitlab-ci.yml``
+
+::
+
+   go-fmt:
+ stage: prebuild
+ image: registry.gitlab.com/libvirt/libvirt-ci/go-fmt:master
+ script:
+   - /go-fmt
+ artifacts:
+   paths:
+ - go-fmt.patch
+   expire_in: 1 week
+   when: on_failure
diff --git a/containers/go-fmt/go-fmt.sh b/containers/go-fmt/go-fmt.sh
new file mode 100755
index 000..9fda79d
--- /dev/null
+++ b/containers/go-fmt/go-fmt.sh
@@ -0,0 +1,24 @@
+#!/bin/sh
+
+GOFMT=$(go env GOROOT)/bin/gofmt
+
+find -name '*.go' | xargs $GOFMT -d -e > go-fmt.patch
+
+if test -n go-fmt.patch


This was supposed to be "-z" not "-n" but I forgot to commit a chunk



You mean `-s`, right?  Because `-z` and `-n` operate on strings, not filenames.


+then
+echo
+echo "❌ ERROR: some files failed go fmt code style check"
+echo
+diffstat go-fmt.patch
+echo
+echo "See the go-fmt patch artifact for full details of mistakes."
+echo
+echo "For guidance on how to configure Emacs or Vim to automatically"
+echo "run go fmt when saving files read"
+echo
+echo " https://blog.golang.org/gofmt";
+echo
+exit 1
+fi
+
+echo "✔ OK: all files passed go fmt code style check"
--
2.25.4



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 :|



signature.asc
Description: PGP signature

Re: [libvirt PATCH 2/2] CONTRIBUTING: Include note about build system tools

[Andrea Bolognani]

On Wed, 2020-04-29 at 10:43 +0200, Andrea Bolognani wrote:
> On Mon, 2020-04-27 at 14:01 +0200, Andrea Bolognani wrote:
> > On Mon, 2020-04-27 at 12:19 +0100, Daniel P. Berrangé wrote:
> > > Just listing the extra packages is simpler than the group name.
> > > 
> > >dnf install gcc make automake libtool autoconf rpm-build
> > 
> > Point taken, the list is short and unlikely to change much.
> > 
> > Can I have your Reviewed-by for the series if I squash your version
> > in?
> 
> So, does that sound like a plan? I'd rather not have this very
> simple documentation patch linger on the list for too long :)

ping

-- 
Andrea Bolognani / Red Hat / Virtualization

[PATCH] news: Update for libvirt 6.3.0

[Michal Privoznik]

Signed-off-by: Michal Privoznik 
---
 docs/news.xml | 74 +++
 1 file changed, 74 insertions(+)

diff --git a/docs/news.xml b/docs/news.xml
index 80819aec23..986e7ca5f8 100644
--- a/docs/news.xml
+++ b/docs/news.xml
@@ -121,8 +121,82 @@
   
 
 
+  
+
+  qemu: Allow checkpoint redefine for offline VMs
+
+
+  Skip the liveness and capability checks when redefining checkpoints 
as
+  we don't need qemu interactions to update the metadata.
+
+  
+  
+
+  daemons: Improve timeout handling
+
+
+  Daemons now support  --timeout 0  which suppresses 
daemon
+  killing after given time of inactivity.
+
+  
+  
+
+  qemu: add support for 'multidevs' option
+
+
+  This option prevents misbehaviours on guest if a QEMU 9pfs export
+  contains multiple devices, due to the potential file ID collisions
+  this otherwise may cause.
+
+  
 
 
+  
+
+  qemu: Various embed driver fixes
+
+
+  When using shared resources from embed driver (e.g. hugepages,
+  machined, etc.) libvirt now generates an unique handler that is not
+  conflicting with other embed drivers or system or session daemons.
+
+  
+  
+
+  Distinguish Cascadelake-Server from Skylake-Server
+
+
+  Libvirt now properly detects Cascadelake-Server and Skylake-Server
+  processors which differ only in stepping.
+
+  
+  
+
+  qemu: Fix domain restore from a block device
+
+
+  When using namespaces, libvirt was unable to restore a domain from a
+  block device because libvirt tried to relabel the device inside the
+  namespace while QEMU was given FD to the block device in the host.
+
+  
+  
+
+  node_device_udev: handle move events
+
+
+  Libvirt now handles move event which is emitted on a 
NIC rename.
+
+  
+  
+
+  qemu: Fix capabilities probing with TCG
+
+
+  Libvirt no long assumes TCG is always available. It now detects
+  whether QEMU supports TCG and reports it accordingly.
+
+  
 
 
   
-- 
2.26.2