Re: [libvirt] [RFC] Events API
On Fri, Sep 19, 2008 at 11:08:37AM -0400, David Lively wrote: int virDeliverEvents(int timeout) This isn't really much use because it doesn't integrate with common main loops. I suggest you look at glib to see how it handles main loops and how to integrate with it. 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] pausing / unpausing guests with libvirt
On Sun, Sep 21, 2008 at 05:16:32PM -0400, Matthew Donovan wrote: DEBUG: libvirt.c: virDomainCreate (domain=0x92bd1e0) DEBUG: libvirt.c: virDomainSuspend (domain=0x92bd1e0) virDomainSuspend() failed: 0 I think this is a bug in the Xen driver - the virDomainCreate api is not updating the internal 'id' parameter of the virDomainPtr object, so when you then call virDomainSuspend() with the same virDomainPtr it doesn't have the id it needs The easy workaround is to just get rid of your existing dom object and lookup a new one with 'virDomainLoopByUUID' after starting it. virDomainPtr dom; char uuid[VIR_UUID_BUFLEN]; virDomainCreate(dom); virDomainGetUUID(dom, uuid); virDomainFree(dom); dom = virDomainLookupByUUID(conn, uuid); virDomainSuspend(dom); 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] pausing / unpausing guests with libvirt
Looks like that did it. I can pause and resume Linux and Windows guests with this method. Thanks a lot! -matthew -Original Message- From: Daniel P. Berrange [mailto:[EMAIL PROTECTED] Sent: Monday, September 22, 2008 4:17 AM To: Matthew Donovan Cc: libvir-list@redhat.com Subject: Re: [libvirt] pausing / unpausing guests with libvirt On Sun, Sep 21, 2008 at 05:16:32PM -0400, Matthew Donovan wrote: DEBUG: libvirt.c: virDomainCreate (domain=0x92bd1e0) DEBUG: libvirt.c: virDomainSuspend (domain=0x92bd1e0) virDomainSuspend() failed: 0 I think this is a bug in the Xen driver - the virDomainCreate api is not updating the internal 'id' parameter of the virDomainPtr object, so when you then call virDomainSuspend() with the same virDomainPtr it doesn't have the id it needs The easy workaround is to just get rid of your existing dom object and lookup a new one with 'virDomainLoopByUUID' after starting it. virDomainPtr dom; char uuid[VIR_UUID_BUFLEN]; virDomainCreate(dom); virDomainGetUUID(dom, uuid); virDomainFree(dom); dom = virDomainLookupByUUID(conn, uuid); virDomainSuspend(dom); 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
Okay - I'm looking at glib docs. You guys are suggesting I create something that's easy to plug into a glib main loop, right? So ... something that's easy to wrap with a GSource via g_source_new()? (Stop me now if I'm on the wrong track!) So ... something that plugs into GSourceFuncs elements (in particular prepare/check/dispatch/finalize) easily?? int virEventsNeedDelivering(virConnectionPtr conn) int virEventsDispatch(virConnectionPtr conn) int virEventsCleanup(virConnectionPtr conn) and perhaps: int virEventsRunOnce(virConnectionPtr conn) to wrap them all for non-glib-ish implementations? Sorry if I'm being dense. I've looked at the qemud events interface, but I still feel like I'm missing something here. Dave On Mon, 2008-09-22 at 07:23 +0100, Richard W.M. Jones wrote: On Fri, Sep 19, 2008 at 11:08:37AM -0400, David Lively wrote: int virDeliverEvents(int timeout) This isn't really much use because it doesn't integrate with common main loops. I suggest you look at glib to see how it handles main loops and how to integrate with it. Rich. -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [RFC] Events API
On Mon, Sep 22, 2008 at 11:11:17AM -0400, David Lively wrote: Okay - I'm looking at glib docs. You guys are suggesting I create something that's easy to plug into a glib main loop, right? So ... something that's easy to wrap with a GSource via g_source_new()? (Stop me now if I'm on the wrong track!) So ... something that plugs into GSourceFuncs elements (in particular prepare/check/dispatch/finalize) easily?? int virEventsNeedDelivering(virConnectionPtr conn) int virEventsDispatch(virConnectionPtr conn) int virEventsCleanup(virConnectionPtr conn) and perhaps: int virEventsRunOnce(virConnectionPtr conn) to wrap them all for non-glib-ish implementations? No, this the wrong approach. This is defining an event loop impl - we don't want todo that. We need to define an API to let an application provide a set of callback for libvirt to talk to an existing event loop impl. ie a way for libvirt to register FD watches and timeouts, not a way for apps to manually process libvirt events in this way this example shows. The public API for this is along the lines of that currently defined in the src/events.h file. There are a set of functions libvirt needs in order to register actions for FDs, and/or timeouts. So the public API should consist of a way to register impls of these APIs typedef int (*virEventAddHandleFunc)(int, int, virEventHandleCallback, void *); typedef void (*virEventUpdateHandleFunc)(int, int); typedef int (*virEventRemoveHandleFunc)(int); typedef int (*virEventAddTimeoutFunc)(int, virEventTimeoutCallback, void *); typedef void (*virEventUpdateTimeoutFunc)(int, int); typedef int (*virEventRemoveTimeoutFunc)(int); void virEventRegisterImpl(virEventAddHandleFunc addHandle, virEventUpdateHandleFunc updateHandle, virEventRemoveHandleFunc removeHandle, virEventAddTimeoutFunc addTimeout, virEventUpdateTimeoutFunc updateTimeout, virEventRemoveTimeoutFunc removeTimeout); A separate libvirt-glib.so, would provide a API call virEventRegisterGLib() which calls virEventRegisterImpl() with a suitable implementation for glib. An application like virt-manager which uses glib and wants events would then calll virEventRegisterGLib(). If it had a custom event loop of its own, then it could call virEventRegisterImpl() directly with its special impl. It may be worth making our public API even more closely aligned with dbus - see dbus-connection.h and dbus-server.h - so people writing glue functions for it could just reuse what they've already written for dbus. typedef dbus_bool_t (* DBusAddWatchFunction) (DBusWatch *watch, void *data); typedef void(* DBusWatchToggledFunction) (DBusWatch *watch, void *data); typedef void(* DBusRemoveWatchFunction)(DBusWatch *watch, void *data); typedef dbus_bool_t (* DBusAddTimeoutFunction) (DBusTimeout*timeout, void *data); typedef void(* DBusTimeoutToggledFunction) (DBusTimeout*timeout, void *data); typedef void(* DBusRemoveTimeoutFunction) (DBusTimeout*timeout, void *data); dbus_bool_t dbus_server_set_watch_functions (DBusServer *server, DBusAddWatchFunction add_function, DBusRemoveWatchFunction remove_function, DBusWatchToggledFunction toggled_function, void *data, DBusFreeFunction free_data_function); dbus_bool_t dbus_server_set_timeout_functions (DBusServer *server, DBusAddTimeoutFunction add_function, DBusRemoveTimeoutFunction remove_function, DBusTimeoutToggledFunction toggled_function, void *data, DBusFreeFunction free_data_function); A 'watch' in DBus terminology is a file descriptor monitor. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |:
Re: [libvirt] [PATCH] read network config in OpenVZ driver
On Thu, Sep 18, 2008 at 03:47:53PM +0400, Evgeniy Sokolov wrote: On Wed, Sep 17, 2008 at 08:28:56PM +0400, Evgeniy Sokolov wrote: I attached patch without hunk which was commited by Daniel. Please commit if you are agree with it. A few comments inline.. ... So you're not artifically restricting the max length of the network name. It is limit in OpenVZ kernel. I did not remove check for max length. Thanks for review. Corrected patch is attached. Okay looks fine to me and that wasn't applied so I pushed this to CVS. Maybe the MAC parsing code could reuse virParseMacAddr() instead of calling scanf but that's cosmetic, thanks ! 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] Re: [PATCH] Add libvirt.h to ignore files
On Tue, Sep 09, 2008 at 12:47:32PM +1000, James Morris wrote: Shouldn't libvirt.h be ignored by SCMS ? in theory yes we should not check generated files in, but that one is fairly central, it's good to be able to see it without building, and it will only change when the libvirt version number changes, so that doesn't add much traffic. For those reasons I prefer to commit it. 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] [RFC] Events API
Okay, at long last, I see what you mean (I think). Apps using libvirt events must register an EventImpl via virRegisterEventImpl. Internally, suppose we implement events via an anonymous pipe. libvirt would call EventImpl.addHandle(pipe_read_fd, POLLIN ..., __virHandleEvents, conn) so the app's main loop would monitor fd (in whatever manner it chooses), then call __virHandleEvents(fd, conn) when it detected activity. __virHandleEvents would pull the event from the pipe and dispatch handlers as appropriate. We'd call eventImpl.removeHandle(pipe_read_fd) when the domain goes away. Am I finally on the right track?? If so, are you proposing that we simply make the existing src/events.h interface public? At this point, I don't see the need for anything but addHandle and removeHandle (but I can see how the others might be useful to libvirt eventually). Dave On Mon, 2008-09-22 at 16:22 +0100, Daniel P. Berrange wrote: No, this the wrong approach. This is defining an event loop impl - we don't want todo that. We need to define an API to let an application provide a set of callback for libvirt to talk to an existing event loop impl. ie a way for libvirt to register FD watches and timeouts, not a way for apps to manually process libvirt events in this way this example shows. The public API for this is along the lines of that currently defined in the src/events.h file. There are a set of functions libvirt needs in order to register actions for FDs, and/or timeouts. So the public API should consist of a way to register impls of these APIs typedef int (*virEventAddHandleFunc)(int, int, virEventHandleCallback, void *); typedef void (*virEventUpdateHandleFunc)(int, int); typedef int (*virEventRemoveHandleFunc)(int); typedef int (*virEventAddTimeoutFunc)(int, virEventTimeoutCallback, void *); typedef void (*virEventUpdateTimeoutFunc)(int, int); typedef int (*virEventRemoveTimeoutFunc)(int); void virEventRegisterImpl(virEventAddHandleFunc addHandle, virEventUpdateHandleFunc updateHandle, virEventRemoveHandleFunc removeHandle, virEventAddTimeoutFunc addTimeout, virEventUpdateTimeoutFunc updateTimeout, virEventRemoveTimeoutFunc removeTimeout); A separate libvirt-glib.so, would provide a API call virEventRegisterGLib() which calls virEventRegisterImpl() with a suitable implementation for glib. An application like virt-manager which uses glib and wants events would then calll virEventRegisterGLib(). If it had a custom event loop of its own, then it could call virEventRegisterImpl() directly with its special impl. It may be worth making our public API even more closely aligned with dbus - see dbus-connection.h and dbus-server.h - so people writing glue functions for it could just reuse what they've already written for dbus. typedef dbus_bool_t (* DBusAddWatchFunction) (DBusWatch *watch, void *data); typedef void(* DBusWatchToggledFunction) (DBusWatch *watch, void *data); typedef void(* DBusRemoveWatchFunction)(DBusWatch *watch, void *data); typedef dbus_bool_t (* DBusAddTimeoutFunction) (DBusTimeout*timeout, void *data); typedef void(* DBusTimeoutToggledFunction) (DBusTimeout*timeout, void *data); typedef void(* DBusRemoveTimeoutFunction) (DBusTimeout*timeout, void *data); dbus_bool_t dbus_server_set_watch_functions (DBusServer *server, DBusAddWatchFunction add_function, DBusRemoveWatchFunction remove_function, DBusWatchToggledFunction toggled_function, void *data, DBusFreeFunction free_data_function); dbus_bool_t dbus_server_set_timeout_functions (DBusServer *server, DBusAddTimeoutFunction add_function, DBusRemoveTimeoutFunction remove_function, DBusTimeoutToggledFunction toggled_function, void *data,
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. Okidoc, uncontroversial, so applied and commited, thanks ! 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 2/3]: Fix storage_conf parsing for empty source
On Fri, Sep 19, 2008 at 11:17:09AM +0100, Richard W.M. Jones wrote: 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. Makes sense, so applied and commited, 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 3/3]: Implement logical stopPool and deletePool more fully
On Fri, Sep 19, 2008 at 10:27:33AM +0100, Daniel P. Berrange wrote: 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. Hum, I hope the behaviour of the command didn't changed that way between RHEL-5/F-8 and now. I just committed but maybe we can make sure to pass /dev/null, since that's the main specific option of vgremove, I guess it will ask by default at least in recent versions. I didn't find an easy way to nullify stdin in virRun, seems we need to do another wrapper for virExec, or I'm mistaken. 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. I commited that patch but apparently we need at least to check that pool deletion still works on F-9/10, so that's not completely done 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] [RFC] Events API
On Fri, Sep 19, 2008 at 11:08:37AM -0400, David Lively wrote: 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 :-) it makes processing event simpler/cheaper, and if you want to scale that's not neglectible :-0 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()). the fd registration is really not ideal, as Dan and Rich suggested the hook based solution allows cleaner code, and more portability. 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). let's copy the kind of interface DBus provided, at least for consistency :-) 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. One thing i would like to make sure for remote is that we can reuse the existing connection, as opening a second connection initiated by the server may give troubles with firewalls. 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] [RFC] Events API
On Fri, Sep 19, 2008 at 10:54:39AM +0100, Daniel P. Berrange wrote: 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: Just a remark but unfortunately that scheme forces a race between the start of the event flow and the return of the list. The way used in the file monitoring API (FAM which I dislike but at least fixed that problem) is that when you register you get a flow of initial events allowing to setup your list of object. Certainly less efficient than single synchronous call but avoid the race. The user code is also simpler because you only use the events to maintain your state. Performance vs. accuracy , the balance is still open for long lived objects like domains though, but as virtualization gets integrated and efficient maybe it's better to play safe. 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] Re: [PATCH] Add .gitignore files
On Sun, 21 Sep 2008, Jim Meyering wrote: James Morris [EMAIL PROTECTED] wrote: I haven't seen these patches go in upstream. Any chance of having them committed so I don't have to carry them locally ? If they can be automatically generated from the .cvsignore ones, then how about adding a rule to do that as well? Doesn't worry me at all, just as long as I don't have to carry these patches. -- James Morris [EMAIL PROTECTED] -- 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
Daniel Veillard wrote: 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. Okidoc, uncontroversial, so applied and commited, thanks ! Thanks for committing DV. I still have to work on answering danpb's one other question on patch 3 (hopefully today), and then I'll post answers/updated patch for that one. Chris Lalancette -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
