7:17 p.m.
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
9:30 p.m.
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
3:54 a.m.
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 :|
4173
days inactive
4173
days old
2 comments
3 participants
participants (3)
-
arvind viswanathan -
Daniel P. Berrange -
Eric Blake