Re: [libvirt PATCH] gitlab: convert to shared container for DCO check

2020-05-01 Thread Andrea Bolognani 
On Fri, 2020-05-01 at 11:58 +0100, Daniel P. Berrangé wrote:
> This removes the locally maintained DCO checking script in favour of the
> shared containre image provided by libvirt-ci.git.

*container

Reviewed-by: Andrea Bolognani 

-- 
Andrea Bolognani / Red Hat / Virtualization

Re: [libvirt-python PATCH v3 2/3] gitlab: introduce CI jobs testing git master & distro libvirt

2020-05-01 Thread Daniel P . Berrangé 
On Fri, May 01, 2020 at 05:56:23PM +0200, Pavel Hrdina wrote:
> On Fri, May 01, 2020 at 10:20:03AM +0100, Daniel P. Berrangé wrote:
> > The python build needs to validate two axis
> > 
> >  - A variety of libvirt versions
> >  - A variety of python versions
> > 
> > We get coverage for both these axis by running a build against the
> > distro provided libvirt packages. All that is then missing is a build
> > against the latest libvirt git master, which only needs to be run on
> > a single distro, for which CentOS 8 is picked as a stable long life
> > base.
> > 
> > Signed-off-by: Daniel P. Berrangé 
> > ---
> >  .gitlab-ci.yml   | 185 +++
> >  ci/README.rst|  13 ++
> >  ci/libvirt-centos-7.Dockerfile   |  86 +
> >  ci/libvirt-centos-8.Dockerfile   |  64 +
> >  ci/libvirt-debian-10.Dockerfile  |  56 
> >  ci/libvirt-debian-9.Dockerfile   |  59 +
> >  ci/libvirt-debian-sid.Dockerfile |  56 
> >  ci/libvirt-fedora-31.Dockerfile  |  53 
> >  ci/libvirt-fedora-32.Dockerfile  |  53 
> >  ci/libvirt-fedora-rawhide.Dockerfile |  54 
> >  ci/libvirt-opensuse-151.Dockerfile   |  55 
> >  ci/libvirt-ubuntu-1804.Dockerfile|  59 +
> >  ci/libvirt-ubuntu-2004.Dockerfile|  56 
> >  ci/refresh   |  27 
> >  14 files changed, 876 insertions(+)
> >  create mode 100644 .gitlab-ci.yml
> >  create mode 100644 ci/README.rst
> >  create mode 100644 ci/libvirt-centos-7.Dockerfile
> >  create mode 100644 ci/libvirt-centos-8.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
> > new file mode 100644
> > index 000..bc95d41
> > --- /dev/null
> > +++ b/.gitlab-ci.yml
> > @@ -0,0 +1,185 @@
> > +
> > +stages:
> > +  - prebuild
> > +  - containers
> > +  - builds
> > +  - docs
> > +
> > +.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-perl/ci-$NAME:latest"
> 
> This doesn't look right, shouldn't we use libvirt-python here?

Err, yes, of course. This would have meant the cache never matched as
the dockerfile is different. I'll push the obvious fix.


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-devaddr: a new library for device address assignment

2020-05-01 Thread Daniel P . Berrangé 
On Fri, May 01, 2020 at 12:57:54PM -0300, Daniel Henrique Barboza wrote:
> 
> 
> On 5/1/20 7:40 AM, Daniel P. Berrangé wrote:
> > On Thu, Apr 30, 2020 at 09:00:51PM -0300, Daniel Henrique Barboza wrote:
> > > 
> > > My initial plan is to get the logic/APIs design from Libvirt, rename
> > > them in a Gopher fashion, re-code it with Go and call it a day :)
> > 
> > That is really not a way I would like to go, as that means we immediately
> > inherit the design bias of the current libvirt code. The goal is to be
> > able to replace current libvirt code eventually, but I don't want it to
> > just be a clone of that code, as I think it misses the opportunity to
> > try to design something better than what we have done.
> > 
> > As a particular example.. the current placement code has no conceptual
> > model of machine types present in QEMU. We've just got many "if" tests
> > that take different codepaths based on heuristics about the machine
> > type. I would like the new API to have an explicit conceptual model
> > of each machine type we intend to support. ie it should have full
> > representation of the default topology of devices that are mandated
> > by the machine type. Ideally this modelling should be extendable
> > without having to write code in the placement model. ie we should
> > be able to load  a "i440fx.yaml" file describing the i440fx machine
> > type and the placement logic "just works". We should not have any
> > tests like "if (is i440fx)" in the code itself.
> 
> 
> That's a sound idea. I'd say that instead of basing yourselves in the QEMU
> machine types addressing we should aim in implementing he machine 
> specification
> instead, even as a long term goal.
> 
> E.G let's say that Libvirt wants addressing services for a hotplug in a QEMU
> i440fx guest. Instead of devaddr implementing "this is how the i440fx 
> addressing works
> in QEMU", devaddr should be more concerned about "this is how the i440fx 
> processor
> addressing works". If QEMU does additional/different things on top of that 
> then
> qemu_driver.c should operate on that. This allows devaddr to be hypervisor 
> agnostic.

Yes, it was not intended to be tied to QEMU's specific implementation
either. It should be a generic modelling / addressing system.

> > The libvirt code shows us the range of features we need to support at
> > least though.
> 
> I'll see if I can take a look in all the "if (pseries)" in Libvirt device 
> addressing code
> to get an idea of how a PowerPC addressing model would work related to x86.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

Re: libvirt-devaddr: a new library for device address assignment

2020-05-01 Thread Daniel Henrique Barboza 




On 5/1/20 7:40 AM, Daniel P. Berrangé wrote:

On Thu, Apr 30, 2020 at 09:00:51PM -0300, Daniel Henrique Barboza wrote:


My initial plan is to get the logic/APIs design from Libvirt, rename
them in a Gopher fashion, re-code it with Go and call it a day :)


That is really not a way I would like to go, as that means we immediately
inherit the design bias of the current libvirt code. The goal is to be
able to replace current libvirt code eventually, but I don't want it to
just be a clone of that code, as I think it misses the opportunity to
try to design something better than what we have done.

