April 2020 - Devel - libvirt List Archives

[RFC PATCH 0/3] Make use of deprecated QMP commands/fields more obvious
by Peter Krempa 30 Apr '20

30 Apr '20

This is based on top of the recent capabilities update: https://www.redhat.com/archives/libvir-list/2020-April/msg01490.html Whole series can be fetched by: git fetch https://gitlab.com/pipo.sk/libvirt.git deprecated-crash and requires a qemu which includes Markus' patches adding the -compat feature: https://lists.gnu.org/archive/html/qemu-devel/2020-03/msg05380.html Note that it was pushed partially, for convenience I'm providing a branch with the patches applied and rebased: git fetch https://gitlab.com/pipo.sk/qemu.git compat-deprecated The main idea is to add developers and other interested parties the ability to enable the -compat options to crash qemu in cases when deprecated QMP command is used and stop formating any deprecated response. The qemu code is not pushed yet and doesn't have any way to be detected but I want to query whether such feature makes sense for developers. Peter Krempa (3): qemu: capabilities: Introduce QEMU_CAPS_COMPAT_DEPRECATED qemu: conf: Add 'deprecated_debug' setting to qemu.conf qemu: command: Handle formatting of '-compat' options src/qemu/libvirtd_qemu.aug | 1 + src/qemu/qemu.conf | 11 +++++++++++ src/qemu/qemu_capabilities.c | 4 ++++ src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 16 ++++++++++++++++ src/qemu/qemu_conf.c | 2 ++ src/qemu/qemu_conf.h | 2 ++ src/qemu/test_libvirtd_qemu.aug.in | 1 + tests/qemucapabilitiesdata/caps_5.1.0.x86_64.xml | 1 + 9 files changed, 39 insertions(+) -- 2.26.2

3 6

[libvirt-ci PATCH 0/4] Add Ubuntu 20.04, drop Ubuntu 16.04
by Andrea Bolognani 30 Apr '20

30 Apr '20

Andrea Bolognani (4): guests: Add Ubuntu 20.04 Start building on Ubuntu 20.04 Stop building on Ubuntu 16.04 guests: Drop Ubuntu 16.04 guests/host_vars/libvirt-ubuntu-1604/docker.yml | 2 -- guests/host_vars/libvirt-ubuntu-1604/install.yml | 2 -- guests/host_vars/libvirt-ubuntu-2004/docker.yml | 2 ++ .../{libvirt-ubuntu-1604 => libvirt-ubuntu-2004}/main.yml | 3 ++- guests/inventory | 2 +- guests/playbooks/build/jobs/defaults.yml | 2 +- guests/playbooks/build/projects/libvirt-dbus.yml | 4 ++-- guests/playbooks/build/projects/libvirt-sandbox.yml | 2 +- guests/playbooks/build/projects/libvirt-tck.yml | 2 +- guests/playbooks/build/projects/libvirt.yml | 2 +- guests/playbooks/build/projects/virt-manager.yml | 4 +++- guests/vars/mappings.yml | 8 +------- jenkins/projects/libvirt-dbus.yaml | 3 +-- jenkins/projects/virt-manager.yaml | 2 +- 14 files changed, 17 insertions(+), 23 deletions(-) delete mode 100644 guests/host_vars/libvirt-ubuntu-1604/docker.yml delete mode 100644 guests/host_vars/libvirt-ubuntu-1604/install.yml create mode 100644 guests/host_vars/libvirt-ubuntu-2004/docker.yml rename guests/host_vars/{libvirt-ubuntu-1604 => libvirt-ubuntu-2004}/main.yml (94%) -- 2.25.4

2 7

[libvirt-ci PATCH 0/3] vault: Add Fedora 32, remove unused secrets
by Andrea Bolognani 30 Apr '20

30 Apr '20

Pushed under the unreviewable vault update rule. Andrea Bolognani (3): vault: Remove unused secrets vault: Add secret for Fedora 32 vault: Remove secret for Fedora 30 guests/vars/vault.yml | 100 +++++++++++++++++------------------------- 1 file changed, 41 insertions(+), 59 deletions(-) -- 2.25.4

1 3

