2:06 p.m.
* Anthony Liguori (anthony(a)codemonkey.ws) wrote:
On 03/15/2011 09:53 AM, Chris Wright wrote:
> QAPI
<snip>
>- 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.
thanks,
-chris
4:05 p.m.
New subject: [libvirt] [Qemu-devel] KVM call minutes for Mar 15
On 03/15/2011 02:06 PM, Chris Wright wrote:
* Anthony Liguori (anthony(a)codemonkey.ws) wrote:
> On 03/15/2011 09:53 AM, Chris Wright wrote:
>> QAPI
<snip>
>> - 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
Maybe, your ASCII art confuses me :-)
QmpSession is just a wrapper around a transport. It can be an fd that
you read() and write() JSON strings to, but it's just as easy to read
and write through JSON strings via virQemuMonitorCommand() or whatever
the interface currently is.
So bypassing libvirt completely to actually use the session?
Currently, it's more like:
client -> QemuMonitorCommand -> libvirt -> QMP -> QEMU
It's not bypassing. It's an API on top of a libvirt command.
FWIW, the code generator could be trivially modified to generate a
libvirt style API if there's any interest. So instead of:
void qmp_block_passwd(QmpSession *sess, const char *device, const char
*password, Error **errp);
It would be:
int virQemuBlockPasswd(virDomainPtr dom, const char *device, const char
*password);
But I'm not sure that's really that useful.
> 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.
To be clear, there's no real support needed from libvirt here other than
the passthrough.
How that interface is supported in libvirt is more or less orthogonal to
libqmp. libqmp is a C API to QMP. It can speak QMP over whatever
transports speak QMP. If you can speak QMP to libvirt, then it's only
natural to bridge libqmp to libvirt.
Regards,
Anthony Liguori
thanks,
-chris
5:34 a.m.
New subject: [libvirt] [Qemu-devel] KVM call minutes for Mar 15
On Tue, Mar 15, 2011 at 12:06:06PM -0700, Chris Wright wrote:
* Anthony Liguori (anthony(a)codemonkey.ws) wrote:
> On 03/15/2011 09:53 AM, Chris Wright wrote:
> > QAPI
<snip>
> >- 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.
Although we provide monitor and command line passthrough in libvirt,
our recommendation is that mgmt apps do not develop against these
APIs. Our goal / policy is that apps should be able todo anything
they need using the formally modelled libvirt public APIs.
The primary intended usage for the monitor/command line passthrough
is debugging & experimentation, and as a very short term hack/workaround
for mgmt apps while formal APIs are added to libvirt. In other words,
we provide the feature because we don't want libvirt to be a roadblock,
but we still strongly discourage their usage untill all other options
have been exhausted.
In same way as loading binary only modules into the kernels sets a
'tainted' flag, we plan that direct usage of monitor/command line
passthrough will set a tainted flag against a VM. This is allow distro
maintainers to identify usage & decide how they wish to support these
features in products (if at all).
Regards,
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 :|
5000
days inactive
5002
days old
2 comments
3 participants
participants (3)
-
Anthony Liguori -
Chris Wright -
Daniel P. Berrange