- Devel - libvirt List Archives

[libvirt] [jenkins-ci PATCH 0/2] Drop Ubuntu 16.04
by Andrea Bolognani 29 Mar '19

29 Mar '19

I'm a bit conflicted about this one: on one hand, unlike Debian 8 we haven't really run into any issue with Ubuntu 16.04, we can still build almost all projects on it, and it doesn't require any crazy hacks to maintain; on the other hand, perhaps the reason why we still claim we can build almost all projects on it is because we don't actually run any build on it, either on CentOS CI or on Travis CI :D Anyway: here are the patches, let's see what other people think. Andrea Bolognani (2): Stop building on Ubuntu 16.04 guests: Drop Ubuntu 18.04 guests/host_vars/libvirt-ubuntu-16/docker.yml | 2 -- .../host_vars/libvirt-ubuntu-16/install.yml | 2 -- guests/host_vars/libvirt-ubuntu-16/main.yml | 22 ------------------- guests/inventory | 1 - guests/playbooks/build/jobs/defaults.yml | 1 - .../playbooks/build/projects/libvirt-dbus.yml | 5 +---- .../build/projects/libvirt-go-xml.yml | 1 - .../playbooks/build/projects/libvirt-go.yml | 1 - .../build/projects/libvirt-ocaml.yml | 1 - .../build/projects/libvirt-sandbox.yml | 1 - .../playbooks/build/projects/libvirt-tck.yml | 1 - guests/playbooks/build/projects/libvirt.yml | 1 - guests/playbooks/build/projects/osinfo-db.yml | 1 - .../playbooks/build/projects/virt-manager.yml | 4 +--- guests/vars/mappings.yml | 3 --- 15 files changed, 2 insertions(+), 45 deletions(-) delete mode 100644 guests/host_vars/libvirt-ubuntu-16/docker.yml delete mode 100644 guests/host_vars/libvirt-ubuntu-16/install.yml delete mode 100644 guests/host_vars/libvirt-ubuntu-16/main.yml -- 2.20.1

4 8

[libvirt] [jenkins-ci PATCH 0/2] Drop Debian 8
by Andrea Bolognani 29 Mar '19

29 Mar '19

See patch 1/2 and https://www.redhat.com/archives/libvir-list/2019-March/msg01864.html for the rationale. Andrea Bolognani (2): Stop building on Debian 8 guests: Drop Debian 8 guests/host_vars/libvirt-debian-8/docker.yml | 2 - guests/host_vars/libvirt-debian-8/install.yml | 2 - guests/host_vars/libvirt-debian-8/main.yml | 20 ----- guests/inventory | 1 - guests/playbooks/build/jobs/defaults.yml | 1 - .../playbooks/build/projects/libvirt-dbus.yml | 1 - .../build/projects/libvirt-go-xml.yml | 1 - .../playbooks/build/projects/libvirt-go.yml | 1 - .../build/projects/libvirt-ocaml.yml | 1 - .../build/projects/libvirt-sandbox.yml | 1 - .../playbooks/build/projects/libvirt-tck.yml | 1 - guests/playbooks/build/projects/libvirt.yml | 1 - guests/playbooks/build/projects/osinfo-db.yml | 1 - .../playbooks/build/projects/virt-manager.yml | 4 +- guests/playbooks/update/tasks/base.yml | 22 ------ guests/playbooks/update/tasks/bootstrap.yml | 6 -- .../templates/jessie-backports.preferences.j2 | 3 - .../templates/jessie-backports.sources.j2 | 1 - guests/vars/mappings.yml | 7 -- guests/vars/vault.yml | 78 +++++++++---------- jenkins/jobs/defaults.yaml | 1 - jenkins/projects/libvirt-dbus.yaml | 1 - jenkins/projects/libvirt-go-xml.yaml | 1 - jenkins/projects/libvirt-go.yaml | 1 - jenkins/projects/libvirt-ocaml.yaml | 1 - jenkins/projects/libvirt-sandbox.yaml | 1 - jenkins/projects/libvirt-tck.yaml | 1 - jenkins/projects/libvirt.yaml | 1 - jenkins/projects/osinfo-db.yaml | 1 - jenkins/projects/virt-manager.yaml | 4 +- 30 files changed, 41 insertions(+), 127 deletions(-) delete mode 100644 guests/host_vars/libvirt-debian-8/docker.yml delete mode 100644 guests/host_vars/libvirt-debian-8/install.yml delete mode 100644 guests/host_vars/libvirt-debian-8/main.yml delete mode 100644 guests/playbooks/update/templates/jessie-backports.preferences.j2 delete mode 100644 guests/playbooks/update/templates/jessie-backports.sources.j2 -- 2.20.1