[libvirt-perl PATCH v3 0/3] gitlab: introduce CI coverage
by Daniel P. Berrangé 30 Apr '20

30 Apr '20

This series introduces CI jobs for the Perl binding, enabling the switch over to use of Merge Requests with pre-merge build validation. v1: https://www.redhat.com/archives/libvir-list/2020-April/msg01157.html v2: https://www.redhat.com/archives/libvir-list/2020-April/msg01408.html This is a different approach from v1, because we don't inherit from the main libvirt container images. Instead we use the libvirt-minimal project as a dependancy. The cost is that the container build stage is more expensive, but the main project build stage is cheaper. This is a net win because the container build stage is cached so is only a penalty the first time, or when the distro parent image has changes to pull in. It also makes the CI process of the binding more self-contained avoiding by avoiding a dep on the container image for libvirt. Daniel P. Berrangé (3): Build: bump min perl to 5.16.0 gitlab: add CI jobs for validating build across platforms gitlab: add a simple job that publishes the API docs as HTML .gitlab-ci.yml | 158 +++++++++++++++++++++++++++ Build.PL | 2 +- ci/README.rst | 12 ++ ci/libvirt-centos-7.Dockerfile | 97 ++++++++++++++++ ci/libvirt-centos-8.Dockerfile | 68 ++++++++++++ ci/libvirt-debian-10.Dockerfile | 68 ++++++++++++ ci/libvirt-debian-9.Dockerfile | 71 ++++++++++++ ci/libvirt-debian-sid.Dockerfile | 68 ++++++++++++ ci/libvirt-fedora-30.Dockerfile | 66 +++++++++++ ci/libvirt-fedora-31.Dockerfile | 66 +++++++++++ ci/libvirt-fedora-rawhide.Dockerfile | 67 ++++++++++++ ci/libvirt-opensuse-151.Dockerfile | 66 +++++++++++ ci/libvirt-ubuntu-1604.Dockerfile | 71 ++++++++++++ ci/libvirt-ubuntu-1804.Dockerfile | 71 ++++++++++++ ci/refresh | 22 ++++ 15 files changed, 972 insertions(+), 1 deletion(-) 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-30.Dockerfile create mode 100644 ci/libvirt-fedora-31.Dockerfile create mode 100644 ci/libvirt-fedora-rawhide.Dockerfile create mode 100644 ci/libvirt-opensuse-151.Dockerfile create mode 100644 ci/libvirt-ubuntu-1604.Dockerfile create mode 100644 ci/libvirt-ubuntu-1804.Dockerfile create mode 100755 ci/refresh -- 2.25.4

1 3

[libvirt-ci PATCH v2] guests: introduce libvirt+dist and libvirt+minimal projects
by Daniel P. Berrangé 30 Apr '20

30 Apr '20

