June 2019 - Devel - libvirt List Archives

[libvirt] [PATCH] tests: qemumonitorjson: Replace use of virReportError
by Peter Krempa 12 Jun '19

12 Jun '19

Use VIR_TEST_VERBOSE instead. This fixes the following syntax check problem: tests/qemumonitorjsontest.c:1409: virReportError(VIR_ERR_INTERNAL_ERROR, "arr should have been cleared"); Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- Pushed under the build-breaker rule. tests/qemumonitorjsontest.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/qemumonitorjsontest.c b/tests/qemumonitorjsontest.c index 68b115fa89..e087d1c256 100644 --- a/tests/qemumonitorjsontest.c +++ b/tests/qemumonitorjsontest.c @@ -1406,7 +1406,7 @@ testQemuMonitorJSONqemuMonitorJSONMergeBitmaps(const void *opaque) return -1; if (arr) { - virReportError(VIR_ERR_INTERNAL_ERROR, "arr should have been cleared"); + VIR_TEST_VERBOSE("arr should have been cleared"); return -1; } -- 2.21.0

1 0

[libvirt] [PATCH 0/3] tests: uri: Improve uri testing and add test for urlencoded uris
by Peter Krempa 11 Jun '19

11 Jun '19

Peter Krempa (3): tests: uri: Use VIR_TEST_DEBUG instead of VIR_DEBUG tests: uri: Run all test cases on a single URI tests: uri: Add test for urlencoded URIs tests/viruritest.c | 80 +++++++++++++++++++++++++++------------------- 1 file changed, 47 insertions(+), 33 deletions(-) -- 2.21.0

2 4

[libvirt] [PATCH 0/3] qemu: Fix two block-job related regressions (blockdev-add saga)
by Peter Krempa 11 Jun '19

11 Jun '19

Peter Krempa (3): qemu: domain: Fix logic bug in qemuDomainStorageSourceAccessAllow qemu: domain: Allow overriding images to read-write in qemuDomainStorageSourceAccessAllow qemu: Use proper block job name when reconnecting to VM src/qemu/qemu_domain.c | 21 ++++++++++++++------- src/qemu/qemu_migration.c | 2 +- src/qemu/qemu_monitor.c | 7 ++++--- src/qemu/qemu_monitor.h | 3 ++- src/qemu/qemu_monitor_json.c | 12 ++++++++---- src/qemu/qemu_monitor_json.h | 3 ++- src/qemu/qemu_process.c | 2 +- 7 files changed, 32 insertions(+), 18 deletions(-) -- 2.21.0

2 6

[libvirt] [PATCH v2 0/4] test_driver: implement virDomainSaveImageGetXMLDesc and virDomainSaveImageDefineXML
by Ilias Stamatis 11 Jun '19

11 Jun '19

Changed in v2: * in testDomainSaveImageDefineXML check first that a saved image already exists before parsing the new file * reordered the arguments of testDomainSaveImageWrite in order for its signature to be consistent with testDomainSaveImageOpen While implementing virDomainSaveImageGetXMLDesc and virDomainSaveImageDefineXML for the test driver, I realized that there exists already code for saving and loading test images which can be reused. However, it needed to be extracted from testDomainSaveFlags and testDomainRestoreFlags into separate functions. The new functions are inspired by the corresponding QEMU driver code where e.g. qemuDomainSaveImageOpen serves as a helper used by other functions. This series of patches initially extracts the code mentioned above into separate functions and then provides the test driver with implementations for virDomainSaveImageGetXMLDesc and virDomainSaveImageDefineXML which make use of the newly introduced functions. Ilias Stamatis (4): test_driver: extract image saving code into a separate function test_driver: extract image loading code into a separate function test_driver: implement virDomainSaveImageDefineXML test_driver: implement virDomainSaveImageGetXMLDesc src/test/test_driver.c | 293 ++++++++++++++++++++++++++++------------- 1 file changed, 205 insertions(+), 88 deletions(-) -- 2.21.0

2 6

[libvirt] [jenkins-ci PATCH] lcitool: Don't warn when using package manager directly
by Andrea Bolognani 11 Jun '19

11 Jun '19

