April 2013 - Devel - libvirt List Archives

[libvirt] [PATCH v5.1 00/11] Introduce driver specific XML parsing callbacks
by Peter Krempa 05 Apr '13

05 Apr '13

In this respin the renaming patch is moved to be first in the series. The argument rearrangement patch was too complicated to move. Unfortunately this rebase operation caused my "git notes" to be lost for the individual patches, so please see v5 for more specific comments. Patches 5 to 11 except for 10 were ACKed in previous versions. Peter Krempa (11): maint: Rename xmlconf to xmlopt and virDomainXMLConfing to virDomainXMLOption conf: Add post XML parse callbacks and prepare for cleaning of virCaps conf callback: Rearrange function parameters qemu: Record the default NIC model in the domain XML virCaps: get rid of "defaultInitPath" value in the virCaps struct virCaps: get rid of defaultDiskDriverName virCaps: get rid of emulatorRequired virCaps: get rid of defaultDiskDriverType virCaps: get rid of hasWideScsiBus virCaps: get rid of macPrefix field virCaps: get rid of defaultConsoleTargetType callback src/conf/capabilities.c | 24 - src/conf/capabilities.h | 23 - src/conf/domain_conf.c | 660 ++++++++++++--------- src/conf/domain_conf.h | 102 ++-- src/conf/snapshot_conf.c | 4 +- src/conf/snapshot_conf.h | 2 +- src/esx/esx_driver.c | 32 +- src/esx/esx_private.h | 2 +- src/libvirt_private.syms | 10 +- src/libvirt_vmx.syms | 1 + src/libxl/libxl_conf.c | 13 - src/libxl/libxl_conf.h | 2 +- src/libxl/libxl_driver.c | 103 ++-- src/lxc/lxc_conf.c | 21 +- src/lxc/lxc_conf.h | 4 +- src/lxc/lxc_controller.c | 10 +- src/lxc/lxc_domain.c | 34 ++ src/lxc/lxc_domain.h | 1 + src/lxc/lxc_driver.c | 71 ++- src/lxc/lxc_process.c | 8 +- src/openvz/openvz_conf.c | 16 +- src/openvz/openvz_conf.h | 2 +- src/openvz/openvz_driver.c | 64 +- src/parallels/parallels_driver.c | 37 +- src/parallels/parallels_utils.h | 2 +- src/phyp/phyp_driver.c | 24 +- src/phyp/phyp_driver.h | 2 +- src/qemu/qemu_capabilities.c | 19 - src/qemu/qemu_command.c | 27 +- src/qemu/qemu_command.h | 6 +- src/qemu/qemu_conf.c | 18 +- src/qemu/qemu_conf.h | 5 +- src/qemu/qemu_domain.c | 98 ++- src/qemu/qemu_domain.h | 1 + src/qemu/qemu_driver.c | 147 +++-- src/qemu/qemu_migration.c | 21 +- src/qemu/qemu_process.c | 34 +- src/security/virt-aa-helper.c | 19 +- src/test/test_driver.c | 67 +-- src/uml/uml_conf.c | 9 - src/uml/uml_conf.h | 2 +- src/uml/uml_driver.c | 69 ++- src/vbox/vbox_tmpl.c | 33 +- src/vmware/vmware_conf.c | 21 +- src/vmware/vmware_conf.h | 2 +- src/vmware/vmware_driver.c | 24 +- src/vmx/vmx.c | 39 +- src/vmx/vmx.h | 12 +- src/xen/xen_driver.c | 37 +- src/xen/xen_driver.h | 4 +- src/xen/xen_hypervisor.c | 13 - src/xen/xend_internal.c | 20 +- src/xen/xm_internal.c | 16 +- src/xenapi/xenapi_driver.c | 40 +- src/xenapi/xenapi_driver_private.h | 2 +- tests/domainsnapshotxml2xmltest.c | 6 +- tests/lxcxml2xmldata/lxc-hostdev.xml | 1 + tests/lxcxml2xmldata/lxc-systemd.xml | 1 + tests/lxcxml2xmltest.c | 8 +- tests/qemuargv2xmltest.c | 6 +- tests/qemumonitorjsontest.c | 28 +- tests/qemumonitortestutils.c | 4 +- tests/qemumonitortestutils.h | 2 +- ...qemuxml2argv-disk-drive-network-nbd-export.args | 3 +- .../qemuxml2argv-disk-drive-network-nbd-export.xml | 1 + ...ml2argv-disk-drive-network-nbd-ipv6-export.args | 3 +- ...xml2argv-disk-drive-network-nbd-ipv6-export.xml | 1 + .../qemuxml2argv-disk-drive-network-nbd-ipv6.args | 3 +- .../qemuxml2argv-disk-drive-network-nbd-ipv6.xml | 1 + .../qemuxml2argv-disk-drive-network-nbd-unix.args | 3 +- .../qemuxml2argv-disk-drive-network-nbd-unix.xml | 1 + .../qemuxml2argv-disk-drive-network-nbd.args | 5 +- .../qemuxml2argv-disk-drive-network-nbd.xml | 1 + .../qemuxml2argv-disk-drive-network-rbd-auth.args | 2 +- .../qemuxml2argv-disk-drive-network-rbd-ipv6.args | 2 +- .../qemuxml2argv-disk-drive-network-rbd-ipv6.xml | 1 + .../qemuxml2argv-disk-drive-network-rbd.args | 2 +- .../qemuxml2argv-disk-drive-network-rbd.xml | 1 + .../qemuxml2argv-disk-drive-network-sheepdog.args | 3 +- .../qemuxml2argv-disk-drive-network-sheepdog.xml | 1 + .../qemuxml2argv-net-bandwidth.xml | 1 + .../qemuxml2argvdata/qemuxml2argv-net-client.args | 4 +- .../qemuxml2argv-net-eth-ifname.args | 4 +- .../qemuxml2argv-net-eth-ifname.xml | 1 + .../qemuxml2argv-net-eth-names.args | 8 +- tests/qemuxml2argvdata/qemuxml2argv-net-eth.args | 4 +- tests/qemuxml2argvdata/qemuxml2argv-net-eth.xml | 1 + .../qemuxml2argvdata/qemuxml2argv-net-hostdev.xml | 1 + tests/qemuxml2argvdata/qemuxml2argv-net-mcast.args | 4 +- .../qemuxml2argv-net-openvswitch.xml | 1 + .../qemuxml2argvdata/qemuxml2argv-net-server.args | 4 +- tests/qemuxml2argvdata/qemuxml2argv-net-user.args | 3 +- tests/qemuxml2argvdata/qemuxml2argv-net-user.xml | 1 + .../qemuxml2argv-net-virtio-network-portgroup.xml | 2 + tests/qemuxml2argvtest.c | 6 +- .../qemuxml2xmlout-graphics-spice-timeout.xml | 1 + tests/qemuxml2xmltest.c | 6 +- tests/qemuxmlnstest.c | 6 +- tests/securityselinuxlabeltest.c | 6 +- tests/testutilslxc.c | 9 - tests/testutilsqemu.c | 11 - tests/testutilsqemu.h | 2 +- tests/testutilsxen.c | 16 - tests/testutilsxen.h | 2 - tests/vmx2xmltest.c | 17 +- tests/xmconfigtest.c | 8 +- tests/xml2sexprtest.c | 9 +- tests/xml2vmxtest.c | 20 +- 108 files changed, 1275 insertions(+), 1052 deletions(-) -- 1.8.1.5

