[libvirt] Problem in running libvirt-cim test suite
Hi, I trying to install libvirt-cim in my ubuntu-xen-3.2.1 machine. I am able to install all dependencies and libvirt-cim , but when I run cimtest which has given in libvirt.org, I am getting following error message * Starting test suite: libvirt-cim ERROR - Failed to create Virtual Network 'cimtest-networkpool' Unable to create network pool cimtest-networkpool Please check your environment.* Is there any special networking setup is require to run cimtest. Any help would be appreciated. Apologies if this topic has been covered already. I can't find it anywhere using Google Thanks, seenu. -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH]: Export device during logical pool discovery
Attached is an updated patch for adding device tags to logical
findPoolSources. Given danpb's last feedback, I completely removed the XML
parsing and did it all with structures. The result should (hopefully) be a lot
easier on the eyes, and is a little more generic.
Signed-off-by: Chris Lalancette [EMAIL PROTECTED]
Index: src/storage_backend_logical.c
===
RCS file: /data/cvs/libvirt/src/storage_backend_logical.c,v
retrieving revision 1.19
diff -u -r1.19 storage_backend_logical.c
--- a/src/storage_backend_logical.c 16 Oct 2008 15:06:04 - 1.19
+++ b/src/storage_backend_logical.c 22 Oct 2008 22:19:07 -
@@ -242,33 +242,70 @@
static int
-virStorageBackendLogicalFindPoolSourcesFunc(virConnectPtr conn ATTRIBUTE_UNUSED,
+virStorageBackendLogicalFindPoolSourcesFunc(virConnectPtr conn,
virStoragePoolObjPtr pool ATTRIBUTE_UNUSED,
char **const groups,
void *data)
{
-virStringList **rest = data;
-virStringList *newItem;
-const char *name = groups[0];
+virStoragePoolSourceListPtr sourceList = data;
+char *pvname = NULL;
+char *vgname = NULL;
+int i;
+virStoragePoolSourceDevicePtr dev;
+virStoragePoolSource *thisSource;
+
+pvname = strdup(groups[0]);
+vgname = strdup(groups[1]);
+
+if (pvname == NULL || vgname == NULL) {
+virStorageReportError(conn, VIR_ERR_NO_MEMORY, %s,
+ _(allocating pvname or vgname));
+goto err_no_memory;
+}
+
+thisSource = NULL;
+for (i = 0 ; i sourceList-nsources; i++) {
+if (STREQ(sourceList-sources[i].name, vgname)) {
+thisSource = sourceList-sources[i];
+break;
+}
+}
-/* Append new XML desc to list */
+if (thisSource == NULL) {
+if (VIR_REALLOC_N(sourceList-sources, sourceList-nsources + 1) != 0) {
+virStorageReportError(conn, VIR_ERR_NO_MEMORY, %s,
+ _(allocating new source));
+goto err_no_memory;
+}
-if (VIR_ALLOC(newItem) != 0) {
-virStorageReportError(conn, VIR_ERR_NO_MEMORY, %s, _(new xml desc));
-return -1;
+thisSource = sourceList-sources[sourceList-nsources];
+sourceList-nsources++;
+
+memset(thisSource, 0, sizeof(*thisSource));
+thisSource-name = vgname;
}
+else
+VIR_FREE(vgname);
-if (asprintf(newItem-val, sourcename%s/name/source, name) = 0) {
-virStorageReportError(conn, VIR_ERR_INTERNAL_ERROR, %s, _(asprintf failed));
-VIR_FREE(newItem);
-return -1;
+if (VIR_REALLOC_N(thisSource-devices, thisSource-ndevice + 1) != 0) {
+virStorageReportError(conn, VIR_ERR_NO_MEMORY, %s,
+ _(allocating new device));
+goto err_no_memory;
}
-newItem-len = strlen(newItem-val);
-newItem-next = *rest;
-*rest = newItem;
+dev = thisSource-devices[thisSource-ndevice];
+thisSource-ndevice++;
+
+memset(dev, 0, sizeof(*dev));
+dev-path = pvname;
return 0;
+
+ err_no_memory:
+VIR_FREE(pvname);
+VIR_FREE(vgname);
+
+return -1;
}
static char *
@@ -277,34 +314,40 @@
unsigned int flags ATTRIBUTE_UNUSED)
{
/*
- * # vgs --noheadings -o vg_name
- * VolGroup00
- * VolGroup01
+ * # pvs --noheadings -o pv_name,vg_name
+ * /dev/sdb
+ * /dev/sdc VolGroup00
*/
const char *regexes[] = {
-^\\s*(\\S+)\\s*$
+^\\s*(\\S+)\\s+(\\S+)\\s*$
};
int vars[] = {
-1
+2
};
-virStringList *descs = NULL;
-const char *prog[] = { VGS, --noheadings, -o, vg_name, NULL };
+const char *const prog[] = { PVS, --noheadings, -o, pv_name,vg_name, NULL };
int exitstatus;
char *retval = NULL;
+virStoragePoolSourceList sourceList;
+int i;
+memset(sourceList, 0, sizeof(sourceList));
if (virStorageBackendRunProgRegex(conn, NULL, prog, 1, regexes, vars,
virStorageBackendLogicalFindPoolSourcesFunc,
- descs, exitstatus) 0)
+ sourceList, exitstatus) 0)
return NULL;
-retval = virStringListJoin(descs, SOURCES_START_TAG, SOURCES_END_TAG, \n);
+retval = virStoragePoolSourceListFormat(conn, sourceList);
if (retval == NULL) {
-virStorageReportError(conn, VIR_ERR_NO_MEMORY, %s, _(retval));
+virStorageReportError(conn, VIR_ERR_INTERNAL_ERROR, %s,
+ _(failed to get source from sourceList));
goto cleanup;
}
cleanup:
-virStringListFree(descs);
+for (i = 0; i sourceList.nsources; i++)
+virStoragePoolSourceFree(sourceList.sources[i]);
+
+
Re: [libvirt] Problem in running libvirt-cim test suite
On Thu, Oct 23, 2008 at 11:39:31AM +0530, srinivas k wrote: Hi, I trying to install libvirt-cim in my ubuntu-xen-3.2.1 machine. I am able to install all dependencies and libvirt-cim , but when I run cimtest which has given in libvirt.org, I am getting following error message * Starting test suite: libvirt-cim ERROR - Failed to create Virtual Network 'cimtest-networkpool' Unable to create network pool cimtest-networkpool Please check your environment.* Is there any special networking setup is require to run cimtest. A wild guess would be to make sure you have dnsmasq, and brctl commands available, and iptables. And also make sure the libvirtd daemon is running. Any help would be appreciated. Apologies if this topic has been covered already. I can't find it anywhere using Google The CIM development team tend to mostly be on a different mailing list. See the 'Mailing list' link here: http://libvirt.org/CIM/ 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 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH]: Export device during logical pool discovery
On Thu, Oct 23, 2008 at 09:05:24AM +0200, Chris Lalancette wrote: Attached is an updated patch for adding device tags to logical findPoolSources. Given danpb's last feedback, I completely removed the XML parsing and did it all with structures. The result should (hopefully) be a lot easier on the eyes, and is a little more generic. ACK, this looks nicer now. 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 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH]: Update ruby-libvirt migrate binding to use rb_scan_args
It's really not a good idea to hand parse variable number of args to a ruby
binding, like I implemented for the migrate method. Convert this to use
rb_scan_args, which is the proper way to do it, and matches all of the other
variable argument implementations in the binding.
Signed-off-by: Chris Lalancette [EMAIL PROTECTED]
diff -r 543054386d15 ext/libvirt/_libvirt.c
--- a/ext/libvirt/_libvirt.c Tue Aug 12 15:07:06 2008 -0700
+++ b/ext/libvirt/_libvirt.c Thu Oct 23 09:44:40 2008 +
@@ -651,37 +651,22 @@
* Class Libvirt::Domain
*/
VALUE libvirt_dom_migrate(int argc, VALUE *argv, VALUE s) {
+VALUE dconn, flags, dname_val, uri_val, bandwidth;
virDomainPtr ddom = NULL;
-VALUE dconn;
-unsigned long flags;
const char *dname;
const char *uri;
-unsigned long bandwidth;
-if (argc 2 || argc 5) {
-rb_raise(rb_eArgError, Must provide between 2 and 5 arguments);
-}
+rb_scan_args(argc, argv, 23, dconn, flags, dname_val, uri_val,
+ bandwidth);
-dconn = argv[0];
-flags = NUM2UINT(argv[1]);
-dname = NULL;
-uri = NULL;
-bandwidth = 0;
+dname = get_string_or_nil(dname_val);
+uri = get_string_or_nil(uri_val);
-switch(argc) {
-case 5:
-Check_Type(argv[4], T_FIXNUM);
-bandwidth = NUM2UINT(argv[4]);
-/* fallthrough */
-case 4:
-uri = get_string_or_nil(argv[3]);
-/* fallthrough */
-case 3:
-dname = get_string_or_nil(argv[2]);
-}
+if (NIL_P(bandwidth))
+bandwidth = INT2FIX(0);
-ddom = virDomainMigrate(domain_get(s), conn(dconn), flags,
-dname, uri, bandwidth);
+ddom = virDomainMigrate(domain_get(s), conn(dconn), NUM2UINT(flags),
+dname, uri, NUM2UINT(bandwidth));
_E(ddom == NULL,
create_error(e_Error, virDomainMigrate, , conn(dconn)));
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH]: Implement ruby-libvirt storage pool discovery binding
Attached is a pretty simple patch to implement the
virConnectFindStoragePoolSources() binding for ruby-libvirt.This capability went
into libvirt-0.4.5, so any version of libvirt that has storage API support
should have support for this call. There's not much more to say; it works in my
testing, and the implementation is pretty straightforward.
Signed-off-by: Chris Lalancette [EMAIL PROTECTED]
diff -r 543054386d15 ext/libvirt/_libvirt.c
--- a/ext/libvirt/_libvirt.c Tue Aug 12 15:07:06 2008 -0700
+++ b/ext/libvirt/_libvirt.c Thu Oct 23 10:03:08 2008 +
@@ -1307,6 +1292,25 @@
_E(pool == NULL, create_error(e_DefinitionError, virStoragePoolDefineXML, , conn));
return pool_new(pool, c);
+}
+
+/*
+ * Call +virConnectFindStoragePoolSources+[http://www.libvirt.org/html/libvirt-libvirt.html#virConnectFindStoragePoolSources]
+ */
+VALUE libvirt_conn_find_storage_pool_sources(int argc, VALUE *argv, VALUE c) {
+virConnectPtr conn = connect_get(c);
+VALUE type, srcSpec_val, flags;
+const char *srcSpec;
+
+rb_scan_args(argc, argv, 12, type, srcSpec_val, flags);
+
+srcSpec = get_string_or_nil(srcSpec_val);
+
+if (NIL_P(flags))
+flags = INT2FIX(0);
+
+gen_call_string(virConnectFindStoragePoolSources, conn, 1, conn,
+StringValueCStr(type), srcSpec, NUM2UINT(flags));
}
/*
@@ -1854,6 +1858,8 @@
libvirt_conn_create_pool_xml, -1);
rb_define_method(c_connect, define_storage_pool_xml,
libvirt_conn_define_pool_xml, -1);
+rb_define_method(c_connect, discover_storage_pool_sources,
+ libvirt_conn_find_storage_pool_sources, -1);
#endif
/*
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH]: Add default pool types
On Wed, Oct 22, 2008 at 04:06:47PM +0200, Chris Lalancette wrote: As suggested by danpb, to fix up the regression caused by last week's VIR_ENUM cleanup patch, add a .defaultFormat member to .poolOptions. In storage_conf.c, if virXPathString(/pool/source/format/@type) returns NULL, then set the pool type to .defaultFormat; otherwise, lookup the type via formatFromString. ACK this looks good now. 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 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 1/2] adapt to API change in gnulib
On Thu, Oct 23, 2008 at 12:12:45PM +0200, Jim Meyering wrote: This is actually two changes sets. The first part is an update from gnulib (including the fix for API change), the second adjusts .cvsignore files (sorting at same time) so that git status is clean after you run make sync-vcs-ignore-files to generate all .gitignore files. For reference, the complete (5000+-line) patch is here: http://meyering.net/code/tmp/libvirt-gnulib.patch If no one comments, I'll commit this in a couple hours. Can you verify that libvirt still builds under MinGW with this update. There has been a recent addition to gnulib for winsock wrappers, and this meant we had to update various things in GTK-VNC code when applying - I have a feeling we'll hit similar problems with libvirt remote driver + mingw with this gnulib update. We had to remove a bunch of our hand-crafted mingw compat code sinceit conflicted with stuff gnulib introduced 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 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 1/2] adapt to API change in gnulib
This is actually two changes sets. The first part is an update from gnulib (including the fix for API change), the second adjusts .cvsignore files (sorting at same time) so that git status is clean after you run make sync-vcs-ignore-files to generate all .gitignore files. For reference, the complete (5000+-line) patch is here: http://meyering.net/code/tmp/libvirt-gnulib.patch If no one comments, I'll commit this in a couple hours. Jim From 89a1178cd0beaadbda730aacc67fe8f27e919914 Mon Sep 17 00:00:00 2001 From: Jim Meyering [EMAIL PROTECTED] Date: Wed, 22 Oct 2008 16:56:58 +0200 Subject: [PATCH 1/2] adapt to API change in gnulib * qemud/qemud.c: Include netdb.h, not getaddrinfo.h * src/remote_internal.c: Likewise. updates from gnulib * gnulib/lib/.cvsignore: * gnulib/lib/Makefile.am: ... --- .gitignore | 32 --- gnulib/lib/.cvsignore |6 + gnulib/lib/.gitignore | 23 -- gnulib/lib/Makefile.am | 194 +-- gnulib/lib/arpa_inet.in.h |6 + gnulib/lib/c-ctype.h | 17 ++- gnulib/lib/float.in.h |6 +- gnulib/lib/gai_strerror.c |7 +- gnulib/lib/getaddrinfo.c | 18 ++- gnulib/lib/getaddrinfo.h | 163 gnulib/lib/getdelim.c | 15 +- gnulib/lib/netinet_in.in.h |6 +- gnulib/lib/poll.c | 439 gnulib/lib/stdint.in.h |5 +- gnulib/lib/stdio.in.h | 90 +++ gnulib/lib/stdlib.in.h | 83 ++ gnulib/lib/string.in.h | 22 ++- gnulib/lib/sys_select.in.h | 37 +++- gnulib/lib/sys_socket.in.h | 311 ++- gnulib/lib/sys_stat.in.h | 50 - gnulib/lib/sys_time.in.h |6 +- gnulib/lib/unistd.in.h | 167 - gnulib/lib/vasnprintf.c| 82 ++- gnulib/lib/wchar.in.h | 10 + gnulib/m4/arpa_inet_h.m4 |9 +- gnulib/m4/eoverflow.m4 | 70 - gnulib/m4/getaddrinfo.m4 | 16 +- gnulib/m4/getdelim.m4 |1 + gnulib/m4/gnulib-cache.m4 |2 +- gnulib/m4/gnulib-common.m4 | 12 +- gnulib/m4/gnulib-comp.m4 | 99 +++- gnulib/m4/include_next.m4 | 32 ++- gnulib/m4/inet_ntop.m4 |5 +- gnulib/m4/inet_pton.m4 |5 +- gnulib/m4/lib-link.m4 | 27 ++- gnulib/m4/lib-prefix.m4| 88 +-- gnulib/m4/lock.m4 | 330 ++--- gnulib/m4/posix-shell.m4 |6 +- gnulib/m4/stdio_h.m4 | 132 ++ gnulib/m4/stdlib_h.m4 | 11 +- gnulib/m4/strdup.m4| 22 ++- gnulib/m4/string_h.m4 | 11 +- gnulib/m4/sys_select_h.m4 | 20 ++- gnulib/m4/sys_socket_h.m4 | 64 - gnulib/m4/sys_stat_h.m4|6 +- gnulib/m4/unistd_h.m4 | 44 +++- gnulib/m4/wchar.m4 | 25 ++- gnulib/tests/.cvsignore| 22 ++ gnulib/tests/.gitignore| 29 -- gnulib/tests/Makefile.am | 193 +- gnulib/tests/dummy.c | 42 --- gnulib/tests/test-EOVERFLOW.c | 32 --- gnulib/tests/test-getaddrinfo.c|2 +- gnulib/tests/test-sys_select.c |5 +- gnulib/tests/test-vc-list-files-cvs.sh |3 +- gnulib/tests/test-vc-list-files-git.sh |3 +- gnulib/tests/test-wchar.c |6 +- qemud/qemud.c |2 +- src/remote_internal.c |2 +- 59 files changed, 2191 insertions(+), 982 deletions(-) delete mode 100644 .gitignore delete mode 100644 gnulib/lib/.gitignore delete mode 100644 gnulib/lib/getaddrinfo.h delete mode 100644 gnulib/m4/eoverflow.m4 delete mode 100644 gnulib/tests/.gitignore delete mode 100644 gnulib/tests/dummy.c delete mode 100644 gnulib/tests/test-EOVERFLOW.c ... diff --git a/qemud/qemud.c b/qemud/qemud.c index 9da27d2..db1a107 100644 --- a/qemud/qemud.c +++ b/qemud/qemud.c @@ -47,11 +47,11 @@ #include fnmatch.h #include grp.h #include signal.h +#include netdb.h #include internal.h #include qemud.h -#include getaddrinfo.h #include util.h #include remote_internal.h #include conf.h diff --git a/src/remote_internal.c b/src/remote_internal.c index 35b7b4b..47a86f0 100644 --- a/src/remote_internal.c +++ b/src/remote_internal.c @@ -58,7 +58,7 @@ #endif #include libxml/uri.h -#include getaddrinfo.h +#include netdb.h /* AI_ADDRCONFIG is missing on some systems. */ #ifndef AI_ADDRCONFIG -- 1.6.0.2.588.g3102 From
Re: [libvirt] Re: [PATCH 01/12] Domain Events - Public API
On Tue, Oct 21, 2008 at 03:11:08PM -0400, Ben Guthro wrote:
[PATCH 01/12] Domain Events - Public API
This patch does the following:
-implements the Event register/deregister code
-Adds some callback lists, and queue functions used by drivers
-Move EventImpl definitions into the public
+
+/**
+ * virEventHandleType:
+ *
+ * a virEventHandleType is used similar to POLLxxx FD events, but is specific
+ * to libvirt. A client app must translate to, and from POLL events when
using
+ * this construct.
+ */
+typedef enum {
+VIR_EVENT_HANDLE_READABLE = (1 0),
+VIR_EVENT_HANDLE_WRITABLE = (1 1),
+VIR_EVENT_HANDLE_ERROR = (1 2),
+VIR_EVENT_HANDLE_HANGUP= (1 3),
+} virEventHandleType;
+
+/**
+ * virEventHandleCallback: callback for receiving file handle events
+ *
+ * @fd: file handle on which the event occurred
+ * @events: bitset of events from virEventHandleType constants
+ * @opaque: user data registered with handle
+ */
+typedef void (*virEventHandleCallback)(int fd, virEventHandleType events,
+ void *opaque);
We avoid using explicit enum types in any public API because they are
not ABI safe in terms of their size. In any case, the 'events' parameter
is atually a bit-mask of zero or more of the virEventHandleType constants,
so the use of the enum isn't technically correct.
+
+/**
+ * virEventAddHandleFunc:
+ * @fd: file descriptor to listen on
+ * @event: events on which to fire the callback
+ * @cb: the callback to be called
+ * @opaque: user data to pass to the callback
+ *
+ * Part of the EventImpl, this callback Adds a file handle callback to
+ * listen for specific events
+ */
+typedef int (*virEventAddHandleFunc)(int fd, virEventHandleType event,
+ virEventHandleCallback cb, void
*opaque);
Here too we should just use 'int events' as a bitmask
+
+/**
+ * virEventUpdateHandleFunc:
+ * @fd: file descriptor to modify
+ * @event: new events to listen on
+ *
+ * Part of the EventImpl, this user-provided callback is notified when
+ * events to listen on change
+ */
+typedef void (*virEventUpdateHandleFunc)(int fd, virEventHandleType event);
Same 'int events' here too.
+
+
+int
+__virEventHandleTypeToPollEvent(virEventHandleType events)
+{
+int ret = 0;
+if(events VIR_EVENT_HANDLE_READABLE)
+ret |= POLLIN;
+if(events VIR_EVENT_HANDLE_WRITABLE)
+ret |= POLLOUT;
+if(events VIR_EVENT_HANDLE_ERROR)
+ret |= POLLERR;
+if(events VIR_EVENT_HANDLE_HANGUP)
+ret |= POLLHUP;
+return ret;
+}
+
+virEventHandleType
+__virPollEventToEventHandleType(int events)
+{
+virEventHandleType ret = 0;
+if(events POLLIN)
+ret |= VIR_EVENT_HANDLE_READABLE;
+if(events POLLOUT)
+ret |= VIR_EVENT_HANDLE_WRITABLE;
+if(events POLLERR)
+ret |= VIR_EVENT_HANDLE_ERROR;
+if(events POLLHUP)
+ret |= VIR_EVENT_HANDLE_HANGUP;
+return ret;
+}
Since these two functions are only used by the libvirtd daemon at
this point, I think its better to just put them in qemud/event.c.
This will avoid need to add conditionals here to disable their
build on Mingw/Windows.
diff --git a/src/libvirt_sym.version b/src/libvirt_sym.version
index 3cc4505..0297c9c 100644
--- a/src/libvirt_sym.version
+++ b/src/libvirt_sym.version
@@ -147,6 +147,10 @@
virStorageVolGetXMLDesc;
virStorageVolGetPath;
+virEventRegisterImpl;
+virConnectDomainEventRegister;
+virConnectDomainEventDeregister;
+
/* Symbols with __ are private only
for use by the libvirtd daemon.
They are not part of stable ABI
@@ -167,8 +171,6 @@
__virGetStoragePool;
__virGetStorageVol;
- __virEventRegisterImpl;
-
__virStateInitialize;
__virStateCleanup;
__virStateReload;
@@ -198,5 +200,7 @@
__virReallocN;
__virFree;
+__virEventHandleTypeToPollEvent;
+__virPollEventToEventHandleType;
These will also be unnecccessary if we put them in qemud/event.c
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 :|
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Re: [PATCH 02/12] Domain Events - Internal API
On Tue, Oct 21, 2008 at 03:11:36PM -0400, Ben Guthro wrote:
[PATCH 02/12] Domain Events - Internal API
This patch
-Removes EventImpl from being a private function
-Introduces the virDomainEventCallbackListPtr, and virDomainEventQueuePtr
objects
diff --git a/src/event.c b/src/event.c
index 49a9e61..1e2b234 100644
--- a/src/event.c
+++ b/src/event.c
@@ -34,14 +34,15 @@ static virEventAddTimeoutFunc addTimeoutImpl = NULL;
static virEventUpdateTimeoutFunc updateTimeoutImpl = NULL;
static virEventRemoveTimeoutFunc removeTimeoutImpl = NULL;
-int virEventAddHandle(int fd, int events, virEventHandleCallback cb, void
*opaque) {
+int virEventAddHandle(int fd, virEventHandleType events,
+ virEventHandleCallback cb, void *opaque) {
if (!addHandleImpl)
return -1;
return addHandleImpl(fd, events, cb, opaque);
}
-void virEventUpdateHandle(int fd, int events) {
+void virEventUpdateHandle(int fd, virEventHandleType events) {
updateHandleImpl(fd, events);
}
This signature change isn't needed - it should still be just an int,
since we're using the enum as a bitset.
ACK, to the rest of the patch.
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 :|
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Re: [PATCH 03/12] Domain Events - daemon changes
On Tue, Oct 21, 2008 at 03:12:52PM -0400, Ben Guthro wrote:
[PATCH 03/12] Domain Events - daemon changes
This code changes the daemaon to:
use the pulic def of virEventRegisterImpl
Add functionality to dispatch events to connected remote drivers
event.c | 21 +
event.h |5 +-
mdns.c | 15 --
qemud.c | 72 ---
qemud.h | 11
remote.c | 143
+++
6 files changed, 227 insertions(+), 40 deletions(-)
diff --git a/qemud/event.c b/qemud/event.c
index bb1f381..f391cd1 100644
--- a/qemud/event.c
+++ b/qemud/event.c
@@ -38,7 +38,7 @@
/* State for a single file handle being monitored */
struct virEventHandle {
int fd;
-int events;
+virEventHandleType events;
As per previous patch, simply using an 'int' is sufficient, likewise
for the few other places in this patch doing the same.
Aside from that, ACK to this patch.
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 :|
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Re: [PATCH 04/12] Domain Events - rpc changes
On Tue, Oct 21, 2008 at 03:14:49PM -0400, Ben Guthro wrote:
[PATCH 04/12] Domain Events - rpc changes
Changes to the RPC protocol
remote_dispatch_localvars.h |3 +++
remote_dispatch_proc_switch.h | 18 ++
remote_dispatch_prototypes.h |3 +++
remote_protocol.c | 29 +
remote_protocol.h | 25 +
remote_protocol.x | 25 -
6 files changed, 102 insertions(+), 1 deletion(-)
diff --git a/qemud/remote_protocol.x b/qemud/remote_protocol.x
index f1bd9ff..b7e41aa 100644
--- a/qemud/remote_protocol.x
+++ b/qemud/remote_protocol.x
@@ -965,6 +965,25 @@ struct remote_storage_vol_get_path_ret {
remote_nonnull_string name;
};
+/**
+ * Events Register/Deregister:
+ * It would seem rpcgen does not like both args, and ret
+ * to be null. It will not generate the prototype otherwise.
+ * Pass back a redundant boolean to force prototype generation.
+ */
Oh yes, I'd come across this problem in the past too. Adding
the cb_registerd field is harmless enough, so lets do it.
+struct remote_domain_events_register_ret {
+int cb_registered;
+};
+
+struct remote_domain_events_deregister_ret {
+int cb_registered;
+};
+
+struct remote_domain_event_ret {
+remote_nonnull_domain dom;
+int event;
+};
+
/*- Protocol. -*/
/* Define the program number, protocol version and procedure numbers here. */
@@ -1086,7 +1105,11 @@ enum remote_procedure {
REMOTE_PROC_NODE_GET_FREE_MEMORY = 102,
REMOTE_PROC_DOMAIN_BLOCK_PEEK = 103,
-REMOTE_PROC_DOMAIN_MEMORY_PEEK = 104
+REMOTE_PROC_DOMAIN_MEMORY_PEEK = 104,
+
+REMOTE_PROC_DOMAIN_EVENTS_REGISTER = 105,
+REMOTE_PROC_DOMAIN_EVENTS_DEREGISTER = 106,
+REMOTE_PROC_DOMAIN_EVENT = 107
};
ACK to this patch.
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 :|
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Re: [PATCH 05/12] Domain Events - Driver API
On Tue, Oct 21, 2008 at 03:15:19PM -0400, Ben Guthro wrote: [PATCH 05/12] Domain Events - Driver API Additions to the driver API ACK 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 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Re: [PATCH 07/12] Domain Events - remote driver
On Tue, Oct 21, 2008 at 03:16:20PM -0400, Ben Guthro wrote: [PATCH 07/12] Domain Events - remote driver Deliver local callbacks in response to remote events remote_internal.c | 276 +- 1 file changed, 271 insertions(+), 5 deletions(-) ACK to this. 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 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Re: [PATCH 09/12] Domain Events - openvz driver
On Tue, Oct 21, 2008 at 03:17:18PM -0400, Ben Guthro wrote: [PATCH 09/12] Domain Events - openvz driver Minor changes to openvz driver structure to prevent compile errors ACK 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 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Re: [PATCH 10/12] Domain Events - test driver
On Tue, Oct 21, 2008 at 03:19:56PM -0400, Ben Guthro wrote: [PATCH 10/12] Domain Events - test driver Minor changes to test driver structure to prevent compile errors ACK 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 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Re: [PATCH 11/12] Domain Events - test harness
On Tue, Oct 21, 2008 at 03:20:19PM -0400, Ben Guthro wrote:
[PATCH 11/12] Domain Events - test harness
Test app, and infrastructure changes for an example dir
ACK.
diff --git a/examples/domain-events/events-c/Makefile.am
b/examples/domain-events/events-c/Makefile.am
new file mode 100644
index 000..3c63ca3
--- /dev/null
+++ b/examples/domain-events/events-c/Makefile.am
@@ -0,0 +1,5 @@
+INCLUDES = [EMAIL PROTECTED]@/include
+bin_PROGRAMS = event-test
Quick automake black-magic tip...
Since we don't want the examples installed into /usr/bin, we can
simply replace
bin_PROGRAMS = event-test
with
noisnt_PROGRAMS = event-test
diff --git a/libvirt.spec.in b/libvirt.spec.in
index cfd4a66..450d907 100644
--- a/libvirt.spec.in
+++ b/libvirt.spec.in
@@ -249,6 +249,9 @@ rm -rf
$RPM_BUILD_ROOT%{_datadir}/doc/libvirt-python-%{version}
rm -rf $RPM_BUILD_ROOT%{_sysconfdir}/libvirt/qemu.conf
%endif
+# We don't want examples in the built rpm
+rm -f $RPM_BUILD_ROOT%{_bindir}/event-test
Use of 'noinst_PROGRAMS' will avoid the need for this
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 :|
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH]: Export device during logical pool discovery
Chris Lalancette wrote: Attached is an updated patch for adding device tags to logical findPoolSources. Given danpb's last feedback, I completely removed the XML parsing and did it all with structures. The result should (hopefully) be a lot easier on the eyes, and is a little more generic. Committed this. -- Chris Lalancette -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] fix mingw compilation warning
Building for mingw, I got this warning: libvirt.c:242: warning: control reaches end of non-void function Here's the fix: fix mingw compilation warning * src/libvirt.c (winsock_init) [HAVE_WINSOCK2_H]: Always return a value. diff --git a/src/libvirt.c b/src/libvirt.c index ca2675a..05a92d3 100644 --- a/src/libvirt.c +++ b/src/libvirt.c @@ -237,8 +237,7 @@ winsock_init (void) /* http://msdn2.microsoft.com/en-us/library/ms742213.aspx */ winsock_version = MAKEWORD (2, 2); err = WSAStartup (winsock_version, winsock_data); -if (err != 0) -return -1; +return err == 0 ? 0 : -1; } #endif -- 1.6.0.2.588.g3102 -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] fix mingw compilation warning
On Thu, Oct 23, 2008 at 01:59:21PM +0200, Jim Meyering wrote: Building for mingw, I got this warning: libvirt.c:242: warning: control reaches end of non-void function Here's the fix: fix mingw compilation warning * src/libvirt.c (winsock_init) [HAVE_WINSOCK2_H]: Always return a value. ACK 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 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] Re: [RFC] sVirt v0.10 - initial prototype
On Wednesday 22 October 2008 5:23:45 am James Morris wrote: On Tue, 21 Oct 2008, Daniel J Walsh wrote: Why do we care about the policy type? Policy type is a fairly meaningless object. If you are trying to figure out if the host machine is valid to run a virtual machine you should just check whether the type is valid on the machine, That way if I define minimum policy with virt support on one host and targeted policy with virt support on another machine, both would work. We need a way to indicate how to interpret the meaning of labels, which may vary depending on how policy has been implemented and deployed within a specific administrative boundary. Keep in mind also that this API needs to be useable with non-SELinux security schemes, although, in any case, just because a label is technically valid on a system, doesn't mean that the meaning is understood. e.g. virt_image_t:s0 on a targeted system could mean something radically different to virt_image_t:s0 on an MLS system, where, say, s0 might mean top secret instead of nothing. Perhaps we should call this element doi (Domain of Interpretation) instead of policytype, in keeping with existing similar security labeling, and not tied in name to the SELinux polictype configuration variable. I thought the SELinux policytype in this case would be a useful starting point for the DOI, although the truth is that this needs to be entirely administratively managed. We can't predict where administrative security boundaries will be or how the user will represent them. Possibile DOI schemes include domain name, policy package+version names, existing kerberos realms etc. I like the concept of a DOI field instead of policy type; considering the portability of guest images this seems like a good solution based on the relative success of DOIs in other distributed applications. However, may I suggest that instead of representing the DOI as a string we use a 32bit integer? I know that may sound a bit odd, but in the networking world most DOI values are represented as integers and when security labels are involved they tend to be 32bits. I understand that using a plain integer is much more abstract than a human readable string but it should make it easier to leverage existing and future* DOI frameworks. *An informal group/list just formed to start discussing DOI management issues such as DOI formats, negotiation and translation. -- paul moore linux @ hp -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] Re: [PATCH 0/6] host (node) device enumeration, take two
On Tue, Oct 21, 2008 at 01:45:47PM -0400, David Lively wrote:
Ok, here's my substantially-reworked node device enumeration patch, this
time done with a proper understanding of the public-obj/Obj/Def
model :-) as last discussed here:
https://www.redhat.com/archives/libvir-list/2008-September/msg00398.html
I've broken it into the following pieces:
1-public-apiadditions to the public API
2-internal-api additions to the internal API
3-local-node-driversthe HAL DeviceKit implementations
4-remote-node-driverthe remote driver
5-virsh-support virsh support
6-python-bindings python bindings
Big differences from the last submission:
* public-obj/Obj/Def object model finally understood :-)
* capabilities structure now struct-ified, handled like
other Def bits
I like the way this bit turned out - makes it very clear what properties
we are exporting in the XML as part of our API/ABI gaurentee.
* using newfangled array-based lists for NodeDeviceObj's
The individual capabilities within a device are still using a linked list,
though that's not a critical problem from the thread safety point of view.
* added flags args to various public APIs (as suggested by Dan V)
* bus folded into capabilities (as discussed w/Dan B)
Yes, this looks much nicer too.
* device key no longer exists - name is unique on node
Some pieces are still incomplete, but I thought it would be better to
post what I have since it's useful as is. Here's what I know of
that's left to do:
* finish Python bindings (will get to Real Soon Now)
* submit Java bindings (I have them, and have been using them)
* implement virNodeDeviceCreate/Destroy (I have no plans for these)
No need to worry about this - I'd like to use them to implement the
creation/deletion of NPIV virtual HBAs eventually.
* subscribe to HAL events update dev state from them (next for me?)
* implement pci_bus/usb_bus capabilities (for PCI/USB controllers)
While on the subject of USB, I've just noticed that HAL seems to
expose 2 devices for every USB device - 'usb' and 'usb_device',
which we're mapping into just a 'usb' capability. Unless there's
compelling reason to have both we might consider just filtering
out one of the two.
* DeviceKit implementation is barely a proof of concept
Noticed one problem - on my build it refuses to enumerate devices
if you pass in a NULL for subsystem name list. I made a really
quick dirty hack to just try it out
@@ -300,13 +301,18 @@ static int devkitNodeDriverStartup(void)
}
/* Populate with known devices */
-devs = devkit_client_enumerate_by_subsystem(devkit_client, NULL, err);
-if (err) {
-DEBUG0(devkit_client_enumerate_by_subsystem failed);
-devs = NULL;
-goto failure;
+for (i = 0 ; i ARRAY_CARDINALITY(caps_tbl) ; i++) {
+const char *caps[] = { caps_tbl[i].cap_name, NULL };
+devs = devkit_client_enumerate_by_subsystem(devkit_client,
+caps,
+err);
+if (err) {
+DEBUG0(devkit_client_enumerate_by_subsystem failed);
+devs = NULL;
+goto failure;
+}
+g_list_foreach(devs, dev_create, devkit_client);
}
-g_list_foreach(devs, dev_create, devkit_client);
driverState-privateData = devkit_client;
* need to resolve naming other issues (see
https://www.redhat.com/archives/libvir-list/2008-September/msg00430.html
* ... and then fill in impl (no hurry; devkit immature now)
I'm still wondering if it is worth us santizing the device names ourselves
somehow, though it might end up being rather a large job. Will have to
think some more about it.
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 :|
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 00/12] Domain Events : DONE !
On Tue, Oct 21, 2008 at 03:10:15PM -0400, Ben Guthro wrote:
The following patch series implements the Events API discussed here
previously in this thread:
Okay, I commited the set of patches to CVS, congratulations (also
added you to the AUTHORS list as a result) !
I made the changes that Dan and I suggested before commiting.
There is just a couple of things I did in addition, I may have
been a bit over zealous in discarding virEventHandleType enums,
I also replaced them by ints in internal APIs where not used
as set. I think the only thing we loose is compiler checkings/warning
in case of switch {} constructs, but I'm still worried about them
as arguments even internally.
Otherwise I also changed virStringListFree to __virStringListFree
and virStringListJoin to __virStringListJoin to make clear they are
not exported from libvirt.c, but that's not related to your patches.
Again congratulations ! I think this also means the next release
will be a 0.5.0 since this is a major API addition. I still looking
at the other pending patches though, it would be better to have them
in the next release ... oh and I want your java bindings and we need
Python too (and QPid !) :-)
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
[EMAIL PROTECTED] | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] fix mingw compilation warning
On Thu, Oct 23, 2008 at 01:59:21PM +0200, Jim Meyering wrote: Building for mingw, I got this warning: libvirt.c:242: warning: control reaches end of non-void function Here's the fix: fix mingw compilation warning * src/libvirt.c (winsock_init) [HAVE_WINSOCK2_H]: Always return a value. neat :-) +1 Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ [EMAIL PROTECTED] | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 00/12] Domain Events : DONE !
Again congratulations ! I think this also means the next release will be a 0.5.0 since this is a major API addition. I still looking at the other pending patches though, it would be better to have them in the next release ... oh and I want your java bindings and we need Python too (and QPid !) :-) Great news! I'm just starting to look at the Python bindings...tryng to wrap my head around this whole process. Java will come after this, though I haven't even begun to look at it. As for Qpid... I suppose that will come after all the others. I've been mostly ignoring this, hoping I wouldn't have to know the gory details...but I guess that's unavoidable. Dave Lively's patches for HAL, and DevKit have some java bindings that are mostly done...I think submitting them are still on his TODO list. Are these the ones you are referring to? Thanks for accepting the patches! Ben -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 00/12] Domain Events : DONE !
Also - Additional work is needed in the hypervisor drivers other than qemu to properly emit domain events. My initial patch submission included some code designed to add, and monitor xenstore watches. It would be nice to get this integrated, as well. Ben Guthro wrote on 10/23/2008 09:40 AM: Again congratulations ! I think this also means the next release will be a 0.5.0 since this is a major API addition. I still looking at the other pending patches though, it would be better to have them in the next release ... oh and I want your java bindings and we need Python too (and QPid !) :-) Great news! I'm just starting to look at the Python bindings...tryng to wrap my head around this whole process. Java will come after this, though I haven't even begun to look at it. As for Qpid... I suppose that will come after all the others. I've been mostly ignoring this, hoping I wouldn't have to know the gory details...but I guess that's unavoidable. Dave Lively's patches for HAL, and DevKit have some java bindings that are mostly done...I think submitting them are still on his TODO list. Are these the ones you are referring to? Thanks for accepting the patches! Ben -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 00/12] Domain Events : DONE !
On Thu, Oct 23, 2008 at 09:40:36AM -0400, Ben Guthro wrote: Again congratulations ! I think this also means the next release will be a 0.5.0 since this is a major API addition. I still looking at the other pending patches though, it would be better to have them in the next release ... oh and I want your java bindings and we need Python too (and QPid !) :-) Great news! I'm just starting to look at the Python bindings...tryng to wrap my head around this whole process. Java will come after this, though I haven't even begun to look at it. As for Qpid... I suppose that will come after all the others. I've been mostly ignoring this, hoping I wouldn't have to know the gory details...but I guess that's unavoidable. Yep, the python stuff is seriously mind-bending with the mix of generated and hand-written code. To help you understand it: - libvir.c - hand written API wrappers - libvirt-py.c - auto-generated APi wrappers - libvir.py - hand written Python calling to C wrappers - libvirt.py - merged libvir.py with autogenerated code - generator.py - the code generator - docs/libvirt.xml - automatically extract API signatures - libvirt-python-api.xml - override incorrect API signatures The generator.py can cope with simple functions using API signature info from those two XML files. Sometimes it'll be able to get the python layer right, but not the C wrappers. For these, blacklist them in 'skip_impl' in generator.py. Sometimes it can't get either the C or python layer write - for those blacklist them in skip_function. I suspect you'll need the latter for the callback registering functions. I wouldn't worry too much about exposing the virEventRegisterImpl() function / callbacks in python. People using python are unlikely to be writing their own event loop impl in python - they'll just use glib/qt. The important bit to expose is the register/unregister of the domain event callbacks. Take a look at the way virRegisterErrorHandler() is handled in the python layer as a reasonable guide. As for Java, that's not time critical, since we release Java bindings separately from the main libvirt C/python code releases. Likewise the QPid stuff is separately released. Dave Lively's patches for HAL, and DevKit have some java bindings that are mostly done...I think submitting them are still on his TODO list. Are these the ones you are referring to? I'm still looking experimenting with the device patches. I think we're getting close to a solution that can be committed, but I'll also need to submit my patches to split the driver out for the daemon to avoid the GPL/LGPL problem introduced by DBus before we can do a release with this merge. Good news is that those patches are almost ready too. 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 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] hourly cvs snapshot broken
Now sure where to report this. Looks like that hourly CVS snapshot haven't been working for more than a month. If hourly snapshots are no longer being created, the Web site should probably be update. http://libvirt.org/downloads.html -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH/RFC] qemu/kvm: allow to hot remove scsi/virtio disks
Hi Daniel,
On Tue, Oct 21, 2008 at 03:25:25PM +0200, Daniel Veillard wrote:
[..snip..]
Those are just stylistic issues, I can apply the patch with those
changed if you wish if you don't have time for a new patch,
Thanks for your comments. Updated version attached. I basically removed
the union in favour of a single slotnum variable and cleaned up the
error messages.
As Daniel P. pointed out, the situation isn't ideal since we can only
hotremove disks added during the same session since qemu has no real
notion of reidentifying the disks that were passed on the command
line, this can hopefully be resolved in the future with a little help
from qemu.
Cheers,
-- Guido
From db7089cbd401f3474b73b2e03be4b1489b860df3 Mon Sep 17 00:00:00 2001
From: Guido Guenther [EMAIL PROTECTED]
Date: Fri, 17 Oct 2008 15:46:38 +0200
Subject: [PATCH] device detach for scsi/virtio disks
so far only disks hot added during the same session can be detached
---
src/domain_conf.h |1 +
src/qemu_driver.c | 134 +++--
2 files changed, 130 insertions(+), 5 deletions(-)
diff --git a/src/domain_conf.h b/src/domain_conf.h
index 4d193f4..886f318 100644
--- a/src/domain_conf.h
+++ b/src/domain_conf.h
@@ -90,6 +90,7 @@ struct _virDomainDiskDef {
char *driverType;
unsigned int readonly : 1;
unsigned int shared : 1;
+int slotnum; /* pci slot number for unattach */
};
diff --git a/src/qemu_driver.c b/src/qemu_driver.c
index 34f743b..4e8e10d 100644
--- a/src/qemu_driver.c
+++ b/src/qemu_driver.c
@@ -2510,12 +2510,12 @@ static int qemudDomainChangeEjectableMedia(virDomainPtr dom,
return 0;
}
-static int qemudDomainAttachDiskDevice(virDomainPtr dom, virDomainDeviceDefPtr dev)
+static int qemudDomainAttachPciDiskDevice(virDomainPtr dom, virDomainDeviceDefPtr dev)
{
struct qemud_driver *driver = (struct qemud_driver *)dom-conn-privateData;
virDomainObjPtr vm = virDomainFindByUUID(driver-domains, dom-uuid);
int ret, i;
-char *cmd, *reply;
+char *cmd, *reply, *s;
char *safe_path;
const char* type = virDomainDiskBusTypeToString(dev-data.disk-bus);
@@ -2563,7 +2563,14 @@ static int qemudDomainAttachDiskDevice(virDomainPtr dom, virDomainDeviceDefPtr d
DEBUG (pci_add reply: %s, reply);
/* If the command succeeds qemu prints:
* OK bus 0... */
-if (!strstr(reply, OK bus 0)) {
+#define PCI_ATTACH_OK_MSG OK bus 0, slot
+if ((s=strstr(reply, PCI_ATTACH_OK_MSG))) {
+char* dummy = s;
+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));
+} else {
qemudReportError (dom-conn, dom, NULL, VIR_ERR_OPERATION_FAILED,
_(adding %s disk failed), type);
VIR_FREE(reply);
@@ -2744,7 +2751,7 @@ static int qemudDomainAttachDevice(virDomainPtr dom,
} else if (dev-data.disk-bus == VIR_DOMAIN_DISK_BUS_SCSI ||
dev-data.disk-bus == VIR_DOMAIN_DISK_BUS_VIRTIO) {
supported = 1;
-ret = qemudDomainAttachDiskDevice(dom, dev);
+ret = qemudDomainAttachPciDiskDevice(dom, dev);
}
break;
}
@@ -2765,6 +2772,123 @@ static int qemudDomainAttachDevice(virDomainPtr dom,
return ret;
}
+static int qemudDomainDetachPciDiskDevice(virDomainPtr dom, virDomainDeviceDefPtr dev)
+{
+struct qemud_driver *driver = (struct qemud_driver *)dom-conn-privateData;
+virDomainObjPtr vm = virDomainFindByUUID(driver-domains, dom-uuid);
+int i, ret = -1;
+char *cmd, *reply;
+virDomainDiskDefPtr detach = NULL;
+
+if (!vm) {
+qemudReportError(dom-conn, dom, NULL, VIR_ERR_INVALID_DOMAIN,
+ %s, _(no domain with matching uuid));
+return -1;
+}
+
+for (i = 0 ; i vm-def-ndisks ; i++) {
+if (STREQ(vm-def-disks[i]-dst, dev-data.disk-dst)) {
+detach = vm-def-disks[i];
+break;
+}
+}
+
+if (!detach) {
+qemudReportError(dom-conn, dom, NULL, VIR_ERR_OPERATION_FAILED,
+ _(disk %s not found), dev-data.disk-dst);
+return -1;
+}
+
+if (detach-slotnum 1) {
+qemudReportError(dom-conn, dom, NULL, VIR_ERR_OPERATION_FAILED,
+ _(disk %s cannot be detached - invalid slot number %d),
+ detach-dst, detach-slotnum);
+return -1;
+}
+
+ret = asprintf(cmd, pci_del 0 %d, detach-slotnum);
+if (ret == -1) {
+qemudReportError(dom-conn, NULL, NULL, VIR_ERR_NO_MEMORY, NULL);
+return ret;
+}
+
+if (qemudMonitorCommand(driver, vm, cmd, reply) 0) {
+qemudReportError(dom-conn, dom, NULL, VIR_ERR_OPERATION_FAILED,
+ _(failed to execute detach disk %s
Re: [libvirt] hourly cvs snapshot broken
On Wed, Oct 22, 2008 at 05:11:54PM -0600, Stuart Jansen wrote: Now sure where to report this. Looks like that hourly CVS snapshot haven't been working for more than a month. If hourly snapshots are no longer being created, the Web site should probably be update. http://libvirt.org/downloads.html the autogen / m4 / build-aux files got broken on the local checkout, I think I have this fixed ... until it breaks again ! thanks for the heads-up ! Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ [EMAIL PROTECTED] | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] Allow changing ejectable device in domains using default qemu emulator
When a qemu domain is launched but an emulator is not explicitly defined, the default emulator is used. Attempts to attach ejectable devices to a domains using the default emulator fail with the error: Error Connecting CDROM: internal error\nCannot determine QEMU argv syntax (null). The following patch is based on similar code in qemudStartVMDaemon() and qemudBuildCommandLine(). I've tested it and it works. Honestly, though, I think this patch is just a band-aid. I'd like to supply a better patch, but I don't have enough experience to judge certain side effects. Instead of requiring functions to determine the emulator that will be used to launch the next qemu domain, qemudStartVMDaemon() should record the emulator that was used to start the current domain. It should also record the emulator's capabilities. This would make it unnecessary to call virDomainDefDefaultEmulator() in qemudDomainChangeEjectableMedia(). It would also make it possible to remove the virDomainDefDefaultEmulator() call from qemudBuildCommandLine(). However, testCompareXMLToArgvFiles() will fail because qemudBuildCommandLine() needs to know vm-def-emulator and virDomainDefParseFile() doesn't set vm-def-emulator to a default value. I don't know if this is a real problem, or if it just means the test needs to be updated. In addition, if we simply set vm-dev-emulator = strdup(virDomainDefDefaultEmulator()) in qemudStartVMDaemon() then virDomainDefFormat() will dump emulator.../emulator for domains that did't actually have it explicitly defined. I don't know if this is a bug or improvement, but it is a change in behavior. 0001-Allow-changing-ejectable-device-in-domains-using-def.patch Description: application/mbox -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] Re: [PATCH 0/6] host (node) device enumeration, take two
On Thu, 2008-10-23 at 13:53 +0100, Daniel P. Berrange wrote:
On Tue, Oct 21, 2008 at 01:45:47PM -0400, David Lively wrote:
* using newfangled array-based lists for NodeDeviceObj's
The individual capabilities within a device are still using a linked list,
though that's not a critical problem from the thread safety point of view.
Right. This was intentional, since there are no per-capability
operations (and hence no need for per-capability locking granularity).
* subscribe to HAL events update dev state from them (next for me?)
BTW, I'm working on this now. Should have something to submit in
another day or two.
* implement pci_bus/usb_bus capabilities (for PCI/USB controllers)
While on the subject of USB, I've just noticed that HAL seems to
expose 2 devices for every USB device - 'usb' and 'usb_device',
which we're mapping into just a 'usb' capability. Unless there's
compelling reason to have both we might consider just filtering
out one of the two.
Yeah, I meant to bring this up. HAL uses usb_device for the USB
devices, and usb for the USB interface(s) provided by the device. The
usb_device is the parent of the usb interface(s). The HAL usb
namespace mirrors the attributes of the parent usb_device, and adds a
few of its own, specific to the interface. Right now I'm reporting both
mostly so the device hierarchy (as defined by the parent relation) is
consistent.
I see two choices:
(a) Just report the interface (usb) objects and fixup their parent to
be the parent of their owning USB device. Each interface object (as in
HAL) will reflect the details of the parent USB device, as well as the
interface-specific bits.
(b) Split libvirt's usb capability into usb_device and
usb_interface. A usb_interface will always have a usb_device as it's
parent (and I would *not* replicate the usb_device details in the
usb_interface - that's the whole reason for keeping it as a separate
device).
I'm leaning fairly strongly towards (b). What do you all think?
* DeviceKit implementation is barely a proof of concept
Noticed one problem - on my build it refuses to enumerate devices
if you pass in a NULL for subsystem name list. I made a really
quick dirty hack to just try it out
@@ -300,13 +301,18 @@ static int devkitNodeDriverStartup(void)
}
/* Populate with known devices */
-devs = devkit_client_enumerate_by_subsystem(devkit_client, NULL, err);
-if (err) {
-DEBUG0(devkit_client_enumerate_by_subsystem failed);
-devs = NULL;
-goto failure;
+for (i = 0 ; i ARRAY_CARDINALITY(caps_tbl) ; i++) {
+const char *caps[] = { caps_tbl[i].cap_name, NULL };
+devs = devkit_client_enumerate_by_subsystem(devkit_client,
+caps,
+err);
+if (err) {
+DEBUG0(devkit_client_enumerate_by_subsystem failed);
+devs = NULL;
+goto failure;
+}
+g_list_foreach(devs, dev_create, devkit_client);
Oh yeah. I forgot I fixed devkit_client_enumerate_by_subsystem to work
as advertised with a NULL subsystem. I submitted the fix a couple
months ago to [EMAIL PROTECTED], but never got any
acknowledgment, and haven't seen any activity on the list whatsoever, so
I'm not surprised it hasn't made it in. Any idea where I should submit
devkit fixes?
In any case, I'll put your workaround in for now. It won't pick up
devices in subsystems not listed in caps_tbl, but those are fairly
useless devices anyway (since we won't recognize any device caps if we
don't explicitly handle that subsystem in caps_tbl).
}
-g_list_foreach(devs, dev_create, devkit_client);
driverState-privateData = devkit_client;
* need to resolve naming other issues (see
https://www.redhat.com/archives/libvir-list/2008-September/msg00430.html
* ... and then fill in impl (no hurry; devkit immature now)
I'm still wondering if it is worth us santizing the device names ourselves
somehow, though it might end up being rather a large job. Will have to
think some more about it.
Yeah, it's a nasty issue. In a lot of ways, the HAL names are pretty
nice. For example, I really like NICs named by MAC address (so knowing
that a particular NIC is eth0 is *not* encoded in the device name, but
rather in a capability). This is also much nicer than naming by (e.g.)
sysfs path, which encodes too much info about where the card is plugged
in (that's what parent info is for).
But I don't see any sign that Devkit is exposing HALish names, though
I'd imagine (if only to make HAL-Devkit transition easier) that they
will need to expose a device property like HAL_UDI. With no activity
on the devkit-devel list, I'm not sure where they're going.
Thanks for the comments. I'll incorporate your devkit workaround, and
wait on further comment before submitting the next take.
Dave
--
Re: [libvirt] [PATCH] Allow changing ejectable device in domains using default qemu emulator
Stuart Jansen wrote: When a qemu domain is launched but an emulator is not explicitly defined, the default emulator is used. Attempts to attach ejectable devices to a domains using the default emulator fail with the error: Error Connecting CDROM: internal error\nCannot determine QEMU argv syntax (null). snip In addition, if we simply set vm-dev-emulator = strdup(virDomainDefDefaultEmulator()) in qemudStartVMDaemon() then virDomainDefFormat() will dump emulator.../emulator for domains that did't actually have it explicitly defined. I don't know if this is a bug or improvement, but it is a change in behavior. I think this is the real bug. Whatever emulator we use to launch the VM should show up in the domain xml, and fixing this would make the reported issue go away as you say. I think the way to do it is to alter virDomainDefDefaultEmulator to return NULL if no emulator is found, rather than error. The we can call it at parse time, rather than offload it to each driver that needs it. The error should trickle down to somewhere else so I don't think this approach loses anything. This would also make all other calls to virDomainDefDefaultEmulator redundant. I could be missing something though :) Thanks, Cole -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
