August 2013 - Devel - libvirt List Archives

[libvirt] [PATCH 0/n] improvements to native-to-xml parsing
by Eric Blake 06 Sep '13

06 Sep '13

I tried to use 'virsh qemu-attach', and hit different failures with both libvirt.git on Fedora 19, and with an older version of libvirt on RHEL 6. I'm posting patches that I have so far to start reviews, but need to write still more patches as I still haven't succeeded at attaching. I also need to add a patch to the testsuite to cover the command line that I'm trying to attach to. Eric Blake (3): qemu: only parse basename when determining emulator properties qemu: simplify list cleanup qemu: recognize -machine accel=kvm when parsing native src/conf/domain_conf.c | 6 ++++ src/qemu/qemu_command.c | 87 +++++++++++++++++++++++++------------------------ 2 files changed, 50 insertions(+), 43 deletions(-) -- 1.8.3.1

3 19

[libvirt] [PATCH 0/3] caps: expose the user and group owner of the HV
by Giuseppe Scrivano 06 Sep '13

06 Sep '13

virt-manager has no way to known the user/group that run the HV process without requiring the user to manually set it trough setup.py or assuming "root" as default value. This series extends the Guest capabilities with "hv_user" and "hv_group", to inform the libvirt user about the user/group (when qemu is used) that run the HV process. Giuseppe Scrivano (3): caps: new internal function "virCapabilitiesSetHvUserAndGroup" qemu: set hv_user/hv_group caps to the user/group which runs qemu caps: add tests and documentation for hv_user and hv_group docs/schemas/capability.rng | 10 +++++++ src/conf/capabilities.c | 46 +++++++++++++++++++++++++++++++ src/conf/capabilities.h | 7 +++++ src/libvirt_private.syms | 1 + src/qemu/qemu_capabilities.c | 3 ++ tests/capabilityschemadata/caps-test2.xml | 4 +++ 6 files changed, 71 insertions(+) -- 1.8.3.1

2 12

[libvirt] [PATCH 0/3] Keep original file label
by Michal Privoznik 06 Sep '13

06 Sep '13

This is just a resurrection of my previous patchset. As of atomicity problem, I just realized there is none. The qemuProcessHook (which is responsible for locking the files) is called prior virSecurityManagerSetAllLabel (responsible for chown()-ing). Anyway, even if there's still one and it's pre-existing, it shouldn't block this set, should it? Michal Privoznik (3): virFile: Add APIs for extended attributes handling virfile: Introduce internal API for managing ACL security_dac: Favour ACLs over chown() configure.ac | 2 + libvirt.spec.in | 1 + m4/virt-acl.m4 | 9 ++ src/Makefile.am | 4 +- src/libvirt_private.syms | 6 + src/security/security_dac.c | 297 ++++++++++++++++++++++++++++++++++++++----- src/util/virfile.c | 301 ++++++++++++++++++++++++++++++++++++++++++++ src/util/virfile.h | 28 +++++ 8 files changed, 617 insertions(+), 31 deletions(-) create mode 100644 m4/virt-acl.m4 -- 1.8.1.5

2 7

[libvirt] [PATCH 0/3] Fix and clean up multiple issues in virsh console handling
by Peter Krempa 04 Sep '13

04 Sep '13

This series has to be applied on top of "virsh: Handle interrupting of jobs manually". Peter Krempa (3): tools: rename console.[ch] to virsh-console.[ch] and fix coding style virsh: Rename vshMakeStdinRaw to vshTTYMakeRaw and move it to virsh.c virsh-console: Avoid using signal() in multithreaded application cfg.mk | 2 +- po/POTFILES.in | 2 +- tools/Makefile.am | 2 +- tools/{console.c => virsh-console.c} | 153 +++++++++++++++-------------------- tools/{console.h => virsh-console.h} | 11 ++- tools/virsh-domain.c | 4 +- tools/virsh.c | 50 +++++++++++- tools/virsh.h | 1 + 8 files changed, 123 insertions(+), 102 deletions(-) rename tools/{console.c => virsh-console.c} (76%) rename tools/{console.h => virsh-console.h} (81%) -- 1.8.3.2

4 10

[libvirt] [PATCH 00/12] Various libxl driver improvements
by Jim Fehlig 04 Sep '13

04 Sep '13

