[libvirt] Out of band channels
by Matthew Booth
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
15 years, 7 months
[libvirt] [PATCH] Fix reference leak in remoteDispatchStorageVolCreateXmlFrom
by Matthias Bolte
---
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
15 years, 7 months
[libvirt] [PATCH] Fix memory leak in virStorageBackendCopyToFD
by Matthias Bolte
---
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
15 years, 7 months
[libvirt] simple LXC/libvirt busybox container (Unable to get cgroup)
by Tony Risinger
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
15 years, 7 months
[libvirt] My beefs with the libvirt XML configuration format
by Diego Elio “Flameeyes” Pettenò
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...
[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/
15 years, 7 months
[libvirt] [PATCH] Fix detection of JSON when restarting libvirtd
by Daniel P. Berrange
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
15 years, 7 months
[libvirt] [PATCH v2 0/3] Fix migration of paused VMs
by Paolo Bonzini
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
15 years, 7 months
[libvirt] [PATCH] Replace <optional><oneOrMore> with <zeroOrMore>.
by Diego Elio 'Flameeyes' Pettenò
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
15 years, 7 months
[libvirt] [PATCH] Remove iptables.c from POTFILES.in
by Matthias Bolte
---
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
15 years, 7 months
[libvirt] [PATCH, TCK] Install tests to /usr/share/... instead of /share/...
by Matthias Bolte
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
15 years, 7 months
