March 2012 - Devel - libvirt List Archives

[libvirt] Per-guest configurable user/group for QEMU processes
by Marcelo Cerri 12 Mar '12

12 Mar '12

Hi, I'm starting working on an improvement for libvirt to be able to support per-guest configurable user and group IDs for QEMU processes. Currently, libvirt uses a configurable pair of user and group, which is defined in qemu.conf, for all qemu processes when running in privileged mode. This topic was already commented in qemu mailing list (http://lists.nongnu.org/archive/html/qemu-devel/2011-10/msg00758.html) but, as this requires changes in libvirt API, I'd like to discuss what would be the best solution for it. A solution (as proposed in the link above) would be to extend the security driver model to allow multiple drivers. In this case, an example of the XML definition would be: ... <seclabel type='dynamic' model='selinux'> <label>system_u:system_r:svirt_t:s0:c633,c712</label> <imagelabel>system_u:object_r:svirt_image_t:s0:c633,c712</imagelabel> </seclabel> <seclabel type='dynamic' model='dac'> <label>102:102</label> <imagelabel>102:102</imagelabel> </seclabel> ... I don't know if this is a clean solution because the usual option would be to enclose the block above in a "<seclabels>" tag. But as this would break the actual API, it's not viable. Another option is to expose the stack security driver that already exists internally in libvirt (maybe extending it to support more than two security drivers): ... <seclabel type='stack'> <seclabel type='dynamic' model='selinux'> <label>system_u:system_r:svirt_t:s0:c633,c712</label> <imagelabel>system_u:object_r:svirt_image_t:s0:c633,c712</imagelabel> </seclabel> <seclabel type='dynamic' model='dac'> <label>102:102</label> <imagelabel>102:102</imagelabel> </seclabel> </seclabel> ... In that case, a nested seclabel only would be allowed when type='stack'. Independently of how multiple security drivers can be expressed in the XML, another problem would be how functions as virDomainGetSecurityLabel should behave. A third option is to just not support multiple security drivers and include a new tag for DAC: ... <seclabel type='dynamic' model='selinux'> <label>system_u:system_r:svirt_t:s0:c633,c712</label> <imagelabel>system_u:object_r:svirt_image_t:s0:c633,c712</imagelabel> </seclabel> <dac process='102:102' image='102:102'/> ... Please let me know your opinions about this topic. Regards, Marcelo

3 6

[libvirt] [PATCH] qemuBuildCommandLine: Don't add tlsPort if none set
by Michal Privoznik 12 Mar '12

12 Mar '12

If user hasn't supplied any tlsPort we default to setting it to zero in our internal structure. However, when building command line we test it against -1 which is obviously wrong. --- src/qemu/qemu_command.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index de2d4a1..ed82cc2 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -5374,7 +5374,7 @@ qemuBuildCommandLine(virConnectPtr conn, virBufferAsprintf(&opt, "port=%u", def->graphics[0]->data.spice.port); - if (def->graphics[0]->data.spice.tlsPort != -1) { + if (def->graphics[0]->data.spice.tlsPort) { if (!driver->spiceTLS) { qemuReportError(VIR_ERR_CONFIG_UNSUPPORTED, _("spice TLS port set in XML configuration," -- 1.7.8.5

4 4

[libvirt] Ifdown functionality request
by Oleg V Popov 12 Mar '12

12 Mar '12

Hello. libvirt can do: <interface type='ethernet'> <target dev='vnet7'/> <script path='/etc/qemu-ifup-mynet'/> </interface> Please. Add if-down script functionality. -- Best regards/Всего наилучшего Popov Oleg/Попов Олег tel: +79115580313 xmpp: user(a)livelace.ru skype: livelace

1 0

[libvirt] libvirt_tck autotest wrapper looks good, commited
by Lucas Meneghel Rodrigues 12 Mar '12

12 Mar '12

Thanks Guannan: https://github.com/autotest/autotest/commit/ba4b748e7b9a9bfe7898a97cdccdc9b… Cheers, Lucas