This series contains several improvements for the libxl driver. Patches 1 and 2 are primarily code movement, putting code in files that are more consistent with other drivers. Patches 3 through 12 improve locking of the libxlDriverPrivate struct, similar to the work done in the QEMU and LXC drivers Obviously post-1.1.2 material, but would be nice to get it in soon thereafter for testing throughout the 1.1.3 cycle... Jim Fehlig (12): libxl: Move detection of autoballoon to libxl_conf libxl: Introduce libxl_domain.[ch] libxl: Earlier detection of not running on Xen libxl: Add libxl_version_info to libxlDriverPrivate libxl: libxl: Use per-domain ctx in libxlMakeDomCreateInfo libxl: User per-domain ctx in libxlDomainGetInfo libxl: Introduce libxlDriverConfig object libxl: Use atomic ops for driver->nactive libxl: Add comments to libxlDriverPrivate fields libxl: Move driver lock/unlock to libxl_conf libxl: Remove unnecessary driver locking libxl: Add libxlDomObjFromDomain po/POTFILES.in | 1 + src/Makefile.am | 1 + src/libxl/libxl_conf.c | 149 +++++- src/libxl/libxl_conf.h | 87 +-- src/libxl/libxl_domain.c | 469 ++++++++++++++++ src/libxl/libxl_domain.h | 61 +++ src/libxl/libxl_driver.c | 1329 ++++++++++------------------------------------ 7 files changed, 1010 insertions(+), 1087 deletions(-) create mode 100644 src/libxl/libxl_domain.c create mode 100644 src/libxl/libxl_domain.h -- 1.8.1.4

5 49

[libvirt] [PATCH] build: only create virt-login-shell for lxc builds
by Eric Blake 03 Sep '13

03 Sep '13

I noticed from an ./autobuild.sh run that we were installing a virt-login-shell.exe binary when cross-building for mingw, even though such a binary is necessarily worthless since the code depends on lxc which is a Linux-only concept. * tools/Makefile.am (conf_DATA, bin_PROGRAMS, dist_man1_MANS): Make virt-login-shell installation conditional. Signed-off-by: Eric Blake <eblake(a)redhat.com> --- I'm debating about pushing this under the build-breaker rule. tools/Makefile.am | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/tools/Makefile.am b/tools/Makefile.am index 74fae2d..4a3338f 100644 --- a/tools/Makefile.am +++ b/tools/Makefile.am @@ -60,10 +60,10 @@ EXTRA_DIST = \ DISTCLEANFILES = confdir = $(sysconfdir)/libvirt -conf_DATA = virt-login-shell.conf +conf_DATA = bin_SCRIPTS = virt-xml-validate virt-pki-validate -bin_PROGRAMS = virsh virt-host-validate virt-login-shell +bin_PROGRAMS = virsh virt-host-validate libexec_SCRIPTS = libvirt-guests.sh if WITH_SANLOCK @@ -71,12 +71,20 @@ sbin_SCRIPTS = virt-sanlock-cleanup DISTCLEANFILES += virt-sanlock-cleanup endif +if WITH_LXC +conf_DATA += virt-login-shell.conf +bin_PROGRAMS += virt-login-shell +endif WITH_LXC + + dist_man1_MANS = \ virt-host-validate.1 \ virt-pki-validate.1 \ virt-xml-validate.1 \ - virt-login-shell.1 \ virsh.1 +if WITH_LXC +dist_man1_MANS += virt-login-shell.1 +endif WITH_LXC if WITH_SANLOCK dist_man8_MANS = virt-sanlock-cleanup.8 endif -- 1.8.3.1

3 4

Re: [libvirt] [PATCHv3 2/6] virsh: Add vshCmdCompleter and vshOptCompleter
by Eric Blake 03 Sep '13

03 Sep '13

