Hi, I have a VMM application using a homegrown client for communicating with hypervisor. I am planning to migrate to libvirt because of the blocking nature of the calls. After going over the architecture, I would like to have a few doubts clarified 1) Should my application be necessarily multi-threaded in order to make use of the non-blocking calls in libvirt. [Are overlapping methods mainly used by multithreaded clients]. 2) I was wondering if there was any way to provide a callback along with the methods to achieve non-blocking.[My application has event library so it can receive events] 3) Is the libvirt RPC client multi-threaded. [i.e., does it internally use multiple threads to dispatch requests to server and return response to the application] I can provide more information, if its not helpful. Thanks Arvind -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://listman.redhat.com/archives/libvirt-users/attachments/20130514/8a1d1907/attachment.htm>
On 05/14/2013 06:17 PM, arvind viswanathan wrote:> Hi, > I have a VMM application using a homegrown client for communicating with > hypervisor. > I am planning to migrate to libvirt because of the blocking nature of the > calls. > After going over the architecture, I would like to have a few doubts > clarified > 1) Should my application be necessarily multi-threaded in order to make use > of the non-blocking calls in libvirt. [Are overlapping methods mainly used > by multithreaded clients].That's up to you; but virsh is our canonical example, and it is multi-threaded in order to allow Ctrl-C to interrupt long-running tasks cleanly.> 2) I was wondering if there was any way to provide a callback along with > the methods to achieve non-blocking.[My application has event library so > it can receive events]Yes, the event API requires that you register a callback to be invoked any time you want to receive notifications of events. You don't have to use events, but if you do, the examples/domain-events/ directory in libvirt.git shows how to use them in both C and Python bindings.> 3) Is the libvirt RPC client multi-threaded. [i.e., does it internally use > multiple threads to dispatch requests to server and return response to the > application]Yes, and the number of worker threads is configured by /etc/libvirt/libvirtd.conf max_workers. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 621 bytes Desc: OpenPGP digital signature URL: <http://listman.redhat.com/archives/libvirt-users/attachments/20130514/f7905337/attachment.sig>
On Tue, May 14, 2013 at 05:17:12PM -0700, arvind viswanathan wrote:> Hi, > I have a VMM application using a homegrown client for communicating with > hypervisor. > I am planning to migrate to libvirt because of the blocking nature of the > calls. > After going over the architecture, I would like to have a few doubts > clarified > 1) Should my application be necessarily multi-threaded in order to make use > of the non-blocking calls in libvirt. [Are overlapping methods mainly used > by multithreaded clients].The libvirt client & server are both multi-thread safe - you can have multiple threads using the same virConnectPtr object & it'll do the right thing with locking. So, yes, our recommendation is to use threads in applications which need non-blocking behaviour> 2) I was wondering if there was any way to provide a callback along with > the methods to achieve non-blocking.[My application has event library so > it can receive events]The only callbacks we have are for receiving event notifications. We don't have any async methods in the libvirt core API> 3) Is the libvirt RPC client multi-threaded. [i.e., does it internally use > multiple threads to dispatch requests to server and return response to the > application]Yes, libvirtd is fully multi-threaded and thus will process requests in parallel, even requests from the same client. Depending your application, there is also the possibility of using the slightly higher level libvirt-gobject library (part of the libvirt-glib codebase). This library integrates with GObject and GIO to provide async methods with callbacks on completion as you describe. The main limitation of this library is that it doesn't have 100% coverage of the current main libvirt APIs. It is being developed mostly to serve features required by the GNOME boxes application, since that's the main user of it currently. Of course we welcome patches to libvirt-gobject from any other interested parties. In addition to provide async APIs, it has a set of objects to managing configuration, so you don't need to use XML directly. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|