- Devel - libvirt List Archives

[libvirt] [PATCH] qemu: managedsave: Don't spam logs with warnings about corrupted image
by Peter Krempa 28 May '14

28 May '14

Even successful start of a VM from a managed save image would spam the logs with the following message: Unable to restore from managed state [path]. Maybe the file is corrupted? Re-arrange the logic to output the warning only when the image is corrupted. The flaw was introduced in commit cfc28c66. --- src/qemu/qemu_driver.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 2b852eb..7a29b82 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -6080,14 +6080,14 @@ qemuDomainObjStart(virConnectPtr conn, VIR_WARN("Failed to remove the managed state %s", managed_save); else vm->hasManagedSave = false; - } - if (ret > 0) { - VIR_WARN("Ignoring incomplete managed state %s", managed_save); - } else { + goto cleanup; + } else if (ret < 0) { VIR_WARN("Unable to restore from managed state %s. " "Maybe the file is corrupted?", managed_save); goto cleanup; + } else { + VIR_WARN("Ignoring incomplete managed state %s", managed_save); } } } -- 1.9.3

2 2

[libvirt] [PATCH 0/3] Fix startup of gluster pools
by Peter Krempa 28 May '14

28 May '14

Currently a gluster pool fails to start due to an attempt to canonicalize a path residing on gluster storage. This series rearranges things to avoid that. Peter Krempa (3): storage: Return backing format from virStorageFileGetMetadataFromFD storage: fs: Drop-in replace use of virStorageFileGetMetadataFromBuf utils: storage: Canonicalize paths only for local filesystems src/qemu/qemu_driver.c | 2 +- src/storage/storage_backend_fs.c | 20 +++++++------------- src/util/virstoragefile.c | 27 +++++++++++++++------------ src/util/virstoragefile.h | 3 ++- 4 files changed, 25 insertions(+), 27 deletions(-) -- 1.9.3

2 7

[libvirt] [PATCH] qemu: reject rather than hang on blockcommit of active layer
by Eric Blake 28 May '14

28 May '14

qemu 2.0 added the ability to commit the active layer, but slightly differently than what libvirt had been anticipating in its implementation of the virDomainBlockCommit call. As a result, if you attempt to do a 'virsh blockcommit $dom vda', qemu gets into a state where it is waiting on libvirt to end the job, while libvirt is waiting on qemu to end the job, and the guest is effectively hung with regards to further commands for that block device. I have patches coming down the pipeline that will add full support for blockcommit of the active layer when coupled with qemu 2.0 or later; but they depend on Peter's improvements to block job handling and form enough of a new feature that they are not ready for inclusion in the 1.2.5 release. So for now, just reject the attempt, rather than letting the user get stuck. This is no worse than the behavior of qemu 1.7 rejecting the job. * src/qemu/qemu_driver.c (qemuDomainBlockCommit): Reject active commit. Signed-off-by: Eric Blake <eblake(a)redhat.com> --- This patch should be committed before the 1.2.5 release, while I continue to polish my full series for active commit support for inclusion after the release. src/qemu/qemu_driver.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 2b852eb..f008763 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -15461,6 +15461,15 @@ qemuDomainBlockCommit(virDomainPtr dom, &top_parent))) goto endjob; + /* FIXME: qemu 2.0 supports active commit, but as a two-stage + * process; qemu 2.1 is further improving active commit. We need + * to start support it in libvirt. */ + if (topSource == &disk->src) { + virReportError(VIR_ERR_OPERATION_UNSUPPORTED, "%s", + _("committing the active layer not supported yet")); + goto endjob; + } + if (!topSource->backingStore) { virReportError(VIR_ERR_INVALID_ARG, _("top '%s' in chain for '%s' has no backing file"), -- 1.9.3

2 2

[libvirt] xl and libvirt.
by Alvin Starr 28 May '14

28 May '14

