December 2009 - Devel - libvirt List Archives

[libvirt] Out of band channels
by Matthew Booth 11 Dec '09

11 Dec '09

A libvirt client can connect to libvirt on a remote host. However, on its own this doesn't give the client a usable level of access. The reason for this is that libvirt doesn't expose some critical management interfaces. For QEMU this amounts to pretty much anything provided directly by the QEMU process, including: * VNC console [1] * Any character device [2] I'm undecided as to whether access to underlying storage falls into this bucket. It would certainly be convenient in certain circumstances. This means, for example that I need out of band access to: * See a graphical console * Connect to a serial console * Connect to a guest channel As these are fairly fundamental operations, I wonder if there has been any thought towards creating tunnels over a libvirt connection. In the first instance, I think this would require a generic method to multiplex multiple streams over a single remote connection. This would obviously be a significant protocol change. Would a messaging protocol, AMQP for instance, be a good candidate here? Secondly, I think interfaces which currently create local resources should have a default which is managed by libvirt itself. So you'd have: <serial> <target port='0'/> </serial> or <serial type='managed'> <target port='0'/> </serial> This would cause libvirt to create whichever host-side chardev is most convenient to it and connect itself. The API would then expose read and write APIs for the named connection. e.g: virDomainFoo foo;[3] if = virDomainGetFoo(domain, "serial0"); bytesIn = virDomainFooRead(foo, &buf, sizeof(buf)); A client application could expose this in a variety of ways locally. Matt [1] There's an open RFE for this one: https://bugzilla.redhat.com/show_bug.cgi?id=526953 [2] e.g. virsh # console RHEL3.FV.64.IDE error: Cannot connect to a remote console device [3] What would you call it? -- Matthew Booth, RHCA, RHCSS Red Hat Engineering, Virtualisation Team M: +44 (0)7977 267231 GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490

3 2

[libvirt] [PATCH] Fix reference leak in remoteDispatchStorageVolCreateXmlFrom
by Matthias Bolte 11 Dec '09

11 Dec '09

