Re: [libvirt] [PATCH] Determine kvm max vcpus via version number
On Wed, Sep 17, 2008 at 09:53:16AM -0400, Cole Robinson wrote: Daniel Veillard wrote: On Fri, Sep 05, 2008 at 12:25:16PM -0400, Cole Robinson wrote: The attached patch is a slimmed down version of a patch I posted a while back. This expands qemu help message parsing to look for a kvm version number, which can be used to determine maximum supported vcpus. A kvmVersion field is added to the qemu_driver structure, and a check to determine the version is added to the libvirtd start up routine. If the kvm version isn't found (say if kvm isn't installed), kvmVersion is set to 0. This is against Guido Gunther's patch maxVCPU runtime detection: his method takes precendence in the code if it's available. Looks fine to me, Daniel I'm actually taking this off the table. I think Guido's solution is sufficient: works fine on f8, where as mine would have to accomodate different qemu help messages between at least f8 and f9, which is just getting into more work and complexity. So please ignore this patch. Okay :-) 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] rename blocked to idle
On Wed, Sep 17, 2008 at 03:15:14PM +0100, Richard W.M. Jones wrote: On Fri, Sep 12, 2008 at 05:10:38PM +0100, John Levon wrote: movement can we please please rename blocked to idle movement literally /everybody/ is confused by that ... dansmith I'm not opposed to changing it, mind you, because I feel the indirect pain of explaining it to others too :) movement actually, normally, the question is my guest isn't running dansmith yeah I still think blocked might make more sense. If the domain is doing I/O it will be most of gthe time blocked until the I/O completes and I guess it's the reason of the naming. It's just unfortunate that we can't distinguish between blocked on I/O and being idle. 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 1/3]: Cleanup the virStorageDriver structs
This patch just cleans up the virStorageDriver structs so that they use the
.functionPointer = functionname syntax of gcc. This makes it much easier to
grep in the code later. This patch also re-arranges the order of the function
pointers in remote_internal so that it matches the definition of
virStorageDriver in src/driver.h. While not strictly necessary, it does make it
a little more sane when looking at it in the future.
Signed-off-by: Chris Lalancette [EMAIL PROTECTED]
Index: src/remote_internal.c
===
RCS file: /data/cvs/libvirt/src/remote_internal.c,v
retrieving revision 1.83
diff -u -r1.83 remote_internal.c
--- a/src/remote_internal.c 29 Aug 2008 07:11:15 - 1.83
+++ b/src/remote_internal.c 19 Sep 2008 08:17:23 -
@@ -4907,14 +4907,14 @@
.numOfDefinedPools = remoteNumOfDefinedStoragePools,
.listDefinedPools = remoteListDefinedStoragePools,
.findPoolSources = remoteFindStoragePoolSources,
-.poolLookupByUUID = remoteStoragePoolLookupByUUID,
.poolLookupByName = remoteStoragePoolLookupByName,
+.poolLookupByUUID = remoteStoragePoolLookupByUUID,
.poolLookupByVolume = remoteStoragePoolLookupByVolume,
.poolCreateXML = remoteStoragePoolCreateXML,
.poolDefineXML = remoteStoragePoolDefineXML,
+.poolBuild = remoteStoragePoolBuild,
.poolUndefine = remoteStoragePoolUndefine,
.poolCreate = remoteStoragePoolCreate,
-.poolBuild = remoteStoragePoolBuild,
.poolDestroy = remoteStoragePoolDestroy,
.poolDelete = remoteStoragePoolDelete,
.poolRefresh = remoteStoragePoolRefresh,
Index: src/storage_driver.c
===
RCS file: /data/cvs/libvirt/src/storage_driver.c,v
retrieving revision 1.9
diff -u -r1.9 storage_driver.c
--- a/src/storage_driver.c 27 Aug 2008 20:05:59 - 1.9
+++ b/src/storage_driver.c 19 Sep 2008 08:17:24 -
@@ -1229,39 +1229,40 @@
static virStorageDriver storageDriver = {
-storage,
-storageOpen,
-storageClose,
-storageNumPools,
-storageListPools,
-storageNumDefinedPools,
-storageListDefinedPools,
-storageFindPoolSources,
-storagePoolLookupByName,
-storagePoolLookupByUUID,
-storagePoolLookupByVolume,
-storagePoolCreate,
-storagePoolDefine,
-storagePoolBuild,
-storagePoolUndefine,
-storagePoolStart,
-storagePoolDestroy,
-storagePoolDelete,
-storagePoolRefresh,
-storagePoolGetInfo,
-storagePoolDumpXML,
-storagePoolGetAutostart,
-storagePoolSetAutostart,
-storagePoolNumVolumes,
-storagePoolListVolumes,
-storageVolumeLookupByName,
-storageVolumeLookupByKey,
-storageVolumeLookupByPath,
-storageVolumeCreateXML,
-storageVolumeDelete,
-storageVolumeGetInfo,
-storageVolumeGetXMLDesc,
-storageVolumeGetPath
+.name = storage,
+.open = storageOpen,
+.close = storageClose,
+.numOfPools = storageNumPools,
+.listPools = storageListPools,
+.numOfDefinedPools = storageNumDefinedPools,
+.listDefinedPools = storageListDefinedPools,
+.findPoolSources = storageFindPoolSources,
+.poolLookupByName = storagePoolLookupByName,
+.poolLookupByUUID = storagePoolLookupByUUID,
+.poolLookupByVolume = storagePoolLookupByVolume,
+.poolCreateXML = storagePoolCreate,
+.poolDefineXML = storagePoolDefine,
+.poolBuild = storagePoolBuild,
+.poolUndefine = storagePoolUndefine,
+.poolCreate = storagePoolStart,
+.poolDestroy = storagePoolDestroy,
+.poolDelete = storagePoolDelete,
+.poolRefresh = storagePoolRefresh,
+.poolGetInfo = storagePoolGetInfo,
+.poolGetXMLDesc = storagePoolDumpXML,
+.poolGetAutostart = storagePoolGetAutostart,
+.poolSetAutostart = storagePoolSetAutostart,
+.poolNumOfVolumes = storagePoolNumVolumes,
+.poolListVolumes = storagePoolListVolumes,
+
+.volLookupByName = storageVolumeLookupByName,
+.volLookupByKey = storageVolumeLookupByKey,
+.volLookupByPath = storageVolumeLookupByPath,
+.volCreateXML = storageVolumeCreateXML,
+.volDelete = storageVolumeDelete,
+.volGetInfo = storageVolumeGetInfo,
+.volGetXMLDesc = storageVolumeGetXMLDesc,
+.volGetPath = storageVolumeGetPath,
};
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 2/3]: Fix storage_conf parsing for empty source
This patch fixes a minor bug in the storage_conf parsing. Creating logical
volume pool XML without a source definition is a valid operation (for example,
if you just want to scan an already existing LVM group), but this bug was making
the parser reject that XML. Bugfix from Dan Berrange, tested by me.
Signed-off-by: Chris Lalancette [EMAIL PROTECTED]
Index: src/storage_conf.c
===
RCS file: /data/cvs/libvirt/src/storage_conf.c,v
retrieving revision 1.14
diff -u -r1.14 storage_conf.c
--- a/src/storage_conf.c 5 Sep 2008 12:03:45 - 1.14
+++ b/src/storage_conf.c 19 Sep 2008 08:18:41 -
@@ -295,7 +295,7 @@
xmlNodePtr *nodeset = NULL;
int nsource, i;
-if ((nsource = virXPathNodeSet(conn, /pool/source/device, ctxt, nodeset)) = 0) {
+if ((nsource = virXPathNodeSet(conn, /pool/source/device, ctxt, nodeset)) 0) {
virStorageReportError(conn, VIR_ERR_XML_ERROR,
%s, _(cannot extract storage pool source devices));
goto cleanup;
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Improved error messages in XM conf module
On Mon, Sep 15, 2008 at 04:12:58PM +0100, Daniel P. Berrange wrote: On Mon, Sep 15, 2008 at 04:06:46PM +0100, Richard W.M. Jones wrote: The attached patch improves error handling in the XM config file parser (src/conf.c). Currently it has a custom error function called virConfError which has three problems. Firstly the conf argument is ignored and therefore pointless to even pass. Secondly the function takes a line number parameter (for reporting the line number where parsing failed), but this is swallowed and not printed in error messages. Thirdly, and most importantly, the name of the file where the error occurs is not printed by default unless the caller happens to print it. If there is an _empty_ file in /etc/xen we get this error: # virsh list --all libvir: error : failed to read configuration file /etc/xen/foobar but if the spurious file under /etc/xen is non-empty, like a script, you get completely anonymous errors such as: libvir: error : configuration file syntax error: expecting an assignment or: libvir: error : configuration file syntax error: expecting a value The patch fixes this by printing out the filename and line number if these are available from the parser context (and the parser context is passed to virConfError instead of the unused virConfPtr). With this patch you'll get errors for the second case like this: # virsh list --inactive libvir: error : /etc/xen/foobar:1: expecting a value ACK, this has annoyed the hell out of me for ages. +1, no problem, 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] [FW: An introduction to libvirt's LXC (LinuX Container) support]
On Wed, Sep 17, 2008 at 04:35:09PM +0100, Daniel P. Berrange wrote: FYI this mail i just sent to [EMAIL PROTECTED] where all the kernel container developers hang out. Great, may be worth dumping in the wiki if not done already :-) 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 3/3]: Implement logical stopPool and deletePool more fully
This patch does a few things.
1) Clean up a bunch of comments which I believe are no longer valid, or just
slightly wrong
2) Enable the stopPool command for the logical backend. The comment in the
code worries about a situation where you try to stop the logical volume that
your rootfs is on, for example. However, that situation is already taken care
of by the LVM tools; if the logical volume you try to stop is active, it will
throw an error saying that the LV is in use, and won't stop it. Therefore, it
should be pretty safe to try to stop logical volumes; it will fail for ones that
are in use, but will stop volumes that have been properly torn down ahead of
time.
3) In deletePool, remove the -f from the vgremove command. Besides the fact
that we probably don't usually want to force things, the -f option doesn't exist
prior to F-9, so this would fail on F-8, RHEL-5, etc.
4) In deletePool, implement pvremove of all source devices. Note that this
should also be relatively safe; it will only pvremove devices that we had
previously pvcreate'd in createPool, which means they were all under control of
libvirt. It will not pvremove devices on an LVM that you previously created,
but were just scanning with libvirt.
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.14
diff -u -r1.14 storage_backend_logical.c
--- a/src/storage_backend_logical.c 8 Sep 2008 08:03:54 - 1.14
+++ b/src/storage_backend_logical.c 19 Sep 2008 08:23:04 -
@@ -294,7 +294,7 @@
unsigned int flags ATTRIBUTE_UNUSED)
{
/*
- * # sudo vgs --noheadings -o vg_name
+ * # vgs --noheadings -o vg_name
* VolGroup00
* VolGroup01
*/
@@ -350,7 +350,6 @@
memset(zeros, 0, sizeof(zeros));
-/* XXX multiple pvs */
if (VIR_ALLOC_N(vgargv, 3 + pool-def-source.ndevice) 0) {
virStorageReportError(conn, VIR_ERR_NO_MEMORY, %s, _(command line));
return -1;
@@ -466,11 +465,11 @@
return 0;
}
-
-/* XXX should we set LVM to inactive ? Probably not - it would
- * suck if this were your LVM root fs :-)
+/*
+ * This is actually relatively safe; if you happen to try to stop the
+ * pool that your / is on, for instance, you will get failure like:
+ * Can't deactivate volume group VolGroup00 with 3 open logical volume(s)
*/
-#if 0
static int
virStorageBackendLogicalStopPool(virConnectPtr conn,
virStoragePoolObjPtr pool)
@@ -480,7 +479,6 @@
return 0;
}
-#endif
static int
virStorageBackendLogicalDeletePool(virConnectPtr conn,
@@ -488,15 +486,32 @@
unsigned int flags ATTRIBUTE_UNUSED)
{
const char *cmdargv[] = {
-VGREMOVE, -f, pool-def-source.name, NULL
+VGREMOVE, pool-def-source.name, NULL
};
+const char *pvargv[3];
+int i, error;
+/* first remove the volume group */
if (virRun(conn, cmdargv, NULL) 0)
return -1;
-/* XXX clear the PVs too ? ie pvremove ? probably ought to */
+/* now remove the pv devices and clear them out */
+error = 0;
+pvargv[0] = PVREMOVE;
+pvargv[2] = NULL;
+for (i = 0 ; i pool-def-source.ndevice ; i++) {
+pvargv[1] = pool-def-source.devices[i].path;
+if (virRun(conn, pvargv, NULL) 0) {
+error = -1;
+virStorageReportError(conn, VIR_ERR_INTERNAL_ERROR,
+ _(cannot remove PV device %s: %s),
+ pool-def-source.devices[i].path,
+ strerror(errno));
+break;
+}
+}
-return 0;
+return error;
}
@@ -610,9 +625,7 @@
.startPool = virStorageBackendLogicalStartPool,
.buildPool = virStorageBackendLogicalBuildPool,
.refreshPool = virStorageBackendLogicalRefreshPool,
-#if 0
.stopPool = virStorageBackendLogicalStopPool,
-#endif
.deletePool = virStorageBackendLogicalDeletePool,
.createVol = virStorageBackendLogicalCreateVol,
.deleteVol = virStorageBackendLogicalDeleteVol,
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 2/3]: Fix storage_conf parsing for empty source
On Fri, Sep 19, 2008 at 10:36:40AM +0200, Chris Lalancette wrote:
This patch fixes a minor bug in the storage_conf parsing. Creating logical
volume pool XML without a source definition is a valid operation (for example,
if you just want to scan an already existing LVM group), but this bug was
making
the parser reject that XML. Bugfix from Dan Berrange, tested by me.
Signed-off-by: Chris Lalancette [EMAIL PROTECTED]
Index: src/storage_conf.c
===
RCS file: /data/cvs/libvirt/src/storage_conf.c,v
retrieving revision 1.14
diff -u -r1.14 storage_conf.c
--- a/src/storage_conf.c 5 Sep 2008 12:03:45 - 1.14
+++ b/src/storage_conf.c 19 Sep 2008 08:18:41 -
@@ -295,7 +295,7 @@
xmlNodePtr *nodeset = NULL;
int nsource, i;
-if ((nsource = virXPathNodeSet(conn, /pool/source/device, ctxt,
nodeset)) = 0) {
+if ((nsource = virXPathNodeSet(conn, /pool/source/device, ctxt,
nodeset)) 0) {
virStorageReportError(conn, VIR_ERR_XML_ERROR,
%s, _(cannot extract storage pool source
devices));
goto cleanup;
ACK, I even re-factored virXPathNodeSet to allow it to return 0 - previously
it would not, but somehow I lost this bit here.
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/3]: Cleanup the virStorageDriver structs
On Fri, Sep 19, 2008 at 10:36:37AM +0200, Chris Lalancette wrote: This patch just cleans up the virStorageDriver structs so that they use the functionPointer = functionname syntax of gcc. This makes it much easier to grep in the code later. This patch also re-arranges the order of the function pointers in remote_internal so that it matches the definition of virStorageDriver in src/driver.h. While not strictly necessary, it does make it a little more sane when looking at it in the future. Signed-off-by: Chris Lalancette [EMAIL PROTECTED] 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] [PATCH 3/3]: Implement logical stopPool and deletePool more fully
On Fri, Sep 19, 2008 at 10:37:30AM +0200, Chris Lalancette wrote: This patch does a few things. 1) Clean up a bunch of comments which I believe are no longer valid, or just slightly wrong ACK 2) Enable the stopPool command for the logical backend. The comment in the code worries about a situation where you try to stop the logical volume that your rootfs is on, for example. However, that situation is already taken care of by the LVM tools; if the logical volume you try to stop is active, it will throw an error saying that the LV is in use, and won't stop it. Therefore, it should be pretty safe to try to stop logical volumes; it will fail for ones that are in use, but will stop volumes that have been properly torn down ahead of time. Ok, that's the scenario I was concerned about, so looks safe to enable this then. 3) In deletePool, remove the -f from the vgremove command. Besides the fact that we probably don't usually want to force things, the -f option doesn't exist prior to F-9, so this would fail on F-8, RHEL-5, etc. Hmm, are you sure it won't prompt for a y/n confirmation ? IIRC, that was the reason I put in the -f. Perhaps simply ensuring stdin is /dev/null takes care of that problem. 4) In deletePool, implement pvremove of all source devices. Note that this should also be relatively safe; it will only pvremove devices that we had previously pvcreate'd in createPool, which means they were all under control of libvirt. It will not pvremove devices on an LVM that you previously created, but were just scanning with libvirt. 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] [RFC] Events API
On Thu, Sep 18, 2008 at 12:45:07PM -0400, David Lively wrote:
Hi -
We have some folks looking into the implementation of events (just VM
state transition events, for now) in libvirtd. I've been assuming that
events will be XML strings, something like:
event type=domain-state-transition timestamp=x
domain-id22/domain-id
old-statenostate/old-state
new-staterunning/new-state
/event
where the contents of the event element are determined by the event
type, and the attributes type and timestamp are required.
Originally, I was thinking one would listen for events by registering
a callback, something like:
int virConnectAddEventHandler(virConnPtr conn, char **filter,
virEventHandler handler, void *arg)
where filter is either NULL, indicating interest in all events, or else
a NULL-terminated vector of event type names, allowing filtering by
event type. void handler(conn, const char *eventXML, arg) would be
called for each matching event.
I think I'd prefer to have properly typed event callbacks for each
type of event we're dealing with, and to register callbacks against
the object being tracked. We also don't want to do transitions
on all the states - eg transitions between nostate running are
happening many times a second - its not useful to track that IMHO.
Against a virConnectPtr object I'd expect to be able to register
to get an event upon
- A new domain object coming into existance
- A existing domain object going out of existance
So, you could register a callback, call Rich's virConnectListAllDomains()
once, and then rely on the callbacks from that point onwards to keep
your list of domains up2date. So in case of listening for domains:
enum {
VIR_CONNECT_DOMAIN_EVENT_ADDED,
VIR_CONNECT_DOMAIN_EVENT_REMOVED,
};
typedef int (*virConnectDomainEventCallback)(virConnectPtr conn,
virDomainPtr dom,
int event,
void *opaque);
int virCOnnectDomainEventRegister(virConnectPtr conn,
virConnectDomainEventCallback cb,
void *opaque);
There would eventually be equivalent API for virNetworkPtr objects
and virStoragePoolPtr objects, to track addition removal of them.
Against a virDomainPtr object, I'd expect to be able to register
to get an event upon the significant state transitions. If we
exclude the transition between nonstate running which just happens
far to often to be practical to track, I don't see a need to filter
the events further - just have the callback get all events against
that domain object.
enum {
VIR_DOMAIN_EVENT_STARTED
VIR_DOMAIN_EVENT_SUSPENDED
VIR_DOMAIN_EVENT_RESUMED
VIR_DOMAIN_EVENT_STOPPED
VIR_DOMAIN_EVENT_SAVED,
VIR_DOMAIN_EVENT_RESTORED,
};
typedef int (*virDomainLifecycleEventCallback)(virDomainPtr dom,
int event,
void *opaque);
virDomainLifecycleEventRegister(virDomainPtr dom,
virDomainLifecycleEventCallback cb,
void *opaque);
I'm a little concerned that a vector of event type names isn't really
adequate for specifying a filter. Does this need to be more general
(XPathString exprs??)
IMHO, XML / xpath is rather overkill for getting lifecycle events.
But my larger concern is that an asynchronous callback mechanism (as
proposed above) assumes the presence of some thread / process from which
to make the callbacks. ???This works fine in the libvirtd context, but
not outside of it. For instance, we build a client only version of
libvirt with ONLY the remote driver, which currently doesn't require
pthreads at all. Introducing asynchronous callbacks into the API means
pthreads is now required for this.
I wouldn't want to use threads for this - any application which is
structured in such a way as to be able to make use of async events
will have some kind of event loop implementation. We merely need to
provoide a way to hook libvirt into that event loop. We already have
the API defined for this - src/event.h, and have an demonstration
impl that the daemon uses qemud/event.c. So we'd want to validate
this src/event.h API contract by doing a proof-of concept impl with
an external Glib event loop and if it proves sane, then make the
event.h file part of the public API.
Applications could either craft their event loop impl themselves, or
we can provide some add-on pre-built helper libraries with common
impls. eg, an optional libvirt-glib library which comes with a
pre-built event impl for applications which use glib. Likewise a
libvirt-qt helper. That'd cover pretty much all common GUI apps.
This approach has been used very successfully by
Re: [libvirt] openvz support in libvirt
2008/9/19 Evgeniy Sokolov [EMAIL PROTECTED] Hello. To start with, I have the following questions: Does libvirt support the xml format for openvz driver described in the next thread? http://www.redhat.com/archives/libvir-list/2008-July/msg00312.html (I think, that it does not. But will it support it in future? :)) What libvirt functionality does openvz driver support? (Openvz does not mentioned in http://libvirt.org/hvsupport.html) Hi Anton, OpenVZ uses generic xml format. It is common for all libvirt drivers. one difference is filesystem: filesystem type=template source name=name of template / target dir=// /filesystem example: domain type='openvz' name210/name Does the 'name ' tag specify domain veid or veid is generated automatically? uuid08344fd6-17d6-711f-6ad8-08b85777a2a2/uuid vcpu13/vcpu memory131072/memory os typeexe/type /os devices filesystem type=template source name=centos-4-i386-minimal / target dir=// quota type=size max=1/ quota type=inodes max=20/ /filesystem interface type='bridge' source bridge='eth10'/ /interface interface type='ethernet' mac address='00:16:3e:34:21:9e'/ ip address=192.168.122.3 / /interface /devices /domain -- 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] [RFC] Events API
On Thu, Sep 18, 2008 at 12:45:07PM -0400, David Lively wrote: I'm a little concerned that a vector of event type names isn't really adequate for specifying a filter. Does this need to be more general (XPathString exprs??) I think I'm with Dan on this one. I would start small -- just domains coming going (unless VirtualIron needs other events). Since there is no limit to the number of API calls we can have in libvirt, add an API call just for registering for these domain events. Instead of trying to overload untyped strings with complicated meanings. But my larger concern is that an asynchronous callback mechanism (as proposed above) assumes the presence of some thread / process from which to make the callbacks. This works fine in the libvirtd context, but not outside of it. For instance, we build a client only version of libvirt with ONLY the remote driver, which currently doesn't require pthreads at all. Introducing asynchronous callbacks into the API means pthreads is now required for this. I'm not quite sure I follow this -- you mean it introduces pthreads into libvirt or into the caller? As far as I can see, nothing about this would require threads in either. The remote protocol allows event messages to be passed back asynchronously, although the current remote driver wouldn't expect to receive them which might be a problem for backwards/forwards compatibility. (Therefore the remote client must tell the remote server that it can handle asynchronous events, and the remote client must be prepared to talk to a server which cannot understand asynchronous events -- there is an internal feature API you can use for this). Notwithstanding that, you would have to add a client call to poll for events or (better) to expose the file descriptor so that callers can use it in select(2)/poll(2). Actually there are a number of ways to do this -- IIRC dbus does something semi-elegant. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my OCaml programming blog: http://camltastic.blogspot.com/ Fedora now supports 68 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 1/3]: Cleanup the virStorageDriver structs
On Fri, Sep 19, 2008 at 10:36:37AM +0200, Chris Lalancette wrote: This patch just cleans up the virStorageDriver structs so that they use the functionPointer = functionname syntax of gcc. This makes it much easier to +1. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] openvz support in libvirt
2008/9/19 Evgeniy Sokolov [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Hello. To start with, I have the following questions: Does libvirt support the xml format for openvz driver described in the next thread? http://www.redhat.com/archives/libvir-list/2008-July/msg00312.html (I think, that it does not. But will it support it in future? :)) What libvirt functionality does openvz driver support? (Openvz does not mentioned in http://libvirt.org/hvsupport.html) Hi Anton, OpenVZ uses generic xml format. It is common for all libvirt drivers. one difference is filesystem: filesystem type=template source name=name of template / target dir=// /filesystem example: domain type='openvz' name210/name Does the 'name ' tag specify domain veid or veid is generated automatically? You need to specify veid. -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [RFC] Events API
On Fri, Sep 19, 2008 at 11:14:07AM +0100, Richard W.M. Jones wrote: On Thu, Sep 18, 2008 at 12:45:07PM -0400, David Lively wrote: I'm a little concerned that a vector of event type names isn't really adequate for specifying a filter. Does this need to be more general (XPathString exprs??) I think I'm with Dan on this one. I would start small -- just domains coming going (unless VirtualIron needs other events). Since there is no limit to the number of API calls we can have in libvirt, add an API call just for registering for these domain events. Instead of trying to overload untyped strings with complicated meanings. But my larger concern is that an asynchronous callback mechanism (as proposed above) assumes the presence of some thread / process from which to make the callbacks. ???This works fine in the libvirtd context, but not outside of it. For instance, we build a client only version of libvirt with ONLY the remote driver, which currently doesn't require pthreads at all. Introducing asynchronous callbacks into the API means pthreads is now required for this. I'm not quite sure I follow this -- you mean it introduces pthreads into libvirt or into the caller? As far as I can see, nothing about this would require threads in either. The remote protocol allows event messages to be passed back asynchronously, although the current remote driver wouldn't expect to receive them which might be a problem for backwards/forwards compatibility. (Therefore the remote client must tell the remote server that it can handle asynchronous events, and the remote client must be prepared to talk to a server which cannot understand asynchronous events -- there is an internal feature API you can use for this). Notwithstanding that, you would have to add a client call to poll for events or (better) to expose the file descriptor so that callers can use it in select(2)/poll(2). Making a client poll for events is evil because it prevents the CPU going into low power mode when nothing is happening. Exposing a FD severely limits your flexibility, because libvirt then has no control over when the FD is being monitored - you may well not want it being select'd on all the time - and/or want to change the events being monitored for at various times. Actually there are a number of ways to do this -- IIRC dbus does something semi-elegant. Yes, the DBus approach (which is what I followed for the src/events.h API) is the way I like best. It doesn't require libvirt to do tricks internally with threads, and doesn't force a particular event loop impl onto applications, and still allows libvirt full control over just when how FD is addded to the event loop for monitoring. 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 2/3]: Fix storage_conf parsing for empty source
On Fri, Sep 19, 2008 at 10:36:40AM +0200, Chris Lalancette wrote: This patch fixes a minor bug in the storage_conf parsing. Creating logical volume pool XML without a source definition is a valid operation (for example, if you just want to scan an already existing LVM group), but this bug was making the parser reject that XML. Bugfix from Dan Berrange, tested by me. +1. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my OCaml programming blog: http://camltastic.blogspot.com/ Fedora now supports 68 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [RFC] Events API
On Fri, Sep 19, 2008 at 11:22:24AM +0100, Daniel P. Berrange wrote: Making a client poll for events is evil because it prevents the CPU going into low power mode when nothing is happening. Didn't mean literally poll of course :-) Exposing a FD severely limits your flexibility, because libvirt then has no control over when the FD is being monitored - you may well not want it being select'd on all the time - and/or want to change the events being monitored for at various times. Yup, didn't get down to the bottom of your other email. Exposing an FD is also tricky on Windows too (where you have the joys of WSAWaitForMultipleEvents), so best to avoid it if possible. If someone (dbus? glib?) has solved this in a platform-independent way already then so much the better. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [RFC] Events API
On Fri, Sep 19, 2008 at 11:30:01AM +0100, Richard W.M. Jones wrote: On Fri, Sep 19, 2008 at 11:22:24AM +0100, Daniel P. Berrange wrote: Making a client poll for events is evil because it prevents the CPU going into low power mode when nothing is happening. Didn't mean literally poll of course :-) Exposing a FD severely limits your flexibility, because libvirt then has no control over when the FD is being monitored - you may well not want it being select'd on all the time - and/or want to change the events being monitored for at various times. Yup, didn't get down to the bottom of your other email. Exposing an FD is also tricky on Windows too (where you have the joys of WSAWaitForMultipleEvents), so best to avoid it if possible. If someone (dbus? glib?) has solved this in a platform-independent way already then so much the better. The glib event loop implementation on Windows is built using the WSAWaitForMultipleEvents API, so any libvirt-glib.so impl of the events.h API would 'just work' in this respect 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] [RFC] Events API
Daniel P. Berrange wrote: Applications could either craft their event loop impl themselves, or we can provide some add-on pre-built helper libraries with common impls. eg, an optional libvirt-glib library which comes with a pre-built event impl for applications which use glib. Likewise a libvirt-qt helper. That'd cover pretty much all common GUI apps. Sounds sane. avahi does the same btw, and I like that approach. cheers, Gerd -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [RFC] Events API
On Fri, Sep 19, 2008 at 01:14:14PM +0200, Gerd Hoffmann wrote: Daniel P. Berrange wrote: Applications could either craft their event loop impl themselves, or we can provide some add-on pre-built helper libraries with common impls. eg, an optional libvirt-glib library which comes with a pre-built event impl for applications which use glib. Likewise a libvirt-qt helper. That'd cover pretty much all common GUI apps. Sounds sane. avahi does the same btw, and I like that approach. Avahi's interface is a thin wrapper arounds dbus's interface :-) And indeed the libvirtd's event.c impl fits into Avahi's interface nicely which demonstrates we're consistent in our thinking. 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] pausing / unpausing guests with libvirt
I'm working on a management application that will control Xen guest vms
(HVMs) with libvirt Java bindings. I want to be able to pause and unpause
the VMs but doing so through the libvirt functions does not seem to actually
pause the VM. The suspend function returns true and doesn't throw any
exceptions, however, the guest VM is still running and responsive.
Any pointers are greatly appreciated.
Thanks
-matthew
I'm using:
libvirt 0.4.5
libvirt-java 0.2.1
Xen 3.1.2
The guest I'm working with is a Fedora Core 6 HVM (though I'd like it to
work with any guest.)
The host is Fedora Core 8.
Code to define and create the domain:
try {
con = new Connect (xen:///);
String xml = buildXMLConfig(config);// config is a
string of XML shown below
domain = con.domainDefineXML(xml);
domain.create ();
} catch (LibvirtException ex) {
logger.error (Error starting VM, ex);
return false;
}
Code to pause the VM:
public boolean pause() throws RemoteException {
logger.info (Pause operation in progress. domain = +domain);
if (domain == null)
return false;
try {
synchronized (domain) {
domain.suspend (); // using suspend() because there is
no pause() function.
}
} catch (LibvirtException ex) {
logger.error (Could not suspend +vm.getName(), ex);
return false;
}
raiseComponentChangeEvent(new
ComponentStateChangeEvent(State.PAUSED));
return true;
}
(The synchronized() statement is because I was running a second thread
watching the state of the VM and I thought maybe that might be contributing
to the problem. The VM is still not paused when there is only one thread
running.)
XML for the domain:
domain type='xen'
nameLinux2/name
os
typehvm/type
loader/usr/lib/xen/boot/hvmloader/loader
boot dev='hd'/
/os
memory50/memory
vcpu1/vcpu
on_shutdownshutdown/on_shutdown
on_rebootrestart/on_reboot
on_crashrestart/on_crash
features
pae/
acpi/
apic/
/features
devices
emulator/usr/lib/xen/bin/qemu-dm/emulator
input type='tablet' bus='usb'/
graphics type='vnc' autoport='yes' listen='192.168.1.226'/
serial type='pty'/
disk type='block'
source dev='/dev/vgvms/Linux2'/
target dev='hda'/
/disk
interface type='bridge'
mac address='D6:5F:DF:05:45:BB'/
source bridge='Bridge2'/
/interface
/devices
/domain
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [RFC] Events API
On Fri, 2008-09-19 at 11:14 +0100, Richard W.M. Jones wrote: On Thu, Sep 18, 2008 at 12:45:07PM -0400, David Lively wrote: I'm a little concerned that a vector of event type names isn't really adequate for specifying a filter. Does this need to be more general (XPathString exprs??) I think I'm with Dan on this one. I would start small -- just domains coming going (unless VirtualIron needs other events). Since there is no limit to the number of API calls we can have in libvirt, add an API call just for registering for these domain events. Instead of trying to overload untyped strings with complicated meanings. Okay. I'm fine with a more strongly-typed event protocol. While it's more work to add new classes of events (as compared with extending event XML), that's probably a Good Thing :-) But my larger concern is that an asynchronous callback mechanism (as proposed above) assumes the presence of some thread / process from which to make the callbacks. This works fine in the libvirtd context, but not outside of it. For instance, we build a client only version of libvirt with ONLY the remote driver, which currently doesn't require pthreads at all. Introducing asynchronous callbacks into the API means pthreads is now required for this. I'm not quite sure I follow this -- you mean it introduces pthreads into libvirt or into the caller? As far as I can see, nothing about this would require threads in either. I meant that if we expected the callbacks to just happen, libvirt (at least, the libvirtd-less version) would need to spawn a thread to make the callbacks. But this is quite easily avoided by providing a hook that clients are responsible for calling for event delivery, as suggested. I had considered this as an alternative to the file-descriptor interface (but thought the fd interface was convenient with to use w/select() poll()). After considering the problems with fds and power-saving and windows compatibility, I agree an event-delivery hook sounds like the best idea, perhaps: int virDeliverEvents(int timeout) where timeout is interpreted as in poll() (i.e., max millisecs to block, 0 means don't block, negative means block forever). The remote protocol allows event messages to be passed back asynchronously, although the current remote driver wouldn't expect to receive them which might be a problem for backwards/forwards compatibility. (Therefore the remote client must tell the remote server that it can handle asynchronous events, and the remote client must be prepared to talk to a server which cannot understand asynchronous events -- there is an internal feature API you can use for this). Notwithstanding that, you would have to add a client call to poll for events or (better) to expose the file descriptor so that callers can use it in select(2)/poll(2). Yeah, I expect the remote implementation will be the worst part! Thanks for the pointers. Thanks, Dave -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] pausing / unpausing guests with libvirt
On Fri, Sep 19, 2008 at 09:23:52AM -0400, Matthew Donovan wrote: I'm working on a management application that will control Xen guest vms (HVMs) with libvirt Java bindings. I want to be able to pause and unpause the VMs but doing so through the libvirt functions does not seem to actually pause the VM. The suspend function returns true and doesn't throw any exceptions, however, the guest VM is still running and responsive. Any pointers are greatly appreciated. Is it possible you could isolate whether the problem is with libvirt or with the Java bindings? One way would be to shell out to 'virsh' just to see if virsh fails to change the state (ie. a libvirt/C) or if the problem is in the Java bindings. Pausing/resuming Xen domains is a very common and well-tested operation so I would be surprised if it's a libvirt problem, but you never know ... Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