The language bindings have traditionally built against a full libvirt, however, this is serious overkill because all they should really need most of the time is access to the main API, and the test driver if they want to run functional tests. The full libvirt build with virt drivers is only needed for integration testing which most bindings won't do. Thus this introduces a new project "libvirt+minimal" which lists the bare minimum dependencies required to build libvirt. Taking libvirt-perl as an example, if creating a container using the current "libvirt,libvirt-perl" project set, the result with 1.4 GB in size for Fedora 31. With the "libvirt+minimal,libvirt-perl" set, the size is just 777 MB. Some projects also wish to have the ability to build against the distro provided libvirt instead of the latest git master, and for this purpose a "libvirt+dist" project is defined which pulls in the package needed for building against the distro libvirt. Thus when building any downstream project there is now a choice of building it against "libvirt" (full git) or "libvirt+minimal" (minimal git) or "libvirt+dist" (prebuilt distro). The same can be added later for example "libvirt-perl+dist" to refer to the distro provided perl binding. In the lcitool dockerfile command, there is a check that the requested project is configured against the requested host. These new projects are not listed against any host, because we don't want them installed by default in the VMs. Thus the dockerfile check is no longer valid and is removed. Whomever is invoking lcitool knows what combination they want and whether it will work. Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- In v2: - Use "+suffix" syntax for new projects - Rename new package to "libvirt" guests/lcitool | 7 ------- guests/vars/mappings.yml | 5 +++++ guests/vars/projects/libvirt+dist.yml | 3 +++ guests/vars/projects/libvirt+minimal.yml | 12 ++++++++++++ 4 files changed, 20 insertions(+), 7 deletions(-) create mode 100644 guests/vars/projects/libvirt+dist.yml create mode 100644 guests/vars/projects/libvirt+minimal.yml diff --git a/guests/lcitool b/guests/lcitool index 0c89e13..abc87d2 100755 --- a/guests/lcitool +++ b/guests/lcitool @@ -1007,13 +1007,6 @@ class Application: for project in projects: if project.rfind("+mingw") >= 0: raise Exception("Obsolete syntax, please use --cross-arch") - if project not in facts["projects"]: - raise Exception( - "Host {} doesn't support project {}".format( - host, - project, - ) - ) varmap = self._dockerfile_build_varmap(facts, mappings, pip_mappings, projects, cross_arch) self._dockerfile_format(facts, cross_arch, varmap) diff --git a/guests/vars/mappings.yml b/guests/vars/mappings.yml index 4a19fb4..9dcad46 100644 --- a/guests/vars/mappings.yml +++ b/guests/vars/mappings.yml @@ -450,6 +450,11 @@ mappings: rpm: libuuid-devel cross-policy-deb: foreign + libvirt: + rpm: libvirt-devel + deb: libvirt-dev + pkg: libvirt + libxml2: deb: libxml2-dev pkg: libxml2 diff --git a/guests/vars/projects/libvirt+dist.yml b/guests/vars/projects/libvirt+dist.yml new file mode 100644 index 0000000..1fc1b2c --- /dev/null +++ b/guests/vars/projects/libvirt+dist.yml @@ -0,0 +1,3 @@ +--- +packages: + - libvirt diff --git a/guests/vars/projects/libvirt+minimal.yml b/guests/vars/projects/libvirt+minimal.yml new file mode 100644 index 0000000..96335f2 --- /dev/null +++ b/guests/vars/projects/libvirt+minimal.yml @@ -0,0 +1,12 @@ +--- +packages: + - glib2 + - gnutls + - libnl3 + - libnlroute3 + - libtirpc + - libxml2 + - python3-docutils + - rpcgen + - xmllint + - xsltproc -- 2.25.4

2 1

[libvirt-ci PATCH 0/4] Add Fedora 32, drop Fedora 30
by Andrea Bolognani 30 Apr '20

30 Apr '20

Fedora 32 was released earlier this week, and Fedora 30 goes EOL the next one. Andrea Bolognani (4): guests: Add Fedora 32 Start building on Fedora 32 Stop building on Fedora 30 guests: Remove Fedora 30 guests/host_vars/libvirt-fedora-30/docker.yml | 2 - guests/host_vars/libvirt-fedora-32/docker.yml | 2 + .../install.yml | 2 +- .../main.yml | 2 +- guests/inventory | 2 +- guests/playbooks/build/jobs/defaults.yml | 4 +- guests/playbooks/build/projects/gtk-vnc.yml | 2 +- guests/playbooks/build/projects/libosinfo.yml | 2 +- .../playbooks/build/projects/libvirt-dbus.yml | 4 +- .../build/projects/libvirt-sandbox.yml | 4 +- .../playbooks/build/projects/libvirt-tck.yml | 4 +- guests/playbooks/build/projects/libvirt.yml | 2 +- .../build/projects/osinfo-db-tools.yml | 2 +- .../playbooks/build/projects/virt-manager.yml | 6 +- .../playbooks/build/projects/virt-viewer.yml | 2 +- jenkins/jobs/defaults.yaml | 4 +- jenkins/new.xml | 6423 ++++++++++++++++ jenkins/old.xml | 6435 +++++++++++++++++ jenkins/projects/gtk-vnc.yaml | 2 +- jenkins/projects/libosinfo.yaml | 2 +- jenkins/projects/libvirt-dbus.yaml | 4 +- jenkins/projects/libvirt-sandbox.yaml | 4 +- jenkins/projects/libvirt-tck.yaml | 4 +- jenkins/projects/libvirt.yaml | 2 +- jenkins/projects/osinfo-db-tools.yaml | 2 +- jenkins/projects/virt-manager.yaml | 6 +- jenkins/projects/virt-viewer.yaml | 2 +- 27 files changed, 12895 insertions(+), 37 deletions(-) delete mode 100644 guests/host_vars/libvirt-fedora-30/docker.yml create mode 100644 guests/host_vars/libvirt-fedora-32/docker.yml rename guests/host_vars/{libvirt-fedora-30 => libvirt-fedora-32}/install.yml (66%) rename guests/host_vars/{libvirt-fedora-30 => libvirt-fedora-32}/main.yml (97%) create mode 100644 jenkins/new.xml create mode 100644 jenkins/old.xml -- 2.25.4