We only do this when performing operations that the corresponding Ansible module doesn't support, so we know what we're doing and don't want warnings to show up. Note that while only the dnf and yum modules complain at the moment, we might as well use warn=no everywhere so that we're already covered in case in the future the pkgng module starts detecting this as well. Signed-off-by: Andrea Bolognani <abologna(a)redhat.com> --- guests/playbooks/update/tasks/base.yml | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/guests/playbooks/update/tasks/base.yml b/guests/playbooks/update/tasks/base.yml index 8fe114e..e0efe5d 100644 --- a/guests/playbooks/update/tasks/base.yml +++ b/guests/playbooks/update/tasks/base.yml @@ -52,11 +52,15 @@ - name: Update installed packages shell: '{{ package_manager }} update && {{ package_manager }} upgrade -y' + args: + warn: no when: - package_format == 'pkg' - name: Clean up packages after update shell: '{{ package_manager }} clean packages -y && {{ package_manager }} autoremove -y' + args: + warn: no when: - package_format == 'rpm' @@ -69,6 +73,8 @@ - name: Clean up packages after update shell: '{{ package_manager }} clean -y && {{ package_manager }} autoremove -y' + args: + warn: no when: - package_format == 'pkg' -- 2.21.0

2 4

Re: [libvirt] [Qemu-devel] PCI(e): Documentation "io-reserve" and related properties?
by Andrea Bolognani 11 Jun '19

11 Jun '19

On Thu, 2019-06-06 at 14:20 -0400, Michael S. Tsirkin wrote: > On Thu, Jun 06, 2019 at 06:19:43PM +0200, Kashyap Chamarthy wrote: > > Hi folks, > > > > Today I learnt about some obscure PCIe-related properties, in context of > > the adding PCIe root ports to a guest, namely: > > > > io-reserve > > mem-reserve > > bus-reserve > > pref32-reserve > > pref64-reserve > > > > Unfortunately, the commit[*] that added them provided no documentation > > whatsover. > > > > In my scenario, I was specifically wondering about what does > > "io-reserve" mean, in what context to use it, etc. (But documentation > > about other properties is also welcome.) > > > > Anyone more well-versed in this area care to shed some light? > > > > > > [*] 6755e618d0 (hw/pci: add PCI resource reserve capability to legacy > > PCI bridge, 2018-08-21) > > So normally bios would reserve just enough io space to satisfy all > devices behind a bridge. What if you intend to hotplug more devices? > These properties allow you to ask bios to reserve extra space. Is it fair to say that setting io-reserve=0 for a pcie-root-port would be a way to implement the requirements set forth in https://bugzilla.redhat.com/show_bug.cgi?id=1408810 ? I tested this on aarch64 and it seems to work as expected, but then again without documentation it's hard to tell. More specifically, I created an aarch64/virt guest with several pcie-root-ports and it couldn't boot much further than GRUB when the number of ports exceeded 24, but as soon as I added the io-reserve=0 option I could get the same guest to boot fine with 32 or even 64 pcie-root-ports. I'm attaching the boot log for reference: there are a bunch of messages about the topic but they would appear to be benign. Hotplug seemed to work too: I tried with a single virtio-net-pci and I could access the network. My understanding is that PCIe devices are required to work without IO space, so this behavior matches my expectations. I wonder, though, what would happen if I had something like -device pcie-root-port,io-reserve=0,id=pci.1 -device pcie-pci-bridge,bus=pci.1 Would I be able to hotplug conventional PCI devices into the pcie-pci-bridge, or would the lack of IO space reservation for the pcie-root-port cause issues with that? -- Andrea Bolognani / Red Hat / Virtualization

2 1

[libvirt] Question about Windows builds
by Christopher Loyd Nugent 11 Jun '19

11 Jun '19

My name is Christopher Nugent. This is my first time posting to the mailing list, and I am still adjusting to the community norms. If I do anything out of line, please let me know. Anyway, on to the question: I am attempting to use libvirt in a Windows application I am developing, and came upon the following in the documentation: Libvirt is known to work as a client (not server) on Windows XP (32-bit), and Windows 7 (64-bit). I am a bit confused as to what this means. Does it mean that I won't be able to use libvirt in a host configuration, Hyper-V acting as the underlying hypervisor? I am posting to the development list because, if I am right, I would like to donate my time to amend the situation. My application will be cross-platform and will support multiple hypervisors, so using libvirt will help me not have to duplicate functionality. Thank you for your time. --Chris Nugent.

2 1

[libvirt] [PATCH]daemon: Fix a crash during virNetlinkEventServiceStopAll
by Liu Haitao 11 Jun '19

11 Jun '19