5 32

[libvirt] Device backend in another domain (xen)
by Marek Marczykowski 05 Apr '13

05 Apr '13

Hi all, Xen have (AFAIK unique) feature of having backend device in other domU (sometimes called driver domain) instead of dom0. Currently libxl support it for disk and network devices, but in general it is valid for any device (perhaps excluding PCI). Current implementation requires ID of backend domain to be specified during device attach/domain startup. There are some upcoming patches to allow also use domain name. I'd like to add support for it into libvirt. The question is how specify domain reference. The simplest approach is to use direct domain ID, logically it fits in <source/> tag, so something like: <disk type='file'> <source file='/path/to/file/inside/domain/7' domid='7'/> <target dev='xvdb'/> </disk> <interface type='bridge'> <source bridge='name-of-bridge-in-domiain-7' domid='7'/> </interface> This have obvious limitation that domain ID changes with each domain restart. But perhaps more correct approach is to use name or UUID? Extending <source/> tag is right thing to do? Or should I add a new tag (<backenddomain uuid='...'/> ? )? Regarding implementation I need some hints how to do the value verification (check if domain exists at least). If it has to be done in domain_conf.c (during XML parsing) it will require predetermined domain load order, which IMHO isn't acceptable. So perhaps the check should be done at domain startup/device attach (by driver)? In any case: is it possible at all to check if domain with given name/UUID exists in scope of domain_conf.c? It looks like it requires connection reference, which isn't passed to virDomain*DefParseXML. -- Best Regards, Marek Marczykowski Invisible Things Lab