As a particular example.. the current placement code has no conceptual
model of machine types present in QEMU. We've just got many "if" tests
that take different codepaths based on heuristics about the machine
type. I would like the new API to have an explicit conceptual model
of each machine type we intend to support. ie it should have full
representation of the default topology of devices that are mandated
by the machine type. Ideally this modelling should be extendable
without having to write code in the placement model. ie we should
be able to load  a "i440fx.yaml" file describing the i440fx machine
type and the placement logic "just works". We should not have any
tests like "if (is i440fx)" in the code itself.



That's a sound idea. I'd say that instead of basing yourselves in the QEMU
machine types addressing we should aim in implementing he machine specification
instead, even as a long term goal.

E.G let's say that Libvirt wants addressing services for a hotplug in a QEMU
i440fx guest. Instead of devaddr implementing "this is how the i440fx 
addressing works
in QEMU", devaddr should be more concerned about "this is how the i440fx 
processor
addressing works". If QEMU does additional/different things on top of that then
qemu_driver.c should operate on that. This allows devaddr to be hypervisor 
agnostic.





The libvirt code shows us the range of features we need to support at
least though.


I'll see if I can take a look in all the "if (pseries)" in Libvirt device 
addressing code
to get an idea of how a PowerPC addressing model would work related to x86.



DHB



Regards,
Daniel

Re: [libvirt-python PATCH v3 2/3] gitlab: introduce CI jobs testing git master & distro libvirt

2020-05-01 Thread Pavel Hrdina 
On Fri, May 01, 2020 at 10:20:03AM +0100, Daniel P. Berrangé wrote:
> The python build needs to validate two axis
> 
>  - A variety of libvirt versions
>  - A variety of python versions
> 
> We get coverage for both these axis by running a build against the
> distro provided libvirt packages. All that is then missing is a build
> against the latest libvirt git master, which only needs to be run on
> a single distro, for which CentOS 8 is picked as a stable long life
> base.
> 
> Signed-off-by: Daniel P. Berrangé 
> ---
>  .gitlab-ci.yml   | 185 +++
>  ci/README.rst|  13 ++
>  ci/libvirt-centos-7.Dockerfile   |  86 +
>  ci/libvirt-centos-8.Dockerfile   |  64 +
>  ci/libvirt-debian-10.Dockerfile  |  56 
>  ci/libvirt-debian-9.Dockerfile   |  59 +
>  ci/libvirt-debian-sid.Dockerfile |  56 
>  ci/libvirt-fedora-31.Dockerfile  |  53 
>  ci/libvirt-fedora-32.Dockerfile  |  53 
>  ci/libvirt-fedora-rawhide.Dockerfile |  54 
>  ci/libvirt-opensuse-151.Dockerfile   |  55 
>  ci/libvirt-ubuntu-1804.Dockerfile|  59 +
>  ci/libvirt-ubuntu-2004.Dockerfile|  56 
>  ci/refresh   |  27 
>  14 files changed, 876 insertions(+)
>  create mode 100644 .gitlab-ci.yml
>  create mode 100644 ci/README.rst
>  create mode 100644 ci/libvirt-centos-7.Dockerfile
>  create mode 100644 ci/libvirt-centos-8.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
> new file mode 100644
> index 000..bc95d41
> --- /dev/null
> +++ b/.gitlab-ci.yml
> @@ -0,0 +1,185 @@
> +
> +stages:
> +  - prebuild
> +  - containers
> +  - builds
> +  - docs
> +
> +.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-perl/ci-$NAME:latest"

This doesn't look right, shouldn't we use libvirt-python here?

Pavel


signature.asc
Description: PGP signature

Re: Backup of vm disk images

2020-05-01 Thread Stefan Hajnoczi 
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?

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


signature.asc
Description: PGP signature

Re: Entering freeze for libvirt 6.3.0

2020-05-01 Thread Daniel Veillard 
On Fri, May 01, 2020 at 11:04:13AM +0100, Daniel P. Berrangé wrote:
> On Tue, Apr 28, 2020 at 03:25:47PM +0200, Daniel Veillard wrote:
> >   We are getting close to the end of the month, so I tagged RC1 in git
> > and pushed signed source tarball and rpms to the usual place:
> > 
> >https://libvirt.org/sources/
> > 
> > Seems to work fine in my very limited testing, CI seems green except for a
> > couple of mingw tests, so that looks good from a distance.
> > 
> > Please give it some testing, RC2 should land on Thursday, and then if
> > everything looks fine I could push the final version over the coming 
> > week-end.
> > 
> >   Stay safe, please test it,
> 
> Things look pretty quiet - we've only had 1 minor docs fix since rc1
> so far.

  Yup I found that yesterday at the time of pushing rc2 no change so far,
so I decided to skip, and see on Monday where we stand,

  thanks,

Daniel

-- 
Daniel Veillard  | Red Hat Developers Tools http://developer.redhat.com/
veill...@redhat.com  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | virtualization library  http://libvirt.org/

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

2020-05-01 Thread Andrea Bolognani 
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.

-- 
Andrea Bolognani / Red Hat / Virtualization

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

2020-05-01 Thread Daniel P . Berrangé 
On Fri, May 01, 2020 at 02:13:26PM +0100, Daniel P. Berrangé wrote:
> With the introduce of automated CI pipelines, we are now ready to switch

s/introduce/introduction/

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

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-python PATCH] gitlab: add CONTRIBUTING.rst file to indicate use of merge requests

2020-05-01 Thread Daniel P . Berrangé 
With the introduce of automated CI pipelines, we are now ready to switch
to using merge requests for the project. With this switch we longer wish
to have patches sent to the mailing list, and thus the git-publish
config is removed.

Signed-off-by: Daniel P. Berrangé 
---
 .gitpublish  |  4 
 CONTRIBUTING.rst | 28 

This CONTRIBUTING.rst is intentionally fairly generic, as I intend to
reuse it for most other projects too (libvirt.git being the exception
which has far more details).

 2 files changed, 28 insertions(+), 4 deletions(-)
 delete mode 100644 .gitpublish
 create mode 100644 CONTRIBUTING.rst

