April 2020 - Devel - libvirt List Archives

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

02 Apr '20

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

2 1

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

02 Apr '20

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

2 1

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

02 Apr '20

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

4 4

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

02 Apr '20

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

2 5

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

02 Apr '20

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

2 1

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

01 Apr '20

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

2 4

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

01 Apr '20

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

2 4