2 1

[libvirt] [PATCH 1/3] Remove support for old kernels lacking private devpts
by Daniel P. Berrange 04 Apr '13

04 Apr '13

From: "Daniel P. Berrange" <berrange(a)redhat.com> Early on kernel support for private devpts was not widespread, so we had compatibiltiy codepaths. Such old kernels are not seriously used for LXC these days, so the compat code can go away Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com> --- src/lxc/lxc_controller.c | 28 +++++++++------------------- 1 file changed, 9 insertions(+), 19 deletions(-) diff --git a/src/lxc/lxc_controller.c b/src/lxc/lxc_controller.c index 1d1443c..cede445 100644 --- a/src/lxc/lxc_controller.c +++ b/src/lxc/lxc_controller.c @@ -1252,8 +1252,9 @@ virLXCControllerSetupDevPTS(virLXCControllerPtr ctrl) } if (access(ctrl->devptmx, R_OK) < 0) { - VIR_WARN("Kernel does not support private devpts, using shared devpts"); - VIR_FREE(ctrl->devptmx); + virReportSystemError(ENOSYS, "%s", + _("Kernel does not support private devpts")); + goto cleanup; } ret = 0; @@ -1278,24 +1279,13 @@ virLXCControllerSetupConsoles(virLXCControllerPtr ctrl, size_t i; for (i = 0 ; i < ctrl->nconsoles ; i++) { - if (ctrl->devptmx) { - VIR_DEBUG("Opening tty on private %s", ctrl->devptmx); - if (lxcCreateTty(ctrl->devptmx, - &ctrl->consoles[i].contFd, - &containerTTYPaths[i]) < 0) { - virReportSystemError(errno, "%s", - _("Failed to allocate tty")); - return -1; - } - } else { - VIR_DEBUG("Opening tty on shared /dev/ptmx"); - if (virFileOpenTty(&ctrl->consoles[i].contFd, - &containerTTYPaths[i], - 0) < 0) { - virReportSystemError(errno, "%s", + VIR_DEBUG("Opening tty on private %s", ctrl->devptmx); + if (lxcCreateTty(ctrl->devptmx, + &ctrl->consoles[i].contFd, + &containerTTYPaths[i]) < 0) { + virReportSystemError(errno, "%s", _("Failed to allocate tty")); - return -1; - } + return -1; } } return 0; -- 1.7.11.7

3 11

[libvirt] [RFC] Per machine type qemu capability detection
by Peter Krempa 04 Apr '13

04 Apr '13

Hi, qemu recently added a qmp/hmp command ("get-cpu-max") to determine maximum number of supported CPUs for a VM. The output of this command depends on the machine type that is used when it is called. The problem here is that libvirt uses "-M none" while detecting capabilities and with that machine type the get-cpu-max command returns always 1. My question is: Is it worthwhile to do per machine type capability detection? It definitely isn't worth doing just for the get-cpu-max support, but it might be needed for Q35 or other stuff that may depend on the actual machine type used. Pros of this approach: ---------------------- - (possibly) more accurate capabilities Cons: ----- - ~10x more qemus started on libvirtd startup (one per machine type) Thanks for your opinions. Peter

4 6

[libvirt] [RFC 0/5] X86CPU "feature-words" & "filtered-features" properties (v2)
by Eduardo Habkost 04 Apr '13

04 Apr '13

Changes v2: * Added "filtered-features" properties * Removed the non-qapi version and kept only the qapi version of the code * Moved the new types to qapi-schema.json instead of creating cpu-qapi-schema.json * Rebased on top of "feature words array" series Git tree: https://github.com/ehabkost/qemu-hacks/tree/work/cpu-raw-feature-props-v2 git://github.com/ehabkost/qemu-hacks.git work/cpu-raw-feature-props-v2 Description: As the work to get X86CPU subclasses static properties defined is taking very long to get reviewed and we risk not getting it finished in 1.5, I am sending an alternative mechanism to allow libvirt to probe for CPU model information. It's interesting to note that this alternative solution is actually _easier_ to use for libvirt, because libvirt logic is already based on CPUID bit values, not "feature names", so it should be very easy to convert the current libvirt code that (incorrectly) query the host CPU directly for available features to instead start QEMU with "-cpu host" and use the "feature-words" array information to find out which CPU features are supported by the host. The "feature-words" property will have two main use cases: * Checking host capabilities, by checking the features of the "host" CPU model; * Checking which features are enabled on each CPU model. The "filtered-features" property will have two main use cases: * Allowing libvirt to emulate the "check" & "enforce" flags while collecting more detailted data about the missing features; * Allowing libvirt to probe for CPU model information even if host features are missing (it can simply combine the "feature-words" and "filtered-features" values to get the full CPU model definition) Example output: $ ./QMP/qmp --path=/tmp/m qom-get --path=/machine/unattached/device[1] --property=feature-words item[0].cpuid-register: EDX item[0].cpuid-input-eax: 1 item[0].features: 126614521 item[1].cpuid-register: ECX item[1].cpuid-input-eax: 1 item[1].features: 2155880449 item[2].cpuid-register: EBX item[2].cpuid-input-eax: 7 item[2].features: 0 item[2].cpuid-input-ecx: 0 item[3].cpuid-register: EDX item[3].cpuid-input-eax: 2147483649 item[3].features: 563346425 item[4].cpuid-register: ECX item[4].cpuid-input-eax: 2147483649 item[4].features: 101 item[5].cpuid-register: EDX item[5].cpuid-input-eax: 3221225473 item[5].features: 0 item[6].cpuid-register: EAX item[6].cpuid-input-eax: 1073741825 item[6].features: 0 item[7].cpuid-register: EDX item[7].cpuid-input-eax: 2147483658 item[7].features: 0 Eduardo Habkost (5): target-i386: Add ECX information to FeatureWordInfo target-i386: Add "feature-words" property target-i386: Use FeatureWord loop on filter_features_for_kvm() target-i386: Introduce X86CPU.filtered_features field target-i386: Add "filtered-features" property to X86CPU .gitignore | 2 + Makefile.objs | 7 +++- qapi-schema.json | 32 +++++++++++++++ target-i386/cpu-qom.h | 3 ++ target-i386/cpu.c | 110 +++++++++++++++++++++++++++++++++++--------------- 5 files changed, 121 insertions(+), 33 deletions(-) -- 1.8.1.4

1 5

[libvirt] libvirt_lxc: implement <hostdev caps=net> device isolation in containers
by Bogdan Purcareata 04 Apr '13

04 Apr '13

>From Bogdan Purcareata <bogdan.purcareata(a)freescale.com> # This line is ignored. From: Bogdan Purcareata <bogdan.purcareata(a)freescale.com> Subject: libvirt_lxc: implement <hostdev caps=net> device isolation in containers In-Reply-To:

1 2

[libvirt] language bindings
by Vasiliy Tolstov 04 Apr '13

04 Apr '13

Hello. I'm newbie in libvirt world and not able to find answer for my question in google. If i want to create binding for some language (for example go) is that possible do not use libvirt C library and talk to libvirtd via some rpc protocol? For example json or internal binary.. is that possible to talk to libvirtd not using C library? -- Vasiliy Tolstov, e-mail: v.tolstov(a)selfip.ru jabber: vase(a)selfip.ru

3 3

Re: [libvirt] [Qemu-devel] attaching disk to paused guest
by Stefan Hajnoczi 04 Apr '13

04 Apr '13

On Wed, Apr 3, 2013 at 1:05 PM, Liron Aravot <laravot(a)redhat.com> wrote: > does qemu support attaching disk to a paused guest? Does it makes sense to allow this operation? Yes, it works. I tested it via libvirt: $ virsh start vm $ cat >/tmp/disk.xml <disk type='file' device='disk'> <driver name='qemu' type='raw'/> <source file='path/to/new_disk.img'/> <target dev='vdb' bus='virtio'/> <alias name='virtio-disk1'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/> </disk> ^D $ virsh suspend vm $ virsh list Id Name State ---------------------------------------------------- 1 vm paused $ virsh attach-device vm /tmp/disk.xml Device attached successfully $ virsh resume vm The issue with hotplug is that it may involve guest cooperation. This is not possible when the guest is paused, but attaching a new virtio-blk adapter is okay because we'll just have pending PCI hotplug notifications when the guest is resumed. Hot unplug is the nasty case because the guest OS isn't running and cannot terminate its guest driver for the device. Because of this, both network adapters and disks in QEMU try to clean up after themselves and libvirt does not need to wait for the guest to acknowledge hot unplug. I think both hotplug and hot unplug should work fine while the guest is paused. Stefan

1 0

[libvirt] [PATCH v3 00/11] Add support for guests with TPM passthrough device
by Stefan Berger 04 Apr '13

04 Apr '13

Hello! The following set of patches adds support to libvirt for adding a TPM passthrough device to a QEMU guest. Support for this was recently accepted into QEMU. This set of patches borrows a lot from the recently added support for rng's. Regards, Stefan --- v2->v3: - followed tree to 03122d7b - some bits fixed v1->v2: - Followed Daniel Berrange's comments (except for the one on de-consolidating the JSON monitor code)

4 23

[libvirt] [PATCH] storage: Fix volume cloning for logical volume.
by Atsushi Kumagai 04 Apr '13

04 Apr '13

When creating a logical volume with virStorageVolCreateXMLFrom, "qemu-img convert" is called internally if clonevol is a file volume. Then, vol->target.format is used as output_fmt parameter but the target.format of logical volumes is always 0 because logical volumes haven't the volume format type element. Fortunately, 0 was treated as RAW file format before commit f772b3d9, so there was no problem. But now, 0 is treated as the type of none, qemu-img fails with "Unknown file format 'none'". This patch fixes this issue by treating output block devices as RAW file format like for input block devices. Signed-off-by: Atsushi Kumagai <kumagai-atsushi(a)mxc.nes.nec.co.jp> diff --git a/src/storage/storage_backend.c b/src/storage/storage_backend.c index bb58d4a..2551f1f 100644 --- a/src/storage/storage_backend.c +++ b/src/storage/storage_backend.c @@ -652,7 +652,12 @@ virStorageBackendCreateQemuImgCmd(virConnectPtr conn, unsigned long long int size_arg; bool preallocate = false; - const char *type = virStorageFileFormatTypeToString(vol->target.format); + /* Treat output block devices as 'raw' format */ + const char *type = + virStorageFileFormatTypeToString(vol->type == VIR_STORAGE_VOL_BLOCK ? + VIR_STORAGE_FILE_RAW : + vol->target.format); + const char *backingType = vol->backingStore.path ? virStorageFileFormatTypeToString(vol->backingStore.format) : NULL; -- 1.7.1

2 1