January 2013 - Devel - libvirt List Archives

[libvirt] [libvirt-php PATCH 0/1] use LDFLAGS for libvirt-php.so
by stefan.kuhn＠foss-group.ch 08 Apr '13

08 Apr '13

I'm getting this warning: * QA Notice: Files built without respecting LDFLAGS have been detected * Please include the following list of files in your report: * /usr/lib64/php5.3/lib/extensions/no-debug-non-zts-20090626/libvirt-php.so The attached patch seems reasonable to me, please check it. Thank you very much for the quick responses and for adding me to the authors! :-) Stefan Stefan Kuhn (1): src/Makefile.am: use LDFLAGS for libvirt-php.so src/Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 1.7.12.4

2 2

[libvirt] Problems with <filesystem type='block'>
by Lars Kellogg-Stedman 24 Mar '13

24 Mar '13

Using libvirt 1.0.1, I'm trying to start an LXC container using the '<filesytem type="block">' syntax, like this: <filesystem type="block" accessmode="passthrough"> <source dev="/dev/vg_files/vm-foobar-root" /> <target dir="/" /> </filesystem> The specified block device exists: # ls -lL /dev/vg_files/vm-foobar-root brw-rw---- 1 root disk 253, 19 Dec 21 22:23 /dev/vg_files/vm-foobar-root If I start the domain, it appears to start without any errors... # virsh start foobar Domain foobar started ...but it's not actually running. The log files (with loglevel=2) don't seem to be very interesting; this is everything from the instance log file: 2012-12-22 04:10:57.862+0000: starting up PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin LIBVIRT_DEBUG=2 LIBVIRT_LOG_OUTPUTS=2:stderr /usr/lib/libvirt/libvirt_lxc --name foobar --console 22 --security=none --handshake 25 --background --veth veth1 2012-12-22 04:10:57.967+0000: 1468: info : libvirt version: 1.0.1 2012-12-22 04:10:57.967+0000: 1468: info : lxcCapsInit:151 : No driver, not initializing security driver PATH=/bin:/sbin TERM=linux container=lxc-libvirt container_uuid=9041e32e-1df2-00c2-4660-dfa5b41510b7 LIBVIRT_LXC_UUID=9041e32e-1df2-00c2-4660-dfa5b41510b7 LIBVIRT_LXC_NAME=foobar /sbin/init 2012-12-22 04:10:58.198+0000: 1: warning : lxcContainerDropCapabilities:1788 : libcap-ng support not compiled in, unable to clear capabilities 2012-12-22 04:10:58.198+0000: 1493: warning : lxcControllerClearCapabilities:679 : libcap-ng support not compiled in, unable to clear capabilities Running an "strace" on the libvirtd process (strace -p <libvirtd_pid> -f ...), it doesn't look like libvirt is ever trying to mount the referenced filesystem. Is this supposed to work? It seems like the support for having libvirt mount the block device is relatively recent, and I haven't had much luck finding examples of other folks using this capability. Thanks, -- Lars

4 8

[libvirt] [PATCH 0/4] Multiple problems with saving to block devices
by Daniel P. Berrange 24 Mar '13

24 Mar '13

This patch series makes it possible to save to a block device, instead of a plain file. There were multiple problems - WHen save failed, we might de-reference a NULL pointer - When save failed, we unlinked the device node !! - The approach of using >> to append, doesn't work with block devices - CGroups was blocking QEMU access to the block device when enabled One remaining problem is not in libvirt, but rather QEMU. The QEMU exec: based migration often fails to detect failure of the command and will thus hang forever attempting a migration that'll never succeed! Fortunately you can now work around this in libvirt using the virsh domjobabort command

4 21

Re: [libvirt] if_bridge.h: include in6.h for struct in6_addr use
by Thomas Backlund 13 Mar '13

13 Mar '13

Thomas Backlund skrev 13.1.2013 20:38: > patch both inline and attached as thunderbird tends to mess up ... > ----- > > if_bridge.h uses struct in6_addr ip6; but does not include the in6.h > header. > > Found by trying to build libvirt and connman against 3.8-rc3 headers. > Ok, ignore this patch, it's not the correct fix as it introduces redefinitions... Btw, the error that I hit that made me suggest this fix was libvirt config check bailing out: config.log:/usr/include/linux/if_bridge.h:173:20: error: field 'ip6' has incomplete type > Reported-by: Colin Guthrie <colin(a)mageia.org> > Reported-by: Christiaan Welvaart <cjw(a)daneel.dyndns.org> > Signed-off-by: Thomas Backlund <tmb(a)mageia.org> > > -- > > diff -Nurp linux-3.8-rc3/include/uapi/linux/if_bridge.h > linux-3.8-rc3.fix/include/uapi/linux/if_bridge.h > --- linux-3.8-rc3/include/uapi/linux/if_bridge.h 2013-01-13 > 20:09:54.257271755 +0200 > +++ linux-3.8-rc3.fix/include/uapi/linux/if_bridge.h 2013-01-13 > 20:15:04.153676151 +0200 > @@ -14,6 +14,7 @@ > #define _UAPI_LINUX_IF_BRIDGE_H > > #include <linux/types.h> > +#include <linux/in6.h> > > #define SYSFS_BRIDGE_ATTR "bridge" > #define SYSFS_BRIDGE_FDB "brforward" > > > ----- > Thomas > -- Thomas