I have been trying do some simulations of an openstack environment on my workstation that is running xen and libvirt. I managed to create nested HVM environments under lx but found a number of shortfalls in libxl code. I have added a nestedhvm as a domain feature and was looking at inspecting the domain configuration when I realized that the persistant data is keept in config files in /var/lib/xen/userdata..... Libvirt and lx have incompatible file names and are using different config formats. Libvirt keeps the data as XML and xl keeps them as xm config files. This means that libvirt domains cannot be manged with xl or xl domains managed by libvirt. Part of me thinks that sticking with the XL file format would be nice from the point of view of being able to use xenlight tools once the domain is configured. At the very least it may make sense to keep an XL copy of the config file in a format that xenlight can use. To achieve my original goal of managing a nested HVM environment from libvirt I need to get the CPUID flags working but I do believe that it would be nice to have the various xen and libvirt tools being able to talk to each other. Any pearls of wisdom would be greatly appreciated. -- Alvin Starr || voice: (905)513-7688 Netvel Inc. || Cell: (416)806-0133 alvin(a)netvel.net ||

3 6

[libvirt] Call for agenda for weekly meeting May 29th, 2014
by Daniel P. Berrange 28 May '14

28 May '14

Hi Folks, Tomorrow (thursday) at 1400 UTC is set for our next weekly meeting on #virt-meeting of irc.oftc.net If you have any agenda items to raise please add them to: https://public.pad.fsfe.org/p/libvirt-community-meeting NB, I will likely be offline tomorrow at the Xen Community Hackathon, so if any agenda items are added, I'll trust that someone else here will chair the meeting the meeting instead.... Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|

1 0

[libvirt] [PATCH 0/5] [RFC] Add support for per-guest-node binding
by Martin Kletzander 28 May '14

28 May '14

