- Devel - libvirt List Archives

[libvirt] [PATCH v2 00/23] qemu: Add support for new vcpu hotplug and unplug
by Peter Krempa 24 Aug '16

24 Aug '16

Version 2 attempts to address feedback on v1: - added more documentation - fixed various typos - fixed bugs appearing when restarting daemon - fixed fallback code - tested upgrade of libvirt Some of the patches were already pushed and this series is rebased on top of that changes. Patches 1-18 with exception of 16 were more or less ACKed already. I've dropped the last patch adding the events from this series. I'm working on adding a new event for vcpu lifecycle. I'm also working on reporting of the vcpu granularity via the domcapabilities API. I'm going to post those separately as well as the new API that will allow modifying the vcpus individually. Peter Krempa (23): qemu: monitor: Return structures from qemuMonitorGetCPUInfo qemu: monitor: Return struct from qemuMonitor(Text|Json)QueryCPUs qemu: caps: Add capability for query-hotpluggable-cpus command qemu: Forbid config when topology based cpu count doesn't match the config qemu: capabilities: Extract availability of new cpu hotplug for machine types qemu: monitor: Extract QOM path from query-cpus reply qemu: monitor: Add support for calling query-hotpluggable-cpus qemu: monitor: Add algorithm for combining query-(hotpluggable-)-cpus data tests: Add test infrastructure for qemuMonitorGetCPUInfo tests: cpu-hotplug: Add data for ppc64 platform including hotplug tests: cpu-hotplug: Add data for ppc64 out-of-order hotplug tests: cpu-hotplug: Add data for ppc64 without threads enabled qemu: domain: Extract cpu-hotplug related data qemu: domain: Prepare for VCPUs vanishing while libvirt is not running util: Extract and rename qemuDomainDelCgroupForThread to virCgroupDelThread conf: Add XML for individual vCPU hotplug qemu: migration: Prepare for non-contiguous vcpu configurations qemu: command: Add helper to convert vcpu definition to JSON props qemu: process: Copy final vcpu order information into the vcpu definition qemu: command: Add support for sparse vcpu topologies qemu: Use mondern vcpu hotplug approach if possible qemu: hotplug: Allow marking unplugged devices by alias qemu: hotplug: Add support for VCPU unplug docs/formatdomain.html.in | 40 +++ docs/schemas/domaincommon.rng | 25 ++ src/conf/domain_conf.c | 152 +++++++++- src/conf/domain_conf.h | 6 + src/libvirt_private.syms | 1 + src/qemu/qemu_capabilities.c | 31 +- src/qemu/qemu_capabilities.h | 3 + src/qemu/qemu_command.c | 50 +++- src/qemu/qemu_command.h | 3 + src/qemu/qemu_domain.c | 312 +++++++++++++++++---- src/qemu/qemu_domain.h | 19 +- src/qemu/qemu_driver.c | 246 +++++++++------- src/qemu/qemu_hotplug.c | 124 +++++++- src/qemu/qemu_hotplug.h | 7 + src/qemu/qemu_migration.c | 16 +- src/qemu/qemu_monitor.c | 260 ++++++++++++++++- src/qemu/qemu_monitor.h | 58 +++- src/qemu/qemu_monitor_json.c | 266 +++++++++++++++--- src/qemu/qemu_monitor_json.h | 8 +- src/qemu/qemu_monitor_text.c | 41 +-- src/qemu/qemu_monitor_text.h | 3 +- src/qemu/qemu_process.c | 182 +++++++++++- src/util/vircgroup.c | 20 ++ src/util/vircgroup.h | 4 + .../generic-vcpus-individual.xml | 23 ++ tests/genericxml2xmltest.c | 2 + tests/qemucapabilitiesdata/caps_2.7.0.x86_64.xml | 55 ++-- .../qemumonitorjson-cpuinfo-ppc64-basic-cpus.json | 77 +++++ ...emumonitorjson-cpuinfo-ppc64-basic-hotplug.json | 27 ++ .../qemumonitorjson-cpuinfo-ppc64-basic.data | 40 +++ ...mumonitorjson-cpuinfo-ppc64-hotplug-1-cpus.json | 149 ++++++++++ ...onitorjson-cpuinfo-ppc64-hotplug-1-hotplug.json | 28 ++ .../qemumonitorjson-cpuinfo-ppc64-hotplug-1.data | 51 ++++ ...mumonitorjson-cpuinfo-ppc64-hotplug-2-cpus.json | 221 +++++++++++++++ ...onitorjson-cpuinfo-ppc64-hotplug-2-hotplug.json | 29 ++ .../qemumonitorjson-cpuinfo-ppc64-hotplug-2.data | 62 ++++ ...mumonitorjson-cpuinfo-ppc64-hotplug-4-cpus.json | 221 +++++++++++++++ ...onitorjson-cpuinfo-ppc64-hotplug-4-hotplug.json | 29 ++ .../qemumonitorjson-cpuinfo-ppc64-hotplug-4.data | 62 ++++ ...umonitorjson-cpuinfo-ppc64-no-threads-cpus.json | 77 +++++ ...nitorjson-cpuinfo-ppc64-no-threads-hotplug.json | 125 +++++++++ .../qemumonitorjson-cpuinfo-ppc64-no-threads.data | 72 +++++ ...nitorjson-cpuinfo-x86-basic-pluggable-cpus.json | 50 ++++ ...orjson-cpuinfo-x86-basic-pluggable-hotplug.json | 82 ++++++ ...emumonitorjson-cpuinfo-x86-basic-pluggable.data | 39 +++ tests/qemumonitorjsontest.c | 183 +++++++++++- .../qemuxml2argv-cpu-hotplug-startup.args | 20 ++ .../qemuxml2argv-cpu-hotplug-startup.xml | 29 ++ tests/qemuxml2argvtest.c | 2 + tests/testutils.c | 4 +- 50 files changed, 3360 insertions(+), 276 deletions(-) create mode 100644 tests/genericxml2xmlindata/generic-vcpus-individual.xml create mode 100644 tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-ppc64-basic-cpus.json create mode 100644 tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-ppc64-basic-hotplug.json create mode 100644 tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-ppc64-basic.data create mode 100644 tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-ppc64-hotplug-1-cpus.json create mode 100644 tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-ppc64-hotplug-1-hotplug.json create mode 100644 tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-ppc64-hotplug-1.data create mode 100644 tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-ppc64-hotplug-2-cpus.json create mode 100644 tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-ppc64-hotplug-2-hotplug.json create mode 100644 tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-ppc64-hotplug-2.data create mode 100644 tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-ppc64-hotplug-4-cpus.json create mode 100644 tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-ppc64-hotplug-4-hotplug.json create mode 100644 tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-ppc64-hotplug-4.data create mode 100644 tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-ppc64-no-threads-cpus.json create mode 100644 tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-ppc64-no-threads-hotplug.json create mode 100644 tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-ppc64-no-threads.data create mode 100644 tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-x86-basic-pluggable-cpus.json create mode 100644 tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-x86-basic-pluggable-hotplug.json create mode 100644 tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-x86-basic-pluggable.data create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-hotplug-startup.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-hotplug-startup.xml -- 2.8.2