9 14

Re: [libvirt] [Qemu-devel] [Qemu PATCH v2] add a boot option to do strict boot
by Eric Blake 04 Mar '13

04 Mar '13

On 01/09/2013 01:39 AM, Amos Kong wrote: > Current seabios will try to boot from selected devices first, > if they are all failed, seabios will also try to boot from > un-selected devices. > > We need to make it configurable. I already posted a seabios > patch to add a new device type to halt booting. Qemu can add > "HALT" at the end of bootindex string, then seabios will halt > booting after trying to boot from selected devices. > > This option only effects when boot priority is changed by > bootindex options, the old style(-boot order=..) will still > try to boot from un-selected devices. > > v2: add HALT entry in get_boot_devices_list() > define boot_strict to bool > > Signed-off-by: Amos Kong <akong(a)redhat.com> > --- Libvirt will need to expose an attribute that lets the user control whether to use this new option; how do we probe via QMP whether the new -boot strict=on command-line option is available? > +++ b/qemu-options.hx > @@ -376,14 +376,14 @@ ETEXI > > DEF("boot", HAS_ARG, QEMU_OPTION_boot, > "-boot [order=drives][,once=drives][,menu=on|off]\n" > - " [,splash=sp_name][,splash-time=sp_time][,reboot-timeout=rb_time]\n" > + " [,splash=sp_name][,splash-time=sp_time][,reboot-timeout=rb_time][,strict=on|off]\n" > " 'drives': floppy (a), hard disk (c), CD-ROM (d), network (n)\n" > " 'sp_name': the file's name that would be passed to bios as logo picture, if menu=on\n" > " 'sp_time': the period that splash picture last if menu=on, unit is ms\n" > " 'rb_timeout': the timeout before guest reboot when boot failed, unit is ms\n", So if I understand correctly, -boot order=... is incompatible with -boot strict=on; even though you have listed both options under a single -boot entry in the -help. We've already declared that -help output is no longer guaranteed stable, so this doesn't really impact libvirt, but would it make any more sense to list this as two orthogonal entries, to make it clear that they don't mix? -boot order=drivers[,once=drives]... -boot strict=on|off[,menu=on|off]... But this is all bikeshedding, so it's not worth a v3 if you disagree. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org

9 16

[libvirt] [PATCHv3 0/5] snapshot revert-and-create
by Eric Blake 28 Feb '13

28 Feb '13

v2 was here: https://www.redhat.com/archives/libvir-list/2012-November/msg00818.html One patch from v2 has already been committed. This patch additionally adds a qemu implementation for the new flag, and I have tested creation of offline branches (I still need to test creation of a branch from a disk-only or online external snapshot). I've also started documenting my plans for a new revert FOLLOW flag, which updates to the current state of external files (rather than reverting completely to the point where the snapshot was taken); once that is working, then implementing the combination of createXML(LIVE|BRANCH) will really be creating the branch, then farming out to revert(FOLLOW) to switch over to the new branch. Eric Blake (5): snapshot: add revert-and-create branching of external snapshots snapshot: prepare to parse new XML snapshot: actually compute branch definition from XML snapshot: support revert-and-create branching in qemu snapshot: add another revert API flag docs/formatsnapshot.html.in | 16 ++++- docs/schemas/domainsnapshot.rng | 45 ++++++------ include/libvirt/libvirt.h.in | 6 ++ src/conf/snapshot_conf.c | 118 ++++++++++++++++++++++++++++--- src/conf/snapshot_conf.h | 2 + src/esx/esx_driver.c | 2 +- src/libvirt.c | 41 +++++++++-- src/qemu/qemu_driver.c | 50 +++++++++++-- src/vbox/vbox_tmpl.c | 2 +- tests/domainsnapshotxml2xmlin/branch.xml | 5 ++ tests/domainsnapshotxml2xmltest.c | 2 +- tools/virsh-snapshot.c | 44 +++++++++--- tools/virsh.pod | 25 ++++++- 13 files changed, 300 insertions(+), 58 deletions(-) create mode 100644 tests/domainsnapshotxml2xmlin/branch.xml -- 1.7.11.7

2 6

[libvirt] [PATCH] ESX: Add AnyType_Serialize routine to esx_vi_types.c
by Ata E Husain Bohra 25 Feb '13

25 Feb '13

Add esxVI_AnyType_Serialize routine to allow serialization of objects containing variables of type "AnyType". The routine attempts to determine the type of the object that covers: boolean, long, int, string, short, byte. If variables does not fall under any above mentioned types then it is added as "anyType". --- src/esx/esx_vi_types.c | 48 ++++++++++++++++++++++++++++++++++++++++++++++++ src/esx/esx_vi_types.h | 3 ++- 2 files changed, 50 insertions(+), 1 deletion(-) diff --git a/src/esx/esx_vi_types.c b/src/esx/esx_vi_types.c index d1f91ff..2076ce4 100644 --- a/src/esx/esx_vi_types.c +++ b/src/esx/esx_vi_types.c @@ -1130,6 +1130,54 @@ esxVI_AnyType_Deserialize(xmlNodePtr node, esxVI_AnyType **anyType) +int +esxVI_AnyType_Serialize(esxVI_AnyType *anyType, const char *element, + virBufferPtr output) +{ + if (element == NULL || output == NULL) { + virReportError(VIR_ERR_INTERNAL_ERROR, "%s", + _("Invalid argument")); + return -1; + } + + if (anyType == NULL || anyType->value == NULL) { + return 0; + } + + switch (anyType->type) { + case esxVI_Type_Boolean: + ESV_VI__XML_TAG__OPEN(output, element, "xsd:boolean"); + break; + case esxVI_Type_String: + ESV_VI__XML_TAG__OPEN(output, element, "xsd:string"); + break; + case esxVI_Type_Short: + ESV_VI__XML_TAG__OPEN(output, element, "xsd:short"); + break; + case esxVI_Type_Byte: + ESV_VI__XML_TAG__OPEN(output, element, "xsd:byte"); + break; + case esxVI_Type_Int: + ESV_VI__XML_TAG__OPEN(output, element, "xsd:int"); + break; + case esxVI_Type_Long: + ESV_VI__XML_TAG__OPEN(output, element, "xsd:long"); + break; + case esxVI_Type_Undefined: + case esxVI_Type_Other: + default: + ESV_VI__XML_TAG__OPEN(output, element, "xsd:anyType"); + break; + } + + virBufferAdd(output, anyType->value, -1); + + ESV_VI__XML_TAG__CLOSE(output, element); + + return 0; +} + + /* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * XSD: String */ diff --git a/src/esx/esx_vi_types.h b/src/esx/esx_vi_types.h index 92dc16f..5150377 100644 --- a/src/esx/esx_vi_types.h +++ b/src/esx/esx_vi_types.h @@ -161,7 +161,8 @@ const char *esxVI_AnyType_TypeToString(esxVI_AnyType *anyType); int esxVI_AnyType_ExpectType(esxVI_AnyType *anyType, esxVI_Type type); int esxVI_AnyType_DeepCopy(esxVI_AnyType **dest, esxVI_AnyType *src); int esxVI_AnyType_Deserialize(xmlNodePtr node, esxVI_AnyType **anyType); - +int esxVI_AnyType_Serialize(esxVI_AnyType *anyType, const char *element, + virBufferPtr output); /* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * -- 1.7.9.5

3 3

[libvirt] [PATCHv2 0/5] Add API to allow TCP connection tunelling
by Peter Krempa 25 Feb '13

25 Feb '13

This series adds ability for the qemu driver to tunnel connections to TCP ports from the host. This is useful for enabling remote VNC/SPICE sessions without the need to configure SSH tunnels or portforwards and without the need to open the ports for public. There's also an advantage for tools such as virt-viewer that have to guess the remote connection parameters and you have to hope that nothing is in your way. With spice/VNC clients that have support for read/write callbacks, this would allow also direct connection without an intermediate socket. The API and tunelling works but there's no (stable and good working) client for this API. I hacked up a dirty netcat-like terminal into virsh for testing purposes (see patch 5/5) but that isn't what I'd like to see. The client should be able to open a listening socket and when a client connects to it, it opens a stream and connects it to the remote host. For the client there are two options: 1) do all the stuff in virsh: + one tool to rule them all - i'd like to daemonize it and I don't know if that's okay in virsh 2) add a new tool "virtunnel": + less virsh pollution - separate tool ... As nobody responded, I'd like to re-ask for someones opinion on this. (note: this is my personal effort, I'm annoyed of opening ssh tunnels to remote displays on my server and I don't want to open the ports to public. ) After this it would be great to add support for this to virt-viewer. I will have a look at that later. ---- Diff to v1: - fixed error reporting in 2/5 - documented limitation to "localhost" in 3/5 - fixed possible segfault in 4/5 --- Peter Krempa (5): api: Add API to allow TCP tunneling through streams to the host fdstream: Add support for TCP connections of streams qemu: Add configuration options to enable TCP tunelling qemu: Implement virNodeTunnelTcp for the qemu driver NOT_TO_BE_APPLIED_UPSTREAM: quick and dirty virsh client to test the stuff include/libvirt/libvirt.h.in | 11 +++++++ src/driver.h | 8 +++++ src/fdstream.c | 73 ++++++++++++++++++++++++++++++++++++++++++++ src/fdstream.h | 5 +++ src/libvirt.c | 67 ++++++++++++++++++++++++++++++++++++++++ src/libvirt_private.syms | 1 + src/libvirt_public.syms | 1 + src/qemu/qemu.conf | 16 ++++++++++ src/qemu/qemu_conf.c | 26 ++++++++++++++++ src/qemu/qemu_conf.h | 13 ++++++++ src/qemu/qemu_driver.c | 48 +++++++++++++++++++++++++++++ src/remote/remote_driver.c | 1 + src/remote/remote_protocol.x | 9 +++++- src/remote_protocol-structs | 6 ++++ src/rpc/gendispatch.pl | 1 + tools/console.c | 66 +++++++++++++++++++++------------------ tools/console.h | 9 ++---- tools/virsh-domain.c | 17 +++++++++-- tools/virsh-host.c | 60 ++++++++++++++++++++++++++++++++++++ 19 files changed, 397 insertions(+), 41 deletions(-) -- 1.8.0

2 7

[libvirt] [PATCH 0/2] Support PCI passthrough in libxl driver
by Chunyan Liu 24 Feb '13

24 Feb '13

This patch series is to add PCI passthrough support to libxenlight driver so that it can create VM with managed/non-managed host pci device defined. Chunyan Liu (2): libxl: add APIs to prepare/release host pci device libxl: support pci passthrough po/POTFILES.in | 1 + src/Makefile.am | 1 + src/libxl/libxl_conf.c | 44 ++++ src/libxl/libxl_conf.h | 5 +- src/libxl/libxl_driver.c | 16 ++ src/libxl/libxl_hostdev.c | 600 +++++++++++++++++++++++++++++++++++++++++++++ src/libxl/libxl_hostdev.h | 44 ++++ 7 files changed, 710 insertions(+), 1 deletions(-) create mode 100644 src/libxl/libxl_hostdev.c create mode 100644 src/libxl/libxl_hostdev.h -- 1.7.3.4

6 7

[libvirt] [PATCH] virsh: add --start option to the define command
by Doug Goldstein 21 Feb '13

21 Feb '13

I often find myself doing virsh "define blah.xml; start blah". I figured adding this would be a easier^Hlazier way to do it. --- tools/virsh-domain.c | 20 ++++++++++++++++++-- 1 files changed, 18 insertions(+), 2 deletions(-) diff --git a/tools/virsh-domain.c b/tools/virsh-domain.c index e91939c..1a3af34 100644 --- a/tools/virsh-domain.c +++ b/tools/virsh-domain.c @@ -5597,6 +5597,7 @@ static const vshCmdInfo info_define[] = { static const vshCmdOptDef opts_define[] = { {"file", VSH_OT_DATA, VSH_OFLAG_REQ, N_("file containing an XML domain description")}, + {"start", VSH_OT_BOOL, 0, N_("start the domain after creation")}, {NULL, 0, 0, NULL} }; @@ -5607,6 +5608,7 @@ cmdDefine(vshControl *ctl, const vshCmd *cmd) const char *from = NULL; bool ret = true; char *buffer; + bool start; if (vshCommandOptString(cmd, "file", &from) <= 0) return false; @@ -5614,17 +5616,31 @@ cmdDefine(vshControl *ctl, const vshCmd *cmd) if (virFileReadAll(from, VSH_MAX_XML_FILE, &buffer) < 0) return false; + start = vshCommandOptBool(cmd, "start"); + dom = virDomainDefineXML(ctl->conn, buffer); VIR_FREE(buffer); if (dom != NULL) { vshPrint(ctl, _("Domain %s defined from %s\n"), virDomainGetName(dom), from); - virDomainFree(dom); } else { vshError(ctl, _("Failed to define domain from %s"), from); - ret = false; + return false; } + + /* Start the domain if the user requested it and it was defined */ + if (start) { + if (virDomainCreate(dom) < 0) { + vshError(ctl, _("Failed to start domain %s, which was " + "successfully defined."), virDomainGetName(dom)); + ret = false; + } else { + vshPrint(ctl, _("Domain %s started\n"), virDomainGetName(dom)); + } + } + + virDomainFree(dom); return ret; } -- 1.7.8.6

7 10