Currently we are only able to bind the whole domain to some host nodes using the /domain/numatune/memory element. Numerous requests were made to support host<->guest numa node bindings, so this series tries to pinch an idea on how to do that using /domain/numatune/memnode elements. So here are few ideas I'd like to know others opinions on: For some reason, qemu wants to know what host nodes it can use to for allocation of the memory. While adding support for that, qemu added various memory objects (-object memory*) with different backends. There's 'memory-file' which is used for hugepages and 'memory-ram' which is used for standard allocation. Latest version of the qemu proposal is here: http://lists.gnu.org/archive/html/qemu-devel/2014-05/msg02706.html Caveats: - I'm not sure how cpu hotplug is done with guest numa nodes, but if there is a possibility to increase the number of numa nodes (which does not make sense to me from (a) user point of view and (b) our XMLs and APIs), we need to be able to hotplug the ram as well, - virDomainGetNumaParameters() now reflects only the /domain/numatune/memory settings, not 'memnode' ones, - virDomainSetNumaParameters() is not allowed when there is some /domain/numatune/memnode parameter as we can query memdev info, but not change it (if I understood the QEMU side correctly), - when domain is started, cpuset.mems cgroup is not modified per for each vcpu, this will be fixed, but the question is how to handle it for non-strict settings [*], - automatic numad placement can be now used together with memnode settings which IMHO doesn't make any sense, but I was hesitant to disable that in case somebody has a constructive criticism in this area. - This series alone is broken when used with /domain/memoryBacking/hugepages, because it will still use the memory-ram object, but that will be fixed with Michal's patches on top of this series. One idea how to solve some of the problems is to say that /domain/numatune/memory is set for the whole domain regardless of what anyone puts in /domain/numatune/memnode. virDomainGetNumaParameters() could be extended to tell the info for all guest numa nodes, although it seems new API would suit better for this kind of information. But is it really neede when we are not able to modify it live and the information is available in the domain XML? *) does (or should) this: ... <numatune> <memory mode='strict' placement='static' nodeset='0-7'/> <memnode nodeid='0' mode='preferred' nodeset='7'/> </numatune> ... mean what it looks like it means, that is "in guest node 0, prefer allocating from host node 7 but feel free to allocate from 0-6 as well in case you can't use 7, but never try allocating from host nodes 8-15"? Martin Kletzander (5): conf, schema: add 'id' field for cells conf, schema: add support for numatune memnode element qemu: purely a code movement qemu: numa capability probing qemu: pass numa node binding preferences to qemu docs/formatdomain.html.in | 29 +++- docs/schemas/domaincommon.rng | 22 +++ src/conf/cpu_conf.c | 39 ++++- src/conf/domain_conf.c | 181 +++++++++++++++++---- src/qemu/qemu_capabilities.c | 2 + src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_cgroup.c | 2 + src/qemu/qemu_command.c | 160 ++++++++++++++++-- src/qemu/qemu_command.h | 3 +- src/qemu/qemu_domain.c | 23 ++- src/qemu/qemu_driver.c | 14 +- src/qemu/qemu_process.c | 3 +- src/util/virnuma.h | 14 +- tests/qemuxml2argvdata/qemuxml2argv-cpu-numa1.xml | 6 +- tests/qemuxml2argvdata/qemuxml2argv-cpu-numa2.xml | 6 +- tests/qemuxml2argvdata/qemuxml2argv-cpu-numa3.xml | 25 +++ .../qemuxml2argv-numatune-auto-prefer.args | 6 + .../qemuxml2argv-numatune-auto-prefer.xml | 29 ++++ .../qemuxml2argv-numatune-auto.args | 6 + .../qemuxml2argv-numatune-auto.xml | 26 +++ .../qemuxml2argv-numatune-memnode-nocpu.xml | 25 +++ .../qemuxml2argv-numatune-memnodes-problematic.xml | 31 ++++ .../qemuxml2argv-numatune-memnodes.args | 8 + .../qemuxml2argv-numatune-memnodes.xml | 31 ++++ .../qemuxml2argv-numatune-prefer.args | 6 + .../qemuxml2argv-numatune-prefer.xml | 29 ++++ tests/qemuxml2argvtest.c | 51 ++++-- .../qemuxml2xmlout-cpu-numa1.xml | 28 ++++ .../qemuxml2xmlout-cpu-numa2.xml | 28 ++++ tests/qemuxml2xmltest.c | 4 + tests/qemuxmlnstest.c | 2 +- 31 files changed, 747 insertions(+), 93 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-numa3.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-numatune-auto-prefer.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-numatune-auto-prefer.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-numatune-auto.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-numatune-auto.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-numatune-memnode-nocpu.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-numatune-memnodes-problematic.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-numatune-memnodes.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-numatune-memnodes.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-numatune-prefer.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-numatune-prefer.xml create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-cpu-numa1.xml create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-cpu-numa2.xml -- 1.9.3

2 10

[libvirt] [PATCH] doc: fix documentation of virDomainSet(Get)Metadata
by Dan Kenigsberg 28 May '14

28 May '14