The virNetlinkEventServiceStopAll() should be executed behind virStateCleanup(), for some important resources like(static virNetlinkEventSrvPrivatePtr server) are freed unexpected. However virStateCleanup() need to use this variable(server). The call trace of virNetlinkEventServiceStopAll: virNetlinkEventServiceStopAll() --> virNetlinkEventServiceStop() --> server[protocol] = NULL; // set server to null The call trace of virStateCleanup(): virStateCleanup() -->qemuStateCleanup() -->qemuProcessStop() -->virNetDevMacVLanDeleteWithVPortProfile() -->virNetlinkEventRemoveClient() --> srv = server[protocol] In virNetlinkEventRemoveClient() the variable server is used again, but now it is null that is freed by virNetlinkEventServiceStopAll().So it would case a crash . The call trace of crash: (gdb) bt 0 __GI___pthread_mutex_lock (mutex=0x0) at /usr/src/debug/glibc/2.24-r0/git/nptl/pthread_mutex_lock.c:67 1 0x00007fb0d555d0f9 in virNetlinkEventRemoveClient () from /usr/lib64/libvirt.so.0 2 0x00007fb0d55551df in virNetDevMacVLanDeleteWithVPortProfile () from /usr/lib64/libvirt.so.0 3 0x00007fb0c1131251 in qemuProcessStop () from /usr/lib64/libvirt/connection-driver/libvirt_driver_qemu.so 4 0x00007fb0c11995ea in ?? () from /usr/lib64/libvirt/connection-driver/libvirt_driver_qemu.so 5 0x00007fb0d5588c5b in ?? () from /usr/lib64/libvirt.so.0 6 0x00007fb0d5587fe8 in ?? () from /usr/lib64/libvirt.so.0 7 0x00007fb0d19533f4 in start_thread (arg=0x7fb0be17b700) at /usr/src/debug/glibc/2.24-r0/git/nptl/pthread_create.c:456 8 0x00007fb0d128f10f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105 Signed-off-by: Liu Haitao <haitao.liu(a)windriver.com> --- src/remote/remote_daemon.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/remote/remote_daemon.c b/src/remote/remote_daemon.c index c3782971f1..7da20a6644 100644 --- a/src/remote/remote_daemon.c +++ b/src/remote/remote_daemon.c @@ -1464,8 +1464,6 @@ int main(int argc, char **argv) { /* Keep cleanup order in inverse order of startup */ virNetDaemonClose(dmn); - virNetlinkEventServiceStopAll(); - if (driversInitialized) { /* NB: Possible issue with timing window between driversInitialized * setting if virNetlinkEventServerStart fails */ @@ -1473,6 +1471,8 @@ int main(int argc, char **argv) { virStateCleanup(); } + virNetlinkEventServiceStopAll(); + virObjectUnref(adminProgram); virObjectUnref(srvAdm); virObjectUnref(qemuProgram); -- 2.21.0

3 2

[libvirt] [PATCH 0/4] incremental backup: QMP interactions
by Eric Blake 11 Jun '19

11 Jun '19

I'm trying to break my incremental backup work into smaller pieces so I can make progress and actually get some code committed, while I continue to hammer away at preparing a v9 series that addresses even more review comments and things learned during testing. These few patches represent the bulk of 14-15/21 from v8, except that the operation to update Checkpoint size must come later in the series when checkpoint_conf.h is ready. Another reason to commit this now, even without the incremental backup clients of the new capabilities, is that capability additions tend to be a conflict magnet, so I'd rather stabilize this and reduce the amount of rebase work I have been doing. Changes from v8: - improve testing of nbd-server-start - split up QMP changes into more manageable pieces - address formatting review comments Eric Blake (4): backup: Prepare for Unix sockets in QMP nbd-server-start backup: Add two new qemu capabilities backup: Add new qemu monitor bitmap backup: Add new parameters to qemu monitor nbd-server-add src/qemu/qemu_capabilities.h | 4 + src/qemu/qemu_monitor.h | 29 +++- src/qemu/qemu_monitor_json.h | 24 ++- src/qemu/qemu_capabilities.c | 6 + src/qemu/qemu_migration.c | 9 +- src/qemu/qemu_monitor.c | 74 ++++++++- src/qemu/qemu_monitor_json.c | 149 +++++++++++++++++- .../caps_4.0.0.aarch64.xml | 2 + .../qemucapabilitiesdata/caps_4.0.0.ppc64.xml | 2 + .../caps_4.0.0.riscv32.xml | 2 + .../caps_4.0.0.riscv64.xml | 2 + .../qemucapabilitiesdata/caps_4.0.0.s390x.xml | 2 + .../caps_4.0.0.x86_64.xml | 2 + tests/qemumonitorjsontest.c | 60 ++++++- 14 files changed, 341 insertions(+), 26 deletions(-) -- 2.20.1

2 19

[libvirt] [RFC PATCH] qemumonitorjsontest: Use VIR_AUTOPTR for test cleanup
by Eric Blake 11 Jun '19

11 Jun '19