diff --git a/.gitpublish b/.gitpublish
deleted file mode 100644
index dced716..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..11e3c41
--- /dev/null
+++ b/CONTRIBUTING.rst
@@ -0,0 +1,28 @@
+==
+Contributing to libvirt-python
+==
+
+The libvirt Python API binding accepts code contributions via merge requests
+on the GitLab project:
+
+   https://gitlab.com/libvirt/libvirt-python/-/merge_requests
+
+It is required that automated CI pipelines succeed before a merge request
+will be accepted. The global pipeline status for the ``master`` branch is
+visible at:
+
+   https://gitlab.com/libvirt/libvirt-python/pipelines
+
+CI pipline results for merge requests will be visible via the contributors'
+own private repository fork:
+
+   https://gitlab.com/::YOUR-USER-NAME::/libvirt-python/pipelines
+
+Contributions submitted to the project must be in compliance with the
+Developer Certificate of Origin Version 1.1. This is documented at:
+
+   https://developercertificate.org/
+
+In indicate compliance, each commit in a series must have a "Signed-off-by"
+tag with the submittor's name and email address. This can be added by passing
+the ``-s`` flag to ``git commit`` when creating the patches.
-- 
2.26.2

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

2020-05-01 Thread Daniel P . Berrangé 
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 ? 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 ?

> 
>   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);
> +}
> -- 
> 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 :|

Re: Entering freeze for libvirt 6.3.0

2020-05-01 Thread Andrea Bolognani 
On Fri, 2020-05-01 at 11:04 +0100, Daniel P. Berrangé wrote:
> On Tue, Apr 28, 2020 at 03:25:47PM +0200, Daniel Veillard wrote:
> >   We are getting close to the end of the month, so I tagged RC1 in git
> > and pushed signed source tarball and rpms to the usual place:
> > 
> >https://libvirt.org/sources/
> > 
> > Seems to work fine in my very limited testing, CI seems green except for a
> > couple of mingw tests, so that looks good from a distance.
> > 
> > Please give it some testing, RC2 should land on Thursday, and then if
> > everything looks fine I could push the final version over the coming 
> > week-end.
> > 
> >   Stay safe, please test it,
> 
> Things look pretty quiet - we've only had 1 minor docs fix since rc1
> so far.

It would be great if someone could take a stab at updating the
release notes. They don't look too barren, but I'm sure there's a
bunch of stuff missing nonetheless.

I'm technically not working today, but if someone were to write some
release notes and CC me I'd happily give them a quick review :)

-- 
Andrea Bolognani / Red Hat / Virtualization

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

2020-05-01 Thread Andrea Bolognani 
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);
+}
-- 
2.25.4

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

2020-05-01 Thread Daniel P . Berrangé 
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

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

[libvirt PATCH] gitlab: convert to shared container for DCO check

2020-05-01 Thread Daniel P . Berrangé 
This removes the locally maintained DCO checking script in favour of the
shared containre image provided by libvirt-ci.git.

Signed-off-by: Daniel P. Berrangé 
---
 .gitlab-ci.yml | 21 -
 scripts/require-dco.py | 99 --
 2 files changed, 9 insertions(+), 111 deletions(-)
 delete mode 100755 scripts/require-dco.py

diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 99e7b510c7..3752618b43 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -221,18 +221,15 @@ potfile:
   - libvirt.pot
 
 
-# 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.
-dco:
+# Check that all commits are signed-off for the DCO.
+# Skip on "libvirt" namespace, since we only need to run
+# this test on developer's personal forks from which
+# merge requests are submitted
+check-dco:
   stage: prebuild
-  image: quay.io/libvirt/buildenv-libvirt-fedora-31:latest
-  before_script:
-- *script_variables
+  image: registry.gitlab.com/libvirt/libvirt-ci/check-dco:master
   script:
-- ./scripts/require-dco.py
-  only:
-- branches
+- /check-dco
   except:
-- /^v.*-maint$/
-- master
+variables:
+  - $CI_PROJECT_NAMESPACE == 'libvirt'
diff --git a/scripts/require-dco.py b/scripts/require-dco.py
deleted file mode 100755
index ae94393319..00
--- a/scripts/require-dco.py
+++ /dev/null
@@ -1,99 +0,0 @@
-#!/usr/bin/env python3
-
-# require-dco.py: validate all commits are signed off
-#
-# Copyright (C) 2020 Red Hat, Inc.
-#
-# This library is free software; you can redistribute it and/or
-# modify it under the terms of the GNU Lesser General Public
-# License as published by the Free Software Foundation; either
-# version 2.1 of the License, or (at your option) any later version.
-#
-# This library is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
-# Lesser General Public License for more details.
-#
-# You should have received a copy of the GNU Lesser General Public
-# License along with this library.  If not, see
-# .
-
-import os
-import os.path
-import sys
-import subprocess
-
-cwd = os.getcwd()
-reponame = os.path.basename(cwd)
-repourl = "https://gitlab.com/libvirt/%s.git"; % reponame
-
-subprocess.check_call(["git", "remote", "add", "dcocheck", repourl])
-subprocess.check_call(["git", "fetch", "dcocheck", "master"],
-  stdout=subprocess.DEVNULL,
-  stderr=subprocess.DEVNULL)
-
-ancestor = subprocess.check_output(["git", "merge-base", "dcocheck/master", 
"HEAD"],
-   universal_newlines=True)
-
-ancestor = ancestor.strip()
-
-subprocess.check_call(["git", "remote", "rm", "dcocheck"])
-
-errors = False
-
-print("\nChecking for 'Signed-off-by: NAME ' on all commits since 
%s...\n" % ancestor)
-
-log = subprocess.check_output(["git", "log", "--format=%H %s", ancestor + 
"..."],
-  universal_newlines=True)
-
-if log == "":
-commits = []
-else:
-commits = [[c[0:40], c[41:]] for c in log.strip().split("\n")]
-
-for sha, subject in commits:
-
-msg = subprocess.check_output(["git", "show", "-s", sha],
-  universal_newlines=True)
-lines = msg.strip().split("\n")
-
-print("🔍 %s %s" % (sha, subject))
-sob = False
-for line in lines:
-if "Signed-off-by:" in line:
-sob = True
-if "localhost" in line:
-print("❌ FAIL: bad email in %s" % line)
-errors = True
-
-if not sob:
-print("❌ FAIL missing Signed-off-by tag")
-errors = True
-
-if errors:
-print("""
-
-❌ ERROR: One or more commits are missing a valid Signed-off-By tag.
-
-
-This project requires all contributors to assert that their contributions
-are provided in compliance with the terms of the Developer's Certificate
-of Origin 1.1 (DCO):
-
-  https://developercertificate.org/
-
-To indicate acceptance of the DCO every commit must have a tag
-
-  Signed-off-by: REAL NAME 
-
-This can be achieved by passing the "-s" flag to the "git commit" command.
-
-To bulk update all commits on current branch "git rebase" can be used:
-
-  git rebase -i master -x 'git commit --amend --no-edit -s'
-
-""")
-
-sys.exit(1)
-
-sys.exit(0)
-- 
2.25.4

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

2020-05-01 Thread Daniel P . Berrangé 
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
+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

[libvirt-ci PATCH 1/2] gitlab: rename job for building check-dco container

2020-05-01 Thread Daniel P . Berrangé 
Signed-off-by: Daniel P. Berrangé 
---
 .gitlab-ci.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 6de69d6..a1ac31a 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -17,7 +17,7 @@ stages:
   after_script:
 - docker logout
 
-build-dco:
+check-dco-container:
   <<: *build_container_definition
   variables:
 NAME: check-dco
-- 
2.25.4

[libvirt-ci PATCH 0/2] add a 'go fmt' container for code style checks

2020-05-01 Thread Daniel P . Berrangé 
This common container will be used across all our Go based projects

Daniel P. Berrangé (2):
  gitlab: rename job for building check-dco container
  containers: add a standard container for running go fmt

 .gitlab-ci.yml   |  7 ++-
 containers/go-fmt/Dockerfile |  9 +
 containers/go-fmt/README.rst | 20 
 containers/go-fmt/go-fmt.sh  | 24 
 4 files changed, 59 insertions(+), 1 deletion(-)
 create mode 100644 containers/go-fmt/Dockerfile
 create mode 100644 containers/go-fmt/README.rst
 create mode 100755 containers/go-fmt/go-fmt.sh

-- 
2.25.4

Re: libvirt-devaddr: a new library for device address assignment

2020-05-01 Thread Daniel P . Berrangé 
On Thu, Apr 30, 2020 at 09:00:51PM -0300, Daniel Henrique Barboza wrote:
> 
> My initial plan is to get the logic/APIs design from Libvirt, rename
> them in a Gopher fashion, re-code it with Go and call it a day :)

That is really not a way I would like to go, as that means we immediately
inherit the design bias of the current libvirt code. The goal is to be
able to replace current libvirt code eventually, but I don't want it to
just be a clone of that code, as I think it misses the opportunity to
try to design something better than what we have done.

As a particular example.. the current placement code has no conceptual
model of machine types present in QEMU. We've just got many "if" tests
that take different codepaths based on heuristics about the machine
type. I would like the new API to have an explicit conceptual model
of each machine type we intend to support. ie it should have full
representation of the default topology of devices that are mandated
by the machine type. Ideally this modelling should be extendable
without having to write code in the placement model. ie we should
be able to load  a "i440fx.yaml" file describing the i440fx machine
type and the placement logic "just works". We should not have any
tests like "if (is i440fx)" in the code itself. 

The libvirt code shows us the range of features we need to support at
least though.

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-devaddr: a new library for device address assignment

2020-05-01 Thread Daniel P . Berrangé 
On Thu, Apr 30, 2020 at 03:14:09PM -0400, Laine Stump wrote:
> Here are two things that would help enable me to make useful contributions:
> 
> 
> 1) a basic "source tree for a go library" setup in a libvirt-subproject on
> gitlab (since gitlab is the official location of libvirt projects now),
> including basic commit and CI hooks/test cases. I'm guessing we could
> borrow/steal a lot from what was done by the people who participated in
> "virt-blocks" last fall. Andrea - any advice/suggestions to give here?
>
> (A side question - should we put it under the libvirt umbrella on gitlab
> right away? Or play around in personal trees at first and then later fork it
> into an official libvirt project?)

I intended it to be under libvirt project right from the start, and have
indeed already created the repos & CI. There is no reason to hide it away
in private repos. It is fine for the official repo to have zero guarantee
of stability in the early days.

> 2) a more concrete idea of what the API should look like. This is always the
> toughest part for me, since it is what the rest of the world sees, so it
> needs to be intelligible and capable of expansion, and I have a long history
> of making questionable choices that come back to haunt me (and everybody
> else! :-P). Since danpb has made good decisions in this area in the past
> (and since the original proposal is his), I'm thinking/hoping he can help
> provide direction to minimize mis-steps (on the other hand, I know he's
> really busy, so maybe he was just hoping that someone else would grab up his
> proposal and run with it).

Yep, this is what I'm fleshing out an API skeleton for now.


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-devaddr: a new library for device address assignment

2020-05-01 Thread Daniel P . Berrangé 
On Thu, Apr 30, 2020 at 03:20:19PM -0300, Daniel Henrique Barboza wrote:
> 
> 
> On 3/19/20 4:00 PM, Laine Stump wrote:
> > TL;DR - I'm not as anti-XML as the proposal seems to be, but also not 
> > pro-XML. I also (after thinking about it) understand the advantage of 
> > putting this in a separate library. So yeah, let's go it!
> 
> [...]
> 
> > Anyway, in the end I think my opinion is we should push ahead and
> > think about consequences of the specifics later, after some
> > experimenting. I'd love to help if there's a place for it. I'm just
> > not sure where/how I could contribute, especially since I have only
> > about 4 hours worth of golang knowledge :-) (certainly not against
> > getting more though!)
> 
> I'll start writing some code here and there for this initiative. Does
> anyone already started doing something? Otherwise I'll push code in
> github/gitlab when I have stuff to show.