--- daemon/remote.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/daemon/remote.c b/daemon/remote.c index 3117615..7a43046 100644 --- a/daemon/remote.c +++ b/daemon/remote.c @@ -4118,12 +4118,15 @@ remoteDispatchStorageVolCreateXmlFrom (struct qemud_server *server ATTRIBUTE_UNU clonevol = get_nonnull_storage_vol (conn, args->clonevol); if (clonevol == NULL) { + virStoragePoolFree(pool); remoteDispatchConnError(rerr, conn); return -1; } newvol = virStorageVolCreateXMLFrom (pool, args->xml, clonevol, args->flags); + virStorageVolFree(clonevol); + virStoragePoolFree(pool); if (newvol == NULL) { remoteDispatchConnError(rerr, conn); return -1; -- 1.6.0.4

2 2

[libvirt] [PATCH] Fix memory leak in virStorageBackendCopyToFD
by Matthias Bolte 11 Dec '09

11 Dec '09

--- src/storage/storage_backend.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/src/storage/storage_backend.c b/src/storage/storage_backend.c index a3b4d5a..9dc801c 100644 --- a/src/storage/storage_backend.c +++ b/src/storage/storage_backend.c @@ -198,6 +198,8 @@ cleanup: if (inputfd != -1) close(inputfd); + VIR_FREE(buf); + return ret; } -- 1.6.0.4

2 2

[libvirt] simple LXC/libvirt busybox container (Unable to get cgroup)
by Tony Risinger 11 Dec '09

11 Dec '09

i'm trying to get even the simplest busybox container with libvirt+LXC with very limited success. I feel l am missing something supremely simple for me to be hung on this for weeks. i dont see anything interesting in domain log, but getting this error from "LIBVIRT_DEBUG=1 libvirtd": 05:27:56.113: error : lxcDomainGetInfo:462 : internal error Unable to get cgroup for arch-nano 05:27:56.113: debug : virDomainFree:2004 : domain=0x81d8e68 05:27:56.113: debug : virUnrefDomain:422 : unref domain 0x81d8e68 arch-nano 1 05:27:56.113: debug : virReleaseDomain:376 : release domain 0x81d8e68 arch-nano 05:27:56.113: debug : virReleaseDomain:392 : unref connection 0x81dc0f0 2 05:27:56.113: debug : remoteSerializeError:141 : prog=536903814 ver=1 proc=16 type=1 serial=4, msg=internal error Unable to get cgroup for arch-nano i've been using this root filesystem layout: [root@PHS-001 arch-nano]# tree . |-- bin | |-- cat -> ../sbin/busybox | |-- chdir -> ../sbin/busybox | |-- chmod -> ../sbin/busybox | |-- ls -> ../sbin/busybox | |-- rm -> ../sbin/busybox | |-- sh -> ../sbin/busybox | `-- vi -> ../sbin/busybox |-- dev | `-- pts |-- etc |-- proc |-- sbin | |-- busybox | `-- init -> busybox `-- sys all folders besides /bin and /sbin were created by libvirt. i tried using the /sbin/init script previously suggested: #!/sbin/busybox sh but i get a similar results either way (script/symlink): 8173 ? Ss 0:00 /usr/lib/libvirt-git/libvirt_lxc --name arch-nano --console 11 --background 8175 pts/0 Ss+ 0:00 init 8177 ? Ss 0:00 init 8181 ? Zs 0:00 [init] <defunct> 8182 ? Zs 0:00 [init] <defunct> 8183 ? Zs 0:00 [init] <defunct> "busybox init" doc says that without an /etc/inittab, sh will be started on /dev/tty2... im am using this config: <domain type='lxc'> <name>arch-nano</name> <memory>500000</memory> <os> <type>exe</type> <init>/sbin/init</init> </os> <devices> <filesystem type='mount'> <source dir='/vps/dom/arch-nano'/> <target dir='/'/> </filesystem> </devices> </domain> on this config i tried removing the console/serial section altogether, but i attempted many configurations of serial/console, including changing the <target> to "2", in attempt to match busybox default. [root@PHS-001 arch-nano]# virsh -c lxc:/// console arch-nano error: Unable to get domain status error: internal error Unable to get cgroup for arch-nano [root@PHS-001 arch-nano]# mount | grep cgroup none on /cgroup type cgroup (rw) if anyone can please point out what i am doing wrong to not be able to move the root and get a console, i'd greatly appreciate it. ive been really stuck on this; i'd rather not write a bunch of scripts/wrappers for lxc-* tools when libvirt does it all splendidly already! libvirt 0.7.4+ kernel 2.6.32 (am i missing a CONFIG_*?) thanks for your time

3 6

[libvirt] My beefs with the libvirt XML configuration format
by Diego Elio “Flameeyes” Pettenò 11 Dec '09

11 Dec '09

Hello, In a recent post on my blog [1] I ranted on about libvirt and in particular I complained that the configuration files look like what I call “almost XML”. The reasons why I say that are multiple, let me try to explain some. In the configuration files, at least those created by virt-manager there is no specification of what the file should be (no document type, no namespace, and, IMHO, a too generic root element name); given that some kind of distinction is needed for software like Emacs's nxml-mode to know how to deal with the file, I think that's pretty bad for interaction between different applications. While libvirt knows perfectly well what it's dealing with, other packages might not. Might not sound a major issue but it starts tickling my senses when this happens. The configuration seem somewhat contrived in places like the disk configuration: if the disk is file-backed it require the file attribute to the <source> element, while it needs the dev attribute if it's a block device; given that it's a path in both cases it would have sounded easier on the user if a single path attribute was used. But this is opinable. The third problem I called out for in the block is a lack of a schema for the files; Daniel corrected me pointing out that the schemas are distributed with the sources and installed. Sure thing, I was wrong. On the other hand I maintain that there are problems with those schemas. The first is that both the version distributed with 0.7.4 and the git version as of today suffer from bug #546254 [2] (secret.rng being not well formed) so it means nobody has even tested them as of lately; then there is the fact that they are never referenced by the human-readable documentation [3] which is why I didn't find it the first time around; add also to that some contrived syntax in those schema as well that causes trang to produce a non-valid rnc file out of them (nxml-mode uses rnc rather than rng). But I guess the one big problem with the schemas is that they don't seem to properly encode what the human-readable documentation says, or what virt-manager does. For instance (please follow me with selector-like syntax), virt-manager creates /domain/os/type[@machine='pc-0.11'] in the created XML; the same attribute seem to be documented: “There are also two optional attributes, arch specifying the CPU architecture to virtualization, and machine referring to the machine type”. The schema does not seem to accept that attribute though (“element type: Relax-NG validity error : Invalid attribute machine for element type” with xmllint, just to make sure that it's not a bug in any other piece of software, this is Daniel's libxml2). Now after voicing my opinions here, as Daniel dared me to do, I'd like to explain a second why I didn't post this on the list in the first place: of what I wrote here, my beefs for calling this aXML, the only things that can be solved easily are the schemas; schemas that, at the time I wrote the blog, I was unable to find. The syntax, and the lack of a “safe” identification of the files as libvirt's are the kind of legacy problems one has to deal with to avoid wasting users' time with migrations and corrections, so I don't really think they should be addressed unless a redesign of the configuration is intended. Just my two cents, you're free to take them as you wish, I cannot boast a curriculum like Daniel's, but I don't think I'm stepping out of place to point out these things. [1] http://blog.flameeyes.eu/2009/12/07/i-know-you-missed-them-virtualisation-r… [2] https://bugzilla.redhat.com/show_bug.cgi?id=546254 [3] http://libvirt.org/format.html -- Diego Elio Pettenò — “Flameeyes” http://blog.flameeyes.eu/ If you found a .asc file in this mail and know not what it is, it's a GnuPG digital signature: http://www.gnupg.org/

6 10

[libvirt] [PATCH] Fix detection of JSON when restarting libvirtd
by Daniel P. Berrange 11 Dec '09

11 Dec '09

The XML XPath for detecting JSON in the running VM statefile was wrong causing all VMs to get JSON mode enabled at libvirtd restart. In addition if a VM was running a JSON enabled QEMU once, and then altered to point to a non-JSON enabled QEMU later the 'monJSON' flag would not get reset to 0. * src/qemu/qemu_driver.c: Fix setting/detection of JSON mode --- src/qemu/qemu_driver.c | 7 ++++++- 1 files changed, 6 insertions(+), 1 deletions(-) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 0dccae6..3661ef0 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -220,8 +220,11 @@ static int qemuDomainObjPrivateXMLParse(xmlXPathContextPtr ctxt, void *data) priv->monConfig->type = VIR_DOMAIN_CHR_TYPE_PTY; VIR_FREE(tmp); - if (virXPathBoolean(NULL, "int(./monitor[1]/@json)", ctxt)) + if (virXPathBoolean(NULL, "count(./monitor[@json = '1']) > 0", ctxt)) { priv->monJSON = 1; + } else { + priv->monJSON = 0; + } switch (priv->monConfig->type) { case VIR_DOMAIN_CHR_TYPE_PTY: @@ -2361,7 +2364,9 @@ static int qemudStartVMDaemon(virConnectPtr conn, #if HAVE_YAJL if (qemuCmdFlags & QEMUD_CMD_FLAG_MONITOR_JSON) priv->monJSON = 1; + else #endif + priv->monJSON = 0; if ((ret = virFileDeletePid(driver->stateDir, vm->def->name)) != 0) { virReportSystemError(conn, ret, -- 1.6.5.2

2 1

[libvirt] [PATCH v2 0/3] Fix migration of paused VMs
by Paolo Bonzini 11 Dec '09

11 Dec '09

This is the final version of QEMU support for migrating paused VMs. The patch series is the same as what I posted on Nov 25, except for the check on the return value of virDomainGetInfo. Patch 2 also had some easily-solved conflicts upon rebasing. I haven't yet implemented an error message when inactive domains are migrated; I'll do so in a follow-up patch. Paolo include/libvirt/libvirt.h.in | 1 + src/libvirt.c | 15 ++++++++++++++- src/qemu/qemu_driver.c | 37 ++++++++++++++++++++++++------------- src/xen/xend_internal.c | 9 +++++++++ tools/virsh.c | 5 ++++- tools/virsh.pod | 7 ++++--- 6 files changed, 56 insertions(+), 18 deletions(-) Paolo Bonzini (3): fix migration of paused vms upon failure add virsh --suspend retrieve paused/running state at the beginning of migration

3 5

[libvirt] [PATCH] Replace <optional><oneOrMore> with <zeroOrMore>.
by Diego Elio 'Flameeyes' Pettenò 11 Dec '09

11 Dec '09

The two syntax should be equivalent, but the former creates, with trang, an invalid Relax-NG Compact form file, as the output will contain the sequence "+?" which is not recognized by tools like rnv. --- docs/schemas/domain.rng | 40 +++++++++++++++++++--------------------- 1 files changed, 19 insertions(+), 21 deletions(-) diff --git a/docs/schemas/domain.rng b/docs/schemas/domain.rng index 5b8f7f8..d1d3efb 100644 --- a/docs/schemas/domain.rng +++ b/docs/schemas/domain.rng @@ -980,27 +980,25 @@ </attribute> </define> <define name="qemucdevSrcDef"> - <optional> - <oneOrMore> - <element name="source"> - <optional> - <attribute name="mode"/> - </optional> - <optional> - <attribute name="path"/> - </optional> - <optional> - <attribute name="host"/> - </optional> - <optional> - <attribute name="service"/> - </optional> - <optional> - <attribute name="wiremode"/> - </optional> - </element> - </oneOrMore> - </optional> + <zeroOrMore> + <element name="source"> + <optional> + <attribute name="mode"/> + </optional> + <optional> + <attribute name="path"/> + </optional> + <optional> + <attribute name="host"/> + </optional> + <optional> + <attribute name="service"/> + </optional> + <optional> + <attribute name="wiremode"/> + </optional> + </element> + </zeroOrMore> <optional> <element name="protocol"> <optional> -- 1.6.5.5

2 1

[libvirt] [PATCH] Remove iptables.c from POTFILES.in
by Matthias Bolte 10 Dec '09

10 Dec '09

--- po/POTFILES.in | 1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/po/POTFILES.in b/po/POTFILES.in index f8e9130..a429b19 100644 --- a/po/POTFILES.in +++ b/po/POTFILES.in @@ -50,7 +50,6 @@ src/uml/uml_conf.c src/uml/uml_driver.c src/util/bridge.c src/util/conf.c -src/util/iptables.c src/util/json.c src/util/logging.c src/util/pci.c -- 1.6.0.4

1 0

[libvirt] [PATCH, TCK] Install tests to /usr/share/... instead of /share/...
by Matthias Bolte 10 Dec '09

10 Dec '09

libvirt-tck expects the tests in /usr/share/libvirt-tck/tests. --- Build.PL | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Build.PL b/Build.PL index 453172c..c85a072 100644 --- a/Build.PL +++ b/Build.PL @@ -100,5 +100,5 @@ my $b = $class->new( $b->add_build_element("conf"); $b->add_build_element("pkgdata"); $b->install_path('conf' => File::Spec->catdir($b->install_base, "etc", "libvirt-tck")); -$b->install_path('pkgdata' => File::Spec->catdir($b->install_base, "share", "libvirt-tck", "tests")); +$b->install_path('pkgdata' => File::Spec->catdir($b->install_base, "usr/share", "libvirt-tck", "tests")); $b->create_build_script; -- 1.6.0.4

2 1