2 3

[libvirt] [PATCH] snapashot: Improve logic of virDomainMomentMoveChildren
by Eric Blake 29 Mar '19

29 Mar '19

Even though Coverity can prove that 'last' is always set if the prior loop executed, gcc 8.0.1 cannot: CC conf/libvirt_conf_la-virdomainmomentobjlist.lo ../../src/conf/virdomainmomentobjlist.c: In function 'virDomainMomentMoveChildren': ../../src/conf/virdomainmomentobjlist.c:178:19: error: 'last' may be used uninitialized in this function [-Werror=maybe-uninitialized] last->sibling = to->first_child; ~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~ Rewrite the loop to a form that should be easier for static analysis to work with. Fixes: ced0898f86bf Reported-by: Bjoern Walk <bwalk(a)linux.ibm.com> Signed-off-by: Eric Blake <eblake(a)redhat.com> --- Qualifies as a build-breaker fix, but I'd like a review before pushing. src/conf/virdomainmomentobjlist.c | 15 +++++++-------- 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/src/conf/virdomainmomentobjlist.c b/src/conf/virdomainmomentobjlist.c index b9ca5b1318..5a217056d1 100644 --- a/src/conf/virdomainmomentobjlist.c +++ b/src/conf/virdomainmomentobjlist.c @@ -164,18 +164,17 @@ void virDomainMomentMoveChildren(virDomainMomentObjPtr from, virDomainMomentObjPtr to) { - virDomainMomentObjPtr child; - virDomainMomentObjPtr last; + virDomainMomentObjPtr child = from->first_child; - if (!from->first_child) - return; - for (child = from->first_child; child; child = child->sibling) { + while (child) { child->parent = to; - if (!child->sibling) - last = child; + if (!child->sibling) { + child->sibling = to->first_child; + break; + } + child = child->sibling; } to->nchildren += from->nchildren; - last->sibling = to->first_child; to->first_child = from->first_child; from->nchildren = 0; from->first_child = NULL; -- 2.20.1

3 3

Re: [libvirt] [PATCH 1/2] snapshots: allow create --redefine to force a new configuration
by Richard Moore 29 Mar '19

29 Mar '19

> > On Wed, Mar 20, 2019 at 8:53 AM Peter Krempa <pkrempa redhat com> > wrote: > > I'm not persuaded that this workaround is necessary. > > Thanks Peter for taking a deeper look! > > And yes your summary seems correct. > I personally still like to give admins the ability to force configs, > but I'm ok if the general upstream opinion to that is no. > > I have asked the reporter - on the bug that I got - to chime in here > and > do the "convincing" as he is the affected person I think he is more > able > to do so - e.g. express the pain with the suggested workaround. > > -- > Christian Ehrhardt > Software Engineer, Ubuntu Server > Canonical Ltd Hi, I am the original fix requestor who Christian has put up with for quite some time now! I will try and summarise in brief; The initial problem was the machine type I had set in various snapshots/VM's had been deprecated and thus rendered the snapshots all unusable after upgrading O/S (that came packaged with newer libvirt/qemu versions.) I thus needed a simple, intuitive way to edit the snapshots to a machine type that was still supported, permanently. snapshot-edit seemed the appropriate tool for doing this, but alas it would not, a way was needed to force it to save the changes. One of my main reasons for using vm/snapshots is testing software install behaviour/compatibility in Windows, so I have a variety of Windows versions, each with snapshots taken with various levels of core 'things' installed (.net framework , C++ redistributables etc.) Thus the snapshots could be many years old. I need to be able to flick between them, so being able to permanently 'fix' them is my goal. The second issue was similarly being able to edit other 'simple' facets of the snapshots e.g. Attached disks, floppies or ISO's - or paths to them. Memory, if testing something that needed more than I ever invisaged way back when. MAC address (we have to register devices on the network via MAC, which expire, and can then render the snapshot unusable if I cannot change the MAC in the snapshot) I hope this makes sense, I have tried to be brief, I can elaborate further if needed. I think being able to edit existing snapshots simply, with once command, would be very beneficial to many people. (I think most people trying to do this would be aware of the risks, especially if the alternative is that the snapshot doesn’t work anyway.) Cheers Richard Moore