I've actually started work on a skeleton for the API this week to
try to flesh out some rough ideas for the general approach to the
problem.

> My understanding from the discussions is that the API is going to supply
> JSON responses instead of domxml (domXML might be supplied as an option,
> but it wouldn't be the default format used). Is that correct?

I'm completely ignoring libvirt Domain XML right now. I don't want the
design to be constrained by any of our historic design decisions in
libvirt. IOW, I intend it to be a greenfield site code wise.

Oone of the eventual goals is to make use of this to replace current
libvirt device addressing code, so eventually attention will have to
return to how this would map to Domain XML. It just isn't a short term
priority.

As for JSON, I'm again not too bothered about that right now, as that's
a really minor part of the problem. Primarily I want to come up with a
plain Go interface, based on some data model structs and APIs. Those
data model structs can trivially be mapped to JSON/YAML using the go
encoding/json or encoding/yaml APIs.

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: Entering freeze for libvirt 6.3.0

2020-05-01 Thread Daniel P . Berrangé 
On Tue, Apr 28, 2020 at 03:25:47PM +0200, Daniel Veillard wrote:
>   We are getting close to the end of the month, so I tagged RC1 in git
> and pushed signed source tarball and rpms to the usual place:
> 
>https://libvirt.org/sources/
> 
> Seems to work fine in my very limited testing, CI seems green except for a
> couple of mingw tests, so that looks good from a distance.
> 
> Please give it some testing, RC2 should land on Thursday, and then if
> everything looks fine I could push the final version over the coming week-end.
> 
>   Stay safe, please test it,

Things look pretty quiet - we've only had 1 minor docs fix since rc1
so far.

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-python PATCH v3 2/3] gitlab: introduce CI jobs testing git master & distro libvirt

2020-05-01 Thread Andrea Bolognani 
On Fri, 2020-05-01 at 10:20 +0100, Daniel P. Berrangé wrote:
> +.build_git_job_template: &build_git_job_definition
> +  image: $CI_REGISTRY_IMAGE/ci-$NAME:latest
> +  stage: builds

This should be git_build_job_template...

> +.build_dist_job_template: &build_dist_job_definition
> +  image: $CI_REGISTRY_IMAGE/ci-$NAME:latest
> +  stage: builds

... and this should be dist_build_job_template now, with all uses
below updated accordingly of course.

> +++ b/ci/README.rst
> @@ -0,0 +1,13 @@
> +CI job assets
> +=
> +
> +This directory contains assets used in the automated CI jobs, most
> +notably the Dockerfiles used to build container images in which the
> +CI jobs then run.
> +
> +The ``refresh`` script is used to re-create the Dockerfiles using the
> +``lcitool`` that is provided by repo https://gitlab.com/libvirt/libvirt-ci

This should read either "the lcitool command", or "the lcitool
script", or something else along those lines.


With these last remaining nits addressed,

  Reviewed-by: Andrea Bolognani 


I still don't feel comfortable ACKing the first patch, but you can
look at it this way: once you've pushed the last two patches, the
first one will suddenly fall squarely under the CI fix rule ;)

-- 
Andrea Bolognani / Red Hat / Virtualization

[libvirt PATCH] docs: Fix grammar in virsh.rst

2020-05-01 Thread Andrea Bolognani 
"allows to" -> "allows one to"

Spotted by Lintian (spelling-error-in-manpage tag).

Signed-off-by: Andrea Bolognani 
---
Pushed as trivial.

 docs/manpages/virsh.rst | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/docs/manpages/virsh.rst b/docs/manpages/virsh.rst
index dc404ddfe8..969a4d5543 100644
--- a/docs/manpages/virsh.rst
+++ b/docs/manpages/virsh.rst
@@ -6567,8 +6567,8 @@ secret-set-value
 
 Set the value associated with *secret* (specified by its UUID) to the value
 Base64-encoded value *base64* or Base-64-encoded contents of file named
-*filename*. Using the *--plain* flag is together with *--file* allows to use
-the file contents directly as the secret value.
+*filename*. Using the *--plain* flag is together with *--file* allows one to
+use the file contents directly as the secret value.
 
 If *--interactive* flag is used the secret value is read as a password from the
 terminal.
@@ -6752,7 +6752,7 @@ xml.  Each  is in the
 form ``disk[,snapshot=type][,driver=type][,stype=type][,file=name]``.
 A *diskspec* must be provided for disks backed by block devices as libvirt
 doesn't auto-generate file names for those.  The optional ``stype`` parameter
-allows to control the type of the source file. Supported values are 'file'
+allows one to control the type of the source file. Supported values are 'file'
 (default) and 'block'. To exclude a disk from an external snapshot use
 ``--diskspec disk,snapshot=no``.
 
-- 
2.25.4

Re: [libvirt-python PATCH v2 2/3] gitlab: introduce CI jobs testing git master & distro libvirt

2020-05-01 Thread Daniel P . Berrangé 
On Thu, Apr 30, 2020 at 07:19:07PM +0200, Andrea Bolognani wrote:
> On Thu, 2020-04-30 at 15:14 +0100, Daniel P. Berrangé wrote:
> > +++ b/.gitlab-ci.yml
> > @@ -0,0 +1,171 @@
> > +
> > +stages:
> > +  - prebuild
> > +  - containers
> > +  - build
> 
> Should this stage be called "builds", just like the previous one is
> called "containers"?
> 
> I'm also thinking whether it would be interesting to have a two
> separate "dist_builds" and "git_builds" stages, just like we have
> a stage for native builds and another one for cross builds in
> libvirt.

I don't want to separate the stages, as then you have to do extra
work to get them to run in parallel.

I've done all the other changes.

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-python PATCH v3 2/3] gitlab: introduce CI jobs testing git master & distro libvirt

2020-05-01 Thread Daniel P . Berrangé 
The python build needs to validate two axis

 - A variety of libvirt versions
 - A variety of python versions

We get coverage for both these axis by running a build against the
distro provided libvirt packages. All that is then missing is a build
against the latest libvirt git master, which only needs to be run on
a single distro, for which CentOS 8 is picked as a stable long life
base.