[re-adding the list, which was accidentally omitted] On 08/28/2013 05:26 AM, Tomas Meszaros wrote: >> Per-option completions make sense. For example, 'virsh vol-key --pool >> <TAB>' wants to use a pool completer, while 'virsh vol-key --vol <TAB>' >> wants to use a volume completer; furthermore, 'virsh vol-key <TAB>' >> should be the combination of the option completer (showing --vol and >> --pool) AND the volume completer filtered to names not starting with '-' >> (since virsh has the semantics that arguments are positional, where the >> option '--vol' is implied if the argument that appears in that position >> does not resemble an option). > > So If I get it right, you are suggesting that it should work like this: > > virsh # vol-key <TAB> > vol1 vol2 pool1 pool2 > > as you said, combination of --vol and --pool completers. No, it should work like this: virsh# vol-key <TAB> vol1 vol2 --vol --pool the combination of all (non-option) completions for the current available mandatory option (volume completer), and of all possible options that still make sense at this point in the command line. Likewise: virsh# vol-key vol <TAB> pool1 pool2 --pool virsh# vol-key -<TAB> --vol --pool virsh# vol-key v<TAB> vol1 vol2 virsh# vol-key --pool <TAB> pool1 pool2 virsh# vol-key --pool pool1 <TAB> vol1 vol2 --vol and so forth. > > > I was initially thinking that completion should work like this: > > virsh # vol-key <TAB> > vol1 vol2 > > It is completing <vol> first becasue <vol> is only mandatory argument > for this command. It is a mandatory option, but mandatory options need not come first. Remember, our option parser allows mandatory options to occur positionally without an option name, OR to be interleaved in any other order by including the option string. > > > Only if someone type: > > virsh # vol-key --pool <TAB> > pool1 pool2 > > then call --pool completer. This is correct - once an option is awaiting an argument, then the option completer must return nothing at that point in time. But if you look at it as the union of two completers - the set of options that are still valid in the current context, and the set of strings that are valid assuming positional semantics of the current option, you will always get the right answer, without needing a per-command completer (just per-option completers). -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org

2 2

[libvirt] RFC: Splitting python binding out into a separate repo & ading to PyPi
by Daniel P. Berrange 03 Sep '13

03 Sep '13

As everyone knows, we have historically always shipped the python binding as part of the libvirt primary tar.gz distribution. In some ways that has simplified life for people, since we know they'll always have a libvirt python that matches their libvirt C library. At the same time though, this policy of ours is causing increasing amounts of pain for a number of our downstream users. In OpenStack, in particular, their development and test environments aim to be able to not rely on any system installed python packages. They use a virtualenv and pip to install all python deps from PyPi (equivalent of Perl's CPAN in Python world). This approach works for everything except the libvirt Python code which is not available standalone on PyPi. This is causing so much pain that people have suggested taking the libvirt python code we ship and just uploading it to PyPi themselves[1]. This would obviously be a somewhat hostile action to take, but the way we distribute libvirt python is forcing OpenStack to consider such things. In RHEL world too, bundling of libvirt + its python binding is causing pain with the fairly recent concept of "software collections"[2]. This allows users to install multiple versions of languages like Python, Perl, etc on the same box in parallel. To use libvirt python with thse alternate python installs though, requires that they recompile the entire libvirt distribution just to get the Python binding. This is obviously not an approach that works for most people, particularly if they're looking to populate their software collection using 'pip' rather than RPM. Looking on google there are a number of other people asking for libvirt python as a separate module, eg on Stackoverflow[3]. I don't think these issues are going to go away, in fact I think they will likely become more pressing, until the point where some 3rd party takes the step of providing libvirt python bindings themselves. I don't think we want to let ourselves drift into the situation where we loose control over releasing libvirt python bindings. IMHO we should / must listen to our users here before it is too late. We can still release libvirt python at the same time as normal libvirt releases, and require that people update the bindings whenever adding new APIs (if the generator doesn't cope with them). We should simply distribute python as a separate tar.gz, as we do for all other languages, and upload it to PyPi, as well as libvirt.org FTP when doing a release. Obviously there will be some work to separate things out, but I don't see that being insurmountable, since all other language bindings manage to be separate, even when doing code generation. We'd also want to change to use distutils, rather than autoconf, since that's what the python world wants. Regards, Daniel [1] http://lists.openstack.org/pipermail/openstack-dev/2013-August/013187.html [2] https://access.redhat.com/site/documentation/en-US/Red_Hat_Developer_Toolse… [3] http://stackoverflow.com/questions/14924460/is-there-any-way-to-install-lib… -- |: 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 :|

9 17

[libvirt] [PATCH v2] kvm: warn if num cpus is greater than num recommended
by Andrew Jones 03 Sep '13

03 Sep '13