1 0

[libvirt] [perl][PATCH 0/3] Add a bunch of constants
by Michal Privoznik 28 Mar '19

28 Mar '19

*** BLURB HERE *** Michal Privoznik (3): Register new error code constants Add VIR_FROM_DOMAIN_CHECKPOINT constant Add VIR_MIGRATE_PARALLEL and VIR_MIGRATE_PARAM_PARALLEL_CONNECTIONS constants Changes | 5 +++++ lib/Sys/Virt.xs | 6 ++++++ lib/Sys/Virt/Domain.pm | 10 ++++++++++ lib/Sys/Virt/Error.pm | 16 ++++++++++++++++ 4 files changed, 37 insertions(+) -- 2.19.2

2 6

[libvirt] Time to drop support for Debian 8 (Jessie)?
by Andrea Bolognani 28 Mar '19

28 Mar '19

We currently support Debian 8 (oldstable) along with Debian 9 (stable), but not without some compromises: * the libvirt-dbus, libvirt-ocaml and virt-manager projects do not support the platform at all because it ships outdated versions of some core components; * on the CI side of things, we are forced to drag in the JRE from backports in order to be able to run the Jenkins agent. All things considered, the situation has been fairly manageable up until now, but a couple of recent developments got me thinking that perhaps it's time to let Jessie go: * the distribution has been moved from the regular Debian infrastructure to archive.debian.org[1], a change which has resulted in the daily update run failing and would require investing time to adapt to; * Debian testing has recently entered the full freeze[2], which means the release of Debian 10 can hopefully be expected to happen within the next few month; * even if the Buster freeze period turned out to be exceedingly long, according to our platform support policy[3] we only promise to support a release for the two years after the most recent major release: given that Debian 9 was released in June 2017[4], we would be able to drop Debian 8 support in three months' time regardless of whether or not Debian 10 has been released in the meantime. Based on the above, I suggest we don't invest any time trying to keep Debian 8 chugging along only to drop it in June, and instead declare it as unsupported right now and move on with our lives. Thoughts? [1] https://lists.debian.org/debian-devel-announce/2019/03/msg00006.html [2] https://lists.debian.org/debian-devel-announce/2019/03/msg00003.html [3] https://libvirt.org/platforms.html [4] https://wiki.debian.org/DebianReleases -- Andrea Bolognani / Red Hat / Virtualization

2 8

[libvirt] [PATCH] virsh: Don't infloop on snapshot/storage_vol failure
by Eric Blake 28 Mar '19

28 Mar '19