2 7

[libvirt-python PATCH 0/3] gitlab: introduce CI jobs for validating python build
by Daniel P. Berrangé 30 Apr '20

30 Apr '20

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 and in the process uncovered a bug in Ubuntu 1804. 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 | 172 ++++++++++++++++++++++++++++++++++ .travis.yml | 55 ----------- ci/libvirt-centos-7.dkr | 85 +++++++++++++++++ ci/libvirt-centos-8.dkr | 64 +++++++++++++ ci/libvirt-debian-10.dkr | 55 +++++++++++ ci/libvirt-debian-9.dkr | 58 ++++++++++++ ci/libvirt-debian-sid.dkr | 55 +++++++++++ ci/libvirt-fedora-30.dkr | 52 ++++++++++ ci/libvirt-fedora-31.dkr | 52 ++++++++++ ci/libvirt-fedora-rawhide.dkr | 53 +++++++++++ ci/libvirt-opensuse-151.dkr | 54 +++++++++++ ci/libvirt-ubuntu-1604.dkr | 58 ++++++++++++ ci/libvirt-ubuntu-1804.dkr | 58 ++++++++++++ ci/refresh | 21 +++++ sanitytest.py | 6 +- 15 files changed, 842 insertions(+), 56 deletions(-) create mode 100644 .gitlab-ci.yml delete mode 100644 .travis.yml create mode 100644 ci/libvirt-centos-7.dkr create mode 100644 ci/libvirt-centos-8.dkr create mode 100644 ci/libvirt-debian-10.dkr create mode 100644 ci/libvirt-debian-9.dkr create mode 100644 ci/libvirt-debian-sid.dkr create mode 100644 ci/libvirt-fedora-30.dkr create mode 100644 ci/libvirt-fedora-31.dkr create mode 100644 ci/libvirt-fedora-rawhide.dkr create mode 100644 ci/libvirt-opensuse-151.dkr create mode 100644 ci/libvirt-ubuntu-1604.dkr create mode 100644 ci/libvirt-ubuntu-1804.dkr create mode 100755 ci/refresh -- 2.25.4

2 9

[libvirt-ci PATCH] guests: introduce libvirt-dist and libvirt-minimal projects
by Daniel P. Berrangé 30 Apr '20

30 Apr '20