4 37

[libvirt] libvirt-python virNodeGetInfo returns None
by Christian Loehle 24 Aug '16

24 Aug '16

I'm trying to use virt-manager with a custom libvirt hypervisor driver. My current problem is that virt-manager closes the connection because virNodeGetInfo(the python binding) returns None: Traceback (most recent call last): File "/home/cloehle/Documents/libvirt/virt-manager/virtManager/connection.py", line 1390, in tick_from_engine self._tick(*args, **kwargs) File "/home/cloehle/Documents/libvirt/virt-manager/virtManager/connection.py", line 1280, in _tick self._hostinfo = self._backend.getInfo() File "/usr/lib/python2.7/dist-packages/libvirt.py", line 3612, in getInfo if ret is None: raise libvirtError ('virNodeGetInfo() failed', conn=self) libvirtError: internal error: client socket is closed The virNodeGetInfo function of my driver should set a valid virNodeInfoPtr, since it only consists of the line: return nodeGetInfo(NULL, info); virsh shows no problems which is why I suspect this is a problem with libvirt-python. So I looked at the source and the first thing that I noticed is in line 2753 of libvirt-override.c: if (!PyArg_ParseTuple(args, (char *)"O:virDomainGetInfo", &pyobj_conn)) return NULL; Since this is for virNodeGetInfo this should probably be virNodeGetInfo instead of domain(the same thing occurs in line 2794 for another function). This could be my source of error but doesn't have to be. Could someone walk me through finding the reason why libvirt-python returns None for my virNodeGetInfo? Is there any good way of debugging where exactly libvirt-python encounters an error and returns None? Any help appreciated, Christian Loehle