The comment in kvm_max_vcpus() states that it's using the recommended procedure from the kernel API documentation to get the max number of vcpus that kvm supports. It is, but by always returning the maximum number supported. The maximum number should only be used for development purposes. qemu should check KVM_CAP_NR_VCPUS for the recommended number of vcpus. This patch adds a warning if a user specifies a number of cpus between the recommended and max. v2: Incorporate tests for max_cpus, which specifies the maximum number of hotpluggable cpus. An additional note is that the message for the fail case was slightly changed, 'exceeds max cpus' to 'exceeds the maximum cpus'. If this is unacceptable change for users like libvirt, then I'll need to spin a v3. Signed-off-by: Andrew Jones <drjones(a)redhat.com> --- kvm-all.c | 69 ++++++++++++++++++++++++++++++++++++--------------------------- 1 file changed, 40 insertions(+), 29 deletions(-) diff --git a/kvm-all.c b/kvm-all.c index a2d49786365e3..021f5f47e53da 100644 --- a/kvm-all.c +++ b/kvm-all.c @@ -1322,24 +1322,20 @@ static int kvm_irqchip_create(KVMState *s) return 0; } -static int kvm_max_vcpus(KVMState *s) +/* Find number of supported CPUs using the recommended + * procedure from the kernel API documentation to cope with + * older kernels that may be missing capabilities. + */ +static int kvm_recommended_vcpus(KVMState *s) { - int ret; - - /* Find number of supported CPUs using the recommended - * procedure from the kernel API documentation to cope with - * older kernels that may be missing capabilities. - */ - ret = kvm_check_extension(s, KVM_CAP_MAX_VCPUS); - if (ret) { - return ret; - } - ret = kvm_check_extension(s, KVM_CAP_NR_VCPUS); - if (ret) { - return ret; - } + int ret = kvm_check_extension(s, KVM_CAP_NR_VCPUS); + return (ret) ? ret : 4; +} - return 4; +static int kvm_max_vcpus(KVMState *s) +{ + int ret = kvm_check_extension(s, KVM_CAP_MAX_VCPUS); + return (ret) ? ret : kvm_recommended_vcpus(s); } int kvm_init(void) @@ -1347,11 +1343,19 @@ int kvm_init(void) static const char upgrade_note[] = "Please upgrade to at least kernel 2.6.29 or recent kvm-kmod\n" "(see http://sourceforge.net/projects/kvm).\n"; + struct { + const char *name; + int num; + } num_cpus[] = { + { "SMP", smp_cpus }, + { "hotpluggable", max_cpus }, + { NULL, } + }, *nc = num_cpus; + int soft_vcpus_limit, hard_vcpus_limit; KVMState *s; const KVMCapabilityInfo *missing_cap; int ret; int i; - int max_vcpus; s = g_malloc0(sizeof(KVMState)); @@ -1392,19 +1396,26 @@ int kvm_init(void) goto err; } - max_vcpus = kvm_max_vcpus(s); - if (smp_cpus > max_vcpus) { - ret = -EINVAL; - fprintf(stderr, "Number of SMP cpus requested (%d) exceeds max cpus " - "supported by KVM (%d)\n", smp_cpus, max_vcpus); - goto err; - } + /* check the vcpu limits */ + soft_vcpus_limit = kvm_recommended_vcpus(s); + hard_vcpus_limit = kvm_max_vcpus(s); - if (max_cpus > max_vcpus) { - ret = -EINVAL; - fprintf(stderr, "Number of hotpluggable cpus requested (%d) exceeds max cpus " - "supported by KVM (%d)\n", max_cpus, max_vcpus); - goto err; + while (nc->name) { + if (nc->num > soft_vcpus_limit) { + fprintf(stderr, + "Warning: Number of %s cpus requested (%d) exceeds " + "the recommended cpus supported by KVM (%d)\n", + nc->name, nc->num, soft_vcpus_limit); + + if (nc->num > hard_vcpus_limit) { + ret = -EINVAL; + fprintf(stderr, "Number of %s cpus requested (%d) exceeds " + "the maximum cpus supported by KVM (%d)\n", + nc->name, nc->num, hard_vcpus_limit); + goto err; + } + } + nc++; } s->vmfd = kvm_ioctl(s, KVM_CREATE_VM, 0); -- 1.8.1.4

4 6

[libvirt] [PATCH 0/3] virsh: Handle interrupting of jobs manually
by Peter Krempa 03 Sep '13

03 Sep '13

Using Ctrl+C to abort migration has a side effect of killing ssh transports used to execute the migration. Add manual handling to avoid this issue. Peter Krempa (3): virsh-domain: rename print_job_progress to vshPrintJobProgress virsh: Remember terminal state when starting and add helpers virsh-domain: Avoid killing ssh transport tunnels when cancelling job tools/virsh-domain.c | 65 +++++++++++++++++++++++++++++++++------------------- tools/virsh.c | 54 +++++++++++++++++++++++++++++++++++++++++++ tools/virsh.h | 9 ++++++++ 3 files changed, 105 insertions(+), 23 deletions(-) -- 1.8.3.2

3 8