- Devel - libvirt List Archives

[libvirt] [libvirt-php][PATCH 0/2] Couple of example fixes
by Michal Privoznik 22 Sep '16

22 Sep '16

Pushed under "I'm the PHP master" rule. Michal Privoznik (2): examples: Sort domains examples: Die early if getting a screenshot fails examples/index.php | 2 +- examples/libvirt.php | 8 ++++++++ 2 files changed, 9 insertions(+), 1 deletion(-) -- 2.8.4

2 3

[libvirt] [PATCH] qemu: fix libvirtd crash in migration after vm shutdown
by weifuqiang 22 Sep '16

22 Sep '16

[PATCH] qemu: fix libvirtd crash in migration after vm shutdown If we shutdown a guest, then migrate it without the arg XML, libvirtd will get crashed. The reason is that: 1 during shutdown callback, qemuProcessStop() , it points vm->def to vm->newDef 2 during migration, it frees persistentDef, which points to vm->newDef when the arg XML is NULL. However, because vm->newDef is now vm->def, what we IN FACT freed is vm->def. 3 it will refer to vm->def after step2, thus invalid read/write causes libvirtd crash We needn't to free persistentDef if persist_xml is NULL, because no extra def was alloced if persistent_xml is NULL. --- src/qemu/qemu_migration.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c index 6a683f7..3636c93 100644 --- a/src/qemu/qemu_migration.c +++ b/src/qemu/qemu_migration.c @@ -4915,7 +4915,7 @@ qemuMigrationRun(virQEMUDriverPtr driver, VIR_WARN("Unable to encode migration cookie"); } - if (persistDef != vm->newDef) + if (persist_xml && persistDef) virDomainDefFree(persistDef); qemuMigrationCookieFree(mig); -- 1.9.5.msysgit.1

3 3

[libvirt] [PATCH 0/7] IVSHMEM round two, this time with cookies
by Martin Kletzander 22 Sep '16

22 Sep '16

Actually just migration cookie flag. Also this version dropped the role and model to make everything more sunshine-n-unicorns. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1347049 Martin Kletzander (7): conf: Fix virDomainShmemDefFind qemu: Add capabilities for ivshmem-{plain,doorbell} qemu: Save various defaults for shmem qemu: Add qemuDomainSupportsNonLegacyShmem qemu: Disable migration with legacy ivshmem qemu: Support newer ivshmem device variants qemu: Add support for hot/cold-(un)plug of shmem devices docs/formatdomain.html.in | 6 +- src/conf/domain_conf.c | 4 +- src/qemu/qemu_capabilities.c | 4 + src/qemu/qemu_capabilities.h | 2 + src/qemu/qemu_command.c | 109 +++++++++- src/qemu/qemu_command.h | 10 + src/qemu/qemu_domain.c | 24 +++ src/qemu/qemu_domain.h | 3 + src/qemu/qemu_driver.c | 39 +++- src/qemu/qemu_hotplug.c | 231 ++++++++++++++++++++- src/qemu/qemu_hotplug.h | 6 + src/qemu/qemu_migration.c | 27 ++- .../caps_2.6.0-gicv2.aarch64.xml | 2 + .../caps_2.6.0-gicv3.aarch64.xml | 2 + tests/qemucapabilitiesdata/caps_2.6.0.ppc64le.xml | 2 + tests/qemucapabilitiesdata/caps_2.6.0.x86_64.xml | 2 + tests/qemucapabilitiesdata/caps_2.7.0.x86_64.xml | 2 + tests/qemuhotplugtest.c | 21 ++ .../qemuhotplug-ivshmem-doorbell-detach.xml | 6 + .../qemuhotplug-ivshmem-doorbell.xml | 3 + .../qemuhotplug-ivshmem-plain-detach.xml | 5 + .../qemuhotplug-ivshmem-plain.xml | 1 + ...muhotplug-base-live+ivshmem-doorbell-detach.xml | 1 + .../qemuhotplug-base-live+ivshmem-doorbell.xml | 63 ++++++ .../qemuhotplug-base-live+ivshmem-plain-detach.xml | 1 + .../qemuhotplug-base-live+ivshmem-plain.xml | 57 +++++ .../qemuxml2argv-shmem-plain-doorbell.args | 46 ++++ .../qemuxml2argv-shmem-plain-doorbell.xml | 1 + tests/qemuxml2argvdata/qemuxml2argv-shmem.args | 18 +- tests/qemuxml2argvtest.c | 3 + tests/qemuxml2xmloutdata/qemuxml2xmlout-shmem.xml | 10 +- 31 files changed, 685 insertions(+), 26 deletions(-) create mode 100644 tests/qemuhotplugtestdevices/qemuhotplug-ivshmem-doorbell-detach.xml create mode 100644 tests/qemuhotplugtestdevices/qemuhotplug-ivshmem-doorbell.xml create mode 100644 tests/qemuhotplugtestdevices/qemuhotplug-ivshmem-plain-detach.xml create mode 100644 tests/qemuhotplugtestdevices/qemuhotplug-ivshmem-plain.xml create mode 120000 tests/qemuhotplugtestdomains/qemuhotplug-base-live+ivshmem-doorbell-detach.xml create mode 100644 tests/qemuhotplugtestdomains/qemuhotplug-base-live+ivshmem-doorbell.xml create mode 120000 tests/qemuhotplugtestdomains/qemuhotplug-base-live+ivshmem-plain-detach.xml create mode 100644 tests/qemuhotplugtestdomains/qemuhotplug-base-live+ivshmem-plain.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-shmem-plain-doorbell.args create mode 120000 tests/qemuxml2argvdata/qemuxml2argv-shmem-plain-doorbell.xml -- 2.10.0