The language bindings have traditionally built against a full libvirt, however, this is serious overkill because all they should really need most of the time is access to the main API, and the test driver if they want to run functional tests. The full libvirt build with virt drivers is only needed for integration testing which most bindings won't do. Thus this introduces a new project "libvirt-minimal" which lists the bare minimum dependencies required to build libvirt. Taking libvirt-perl as an example, if creating a container using the current "libvirt,libvirt-perl" project set, the result with 1.4 GB in size for Fedora 31. With the "libvirt-minimal,libvirt-perl" set, the size is just 777 MB. Some projects also wish to have the ability to build against the distro provided libvirt instead of the latest git master, and for this purpose a "libvirt-dist" project is defined which pulls in the package needed for building against the distro libvirt. In the lcitool dockerfile command, there is a check that the requested project is configured against the requested host. These new projects are not listed against any host, because we don't want them installed by default in the VMs. Thus the dockerfile check is no longer valid and is removed. Whomever is invoking lcitool knows what combination they want and whether it will work. Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- guests/lcitool | 7 ------- guests/vars/mappings.yml | 5 +++++ guests/vars/projects/libvirt-dist.yml | 3 +++ guests/vars/projects/libvirt-minimal.yml | 13 +++++++++++++ 4 files changed, 21 insertions(+), 7 deletions(-) create mode 100644 guests/vars/projects/libvirt-dist.yml create mode 100644 guests/vars/projects/libvirt-minimal.yml diff --git a/guests/lcitool b/guests/lcitool index 0c89e13..abc87d2 100755 --- a/guests/lcitool +++ b/guests/lcitool @@ -1007,13 +1007,6 @@ class Application: for project in projects: if project.rfind("+mingw") >= 0: raise Exception("Obsolete syntax, please use --cross-arch") - if project not in facts["projects"]: - raise Exception( - "Host {} doesn't support project {}".format( - host, - project, - ) - ) varmap = self._dockerfile_build_varmap(facts, mappings, pip_mappings, projects, cross_arch) self._dockerfile_format(facts, cross_arch, varmap) diff --git a/guests/vars/mappings.yml b/guests/vars/mappings.yml index 753f0fe..a9ab3d5 100644 --- a/guests/vars/mappings.yml +++ b/guests/vars/mappings.yml @@ -450,6 +450,11 @@ mappings: rpm: libuuid-devel cross-policy-deb: foreign + libvirt-devel: + rpm: libvirt-devel + deb: libvirt-dev + pkg: libvirt + libxml2: deb: libxml2-dev pkg: libxml2 diff --git a/guests/vars/projects/libvirt-dist.yml b/guests/vars/projects/libvirt-dist.yml new file mode 100644 index 0000000..aa95f23 --- /dev/null +++ b/guests/vars/projects/libvirt-dist.yml @@ -0,0 +1,3 @@ +--- +packages: + - libvirt-devel diff --git a/guests/vars/projects/libvirt-minimal.yml b/guests/vars/projects/libvirt-minimal.yml new file mode 100644 index 0000000..9402c4f --- /dev/null +++ b/guests/vars/projects/libvirt-minimal.yml @@ -0,0 +1,13 @@ +--- +packages: + - glib2 + - gnutls + - libnl3 + - libnlroute3 + - libpcap + - libtirpc + - libxml2 + - python3-docutils + - rpcgen + - xmllint + - xsltproc -- 2.25.4

2 3

Live migration garp
by Ignazio Cassano 30 Apr '20

30 Apr '20

Hello All, I am facing issues under openstack rocky with last libvirt available on centos 7. There is an open discussione here: https://bugs.launchpad.net/neutron/+bug/1866139 About sending garp when an instance live migrate. What must send garp ? The problem is this: when live migrate a vm from a node to another it stops to responds to ping requests. It starts to respond only when it send a network request for example when its chrony daemon pools a server. Anyone could help me, please? Best Regards Ignazio

2 2

Re: Libvirt Application Development Guide
by Daniel P. Berrangé 30 Apr '20

30 Apr '20

Replying again to re-add the mailing list On Thu, Apr 30, 2020 at 08:56:12AM +0000, charalambous s. (sc3n17) wrote: > Hello Daniel, > > Thank you for getting back to me! > > I understand that the state of the document was perhaps not as polished > as one would like, however it was immensely helpful to me when developing > my project. If it is not too difficult / costly, I personally would prefer > if it was left up, since there aren't really any alternatives that are as > useful. I do understand however that if I'm the only person that has used > it in recent times, it may not be worth the effort. Since you say it was useful to you, it is likely useful to other people as well. Based on this I've temporarily re-enabled the cronjob that was publishing it at: https://libvirt.org/docs/libvirt-appdev-guide-python/en-US/html/ I only re-enabled it for the python appdev guide, not the even older C appdev guide. I'll see about moving the cronjob into GitLab CI so we have a more formal publishing approach. This will mean we can validate it when we accept merge requests for the content too. > Personally, I feel that the guide was good enough to guide me in > the right direction when using the library, and the examples > provided were useful in getting an idea of what was going on. A > section of my project report is a short list of improvements that > could be made to the guide, so if you do decide to reinstate it, > I could help with improving some sections a little bit. Since it lacks any current maintainer, we'd be happy if anyone wants to volunteer to contribute improvements to it, whether little or large! Thankyou for your interest in, and feedback to, the libvirt project. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|

1 0