Signed-off-by: Daniel P. Berrangé 
---
 .gitlab-ci.yml   | 185 +++
 ci/README.rst|  13 ++
 ci/libvirt-centos-7.Dockerfile   |  86 +
 ci/libvirt-centos-8.Dockerfile   |  64 +
 ci/libvirt-debian-10.Dockerfile  |  56 
 ci/libvirt-debian-9.Dockerfile   |  59 +
 ci/libvirt-debian-sid.Dockerfile |  56 
 ci/libvirt-fedora-31.Dockerfile  |  53 
 ci/libvirt-fedora-32.Dockerfile  |  53 
 ci/libvirt-fedora-rawhide.Dockerfile |  54 
 ci/libvirt-opensuse-151.Dockerfile   |  55 
 ci/libvirt-ubuntu-1804.Dockerfile|  59 +
 ci/libvirt-ubuntu-2004.Dockerfile|  56 
 ci/refresh   |  27 
 14 files changed, 876 insertions(+)
 create mode 100644 .gitlab-ci.yml
 create mode 100644 ci/README.rst
 create mode 100644 ci/libvirt-centos-7.Dockerfile
 create mode 100644 ci/libvirt-centos-8.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
new file mode 100644
index 000..bc95d41
--- /dev/null
+++ b/.gitlab-ci.yml
@@ -0,0 +1,185 @@
+
+stages:
+  - prebuild
+  - containers
+  - builds
+  - docs
+
+.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-perl/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
+
+.build_git_job_template: &build_git_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"
+  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 install
+- popd
+- $PYTHON setup.py build
+- $PYTHON setup.py test
+
+.build_dist_job_template: &build_dist_job_definition
+  image: $CI_REGISTRY_IMAGE/ci-$NAME:latest
+  stage: builds
+  before_script:
+- export MAKEFLAGS="-j$(getconf _NPROCESSORS_ONLN)"
+  script:
+- $PYTHON setup.py build
+- $PYTHON setup.py test
+
+# Check that all commits are signed-off for the DCO.
+# Skip on "libvirt" namespace, since we only need to run
+# this test on developer's personal forks from which
+# merge requests are submitted
+check-dco:
+  stage: prebuild
+  image: registry.gitlab.com/libvirt/libvirt-ci/check-dco:master
+  script:
+- /check-dco
+  except:
+variables:
+  - $CI_PROJECT_NAMESPACE == 'libvirt'
+
+centos-7-container:
+  <<: *container_job_definition
+  variables:
+NAME: centos-7
+
+centos-8-container:
+  <<: *container_job_definition
+  variables:
+NAME: centos-8
+
+debian-9-container:
+  <<: *container_job_definition
+  variables:
+NAME: debian-9
+
+debian-10-container:
+  <<: *container_job_definition
+  variables:
+NAME: debian-10
+
+debian-sid-container:
+  <<: *container_job_definition
+  variables:
+NAME: debian-sid
+
+fedora-31-container:
+  <<: *container_job_definition
+  variables:
+NAME: fedora-31
+
+fedora-32-container:
+  <<: *container_job_definition
+  variables:
+NAME: fedora-32
+
+fedora-rawhide-container:
+  <<: *container_job_definition
+  variables:
+NAME: fedora-rawhide
+
+opensuse-151-container:
+  <<: *container_job_definition
+  variables:
+

[libvirt-python PATCH v3 0/3] gitlab: introduce CI jobs for validating python build

2020-05-01 Thread Daniel P . Berrangé 
This introduces GitLab CI to the python module. Traditional Jenkins has
validated the python build across all distros, using libvirt git. This
tested one axis - a variety of python versions - but failed to test the
other interesting axis - a variety of libvirt versions.

This new CI setup fixes that mistake validating both axis.

Daniel P. Berrangé (3):
  test: workaround missing VIR_TYPED_PARAM enums in API definition
  gitlab: introduce CI jobs testing git master & distro libvirt
  travis: delete redundant configuration

 .gitlab-ci.yml   | 185 +++
 .travis.yml  |  55 
 ci/README.rst|  13 ++
 ci/libvirt-centos-7.Dockerfile   |  86 +
 ci/libvirt-centos-8.Dockerfile   |  64 +
 ci/libvirt-debian-10.Dockerfile  |  56 
 ci/libvirt-debian-9.Dockerfile   |  59 +
 ci/libvirt-debian-sid.Dockerfile |  56 
 ci/libvirt-fedora-31.Dockerfile  |  53 
 ci/libvirt-fedora-32.Dockerfile  |  53 
 ci/libvirt-fedora-rawhide.Dockerfile |  54 
 ci/libvirt-opensuse-151.Dockerfile   |  55 
 ci/libvirt-ubuntu-1804.Dockerfile|  59 +
 ci/libvirt-ubuntu-2004.Dockerfile|  56 
 ci/refresh   |  27 
 sanitytest.py|   6 +-
 16 files changed, 881 insertions(+), 56 deletions(-)
 create mode 100644 .gitlab-ci.yml
 delete mode 100644 .travis.yml
 create mode 100644 ci/README.rst
 create mode 100644 ci/libvirt-centos-7.Dockerfile
 create mode 100644 ci/libvirt-centos-8.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.25.4

[libvirt-python PATCH v3 1/3] test: workaround missing VIR_TYPED_PARAM enums in API definition

2020-05-01 Thread Daniel P . Berrangé 
On Ubuntu 18.04 with libvirt 4.0.0 libvirt-python build fails

running test
/usr/bin/python3 sanitytest.py build/lib.linux-x86_64-3.6 
/usr/share/libvirt/api/libvirt-api.xml
Cannot get a value of enum VIR_TYPED_PARAM_BOOLEAN (originally 
VIR_DOMAIN_BLKIO_PARAM_BOOLEAN)
Cannot get a value of enum VIR_TYPED_PARAM_DOUBLE (originally 
VIR_DOMAIN_BLKIO_PARAM_DOUBLE)
Cannot get a value of enum VIR_TYPED_PARAM_INT (originally 
VIR_DOMAIN_BLKIO_PARAM_INT)
...snip...