Most of our completers used the pattern: if ((nITEM = virITEMListAll()) < 0) return NULL; but the virDomainSnapshot and virStorageVolume completers were instead using goto error because of a prior allocation. If the ListAll fails with -1, the cleanup label was running a loop of 'size_t i < int nITEM', which is an extreme waste of CPU cycles. Reported-by: Ján Tomko <jtomko(a)redhat.com> Signed-off-by: Eric Blake <eblake(a)redhat.com> --- This one is a bug fix, so worth having in 5.2. tools/virsh-completer.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/tools/virsh-completer.c b/tools/virsh-completer.c index c4adbb70d0..e9ef9b99f9 100644 --- a/tools/virsh-completer.c +++ b/tools/virsh-completer.c @@ -278,6 +278,7 @@ virshStorageVolNameCompleter(vshControl *ctl, virshControlPtr priv = ctl->privData; virStoragePoolPtr pool = NULL; virStorageVolPtr *vols = NULL; + int rc; int nvols = 0; size_t i = 0; char **ret = NULL; @@ -290,8 +291,9 @@ virshStorageVolNameCompleter(vshControl *ctl, if (!(pool = virshCommandOptPool(ctl, cmd, "pool", NULL))) return NULL; - if ((nvols = virStoragePoolListAllVolumes(pool, &vols, flags)) < 0) + if ((rc = virStoragePoolListAllVolumes(pool, &vols, flags)) < 0) goto error; + nvols = rc; if (VIR_ALLOC_N(ret, nvols + 1) < 0) goto error; @@ -631,6 +633,7 @@ virshSnapshotNameCompleter(vshControl *ctl, virshControlPtr priv = ctl->privData; virDomainPtr dom = NULL; virDomainSnapshotPtr *snapshots = NULL; + int rc; int nsnapshots = 0; size_t i = 0; char **ret = NULL; @@ -643,8 +646,9 @@ virshSnapshotNameCompleter(vshControl *ctl, if (!(dom = virshCommandOptDomain(ctl, cmd, NULL))) return NULL; - if ((nsnapshots = virDomainListAllSnapshots(dom, &snapshots, flags)) < 0) + if ((rc = virDomainListAllSnapshots(dom, &snapshots, flags)) < 0) goto error; + nsnapshots = rc; if (VIR_ALLOC_N(ret, nsnapshots + 1) < 0) goto error; -- 2.20.1

2 1

[libvirt] [jenkins-ci PATCH] jenkins: only send one email on build failure
by Daniel P. Berrangé 28 Mar '19

28 Mar '19

The current config causes jenkins to send a build on every single failure. This is way too noisy so change it to only send emails on the transition from good to bad. Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- jenkins/jobs/autotools.yaml | 8 ++++---- jenkins/jobs/generic.yaml | 8 ++++---- jenkins/jobs/go.yaml | 4 ++-- jenkins/jobs/perl-modulebuild.yaml | 6 +++--- jenkins/jobs/python-distutils.yaml | 6 +++--- 5 files changed, 16 insertions(+), 16 deletions(-) diff --git a/jenkins/jobs/autotools.yaml b/jenkins/jobs/autotools.yaml index e365ec4..f04ec17 100644 --- a/jenkins/jobs/autotools.yaml +++ b/jenkins/jobs/autotools.yaml @@ -50,7 +50,7 @@ publishers: - email: recipients: '{obj:spam}' - notify-every-unstable-build: true + notify-every-unstable-build: false send-to-individuals: false - job-template: @@ -89,7 +89,7 @@ publishers: - email: recipients: '{obj:spam}' - notify-every-unstable-build: true + notify-every-unstable-build: false send-to-individuals: false - job-template: @@ -132,7 +132,7 @@ publishers: - email: recipients: '{obj:spam}' - notify-every-unstable-build: true + notify-every-unstable-build: false send-to-individuals: false - job-template: @@ -174,5 +174,5 @@ publishers: - email: recipients: '{obj:spam}' - notify-every-unstable-build: true + notify-every-unstable-build: false send-to-individuals: false diff --git a/jenkins/jobs/generic.yaml b/jenkins/jobs/generic.yaml index 1990930..ca69513 100644 --- a/jenkins/jobs/generic.yaml +++ b/jenkins/jobs/generic.yaml @@ -45,7 +45,7 @@ publishers: - email: recipients: '{obj:spam}' - notify-every-unstable-build: true + notify-every-unstable-build: false send-to-individuals: false - job-template: @@ -83,7 +83,7 @@ publishers: - email: recipients: '{obj:spam}' - notify-every-unstable-build: true + notify-every-unstable-build: false send-to-individuals: false - job-template: @@ -121,7 +121,7 @@ publishers: - email: recipients: '{obj:spam}' - notify-every-unstable-build: true + notify-every-unstable-build: false send-to-individuals: false - job-template: @@ -159,5 +159,5 @@ publishers: - email: recipients: '{obj:spam}' - notify-every-unstable-build: true + notify-every-unstable-build: false send-to-individuals: false diff --git a/jenkins/jobs/go.yaml b/jenkins/jobs/go.yaml index 3c14c35..1bdcb5f 100644 --- a/jenkins/jobs/go.yaml +++ b/jenkins/jobs/go.yaml @@ -45,7 +45,7 @@ publishers: - email: recipients: '{obj:spam}' - notify-every-unstable-build: true + notify-every-unstable-build: false send-to-individuals: false - job-template: @@ -83,5 +83,5 @@ publishers: - email: recipients: '{obj:spam}' - notify-every-unstable-build: true + notify-every-unstable-build: false send-to-individuals: false diff --git a/jenkins/jobs/perl-modulebuild.yaml b/jenkins/jobs/perl-modulebuild.yaml index 933020a..7173493 100644 --- a/jenkins/jobs/perl-modulebuild.yaml +++ b/jenkins/jobs/perl-modulebuild.yaml @@ -47,7 +47,7 @@ publishers: - email: recipients: '{obj:spam}' - notify-every-unstable-build: true + notify-every-unstable-build: false send-to-individuals: false @@ -86,7 +86,7 @@ publishers: - email: recipients: '{obj:spam}' - notify-every-unstable-build: true + notify-every-unstable-build: false send-to-individuals: false - job-template: @@ -127,5 +127,5 @@ publishers: - email: recipients: '{obj:spam}' - notify-every-unstable-build: true + notify-every-unstable-build: false send-to-individuals: false diff --git a/jenkins/jobs/python-distutils.yaml b/jenkins/jobs/python-distutils.yaml index 6b388f2..f56794c 100644 --- a/jenkins/jobs/python-distutils.yaml +++ b/jenkins/jobs/python-distutils.yaml @@ -47,7 +47,7 @@ publishers: - email: recipients: '{obj:spam}' - notify-every-unstable-build: true + notify-every-unstable-build: false send-to-individuals: false @@ -86,7 +86,7 @@ publishers: - email: recipients: '{obj:spam}' - notify-every-unstable-build: true + notify-every-unstable-build: false send-to-individuals: false - job-template: @@ -127,5 +127,5 @@ publishers: - email: recipients: '{obj:spam}' - notify-every-unstable-build: true + notify-every-unstable-build: false send-to-individuals: false -- 2.20.1

2 4

[libvirt] [jenkins-ci PATCH v2 1/2] guests: Update test dependencies for osinfo-db
by Fabiano Fidêncio 28 Mar '19

28 Mar '19

The new dependencies are: - python3 - python3-lxml - python3-pytest - python3-requests xmllint has been removed in favour of a own crafted test using python3-lxml Signed-off-by: Fabiano Fidêncio <fidencio(a)redhat.com> --- guests/vars/projects/osinfo-db.yml | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/guests/vars/projects/osinfo-db.yml b/guests/vars/projects/osinfo-db.yml index d9320a4..56bd77a 100644 --- a/guests/vars/projects/osinfo-db.yml +++ b/guests/vars/projects/osinfo-db.yml @@ -1,4 +1,7 @@ --- packages: - intltool - - xmllint + - python3 + - python3-lxml + - python3-pytest + - python3-requests -- 2.20.1

3 4

[libvirt] [PATCH] tests: Disable some tests on 32 bit systems
by Michal Privoznik 28 Mar '19

28 Mar '19

On 32 bit systems there are two tests failing currently: qemufirmwaretest and qemuxml2argvtest (not every test case in them is failing, only some of them). There are several problems: 1) in qemufirmwaretest it's 'QEMU FW precedence test' which is failing. This is because the code tests qemuFirmwareFetchConfigs() which tries to compile a list of some paths from the system and if one of the paths is an empty file it should not appear on the returned list. The code uses virFileLength() to query the file size which uses stat() under the hood. The test uses virfilewrapper to redirect stat() into qemufirmwaredata/ but for reasons beyond me real_stat() returns mangled buffer making the code see a file with a real size even for empty files. I've track this one to a problem in virfilewrapper.c which will call real___xstat() which points to a function in libvirt.so (!) which returns stat with 32bit members even though we're compiling with LARGE_FILE and therefore expect 64bit members in the stat struct. 2) qemuxml2argvtest has two tests failing: 2a) [aarch64-]os-firmware-* - These fail because of the same reason as described in 1) 2b) pseries-hostdevs-* - These fail because they again rely on some stat (lstat to be precise). When building the cmd line for these test cases the code does some search in /sys/bus/pci/... and since we have virpcimock everything works just fine. Except when virfilewrapper.c is linked in because then lstat() is taken from there and when it initializes itself it will lookup real_lstat() which will now point not to virpcimock but to glibc. Again, reasons beyond me. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- Quite frankly, I hate this patch. But the problem is in our mocking, not in the actual code its testing. And I've tried everything I was able to come up with on how to fix this. So if you have any idea, I'm all ears. tests/qemufirmwaretest.c | 7 +++++++ tests/qemuxml2argvtest.c | 6 ++++++ 2 files changed, 13 insertions(+) diff --git a/tests/qemufirmwaretest.c b/tests/qemufirmwaretest.c index 2b5cbf649b..3332bf0a34 100644 --- a/tests/qemufirmwaretest.c +++ b/tests/qemufirmwaretest.c @@ -52,6 +52,8 @@ testParseFormatFW(const void *opaque) } +#if defined(__x86_64__) || defined(__amd64__) || defined(__aarch64__) +/* XXX Dirty hack, but mocking stat on 32bits is above my skills */ static int testFWPrecedence(const void *opaque ATTRIBUTE_UNUSED) { @@ -97,6 +99,7 @@ testFWPrecedence(const void *opaque ATTRIBUTE_UNUSED) return 0; } +#endif static int @@ -124,8 +127,12 @@ mymain(void) DO_PARSE_TEST("usr/share/qemu/firmware/61-ovmf.json"); DO_PARSE_TEST("usr/share/qemu/firmware/70-aavmf.json"); + +#if defined(__x86_64__) || defined(__amd64__) || defined(__aarch64__) + /* XXX Dirty hack, but mocking stat on 32bits is above my skills */ if (virTestRun("QEMU FW precedence test", testFWPrecedence, NULL) < 0) ret = -1; +#endif virFileWrapperClearPrefixes(); diff --git a/tests/qemuxml2argvtest.c b/tests/qemuxml2argvtest.c index 0c0dcae197..364792d24d 100644 --- a/tests/qemuxml2argvtest.c +++ b/tests/qemuxml2argvtest.c @@ -2038,6 +2038,8 @@ mymain(void) DO_TEST("pseries-many-buses-2", QEMU_CAPS_DEVICE_SPAPR_PCI_HOST_BRIDGE, QEMU_CAPS_VIRTIO_SCSI); +# if defined(__x86_64__) || defined(__amd64__) || defined(__aarch64__) + /* XXX Dirty hack, but mocking stat on 32bits is above my skills */ DO_TEST("pseries-hostdevs-1", QEMU_CAPS_DEVICE_SPAPR_PCI_HOST_BRIDGE, QEMU_CAPS_VIRTIO_SCSI, @@ -2050,6 +2052,7 @@ mymain(void) QEMU_CAPS_DEVICE_SPAPR_PCI_HOST_BRIDGE, QEMU_CAPS_VIRTIO_SCSI, QEMU_CAPS_DEVICE_VFIO_PCI); +# endif DO_TEST("pseries-features", QEMU_CAPS_DEVICE_SPAPR_PCI_HOST_BRIDGE, @@ -3157,10 +3160,13 @@ mymain(void) DO_TEST_CAPS_ARCH_LATEST("x86_64-pc-graphics", "x86_64"); DO_TEST_CAPS_ARCH_LATEST("x86_64-q35-graphics", "x86_64"); +# if defined(__x86_64__) || defined(__amd64__) || defined(__aarch64__) + /* XXX Dirty hack, but mocking stat on 32bits is above my skills */ DO_TEST_CAPS_LATEST("os-firmware-bios"); DO_TEST_CAPS_LATEST("os-firmware-efi"); DO_TEST_CAPS_LATEST("os-firmware-efi-secboot"); DO_TEST_CAPS_ARCH_LATEST("aarch64-os-firmware-efi", "aarch64"); +# endif if (getenv("LIBVIRT_SKIP_CLEANUP") == NULL) virFileDeleteTree(fakerootdir); -- 2.19.2

3 2