Everywhere else is switching, we might as well use it here, too. Signed-off-by: Eric Blake <eblake(a)redhat.com> --- Partial patch - is it worth me continuing the cleanups on the rest of the file? --- tests/qemumonitortestutils.h | 3 +++ tests/qemumonitorjsontest.c | 35 +++++++++++++++-------------------- 2 files changed, 18 insertions(+), 20 deletions(-) diff --git a/tests/qemumonitortestutils.h b/tests/qemumonitortestutils.h index 8461c80caa..a2d2d30820 100644 --- a/tests/qemumonitortestutils.h +++ b/tests/qemumonitortestutils.h @@ -24,6 +24,7 @@ # include "qemu/qemu_conf.h" # include "qemu/qemu_monitor.h" # include "qemu/qemu_agent.h" +# include "virautoclean.h" typedef struct _qemuMonitorTest qemuMonitorTest; typedef qemuMonitorTest *qemuMonitorTestPtr; @@ -102,4 +103,6 @@ qemuMonitorPtr qemuMonitorTestGetMonitor(qemuMonitorTestPtr test); qemuAgentPtr qemuMonitorTestGetAgent(qemuMonitorTestPtr test); virDomainObjPtr qemuMonitorTestGetDomainObj(qemuMonitorTestPtr test); +VIR_DEFINE_AUTOPTR_FUNC(qemuMonitorTest, qemuMonitorTestFree); + #endif /* LIBVIRT_QEMUMONITORTESTUTILS_H */ diff --git a/tests/qemumonitorjsontest.c b/tests/qemumonitorjsontest.c index a7f64058d4..10bffce2a3 100644 --- a/tests/qemumonitorjsontest.c +++ b/tests/qemumonitorjsontest.c @@ -152,12 +152,11 @@ testQemuMonitorJSONGetStatus(const void *opaque) { const testGenericData *data = opaque; virDomainXMLOptionPtr xmlopt = data->xmlopt; - qemuMonitorTestPtr test = qemuMonitorTestNewSchema(xmlopt, data->schema); - int ret = -1; + VIR_AUTOPTR(qemuMonitorTest) test = NULL; bool running = false; virDomainPausedReason reason = 0; - if (!test) + if (!(test = qemuMonitorTestNewSchema(xmlopt, data->schema))) return -1; if (qemuMonitorTestAddItem(test, "query-status", @@ -168,7 +167,7 @@ testQemuMonitorJSONGetStatus(const void *opaque) " \"running\": true " " } " "}") < 0) - goto cleanup; + return -1; if (qemuMonitorTestAddItem(test, "query-status", "{ " " \"return\": { " @@ -176,7 +175,7 @@ testQemuMonitorJSONGetStatus(const void *opaque) " \"running\": false " " } " "}") < 0) - goto cleanup; + return -1; if (qemuMonitorTestAddItem(test, "query-status", "{ " " \"return\": { " @@ -185,61 +184,57 @@ testQemuMonitorJSONGetStatus(const void *opaque) " \"running\": false " " } " "}") < 0) - goto cleanup; + return -1; if (qemuMonitorGetStatus(qemuMonitorTestGetMonitor(test), &running, &reason) < 0) - goto cleanup; + return -1; if (!running) { virReportError(VIR_ERR_INTERNAL_ERROR, "%s", "Running was not true"); - goto cleanup; + return -1; } if (reason != VIR_DOMAIN_PAUSED_UNKNOWN) { virReportError(VIR_ERR_INTERNAL_ERROR, "Reason was unexpectedly set to %d", reason); - goto cleanup; + return -1; } if (qemuMonitorGetStatus(qemuMonitorTestGetMonitor(test), &running, &reason) < 0) - goto cleanup; + return -1; if (running) { virReportError(VIR_ERR_INTERNAL_ERROR, "%s", "Running was not false"); - goto cleanup; + return -1; } if (reason != VIR_DOMAIN_PAUSED_UNKNOWN) { virReportError(VIR_ERR_INTERNAL_ERROR, "Reason was unexpectedly set to %d", reason); - goto cleanup; + return -1; } if (qemuMonitorGetStatus(qemuMonitorTestGetMonitor(test), &running, &reason) < 0) - goto cleanup; + return -1; if (running) { virReportError(VIR_ERR_INTERNAL_ERROR, "%s", "Running was not false"); - goto cleanup; + return -1; } if (reason != VIR_DOMAIN_PAUSED_MIGRATION) { virReportError(VIR_ERR_INTERNAL_ERROR, "Reason was unexpectedly set to %d", reason); - goto cleanup; + return -1; } - ret = 0; - - cleanup: - qemuMonitorTestFree(test); - return ret; + return 0; } static int -- 2.20.1

2 1