2 1

[libvirt] Does libvirt live migration have error handling on port bind failure
by Prasanna Kalever 24 Aug '16

24 Aug '16

Hello, This was the scenario close to 3 years back, libvirt's live migration tries to use ports in ephemeral port range, but has no fallback to use (an)other port(s) when the one it wants is already in use. If some port say 49152 is already used by some application say gluster in our case (gluster as of today also uses 49152-65535), live migration fails because of lack of fallback mechanism in libvirt, that's where gluster had compromised to go with some hack [1] on bug [2] since getting that addressed in libvirt takes more time than it does with gluster. As may releases passed from then in libvirt, I hope now there exist a fallback mechanism for port conflicts in libvirt. Can someone confirm so ? Also It will be greatly appreciable, if someone can tell how the port binding (mostly defense on clash) works with libvirt live migration today ? Sincere Thanks, -- Prasanna

3 7

[libvirt] [PATCH 0/9] add ACL checks to vz driver
by Nikolay Shirokovskiy 24 Aug '16

24 Aug '16

First (patches 1 - 8) prepare driver to add checks. Nikolay Shirokovskiy (9): vz: expand start/stop/... APIs for ACL checks vz: implement plain create API thru createFlags instead of visa versa vz: factor out block stats impl vz: factor out converting block stats to params vz: add missing flagged versions of API functions vz: expand setting memory API calls vz: prepare migration for ACL checks remote: rename protocol names for close callbacks vz: add ACL checks to API calls daemon/remote.c | 4 +- src/Makefile.am | 5 +- src/check-aclrules.pl | 1 + src/remote/remote_driver.c | 4 +- src/remote/remote_protocol.x | 8 +- src/vz/vz_driver.c | 889 +++++++++++++++++++++++++++++++++++-------- src/vz/vz_sdk.c | 172 ++++----- src/vz/vz_sdk.h | 23 +- 8 files changed, 828 insertions(+), 278 deletions(-) -- 1.8.3.1

2 19

[libvirt] [PATCH RFC 0/5] Remove usb address set caching
by Tomasz Flendrich 23 Aug '16

23 Aug '16

During my work on removing addresses caching, usb addresses were added :). It should be applied on top of: https://www.redhat.com/archives/libvir-list/2016-August/msg00945.html or some small conflicts appear. I took an approach where exactly the same function is used to both calculate and recalculate the address set. It forces us to keep all the usb address handling in such state that reusing that function doesn't perform any changes that aren't needed. It might even be possible to unify the handling of usb devices into one function, "qemuDomainAssignUSBAddresses", and remove some code. For example, virDomainUSBAddressEnsure looks almost exactly like qemuDomainAssignUSBPorts plus virDomainUSBAddressReserve. The end goal would be simply calling qemuDomainAssignUSBAddresses() as many times as we want, for example when creating a new domain or after a hotplug. To see what I mean, please take a look at qemuDomainAttachUSBMassStorageDevice. If I remove the call to virDomainUSBAddressEnsure and move creating the USB address set somewhere down (after virDomainDiskInsertPreAlloced), it works - the address is assigned flawlessly. Does it make any sense? Is there any reason why we don't add new usb hubs when hotplugging devices? By the way please excuse me for resending an old patch series a few minutes ago, it was an accident. Tomasz Flendrich (5): Add qemuDomainUSBAddrSetCreateFromDomain qemu_hotplug: use a recalculated usb address set remove qemuDomainReleaseDeviceAddress and its uses remove unused virDomainUSBAddressRelease Add a USB hotplug testcase for reattachment src/conf/domain_addr.c | 30 ------------- src/conf/domain_addr.h | 5 --- src/libvirt_private.syms | 1 - src/qemu/qemu_domain.c | 3 +- src/qemu/qemu_domain.h | 2 - src/qemu/qemu_domain_address.c | 62 ++++++++++++--------------- src/qemu/qemu_domain_address.h | 8 ++-- src/qemu/qemu_hotplug.c | 95 +++++++++++------------------------------- src/qemu/qemu_process.c | 6 +-- tests/qemuhotplugtest.c | 7 +++- 10 files changed, 62 insertions(+), 157 deletions(-) -- 1.9.1

2 7

[libvirt] network ethernet - device not up and ip not assigned
by Vasiliy Tolstov 23 Aug '16