6 6

[libvirt] [PATCH] Fix a few typo in translated strings
by Daniel Veillard 12 Mar '12

12 Mar '12

this was raised by our hindi localization team chandan kumar <chandankumar.093047(a)gmail.com> pushed under trivial rule diff --git a/src/lxc/lxc_controller.c b/src/lxc/lxc_controller.c index 8f336f5..bbc9d9c 100644 --- a/src/lxc/lxc_controller.c +++ b/src/lxc/lxc_controller.c @@ -1591,14 +1591,14 @@ lxcControllerRun(virDomainDefPtr def, if (virSetBlocking(monitor, false) < 0 || virSetBlocking(client, false) < 0) { virReportSystemError(errno, "%s", - _("Unable to set file descriptor non blocking")); + _("Unable to set file descriptor non-blocking")); goto cleanup; } for (i = 0 ; i < nttyFDs ; i++) { if (virSetBlocking(ttyFDs[i], false) < 0 || virSetBlocking(containerTtyFDs[i], false) < 0) { virReportSystemError(errno, "%s", - _("Unable to set file descriptor non blocking")); + _("Unable to set file descriptor non-blocking")); goto cleanup; } } diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index 6ec1eb9..996763c 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -866,7 +866,7 @@ static int qemuCollectPCIAddress(virDomainDefPtr def ATTRIBUTE_UNUSED, if (info->addr.pci.function != 0) { qemuReportError(VIR_ERR_XML_ERROR, _("Attempted double use of PCI Address '%s' " - "(may need \"multifunction='on'\" for device on function 0"), + "(may need \"multifunction='on'\" for device on function 0)"), addr); } else { qemuReportError(VIR_ERR_XML_ERROR, diff --git a/src/qemu/qemu_monitor_json.c b/src/qemu/qemu_monitor_json.c index afd744a..1a0ee94 100644 --- a/src/qemu/qemu_monitor_json.c +++ b/src/qemu/qemu_monitor_json.c @@ -3356,13 +3356,13 @@ qemuMonitorJSONBlockIoThrottleInfo(virJSONValuePtr result, if (!temp_dev || temp_dev->type != VIR_JSON_TYPE_OBJECT) { qemuReportError(VIR_ERR_INTERNAL_ERROR, "%s", - _("block io throttle device entry was not in expected format")); + _("block_io_throttle device entry was not in expected format")); goto cleanup; } if ((current_dev = virJSONValueObjectGetString(temp_dev, "device")) == NULL) { qemuReportError(VIR_ERR_INTERNAL_ERROR, "%s", - _("block io throttle device entry was not in expected format")); + _("block_io_throttle device entry was not in expected format")); goto cleanup; } @@ -3376,7 +3376,7 @@ qemuMonitorJSONBlockIoThrottleInfo(virJSONValuePtr result, if ((inserted = virJSONValueObjectGet(temp_dev, "inserted")) == NULL || inserted->type != VIR_JSON_TYPE_OBJECT) { qemuReportError(VIR_ERR_INTERNAL_ERROR, "%s", - _("block io throttle inserted entry was not in expected format")); + _("block_io_throttle inserted entry was not in expected format")); goto cleanup; } -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/

1 0

[libvirt] [PATCH RFC 0/8] qemu: Cache results of parsing qemu help output
by Lee Schermerhorn 12 Mar '12

12 Mar '12

Stracing libvirtd shows that the qemu driver is executing 2 different qemu binaries 3 times each to fetch the version, capabilities [supported devices], and cpu models each time VM state is queried. E.g., [lines wrapped]: 6471 17:15:26.561890 execve("/usr/bin/qemu", ["/usr/bin/qemu", "-cpu", "?"], [/* 2 vars */]) = 0 6472 17:15:26.626668 execve("/usr/bin/qemu", ["/usr/bin/qemu", "-help"], [/* 2 vars */]) = 0 6473 17:15:26.698104 execve("/usr/bin/qemu", ["/usr/bin/qemu", "-device", "?", "-device", "pci-assign,?", "-device", "virtio-blk-pci,?"], [/* 2 vars */]) = 0 6484 17:15:27.267770 execve("/usr/bin/qemu-system-x86_64", ["/usr/bin/qemu-system-x86_64", "-cpu", "?"], /* 2 vars */]) = 0 6492 17:15:27.333177 execve("/usr/bin/qemu-system-x86_64", ["/usr/bin/qemu-system-x86_64", "-help"], [/* 2 vars */]) = 0 6496 17:15:27.402280 execve("/usr/bin/qemu-system-x86_64", ["/usr/bin/qemu-system-x86_64", "-device", "?", "-device", "pci-assign,?", "-device", "virtio-blk-pci,?"], [/* 2 vars */]) = 0 ~1sec per libvirt api call. Not a killer, but on a heavily loaded host -- several 10s of VMs -- a periodic query of all VM state, such as from a cloud compute manager, can take a couple of minutes to complete. Because the qemu binaries on the host do not change all that often, the results of parsing the qemu help output from the exec's above can be cached. The qemu driver already does some caching of capabilities, but it does not prevent the execs above. This series is a work in progress. I'm submitting it as an RFC because I saw Eric mention the frequent execing of qemu binaries and I have been working on this to eliminate the overhead shown above. The series caches the parse results of: + qemuCapsExtractVersionInfo + qemuCapsProbeMachineTypes + qemuCapsProbeCPUModels by splitting these functions into two parts. The existing function name fetches the cached parse results for the specified binary and returns them. The other half, named "qemuCapsCacheX", where X is one of ExtractVersionInfo, ProbeMachineTypes, and ProbeCPUModels, exec's the emulator binary and caches the results. The act of fetching the cached results will fill or refresh the cache as necessary in a new function qemuCapsCachedInfoGet(). A few auxilliary function have been added -- e.g., virCapabilitiesDupMachines() to duplicate a cached list of machine types and virBitmapDup() to duplicate cached capabilities flags. The series does not attempt to integrate with nor remove the existing capabilities caching. TBD. The series was developed and tested in the context of the Ubuntu 11.04 natty libvirt_0.8.8-1ubuntu6.7 package using quilt to manage patches in the debian/patches directory. In that context, it builds, passes all "make check" tests [under pbuilder] and some fairly heavy, overlapping VM launch tests where it does eliminate all but a few initial exec's of the various qemu* and kvm binaries. The version here, rebased to libvirt-0.9.10, builds cleanly under mock on Fedora 16 in the context of a modified libvirt-0.9.10-1.fc16 source package. I.e., no errors and warning-for-warning compatible with build of the libvirt-0.9.10 fc16 srpm downloaded from libvirt.org. I placed the modified spec file [applies the patches] and the build logs at: http://downloads.linux.hp.com/~lts/Libvirt/ I have installed the patched libvirt on a fedora 16 system and successfully defined and launched a vm. Testing in progress. I'll place an annotated test log ont the site above when complete. I also need to rebase atop the current mainline sources, but I wanted to get this series out for review to see if the overall approach would be acceptable. Comments?

