[libvirt] [PATCH] Java bindings for domain events
by David Lively
The attached patch (against libvirt-java) contains Java bindings for the
new domain event code. It works (see EventTest.java), but there's a
certain amount of hokiness regarding the EventImpl stuff that I'd like
to discuss.
Unlike the C and Python interfaces, the Java interface does not
currently allow the client to supply an EventImpl. The problem is that
Java really has no way to interact with unix file descriptors so there's
no reasonable way to implement a fd-watching EventImpl in pure Java
(java.io.FileDescriptor doesn't do the trick since there's no way of
constructing one from raw (int) unix fd)[**].
So for now, I've had the Java bindings register an EventImpl when the
Connect class is loaded. This EventImpl is a Java class, with native
methods implementing it. In fact, I've simply stolen (verbatim) the
EventImpl from libvirt/qemud/events.c and made the native methods call
it. [If we stick with this solution, it would obviously be better to
somehow share this code with libvirtd rather than copy it.]
The other tricky subject is multi-threading. For now, I've avoided it
by exposing Connect.eventImpl.run_once() and forcing the client to call
it from their "event loop". But the normal Java way of doing things
would simply run the EventImpl in a separate thread. In fact, this
EventImpl does implement Runnable, which makes it trivial to run in a
separate thread -- but I don't declare that it implements Runnable yet
because it's not safe to run in a thread while another thread might be
making libvirt calls.
It shouldn't be hard to make this thread-safe using Java synchronized
methods and statements, but I haven't done that yet. Should I??
** java.nio.Channel and friends seem to be the "right" interface for
exposing abstract "selectable channels" in Java. It's just complicated
enough that I've avoided it for now. But I can look into going this way
for allowing Java to provide an EventImpl in the future ..
Cheers,
Dave
15 years, 6 months
Re: >>: [libvirt] OpenVZ capabilites in LibVIRT
by Anton Protopopov
2008/11/15 Ivan Vovk <vovk.is(a)gmail.com>
> Hi Anton,
>
> do i understand correctly that patch for OpenVZ bridge support was
> committed? If so can it be obtained from CVS repository with a new snapshot?
>
Yes, it is commited in libvirt-0.4.6-alt2 that appear in Sisyphus on monday,
or so.
If you are interesting, you can see my git:
http://git.altlinux.org/people/aspsk/packages/?p=libvirt.git;a=summary
>
> Then can you help me a bit again? After I got a new checkout with
>
> cvs -d :pserver:anoncvs@libvirt.org:2401/data/cvs co libvirt
>
> and tried to do a build, i got the following:
>
> [root@alt-03 libvirt]# ./autogen.sh --prefix=$HOME/usr
>
> You must have autopoint installed to compile libvirt.
> Download the appropriate package for your distribution,
> But was is 'autopoint'? I was not able to find it neither in ALT's
> repository, not somewhere else ... =(
>
# apt-get install gettext-tools
# man autopoint
15 years, 6 months
[libvirt] [RFC] making (newly public) EventImpl interface more consistent
by David Lively
Hi Folks -
Since virEventRegisterImpl is now public (in libvirt.h), a nagging
concern of mine has become more urgent. Essentially this callback gives
clients a way of registering their own "handle (fd) watcher" and "timer"
functionality for use by libvirt.
What bugs me is the inconsistency between the handle-watcher and timer
interfaces: the timer "add" function returns a timer id, which is then
used to identify the timer to the "update" and "remove" functions. But
the handle-watcher add / update / remove functions identify the watcher
by the handle (fd). The semantics of registering the same handle twice
aren't specified (what happens when we pass that same fd in a subsequent
"update" or "remove"?). Even worse, this doesn't allow one to manage
multiple watches on the same handle reasonably.
So why not make the handle "add" function return a "watch
id" (analogous to the "timer id" returned by the timer "add" fn)? And
then use this watch id to specify the handle-watcher in the "update" and
"remove" functions. This conveniently handles multiple watches on the
same handle, and also makes the "handle-watching" interface more
consistent with the "timer" interface (which is registered at the same
time). We'd pass both the watch id and the handle (fd) into the
watch-handler callback.
I'd like to implement and submit this (along with fixups to the event
test code) if there are no objections.
Thanks,
Dave
P.S. I'm currently working on Java bindings to the new event code ...
15 years, 6 months
[libvirt] [PATCH] avoid format string warnings
by Jim Meyering
>From f06595fb110e1e5a4c4f6ea8c729da3341f89ac4 Mon Sep 17 00:00:00 2001
From: Jim Meyering <meyering(a)redhat.com>
Date: Fri, 14 Nov 2008 13:19:29 +0100
Subject: [PATCH] avoid format string warnings
* src/openvz_driver.c (ADD_ARG_LIT): Add "%s" arg before _(...).
* src/qemu_driver.c (PCI_ATTACH_OK_MSG): Likewise.
* src/util.c (virExec, virRun): Likewise.
---
src/openvz_driver.c | 4 ++--
src/qemu_driver.c | 2 +-
src/util.c | 4 ++--
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/openvz_driver.c b/src/openvz_driver.c
index 48ffa13..95631ee 100644
--- a/src/openvz_driver.c
+++ b/src/openvz_driver.c
@@ -426,7 +426,7 @@ openvzDomainSetNetwork(virConnectPtr conn, const char *vpsid,
dev_name_ve = openvzGenerateContainerVethName(veid);
if (dev_name_ve == NULL) {
openvzError(conn, VIR_ERR_INTERNAL_ERROR,
- _("Could not generate eth name for container"));
+ "%s", _("Could not generate eth name for container"));
rc = -1;
goto exit;
}
@@ -437,7 +437,7 @@ openvzDomainSetNetwork(virConnectPtr conn, const char *vpsid,
net->ifname = openvzGenerateVethName(veid, dev_name_ve);
if (net->ifname == NULL) {
openvzError(conn, VIR_ERR_INTERNAL_ERROR,
- _("Could not generate veth name"));
+ "%s", _("Could not generate veth name"));
rc = -1;
VIR_FREE(dev_name_ve);
goto exit;
diff --git a/src/qemu_driver.c b/src/qemu_driver.c
index 8291bfe..47167b7 100644
--- a/src/qemu_driver.c
+++ b/src/qemu_driver.c
@@ -2611,7 +2611,7 @@ static int qemudDomainAttachPciDiskDevice(virDomainPtr dom, virDomainDeviceDefPt
s += strlen(PCI_ATTACH_OK_MSG);
if (virStrToLong_i ((const char*)s, &dummy, 10, &dev->data.disk->slotnum) == -1)
- qemudLog(QEMUD_WARN, _("Unable to parse slot number\n"));
+ qemudLog(QEMUD_WARN, "%s", _("Unable to parse slot number\n"));
} else {
qemudReportError (dom->conn, dom, NULL, VIR_ERR_OPERATION_FAILED,
_("adding %s disk failed"), type);
diff --git a/src/util.c b/src/util.c
index 6141847..9b1c5f4 100644
--- a/src/util.c
+++ b/src/util.c
@@ -406,7 +406,7 @@ virExec(virConnectPtr conn,
char *argv_str;
if ((argv_str = virArgvToString(argv)) == NULL) {
- ReportError(conn, VIR_ERR_NO_MEMORY, _("command debug string"));
+ ReportError(conn, VIR_ERR_NO_MEMORY, "%s", _("command debug string"));
return -1;
}
DEBUG0(argv_str);
@@ -523,7 +523,7 @@ virRun(virConnectPtr conn,
char *argv_str = NULL;
if ((argv_str = virArgvToString(argv)) == NULL) {
- ReportError(conn, VIR_ERR_NO_MEMORY, _("command debug string"));
+ ReportError(conn, VIR_ERR_NO_MEMORY, "%s", _("command debug string"));
goto error;
}
DEBUG0(argv_str);
--
1.6.0.4.911.gc990
15 years, 6 months
[libvirt] RFC: Add a 'reason' argument for domain events ?
by Daniel P. Berrange
We currently have a set of domain lifecycle events
VIR_DOMAIN_EVENT_ADDED = 0,
VIR_DOMAIN_EVENT_REMOVED = 1,
VIR_DOMAIN_EVENT_STARTED = 2,
VIR_DOMAIN_EVENT_SUSPENDED = 3,
VIR_DOMAIN_EVENT_RESUMED = 4,
VIR_DOMAIN_EVENT_STOPPED = 5,
VIR_DOMAIN_EVENT_SAVED = 6,
VIR_DOMAIN_EVENT_RESTORED = 7,
And a couple more I proposed last week to allow distinguishing of new
domains which are transient vs persistent
VIR_DOMAIN_EVENT_DEFINED = 8,
VIR_DOMAIN_EVENT_UNDEFINED = 9,
Previously Stefan has suggested we should consider having an event for
migration, and though I rejected that at the time, I'm now inclined to
agree that this info would be useful here. I'm also thinking I'd like
to have more information about STOPPED & STARTED events in general.
eg, there are a number of reasons why an domain may have started
- explicitly booted on the host
- restored from a saved image
- incoming migration operation
and there are a number of reasons why a domain might have stopped
- forcably destroyed by host admin
- shutdown by host admin
- shutdown by guest admin
- host emulator process crashed
- killed by mgmt after host emulation hung
- migrated to another host
- saved to a memory image
We have explicit events for the SAVED/RESTORED reasons, but what should
we do about the other reasons ?
One option is to add alot more events
VIR_DOMAIN_MIGRATED_IN (migrated to another node)
VIR_DOMAIN_MIGRATED_OUT (migrated from another node)
VIR_DOMAIN_SHUTDOWN (graceful shutdown by host admin)
VIR_DOMAIN_DESTROYED (force destroyed by host admin)
VIR_DOMAIN_CRASHED (guest kernel crashed)
VIR_DOMAIN_HUNG (host emulator hung)
leaving STOPPED to just be a generic stop event, with no particular
reason.
The downside with this, is if an application just wants to know about
whether a domain shutdown, not why, then they have to track lots and
lots of events.
Also, not every driver would be able to provide all of these events,
so would often have to fallback on a generic STOPPED event
So one alternative is to provide a generic 'char * reason' with each
event with provides scope on the cause of the lifecycle operation.
So you'd get
VIR_DOMAIN_STOPPED ("crashed", "shutdown", "destroyed",
"quit", "hung", "migrated", "saved")
VIR_DOMAIN_STARTED ("booted", "migrated", "restored")
nb, we could remove the explicit SAVED and RESTORED events in this style.
With such a 'reason' arg, we could possibly avoid adding the DEFINED
and UNDEFINED events I suggested. Instead, adding a reason for ADDED
and REMOVED events,
VIR_DOMAIN_ADDED ("started", "defined")
VIR_DOMAIN_REMOVED ("shutdown", "undefined")
which lets you distinguish transient from persistent domains. The downside
of this though, is that we can't explicitly track when a configuration
file is 're-defined', eg adding a config file for an existing running
guest.
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
15 years, 6 months
[libvirt] [PATCH]: Implement Qemu/KVM live migration
by Chris Lalancette
All,
Attached is a patch to implement Qemu/KVM live migration in libvirt. Now
that upstream Qemu has settled on an interface that is friendly to libvirt (i.e.
one that doesn't block the monitor on -incoming), we can implement it here.
Note that the bulk of this patch was written by Rich Jones quite a while ago.
My hand in it has mostly been to forward port it to current libvirt CVS, tweak
it for the new Qemu style, and test it out with a recent KVM (kvm-78, in
particular).
Note that there is a FIXME in the code. When testing this out with kvm-78,
I found that if I let the source side kill the source VM immediately after the
"migrate" monitor command completed, the migration to the destination would
never complete. This seems to be a bug in Qemu; the migrate monitor command
shouldn't return until the migrate is really, truly complete. I'm posting this
now so I can get reviews, and start to address review comments while I try to
figure out what's going on with Qemu. With my temporary hack of the sleep()
call in there, though, I was able to successfully live migrate an F-9 guest
between two machines.
Signed-off-by: Chris Lalancette <clalance(a)redhat.com>
15 years, 6 months
[libvirt] [PATCH] add the check whether the domain has already used a disk which attach
by S.Sakamoto
Hi,
"attach-disk" does not give an error,
when the domain which is attached has already used the source which attach.
This has danger of the data corruption.
I make the patch to add the check of this.
This patch outputs an error,
when the domain which is attached has already used the source which attach.
Thanks,
Shigeki Sakamoto.
Index: src/virsh.c
===================================================================
RCS file: /data/cvs/libvirt/src/virsh.c,v
retrieving revision 1.170
diff -u -p -r1.170 virsh.c
--- src/virsh.c 13 Oct 2008 16:46:29 -0000 1.170
+++ src/virsh.c 4 Nov 2008 07:28:20 -0000
@@ -4993,6 +4993,11 @@ cmdAttachDisk(vshControl *ctl, const vsh
char *source, *target, *driver, *subdriver, *type, *mode;
int isFile = 0, ret = FALSE;
char *buf = NULL, *tmp = NULL;
+ xmlDocPtr xml = NULL;
+ xmlXPathObjectPtr obj = NULL;
+ xmlXPathContextPtr ctxt = NULL;
+ char *doc;
+ char xpath[PATH_MAX];
if (!vshConnectionUsability(ctl, ctl->conn, TRUE))
goto cleanup;
@@ -5034,6 +5039,35 @@ cmdAttachDisk(vshControl *ctl, const vsh
}
}
+ if (source) {
+ doc = virDomainGetXMLDesc(dom, 0);
+ if (!doc)
+ goto cleanup;
+
+ xml = xmlReadDoc((const xmlChar *) doc, "domain.xml", NULL,
+ XML_PARSE_NOENT | XML_PARSE_NONET |
+ XML_PARSE_NOWARNING);
+ free(doc);
+ if (!xml)
+ goto cleanup;
+ ctxt = xmlXPathNewContext(xml);
+ if (!ctxt)
+ goto cleanup;
+
+ sprintf(xpath, "string(/domain/devices/disk/source[@dev='%s']/@dev)", source);
+ obj = xmlXPathEval(BAD_CAST xpath, ctxt);
+ if (!strcmp(obj->stringval, source)) {
+ vshError(ctl, FALSE, _("Disk %s is already in use by own guest"), source);
+ goto cleanup;
+ }
+ sprintf(xpath, "string(/domain/devices/disk/source[@file='%s']/@file)", source);
+ obj = xmlXPathEval(BAD_CAST xpath, ctxt);
+ if (!strcmp(obj->stringval, source)) {
+ vshError(ctl, FALSE, _("Disk %s is already in use by own guest"), source);
+ goto cleanup;
+ }
+ }
+
/* Make XML of disk */
tmp = vshMalloc(ctl, 1);
if (!tmp) goto cleanup;
@@ -5123,6 +5157,10 @@ cmdAttachDisk(vshControl *ctl, const vsh
ret = TRUE;
cleanup:
+ xmlXPathFreeObject(obj);
+ xmlXPathFreeContext(ctxt);
+ if (xml)
+ xmlFreeDoc(xml);
if (dom)
virDomainFree(dom);
free(buf);
15 years, 6 months
[libvirt] [PATCH] Register storage backends in test driver
by Cole Robinson
The refactored storage backend registering broke the test driver. The
attached patch makes everything work again by explicitly registering the
backends on driver startup.
Thanks,
Cole
diff --git a/src/test.c b/src/test.c
index 30dc52a..a785f04 100644
--- a/src/test.c
+++ b/src/test.c
@@ -43,6 +43,11 @@
#include "network_conf.h"
#include "domain_conf.h"
#include "storage_conf.h"
+#include "storage_backend.h"
+#include "storage_backend_logical.h"
+#include "storage_backend_iscsi.h"
+#include "storage_backend_disk.h"
+#include "storage_backend_fs.h"
#include "xml.h"
#define MAX_CPUS 128
@@ -663,6 +668,17 @@ static int testOpen(virConnectPtr conn,
return VIR_DRV_OPEN_ERROR;
}
+ if (virStorageBackendRegister(&virStorageBackendDirectory) < 0 ||
+ virStorageBackendRegister(&virStorageBackendFileSystem) < 0 ||
+ virStorageBackendRegister(&virStorageBackendNetFileSystem) < 0 ||
+ virStorageBackendRegister(&virStorageBackendLogical) < 0 ||
+ virStorageBackendRegister(&virStorageBackendISCSI) < 0 ||
+ virStorageBackendRegister(&virStorageBackendDisk) < 0) {
+ testError(NULL, VIR_ERR_INTERNAL_ERROR,
+ _("Failed to register storage backends."));
+ return VIR_DRV_OPEN_DECLINED;
+ }
+
if (STREQ(uri->path, "/default"))
ret = testOpenDefault(conn);
else
15 years, 6 months
[libvirt] [PATCH] 0/7 host ("node") device enumeration - completed submission
by David Lively
Since the version of this I posted last week still had some outstaning
TODO items that I have since finished, I'm re-submitting the whole
thing. I consider this a "complete submission" since I don't think it's
necessary to implement any additional functionality to make this
acceptable. (The two remaining unimplemented items are
virNodeDeviceCreate / Destroy and a real Devkit impl, neither of which
needs to be done immediately, for reasons discussed earlier.)
These patches implement the node device enumeration functionality, as
discussed here:
https://www.redhat.com/archives/libvir-list/2008-September/msg00398.html
I've broken it into the following pieces:
1-public-api additions to the public API
2-internal-api additions to the internal API
3-local-node-drivers the HAL & DeviceKit implementations
4-remote-node-driver the remote driver
5-virsh-support virsh support
6-python-bindings python bindings
7-java-bindings Java bindings (for libvirt-java)
Dave
15 years, 6 months
