[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [Qemu-devel] KVM call minutes for Mar 15

* Anthony Liguori (anthony codemonkey ws) wrote:
> On 03/15/2011 09:53 AM, Chris Wright wrote:
> > QAPI
> >- c library implementation is critical to have unit tests and test
> >   driven development
> >   - thread safe?
> >     - no shared state, no statics.
> >     - threading model requires lock for the qmp session
> >   - licensiing?
> >     - LGPL
> >   - forwards/backwards compat?
> >     - designed with that in mind see wiki:
> >
> >       http://wiki.qemu.org/Features/QAPI
> One neat feature of libqmp is that once libvirt has a better QMP
> passthrough interface, we can create a QmpSession that uses libvirt.
> It would look something like:
> QmpSession *libqmp_session_new_libvirt(virDomainPtr dom);

Looks like you mean this?

       -> request QmpSession -> 
client                          libvirt
       <- return QmpSession  <-

client -> QmpSession -> QMP -> QEMU

So bypassing libvirt completely to actually use the session?

Currently, it's more like:

client -> QemuMonitorCommand -> libvirt -> QMP -> QEMU

> The QmpSession returned by this call can then be used with all of
> the libqmp interfaces.  This means we can still exercise our test
> suite with a guest launched through libvirt.  It also should make
> the libvirt pass through interface a bit easier to consume by third
> parties.

This sounds like it's something libvirt folks should be involved with.
At the very least, this mode is there now and considered basically
unstable/experimental/developer use:

 "Qemu monitor command '%s' executed; libvirt results may be unpredictable!"

So likely some concern about making it easier to use, esp. assuming
that third parties above are mgmt apps, not just developers.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]