2 7

[libvirt] Restart: [PATCH RFC 0/8] qemu: Cache results of parsing qemu help output
by Lee Schermerhorn 11 Mar '12

11 Mar '12

Send of series failed at patch 6. Attempting to restart here rather than resend entire series.

1 2

[libvirt] Qemu, libvirt, and CPU models
by Eduardo Habkost 09 Mar '12

09 Mar '12

Hi, Sorry for the long message, but I didn't find a way to summarize the questions and issues and make it shorter. For people who don't know me: I have started to work recently on the Qemu CPU model code. I have been looking at how things work on libvirt+Qemu today w.r.t. CPU models, and I have some points I would like to understand better and see if they can be improved. I have two main points I would like to understand/discuss: 1) The relationship between libvirt's cpu_map.xml and the Qemu CPU model definitions. 2) How we could properly allow CPU models to be changed without breaking existing virtual machines? Note that for all the questions below, I don't expect that we design the whole solution and discuss every single detail in this thread. I just want to collectn suggestions, information about libvirt requirements and assumptions, and warnings about expected pitfalls before I start working on a solution on Qemu. 1) Qemu and cpu_map.xml I would like to understand how cpu_map.xml is supposed to be used, and how it is supposed to interact with the CPU model definitions provided by Qemu. More precisely: 1.1) Do we want to eliminate the duplication between the Qemu CPU definitions and cpu_map.xml? 1.1.1) If we want to eliminate the duplication, how can we accomplish that? What interfaces you miss, that Qemu could provide? 1.1.2) If the duplication has a purpose and you want to keep cpu_map.xml, then: - First, I would like to understand why libvirt needs cpu_map.xml? Is it part of the "public" interface of libvirt, or is it just an internal file where libvirt stores non-user-visible data? - How can we make sure there is no confusion between libvirt and Qemu about the CPU models? For example, what if cpu_map.xml says model 'Moo' has the flag 'foo' enabled, but Qemu disagrees? How do we guarantee that libvirt gets exactly what it expects from Qemu when it asks for a CPU model? We have "-cpu ?dump" today, but it's not the better interface we could have. Do you miss something in special in the Qemu<->libvirt interface, to help on that? 1.2) About the probing of available features on the host system: Qemu has code specialized to query KVM about the available features, and to check what can be enabled and what can't be enabled in a VM. On many cases, the available features match exactly what is returned by the CPUID instruction on the host system, but there are some exceptions: - Some features can be enabled even when the host CPU doesn't support it (because they are completely emulated by KVM, e.g. x2apic). - On many other cases, the feature may be available but we have to check if Qemu+KVM are really able to expose it to the guest (many features work this way, as many depend on specific support by the KVM kernel module and/or Qemu). I suppose libvirt does want to check which flags can be enabled in a VM, as it already have checks for host CPU features (e.g. src/cpu/cpu_x86.c:x86Compute()). But I also suppose that libvirt doesn't want to duplicate the KVM feature probing code present on Qemu, and in this case we could have an interface where libvirt could query for the actually-available CPU features. Would it be useful for libvirt? What's the best way to expose this interface? 1.3) Some features are not plain CPU feature bits: e.g. level=X can be set in "-cpu" argument, and other features are enabled/disabled by exposing specific CPUID leafs and not just a feature bit (e.g. PMU CPUID leaf support). I suppose libvirt wants to be able to probe for those features too, and be able to enable/disable them, right? 2) How to change an existing model and keep existing VMs working? Sometimes we have to update a CPU model definition because of some bug. Eamples: - The CPU models Conroe, Penrym and Nehalem, have level=2 set. This works most times, but it breaks CPU core/thread topology enumeration. We have to change those CPU models to use level=4 to fix the bug. - This can happen with plain CPU feature bits, too, not just "level": sometimes real-world CPU models have a feature that is not supported by Qemu+KVM yet, but when the kernel and Qemu finally starts to support it, we may want to enable it on existing CPU models. Sometimes a model simply has the wrong set of feature bits, and we have to fix it to have the right set of features. But if we simply change the existing model definition, this will break existing machines: - Today, it would break on live migration, but that's slightly easy to fix: we have to migrate the CPUID information too, to make sure we won't change the CPU under the guest OS feet. - Even if we fix live migration, simple "cold" migration will make the guest OS see a different CPU after a reboot, and that's undesirable too. Even if the Qemu developers disagree with me and decide that this is not a problem, libvirt may want to expose a more stable CPU to the guest, and some cooperation from Qemu would be ncessary. So, my questions are: About the libvirt<->Qemu interface: 2.1) What's the best mechanism to have different versions of a CPU model? An alias system like the one used by machine-types? How to implement this without confusing the existing libvirt probing code? 2.2) We have to make the CPU model version-choosing mechanism depend on the machine-type. e.g. if the user has a pc-1.0 machine using the Nehalem CPU model, we have to keep using the level=2 version of that CPU. But if the user chose a newer machine-type version, we can safely get the latest-and-greates version of the Nehalem CPU model. How to make this work without confusing libvirt? About the user<->libvirt interface: 2.3) How all this will interact with cpu_map.xml? Right now there's the assumption that the CPU model definitions are immutable, right? 2.4) How do you think libvirt would expose this "CPU model version" to the user? Should it just expose the unversioned CPU models to the user, and let Qemu or libvirt choose the right version based on machine-type? Should it expose only the versioned CPU models (because they are immutable) and never expose the unversioned aliases? Should it expose the unversioned alias, but change the Domain XML definition automatically to the versioned immutable one (like it happens with machine-type)? I don't plan to interfere on the libvirt interface design, but I suppose that libvirt design assumptions will be impacted by the solution we choose on Qemu. For example: right now libvirt seems to assume that CPU models are immutable. Are you going to keep this assumption in the libvirt interfaces? Because I am already willing to break this assumption on Qemu, although I would like to cooperate with libvirt and not break any requirements/assumptions without warning. -- Eduardo