The code generated for the binding is still correct and so we can just
whitelist this error scenario.

Signed-off-by: Daniel P. Berrangé 
---
 sanitytest.py | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/sanitytest.py b/sanitytest.py
index 1bedd55..f187c15 100644
--- a/sanitytest.py
+++ b/sanitytest.py
@@ -73,7 +73,11 @@ for n in second_pass:
 val = int(v[val])
 break
 
-if type(val) != int:
+# Version 4.0.0 was broken as missing VIR_TYPED_PARAM enums
+# constants. This is harmless from POV of validating API
+# coverage so ignore this error.
+if (type(val) != int and
+not val.startswith("VIR_TYPED_PARAM_")):
 fail = True
 print("Cannot get a value of enum %s (originally %s)" % (val, name))
 enumvals[typ][name] = val
-- 
2.25.4

[libvirt-python PATCH v3 3/3] travis: delete redundant configuration

2020-05-01 Thread Daniel P . Berrangé 
Now that we're standardizing on GitLab CI for both official gating CI
and developer CI, there's no compelling reason to continue to support
Travis CI.

Reviewed-by: Andrea Bolognani 
Signed-off-by: Daniel P. Berrangé 
---
 .travis.yml | 55 -
 1 file changed, 55 deletions(-)
 delete mode 100644 .travis.yml

diff --git a/.travis.yml b/.travis.yml
deleted file mode 100644
index fe24957..000
--- a/.travis.yml
+++ /dev/null
@@ -1,55 +0,0 @@
-language: python
-os: linux
-dist: xenial
-
-python:
-  - 3.6
-
-env:
-  - LIBVIRT=1.2.0 EXT=gz
-  - LIBVIRT=2.0.0 EXT=xz
-  - LIBVIRT=3.6.0 EXT=xz
-  - LIBVIRT=4.5.0 EXT=xz
-  - LIBVIRT=5.0.0 EXT=xz
-
-install:
-  - sudo apt-get -qqy build-dep libvirt libxml2-dev
-  - sudo apt-get -qqy install curl
-  - pip install -r requirements-test.txt
-  - curl -O -s https://libvirt.org/sources/libvirt-${LIBVIRT}.tar.${EXT}
-  - tar -xf libvirt-${LIBVIRT}.tar.${EXT}
-  - pushd libvirt-${LIBVIRT}
-  - |
-./configure --prefix=`pwd`/../libvirt-vroot \
---without-libvirtd \
---without-esx \
---without-vbox \
---without-libxl \
---without-xen \
---without-qemu \
---without-lxc \
---without-hyperv \
---without-macvtap \
---disable-werror
-  - make
-  - make install
-  - popd
-
-script:
-  - LD_LIBRARY_PATH=`pwd`/libvirt-vroot/lib 
PKG_CONFIG_PATH=`pwd`/libvirt-vroot/lib/pkgconfig python setup.py build sdist 
test
-
-notifications:
-  irc:
-# The channel name "irc.oftc.net#virt" is encrypted against 
libvirt/libvirt-python
-# to prevent IRC notifications from github forks. This was created using:
-# $ travis encrypt -r "libvirt/libvirt-python" "irc.oftc.net#virt"
-channels:
-  - secure: 
"K4JrbRpz4CHtZ1vjthVwseT8K6INJgjtZethP4DN1jOpm1uC5esbe1Q1qJOfB92JbMcdM6DNjrVg5eyTJj35aD9UoGpTUcPMsYrhlTPHZtfAuLv/at2eB2XRmETlhiXHgI6LizX6gTiwGW5ZHYwGChzumWxu141d/L9harNh9R6z8XH9uJpkNdOAIsJcwS56XGZ74CKsrqF5dK6ZYPIyP+i7gPO67gEWo0oD6TiJKR908fw03ZiXarIFmLRlk4MbHywLRF0byfD0gg2Ht/tDX73+59QXjLKo/GvQecwoU8UuuFRJlyhUfvm1JYYydnS+O7fPJvI0FWlYFY7i76aeVqkARHRpHknFueT6kZADOmiyMLuvdr+gWVuyIdX33vVJtDm4T1OtNMG/wy9EUZUU1vEu+gHhaRkf/O0GkMj0Hac4I14BGyd/Wdhto6zWojFiMEG/HRHey6l15MBQu49QyW/YMyWi/LeBWXuCUgwQ/ij5EPgsn36OxCafV9zMz0oXZskwX6rJGQRZsdgdwYvt2hP3muLaJbwVyT0bGlOJDJieOa/LVKOXPcQm26aGfyMuLgm0//E9v++6W1IDKh6+BNsfTKAwTxlAvJyz6Bns3XuUJUxUz2+uQVSS6S3EwEZUJ+yHDd2F4sX5OP1L7TWIOWFbI4vQK90ZZ7/jgiYQbwo="
-on_success: change
-on_failure: always
-  email:
-# The list name 'libvirt...@redhat.com" is encrypted against 
libvirt/libvirt-python
-# to prevent IRC notifications from github forks. This was created using:
-# $ travis encrypt -r "libvirt/libvirt-python" "libvirt...@redhat.com"
-recipients:
-  - secure: 
"l6TTLcEcXdDEldHE2NgSIdt6a0k99ug3hp2W4IlnqJWJfIk/87nysJtLNrA0va20pPApCa3iJfMq4PUmBGiIIimTN0/KgC7tONDraogXhCbgfZp9Ejy/57TXxygSp4oum2kDw/c5uLnfrFV/xcn1fk6hvH6CD3bVcJPOQ/mc5FSKLqN5UzwqNnMpMTtG9qxCwfXJ/Bdm9fbURfezC7djcYRwRfPUe3TSD0L76G2HnQnSy4RqR3KFSjQHFPnSGM5IbsokbOaFKCyp/pHOt7QomQaY7YAPX/K9O+eP+hkkp6DGADkkumHctcgnMoyxpahf7pNKw9S8JYabH2NwREIq8whbp9Mo+R4rYO2ozroLWHaboYs/pBLrs606ivTwOmWGRCpJdCmmKTiZNyo6MRrwiOM6x+2YHUTMOa2kVheRNzaaxMFzHPW2kZ20bujPhfViJsRYj9flo5GJXJLyjluGZK5RjrguNJeIh8VJNBiSHW37uj7drmNBsqMad+65mf/4xtGITBqhz5Spx5R9UMZbuiJvcm8GasJMMdQ+bCfuWYjF2nZvSvFEr54Ii1YrDp6FKQ8YG1aD1/D8Z0/b3pLd/8Pn+M9yIWyO/Sto5TbSUjxBTmTStuDmtYE5uu1miYebvgJH5MovWPBegYgrfI417kPJgCG3q/R0YcZFMKFfQyo="
-- 
2.25.4

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