2 12

[libvirt] [PATCH 0/7] Fix some typos.
by Nitesh Konkar 22 Sep '16

22 Sep '16

*** BLURB HERE *** Nitesh Konkar (7): domain_conf.c:fix a typo domain_conf.h:fix a typo domain_conf.c:fix a typo storage_conf.c:fix a typo interface_backend_udev.c:fix a typo esx_driver.c:fix a typo esx_driver.c:fix a typo src/conf/domain_conf.c | 4 ++-- src/conf/domain_conf.h | 2 +- src/conf/storage_conf.c | 2 +- src/esx/esx_driver.c | 4 ++-- src/interface/interface_backend_udev.c | 2 +- 5 files changed, 7 insertions(+), 7 deletions(-) -- 2.1.0

2 9

[libvirt] [PATCH 0/4] fix some libvirtd cleanup leaks and crashes
by Nikolay Shirokovskiy 22 Sep '16

22 Sep '16

Crash situation of last 2 patches can easily simulated, just patch libvirt: diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 30a2830..f6b71d6 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -4515,6 +4515,8 @@ processMonitorEOFEvent(virQEMUDriverPtr driver, unsigned int stopFlags = 0; virObjectEventPtr event = NULL; + sleep(3); + if (qemuProcessBeginStopJob(driver, vm, QEMU_JOB_DESTROY, true) < 0) return; then when it is up and running and there is also a qemu domain running: kill -9 $QEMU_DOMAIN && kill libvirtd If first 2 patches are not applied yet then make sure there is no admin server clients present. Nikolay Shirokovskiy (4): daemon: break cyclic deps between admin clients and daemon daemon: call free callbacks synchronously in event loop impl daemon: keep daemon until all hypervisors drivers are cleaned up qemu: first wait all workers finish on state cleanup daemon/libvirtd.c | 7 ++++- src/qemu/qemu_driver.c | 2 +- src/rpc/virnetdaemon.c | 1 + src/rpc/virnetsocket.c | 70 ++++++++++++++++++++++--------------------------- src/util/vireventpoll.c | 24 +++++++---------- 5 files changed, 50 insertions(+), 54 deletions(-) -- 1.8.3.1

2 6

Re: [libvirt] [RFC v2] libvirt vGPU QEMU integration
by Tian, Kevin 22 Sep '16

22 Sep '16

> From: Tian, Kevin > Sent: Thursday, September 22, 2016 10:33 AM > > > > > > Another example is class-specific attributes such > > > as 'resolution', etc. which you listed under 'display class'. All those > > > attributes should be moved to mdev directory. Only class ID is > > > required under each type. > > > > Can you elaborate on what you're proposing here? If we don't have > > attributes like 'resolution' under the type-id then we can't describe > > to the user the features of the mdev before we create it. I don't > > think anybody wants a 'create it and find out' type of interface. > > Thanks, > > > > I think such way would be racy. What about two clients creating mdev > devices simultaneously? How to guarantee their configuration of class > specific attributes not mutual-impacted since before creation any such > configuration would be global under that type? > > My feeling is that we'd better keep create simple - just write a UUID > to "type-id/create". Any class-specific attribute, if we really want to > support, should be able to be individually configured with required > resource allocated incrementally on top of basic resources allocated > at create stage. Then libvirt can set those attributes between create > and open a mdev device. If this direction is accepted, then naturally > such attributes should be put under mdev directory. Possibly we > don't need a class description under type-id. libvirt just checks directly > whether any known class represented in each mdev directory (vendor > driver will expose it on demand), and then operate attributes under > that class. > Have a better understanding of your concern now. User needs to know and set a list of attributes before requesting to create a new mdev device. From this angle all attributes should be enumerated per type-id. But as I explained above, writing multiple sysfs nodes to create a mdev device is racy. We either need a way to guarantee transactional operations on those nodes, or having type-id directory to only expose supported attributes while programming those attributes has to be through per-mdev directory after mdev device is created... Thanks Kevin

1 0

[libvirt] [PATCHv2] qemu: agent: Fix QEMU guest agent is not available due to an error
by Xiubo Li 22 Sep '16

22 Sep '16

These days, we experienced one qemu guest agent is not available error. Then the guest agent couldn't be used forever before rebooting the libvirtd daemon or reboot the qemu-guest-agent in the VM(you can also reboot the VM) to clear the priv->agentError. This is one bug for a long time in many verisons of libvirtd: https://bugzilla.redhat.com/show_bug.cgi?id=1090551 And there is one python script to reproduce this bug from the bugzilla: https://github.com/aspirer/study/blob/master/qemu-guest-agent/test2.py Just set the timeout to 0 at Line26, you can reproduce it very quickly: rsp = libvirt_qemu.qemuAgentCommand(dom, cmd, 1, 0) // 1 -> 0 The reason why this could happen is that: In case we received something like {"return": {}} for example, it is likely that somebody: 1) Started GA thread which sent one "guest-ping" command with seconds equals to VIR_DOMAIN_QEMU_AGENT_COMMAND_NOWAIT(0) makes this function return immediately without waiting, but after updating the events, it will sleep in virCondWait() or virCondWaitUntil(). 2) While in AgentIO thread the "guest-ping" command is sent successfully, with updating the events it will wait for reply. 3) Then the GA thread is woken up and the mon->msg is set to NULL and exit. 4) At last the AgentIO thread receives the reply of "guest-ping" command with the mon->msg == NULL. This case could be adapt to all the GA commands, including guest-sync, etc. This patch will check if this is the case and don't report an error but return silently. Signed-off-by: Xiubo Li <lixiubo(a)cmss.chinamobile.com> Signed-off-by: Zhuoyu Zhang <zhangzhuoyu(a)cmss.chinamobile.com> Signed-off-by: Wei Tang <tangwei(a)cmss.chinamobile.com> Signed-off-by: Yaowei Bai <baiyaowei(a)cmss.chinamobile.com> Signed-off-by: Qide Chen <chenqide(a)cmss.chinamobile.com> --- Changes in V2: - check value type instead of object type. src/qemu/qemu_agent.c | 37 ++++++++++++++++++++++++++++--------- src/util/virjson.h | 7 +++++++ 2 files changed, 35 insertions(+), 9 deletions(-) diff --git a/src/qemu/qemu_agent.c b/src/qemu/qemu_agent.c index eeede6b..f5408cc 100644 --- a/src/qemu/qemu_agent.c +++ b/src/qemu/qemu_agent.c @@ -308,7 +308,6 @@ qemuAgentIOProcessLine(qemuAgentPtr mon, { virJSONValuePtr obj = NULL; int ret = -1; - unsigned long long id; VIR_DEBUG("Line [%s]", line); @@ -333,16 +332,36 @@ qemuAgentIOProcessLine(qemuAgentPtr mon, obj = NULL; ret = 0; } else { - /* If we've received something like: - * {"return": 1234} - * it is likely that somebody started GA - * which is now processing our previous - * guest-sync commands. Check if this is - * the case and don't report an error but + virJSONValuePtr val; + + /* In case we received something like: + * {"return": {}} for example, + * it is likely that somebody: + * + * 1) Started GA thread which sent one "guest-ping" command + * with seconds equals to VIR_DOMAIN_QEMU_AGENT_COMMAND_NOWAIT(0) + * makes this function return immediately without waiting, but + * after updating the events, it will sleep in virCondWait() or + * virCondWaitUntil(). + * + * 2) While in AgentIO thread the "guest-ping" command is sent + * successfully, with updating the events it will wait for reply. + * + * 3) Then the GA thread is woken up and the mon->msg is set + * to NULL and exit. + * + * 4) At last the AgentIO thread receives the reply of "guest-ping" + * command with the mon->msg == NULL. + * + * This case could be adapt to all the GA commands, including + * guest-sync, etc. + * + * Check if this is the case and don't report an error but * return silently. */ - if (virJSONValueObjectGetNumberUlong(obj, "return", &id) == 0) { - VIR_DEBUG("Ignoring delayed reply to guest-sync: %llu", id); + val = virJSONValueObjectGet(obj, "return"); + if (val && virJSONValueTypeIsValid(val)) { + VIR_DEBUG("Ignoring delayed command reply"); ret = 0; goto cleanup; } diff --git a/src/util/virjson.h b/src/util/virjson.h index 66ed48a..cb1d973 100644 --- a/src/util/virjson.h +++ b/src/util/virjson.h @@ -80,6 +80,13 @@ struct _virJSONValue { } data; }; +static inline bool +virJSONValueTypeIsValid(virJSONValuePtr value) +{ + return ((value->type >= VIR_JSON_TYPE_OBJECT) && + (value->type <= VIR_JSON_TYPE_BOOLEAN)); +} + void virJSONValueFree(virJSONValuePtr value); int virJSONValueObjectCreate(virJSONValuePtr *obj, ...) -- 1.8.3.1

3 2

[libvirt] [PATCH] libxl: support VIR_MIGRATE_PERSIST_DEST migration flag
by Jim Fehlig 22 Sep '16

22 Sep '16

By default, virt-manager (and likely other libvirt-based apps) sets the VIR_MIGRATE_PERSIST_DEST flag when invoking the migrate API, which fails in a Xen setup since the libxl driver does not support the flag. Persisting a domain is a trivial task in the grand scheme of migration, so be nice to libvirt apps and add support for VIR_MIGRATE_PERSIST_DEST in the libxl driver. Signed-off-by: Jim Fehlig <jfehlig(a)suse.com> --- src/libxl/libxl_migration.c | 23 +++++++++++++++++++++++ src/libxl/libxl_migration.h | 1 + 2 files changed, 24 insertions(+) diff --git a/src/libxl/libxl_migration.c b/src/libxl/libxl_migration.c index f1da251..3b0dc74 100644 --- a/src/libxl/libxl_migration.c +++ b/src/libxl/libxl_migration.c @@ -1021,6 +1021,29 @@ libxlDomainMigrationFinish(virConnectPtr dconn, event = NULL; } + if (flags & VIR_MIGRATE_PERSIST_DEST) { + unsigned int oldPersist = vm->persistent; + virDomainDefPtr vmdef; + + vm->persistent = 1; + if (!(vmdef = virDomainObjGetPersistentDef(cfg->caps, + driver->xmlopt, vm))) + goto cleanup; + + if (virDomainSaveConfig(cfg->configDir, cfg->caps, vmdef) < 0) + goto cleanup; + + event = virDomainEventLifecycleNewFromObj(vm, + VIR_DOMAIN_EVENT_DEFINED, + oldPersist ? + VIR_DOMAIN_EVENT_DEFINED_UPDATED : + VIR_DOMAIN_EVENT_DEFINED_ADDED); + if (event) { + libxlDomainEventQueue(driver, event); + event = NULL; + } + } + if (virDomainSaveStatus(driver->xmlopt, cfg->stateDir, vm, cfg->caps) < 0) goto cleanup; diff --git a/src/libxl/libxl_migration.h b/src/libxl/libxl_migration.h index c02026d..8a074a0 100644 --- a/src/libxl/libxl_migration.h +++ b/src/libxl/libxl_migration.h @@ -29,6 +29,7 @@ # define LIBXL_MIGRATION_FLAGS \ (VIR_MIGRATE_LIVE | \ VIR_MIGRATE_PEER2PEER | \ + VIR_MIGRATE_PERSIST_DEST | \ VIR_MIGRATE_UNDEFINE_SOURCE | \ VIR_MIGRATE_PAUSED) -- 2.1.4

2 2

[libvirt] [PATCH] qemu_process: show shutoff reasons when debug log disabled
by Chen Hanxiao 22 Sep '16

22 Sep '16

From: Chen Hanxiao <chenhanxiao(a)gmail.com> We have a few of senarios that libvirtd would invoke qemuProcessStop and leave a "shutting down" in /var/log/libvirt/qemu/$DOMAIN.log. The shutoff reason showing in debug log is also very important for us to know why VM shutting down in domain log, as we seldom enable debug log of libvirtd. Signed-off-by: Chen Hanxiao <chenhanxiao(a)gmail.com> --- src/qemu/qemu_process.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c index b10b053..73e9271 100644 --- a/src/qemu/qemu_process.c +++ b/src/qemu/qemu_process.c @@ -5803,7 +5803,9 @@ void qemuProcessStop(virQEMUDriverPtr driver, virDomainObjBroadcast(vm); if ((timestamp = virTimeStringNow()) != NULL) { - qemuDomainLogAppendMessage(driver, vm, "%s: shutting down\n", timestamp); + qemuDomainLogAppendMessage(driver, vm, "%s: shutting down, reason=%s\n", + timestamp, + virDomainShutoffReasonTypeToString(reason)); VIR_FREE(timestamp); } -- 1.8.3.1

2 1

[libvirt] [PATCH] qemu_process: move graphics validation into separate function
by Pavel Hrdina 22 Sep '16

22 Sep '16

Signed-off-by: Pavel Hrdina <phrdina(a)redhat.com> --- src/qemu/qemu_process.c | 56 +++++++++++++++++++++++++++++-------------------- 1 file changed, 33 insertions(+), 23 deletions(-) diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c index 1f56883..b360f6b 100644 --- a/src/qemu/qemu_process.c +++ b/src/qemu/qemu_process.c @@ -4409,6 +4409,38 @@ qemuProcessStartWarnShmem(virDomainObjPtr vm) } } + +static int +qemuProcessStartValidateGraphics(virDomainObjPtr vm) +{ + size_t i; + + for (i = 0; i < vm->def->ngraphics; i++) { + virDomainGraphicsDefPtr graphics = vm->def->graphics[i]; + + switch (graphics->type) { + case VIR_DOMAIN_GRAPHICS_TYPE_VNC: + case VIR_DOMAIN_GRAPHICS_TYPE_SPICE: + if (graphics->nListens > 1) { + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", + _("QEMU does not support multiple listens for " + "one graphics device.")); + return -1; + } + break; + + case VIR_DOMAIN_GRAPHICS_TYPE_SDL: + case VIR_DOMAIN_GRAPHICS_TYPE_RDP: + case VIR_DOMAIN_GRAPHICS_TYPE_DESKTOP: + case VIR_DOMAIN_GRAPHICS_TYPE_LAST: + break; + } + } + + return 0; +} + + static int qemuProcessStartValidateXML(virQEMUDriverPtr driver, virDomainObjPtr vm, @@ -4456,8 +4488,6 @@ qemuProcessStartValidate(virQEMUDriverPtr driver, virCapsPtr caps, unsigned int flags) { - size_t i; - if (!(flags & VIR_QEMU_PROCESS_START_PRETEND)) { if (vm->def->virtType == VIR_DOMAIN_VIRT_KVM) { VIR_DEBUG("Checking for KVM availability"); @@ -4484,27 +4514,7 @@ qemuProcessStartValidate(virQEMUDriverPtr driver, qemuProcessStartWarnShmem(vm); - for (i = 0; i < vm->def->ngraphics; i++) { - virDomainGraphicsDefPtr graphics = vm->def->graphics[i]; - - switch (graphics->type) { - case VIR_DOMAIN_GRAPHICS_TYPE_VNC: - case VIR_DOMAIN_GRAPHICS_TYPE_SPICE: - if (graphics->nListens > 1) { - virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", - _("QEMU does not support multiple listens for " - "one graphics device.")); - return -1; - } - break; - - case VIR_DOMAIN_GRAPHICS_TYPE_SDL: - case VIR_DOMAIN_GRAPHICS_TYPE_RDP: - case VIR_DOMAIN_GRAPHICS_TYPE_DESKTOP: - case VIR_DOMAIN_GRAPHICS_TYPE_LAST: - break; - } - } + qemuProcessStartValidateGraphics(vm); return 0; } -- 2.10.0

2 2