5 7

[libvirt] [PATCH] Removed more AMD-specific features from cpu64-rhel* models
by Martin Kletzander 09 Mar '12

09 Mar '12

We found few more AMD-specific features in cpu64-rhel* models that made it impossible to start qemu guest on Intel host (with this setting) even though qemu itself starts correctly with them. --- src/cpu/cpu_map.xml | 2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/src/cpu/cpu_map.xml b/src/cpu/cpu_map.xml index 7ef230e..6a6603b 100644 --- a/src/cpu/cpu_map.xml +++ b/src/cpu/cpu_map.xml @@ -347,7 +347,6 @@ </model> <model name='cpu64-rhel6'> - <feature name='abm'/> <feature name='apic'/> <feature name='clflush'/> <feature name='cmov'/> @@ -373,7 +372,6 @@ <feature name='sse'/> <feature name='sse2'/> <feature name='pni'/> - <feature name='sse4a'/> <feature name='syscall'/> <feature name='tsc'/> </model> -- 1.7.3.4

3 4

[libvirt] [PATCH v2] Removed more AMD-specific features from cpu64-rhel* models
by Martin Kletzander 09 Mar '12

09 Mar '12

We found few more AMD-specific features in cpu64-rhel* models that made it impossible to start qemu guest on Intel host (with this setting) even though qemu itself starts correctly with them. This impacts one test, thus the fix in tests/cputestdata/. --- src/cpu/cpu_map.xml | 2 -- .../cputestdata/x86-baseline-no-vendor-result.xml | 3 +-- 2 files changed, 1 insertions(+), 4 deletions(-) diff --git a/src/cpu/cpu_map.xml b/src/cpu/cpu_map.xml index 7ef230e..6a6603b 100644 --- a/src/cpu/cpu_map.xml +++ b/src/cpu/cpu_map.xml @@ -347,7 +347,6 @@ </model> <model name='cpu64-rhel6'> - <feature name='abm'/> <feature name='apic'/> <feature name='clflush'/> <feature name='cmov'/> @@ -373,7 +372,6 @@ <feature name='sse'/> <feature name='sse2'/> <feature name='pni'/> - <feature name='sse4a'/> <feature name='syscall'/> <feature name='tsc'/> </model> diff --git a/tests/cputestdata/x86-baseline-no-vendor-result.xml b/tests/cputestdata/x86-baseline-no-vendor-result.xml index 4b4921c..00e03b2 100644 --- a/tests/cputestdata/x86-baseline-no-vendor-result.xml +++ b/tests/cputestdata/x86-baseline-no-vendor-result.xml @@ -1,4 +1,3 @@ <cpu mode='custom' match='exact'> - <model fallback='allow'>kvm64</model> - <feature policy='require' name='lahf_lm'/> + <model fallback='allow'>cpu64-rhel6</model> </cpu> -- 1.7.3.4

2 1