2020-05-01 Thread Daniel P . Berrangé 
^ since 5.6.0

On Thu, Apr 30, 2020 at 04:35:32PM -0400, Laine Stump wrote:
> To make it simpler to answer questions of "Why doesn't this thing work
> for me?"
> 
> Signed-off-by: Laine Stump 
> ---
>  docs/formatnetwork.html.in | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/docs/formatnetwork.html.in b/docs/formatnetwork.html.in
> index 2bccac014b..3571d44cd6 100644
> --- a/docs/formatnetwork.html.in
> +++ 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 1.0.3. Usage of XML

. Since 1.0.3  - can I have a go in your time machine :-)

> +  namespaces comes with no support guarantees, so use at your own
> +  risk.
>  
>  
>  
> -- 
> 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 :|

Re: [libvirt-ci PATCH 0/4] check-dco: Support namespaces other than libvirt

2020-05-01 Thread Daniel P . Berrangé 
On Thu, Apr 30, 2020 at 09:28:08PM +0200, Andrea Bolognani wrote:
> See patch 4/4.
> 
> Andrea Bolognani (4):
>   containers: New top-level directory
>   check-dco: Fix script name in top comment
>   check-dco: Change remote name
>   check-dco: Support namespaces other than libvirt
> 
>  .gitlab-ci.yml   |  2 +-
>  {check-dco => containers/check-dco}/Dockerfile   |  0
>  {check-dco => containers/check-dco}/check-dco.py | 16 ++--
>  3 files changed, 11 insertions(+), 7 deletions(-)
>  rename {check-dco => containers/check-dco}/Dockerfile (100%)
>  rename {check-dco => containers/check-dco}/check-dco.py (84%)

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

[PATCH] conf: Add qemu_job_wait_time option

2020-05-01 Thread MIKI Nobuhiro 
The waiting time to acquire the lock times out, which leads to a segment fault.
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
```

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.
+
+  
 
 
 
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.
diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c
index c598240..34d29ec 100644
--- a/src/qemu/qemu_conf.c
+++ b/src/qemu/qemu_conf.c
@@ -272,6 +272,7 @@ virQEMUDriverConfigPtr virQEMUDriverConfigNew(bool 
privileged,
 cfg->keepAliveInterval = 5;
 cfg->keepAliveCount = 5;
 cfg->seccompSandbox = -1;
+cfg->qemuJobWaitTime = 30;
 
 cfg->logTimestamp = true;
 cfg->glusterDebugLevel = 4;
@@ -655,6 +656,8 @@ virQEMUDriverConfigLoadProcessEntry(virQEMUDriverConfigPtr 
cfg,
 return -1;
 if (virConfGetValueUInt(conf, "max_threads_per_process", 
&cfg->maxThreadsPerProc) < 0)
 return -1;
+if (virConfGetValueUInt(conf, "qemu_job_wait_time", &cfg->qemuJobWaitTime) 
< 0)
+return -1;
 
 if (virConfGetValueType(conf, "max_core") == VIR_CONF_STRING) {
 if (virConfGetValueString(conf, "max_core", &corestr) < 0)
diff --git a/src/qemu/qemu_conf.h b/src/qemu/qemu_conf.h
index b9ef455..49dd7b6 100644
--- a/src/qemu/qemu_conf.h
+++ b/src/qemu/qemu_conf.h
@@ -218,6 +218,8 @@ struct _virQEMUDriverConfig {
 gid_t swtpm_group;
 
 char **capabilityfilters;
+
+unsigned int qemuJobWaitTime;
 };
 
 G_DEFINE_AUTOPTR_CLEANUP_FUNC(virQEMUDriverConfig, virObjectUnref);
diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
index d63ec23..4badc0f 100644
--- a/src/qemu/qemu_domain.c
+++ b/src/qemu/qemu_domain.c
@@ -6212,9 +6212,6 @@ qemuDomainObjCanSetJob(qemuDomainObjPrivatePtr priv,
  priv->job.agentActive == QEMU_AGENT_JOB_NONE));
 }
 
-/* Give up waiting for mutex after 30 seconds */
-#define QEMU_JOB_WAIT_TIME (1000ull * 30)
-
 /**
  * qemuDomainObjBeginJobInternal:
  * @driver: qemu driver
@@ -6225,7 +6222,7 @@ qemuDomainObjCanSetJob(qemuDomainObjPrivatePtr priv,
  *
  * Acquires job for a domain object which must be locked before
  * calling. If there's already a job running waits up to
- * QEMU_JOB_WAIT_TIME after which the functions fails reporting
+ * cfg->qemuJobWaitTime after which the functions fails reporting
  * an error unless @nowait is set.
  *
  * If @nowait is true this function tries to acquire job and if
@@ -6272,7 +6269,7 @@ qemuDomainObjBeginJobInternal(virQEMUDriverPtr driver,
 return -1;
 
 priv->jobs_queued++;
-then = now + QEMU_JOB_WAIT_TIME;
+then = now + 1000ull * cfg->qemuJobWaitTime;
 
  retry:
 if ((!async && job != QEMU_JOB_DESTROY) &&
diff --git a/src/qemu/test_libvirtd_qemu.aug.in 
b/src/qemu/test_libvirtd_qemu.aug.in
index 19da591..b2886df 100644
--- a/src/qemu/test_libvirtd_qemu.aug.in
+++ b/src/qemu/test_libvirtd_qemu.aug.in
@@ -76,6 +76,7 @@ module Test_libvirtd_qem