The documentation of the functions should match the argument name in the actual function signature. Signed-off-by: Dan Kenigsberg <danken(a)redhat.com> --- src/libvirt.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/libvirt.c b/src/libvirt.c index 72a9f6d..f01b6dd 100644 --- a/src/libvirt.c +++ b/src/libvirt.c @@ -10109,14 +10109,14 @@ virDomainGetSecurityLabelList(virDomainPtr domain, /** * virDomainSetMetadata: * @domain: a domain object - * @type: type of description, from virDomainMetadataType + * @type: type of metadata, from virDomainMetadataType * @metadata: new metadata text * @key: XML namespace key, or NULL * @uri: XML namespace URI, or NULL * @flags: bitwise-OR of virDomainModificationImpact * * Sets the appropriate domain element given by @type to the - * value of @description. A @type of VIR_DOMAIN_METADATA_DESCRIPTION + * value of @metadata. A @type of VIR_DOMAIN_METADATA_DESCRIPTION * is free-form text; VIR_DOMAIN_METADATA_TITLE is free-form, but no * newlines are permitted, and should be short (although the length is * not enforced). For these two options @key and @uri are irrelevant and @@ -10202,7 +10202,7 @@ virDomainSetMetadata(virDomainPtr domain, /** * virDomainGetMetadata: * @domain: a domain object - * @type: type of description, from virDomainMetadataType + * @type: type of metadata, from virDomainMetadataType * @uri: XML namespace identifier * @flags: bitwise-OR of virDomainModificationImpact * -- 1.9.3

2 1

[libvirt] [PATCH] virsh: forbid negative vcpu argument to vcpupin.
by Jincheng Miao 28 May '14

28 May '14

vcpupin will allow argument --vcpu as a signed number, and pass it to virDomainPinVcpu directlly without checking if this value is positive(valid). > virsh vcpupin r7 -1 0 error: numerical overflow: input too large: 4294967295 This message is inaccurate, and the negative vcpu is non-valuable. So forbid vcpu argument as a negative. Signed-off-by: Jincheng Miao <jmiao(a)redhat.com> --- tools/virsh-domain.c | 24 ++++++++++-------------- 1 files changed, 10 insertions(+), 14 deletions(-) diff --git a/tools/virsh-domain.c b/tools/virsh-domain.c index 84a6706..d9804cc 100644 --- a/tools/virsh-domain.c +++ b/tools/virsh-domain.c @@ -5797,7 +5797,7 @@ cmdVcpuPin(vshControl *ctl, const vshCmd *cmd) { virDomainInfo info; virDomainPtr dom; - int vcpu = -1; + unsigned int vcpu; const char *cpulist = NULL; bool ret = false; unsigned char *cpumap = NULL; @@ -5830,29 +5830,25 @@ cmdVcpuPin(vshControl *ctl, const vshCmd *cmd) query = !cpulist; - /* In query mode, "vcpu" is optional */ - if (vshCommandOptInt(cmd, "vcpu", &vcpu) < !query) { + /* In query mode, "vcpu" is optional*/ + if (vshCommandOptUInt(cmd, "vcpu", &vcpu) < !query) { vshError(ctl, "%s", _("vcpupin: Invalid or missing vCPU number.")); - virDomainFree(dom); - return false; - } - - if ((maxcpu = vshNodeGetCPUCount(ctl->conn)) < 0) { - virDomainFree(dom); - return false; + goto cleanup; } if (virDomainGetInfo(dom, &info) != 0) { vshError(ctl, "%s", _("vcpupin: failed to get domain information.")); - virDomainFree(dom); - return false; + goto cleanup; } if (vcpu >= info.nrVirtCpu) { vshError(ctl, "%s", _("vcpupin: Invalid vCPU number.")); - virDomainFree(dom); - return false; + goto cleanup; + } + + if ((maxcpu = vshNodeGetCPUCount(ctl->conn)) < 0) { + goto cleanup; } cpumaplen = VIR_CPU_MAPLEN(maxcpu); -- 1.7.1

2 1

[libvirt] [PATCHv2 00/33] Gluster backing chains and relative block commit/pull
by Peter Krempa 28 May '14

28 May '14

Hi, this is my second take on this topic. Some of the patches are still in a RFC status as the last six patches require qemu support which is still on review upstream. The rest should be fine as is even without the qemu bits. Peter Krempa (33): qemu: process: Refresh backing chain info when reconnecting to qemu qemu: Make qemuDomainPrepareDiskChainElement aware of remote storage storage: Store gluster volume name separately storage: Rework debugging of storage file access through storage driver conf: Fix domain disk path iterator to work with networked storage storage: Add NONE protocol type for network disks storage: Add support for access to files using provided uid/gid storage: Add storage file API to read file headers storage: backend: Add unique id retrieval API storage: Add API to check accessibility of storage volumes storage: Move virStorageFileGetMetadata to the storage driver storage: Determine the local storage type right away test: storage: Initialize storage source to correct type storage: backend: Add possibility to suppress errors from backend lookup storage: Switch metadata crawler to use storage driver to get unique path storage: Switch metadata crawler to use storage driver to read headers storage: Switch metadata crawler to use storage driver file access check storage: Add infrastructure to parse remote network backing names storage: Change to new backing store parser storage: Traverse backing chains of network disks util: string: Return element count from virStringSplit util: string: Add helper to free non-NULL terminated string arrays util: storagefile: Add helper to resolve "../", "./" and "////" in paths util: storage: Add helper to resolve relative path difference util: storagefile: Add canonicalization to virStorageFileSimplifyPath storage: gluster: Add backend to return unique storage file path qemu: json: Add format strings for optional command arguments qemu: monitor: Add argument for specifying backing name for block commit qemu: monitor: Add support for backing name specification for block-stream lib: Introduce flag VIR_DOMAIN_BLOCK_COMMIT_RELATIVE lib: Introduce flag VIR_DOMAIN_BLOCK_REBASE_RELATIVE qemu: Add support for networked disks for block commit qemu: Add support for networked disks for block pull/block rebase cfg.mk | 2 +- include/libvirt/libvirt.h.in | 6 + src/Makefile.am | 2 + src/conf/domain_conf.c | 72 ++- src/libvirt_private.syms | 7 +- src/qemu/qemu_capabilities.c | 8 + src/qemu/qemu_capabilities.h | 2 + src/qemu/qemu_command.c | 24 +- src/qemu/qemu_domain.c | 10 +- src/qemu/qemu_driver.c | 160 +++++-- src/qemu/qemu_migration.c | 6 +- src/qemu/qemu_monitor.c | 21 +- src/qemu/qemu_monitor.h | 4 +- src/qemu/qemu_monitor_json.c | 139 ++++-- src/qemu/qemu_monitor_json.h | 2 + src/qemu/qemu_process.c | 5 + src/security/virt-aa-helper.c | 2 + src/storage/storage_backend.c | 16 +- src/storage/storage_backend.h | 22 +- src/storage/storage_backend_fs.c | 127 +++++- src/storage/storage_backend_gluster.c | 203 +++++++-- src/storage/storage_driver.c | 329 +++++++++++++- src/storage/storage_driver.h | 15 +- src/util/virstoragefile.c | 818 ++++++++++++++++++++++++---------- src/util/virstoragefile.h | 31 +- src/util/virstring.c | 44 +- src/util/virstring.h | 7 + tests/Makefile.am | 7 +- tests/qemumonitorjsontest.c | 2 +- tests/virstoragetest.c | 290 +++++++++++- tools/virsh-domain.c | 29 +- 31 files changed, 1988 insertions(+), 424 deletions(-) -- 1.9.3

2 59

[libvirt] [bug] python-libvirt vcpus mismatch
by Chris Friesen 28 May '14

28 May '14

I've got a libvirt-created instance where I've been messing with affinity, and now something is strange. I did the following in python: >>> import libvirt >>> conn=libvirt.open("qemu:///system") >>> dom = conn.lookupByName('instance-00000027') >>> dom.vcpus() ([(0, 1, 528150000000L, 2), (1, 1, 548070000000L, 3)], [(False, False, True, False), (False, False, True, False)]) I'm totally confused by that "3". It's supposed to represent the physical cpu that virtual cpu 1 is running on. But cpu 3 isn't even in the allowable affinity map for vcpu 1. If I query the data other ways, I get both cpus running on physical cpu 2: root@compute-0:~# virsh vcpupin instance-00000027 VCPU: CPU Affinity ---------------------------------- 0: 2 1: 2 root@compute-0:~# virsh emulatorpin instance-00000027 emulator: CPU Affinity ---------------------------------- *: 2 root@compute-0:~# taskset -pac 15072 pid 15072's current affinity list: 2 pid 15073's current affinity list: 1-3 pid 15075's current affinity list: 2 pid 15076's current affinity list: 0 So I'm left with the conclusion that there is something strange going on with libvirt-python. Anyone got any ideas? Chris

2 1