23 Aug '16

I'm install latest libvir and configure network to assign some ip to ethernet device. But after start tap device is down and no addresses assigned. My investigation: qemu_interface.c have functions: qemuInterfaceStartDevice and qemuInterfaceStopDevice In start device in case of ethernet device no action performed (this is bug i think). In stop device i see, that we try to assign ip address to device (why?) I think we need to move assigning addresses from stop device, to start device, also note, that for routes we need device to up (how we deal in case of user in xml specify device is down and have route element inside xml for this device?) In case of stop device i think we does not need anything (in case of linux) becaue when tap deleted routes and addresses dissapeared from the kernel. What do you think? -- Vasiliy Tolstov, e-mail: v.tolstov(a)selfip.ru

2 1

[libvirt] [PATCH] lxc: don't try to reference NULL when mounting filesystems
by Daniel P. Berrange 22 Aug '16

22 Aug '16

<filesystem type='ram' accessmode='passthrough'> <source usage='524288' units='KiB'/> <target dir='/dev/shm'/> </filesystem> would lead to lxcContainerMountAllFS calling STRPREFIX on a NLL pointer because it failed to check if fs->src->path was non-NULL. This is a regression caused by commit da665fbd4858890fbb3bbf5da2a7b6ca37bb3220 Author: Olga Krishtal <okrishtal(a)virtuozzo.com> Date: Thu Jul 14 16:52:38 2016 +0300 filesystem: adds possibility to use storage pool as fs source Signed-off-by: Olga Krishtal <okrishtal(a)virtuozzo.com> Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com> --- src/lxc/lxc_container.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/src/lxc/lxc_container.c b/src/lxc/lxc_container.c index e1eb434..5357df4 100644 --- a/src/lxc/lxc_container.c +++ b/src/lxc/lxc_container.c @@ -1627,8 +1627,7 @@ static int lxcContainerMountAllFS(virDomainDefPtr vmDef, if (lxcContainerResolveSymlinks(vmDef->fss[i], false) < 0) return -1; - - if (!(vmDef->fss[i]->src && + if (!(vmDef->fss[i]->src && vmDef->fss[i]->src->path && STRPREFIX(vmDef->fss[i]->src->path, vmDef->fss[i]->dst)) && lxcContainerUnmountSubtree(vmDef->fss[i]->dst, false) < 0) return -1; -- 2.7.4

3 2

[libvirt] remove-the-dead
by JieWang 22 Aug '16

22 Aug '16

[PATCH] remove the dead code this patch is to remove the dead code Signed-off-by: JieWang <wangjie88(a)huawei.com>

1 0

[libvirt] [PATCH] remove the dead code this patch is to remove the dead code Signed-off-by: JieWang <wangjie88@huawei.com>
by JieWang 22 Aug '16

22 Aug '16

Signed-off-by: JieWang <wangjie88(a)huawei.com> --- src/qemu/qemu_migration.c | 1 - 1 file changed, 1 deletion(-) diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c index 6a683f7..759e15a 100644 --- a/src/qemu/qemu_migration.c +++ b/src/qemu/qemu_migration.c @@ -1602,7 +1602,6 @@ qemuMigrationPrecreateDisk(virConnectPtr conn, _("cannot precreate storage for disk type '%s'"), virStorageTypeToString(disk->src->type)); goto cleanup; - break; } if ((vol = virStorageVolLookupByName(pool, volName))) { -- 1.9.5.msysgit.1

1 0

[libvirt] [PATCH] remove the dead code this patch is to remove the dead code Signed-off-by: JieWang <wangjie88@huawei.com>
by Jie Wang 22 Aug '16

22 Aug '16

From: JieWang <wangjie88(a)huawei.com> Signed-off-by: JieWang <wangjie88(a)huawei.com> --- src/qemu/qemu_migration.c | 1 - 1 file changed, 1 deletion(-) diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c index 6a683f7..759e15a 100644 --- a/src/qemu/qemu_migration.c +++ b/src/qemu/qemu_migration.c @@ -1602,7 +1602,6 @@ qemuMigrationPrecreateDisk(virConnectPtr conn, _("cannot precreate storage for disk type '%s'"), virStorageTypeToString(disk->src->type)); goto cleanup; - break; } if ((vol = virStorageVolLookupByName(pool, volName))) { -- 1.9.5.msysgit.1

1 0