KVM call minutes for Mar 15

KVM call minutes for Mar 15

[Chris Wright]

QAPI -- http://wiki.qemu.org/Features/QAPI
- please review!
- Anthony would like to see feedback and plans to commit in a week
  (assuming agreement and no major issues in review)
- some concern about the maintainability of code generation
  - but still nothing concrete on the list, need to review and discuss
    on the list
- some concern that implementation details may change the wire protocol
  - introduces a new mechanism for new signals (mask by default and
    enabled explicitly)
  - disagreement over when/how to introduce new extensions
- libvirt feedback?
  - no protocol level changes
    - old and new versions are testable with test suite and proves this
- 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

QCFG -- http://wiki.qemu.org/Features/QCFG
- command line args translation to objects is complex and buggy
- schema + code generator to formalize this
- formally describe each command line option and generate code
  to build and validate objects
- provides systematic way to document command line options
- automatically 
- device_add does multiple conversions to go from qmp to qemuopts to
  objects
- move to basic c structures, and autogenerated marshalling code
- no plan to do this work soon, late in 0.15 cycle
  - same as qapi, fork a tree, do mass conversion and merge for 0.16 cycle
- qmp server mode to take all configuation commands before actually
  starting the guest
- can provide a config file 
- qdev...
  - could just bridge to setting and getting qdev properties
  - OR get to point where device objects go directly to qdev device init
- why not move command line to qmp instead of new schema?
  - single schema
- considerations for -M (didn't capture all of these)
- for all the details:
  
  http://wiki.qemu.org/Features/QCFG

Merging big changes
- in the past, evolving in tree has not worked well, leaving partial
  conversions
- QAPI/QCFG method of doing changes in external tree hopes to set new precedent
  - preserve patch/review on list
  - do full conversion
  - provide strong testing to show it works

Kemari merge plans
- just needs some ACKs
- Juan, Anthony, anybody else who is familiar with migration to review?

switch from gpxe to ipxe
- possible 0.15 release w/ ipxe (Alex looking into it)
- Michael Brown been helpful in fixing bugs, so compat
- Alex will send out mail soon on the details
- ipxe releases?  not yet, there are plans for it, should be coming RSN
- Stefan volunteers to help test

[Qemu-devel] KVM call minutes for Mar 15

[Chris Wright]

QAPI -- http://wiki.qemu.org/Features/QAPI
- please review!
- Anthony would like to see feedback and plans to commit in a week
  (assuming agreement and no major issues in review)
- some concern about the maintainability of code generation
  - but still nothing concrete on the list, need to review and discuss
    on the list
- some concern that implementation details may change the wire protocol
  - introduces a new mechanism for new signals (mask by default and
    enabled explicitly)
  - disagreement over when/how to introduce new extensions
- libvirt feedback?
  - no protocol level changes
    - old and new versions are testable with test suite and proves this
- 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

QCFG -- http://wiki.qemu.org/Features/QCFG
- command line args translation to objects is complex and buggy
- schema + code generator to formalize this
- formally describe each command line option and generate code
  to build and validate objects
- provides systematic way to document command line options
- automatically 
- device_add does multiple conversions to go from qmp to qemuopts to
  objects
- move to basic c structures, and autogenerated marshalling code
- no plan to do this work soon, late in 0.15 cycle
  - same as qapi, fork a tree, do mass conversion and merge for 0.16 cycle
- qmp server mode to take all configuation commands before actually
  starting the guest
- can provide a config file 
- qdev...
  - could just bridge to setting and getting qdev properties
  - OR get to point where device objects go directly to qdev device init
- why not move command line to qmp instead of new schema?
  - single schema
- considerations for -M (didn't capture all of these)
- for all the details:
  
  http://wiki.qemu.org/Features/QCFG

Merging big changes
- in the past, evolving in tree has not worked well, leaving partial
  conversions
- QAPI/QCFG method of doing changes in external tree hopes to set new precedent
  - preserve patch/review on list
  - do full conversion
  - provide strong testing to show it works

Kemari merge plans
- just needs some ACKs
- Juan, Anthony, anybody else who is familiar with migration to review?

switch from gpxe to ipxe
- possible 0.15 release w/ ipxe (Alex looking into it)
- Michael Brown been helpful in fixing bugs, so compat
- Alex will send out mail soon on the details
- ipxe releases?  not yet, there are plans for it, should be coming RSN
- Stefan volunteers to help test

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

[Anthony Liguori]

On 03/15/2011 09:53 AM, Chris Wright wrote:
> QAPI -- http://wiki.qemu.org/Features/QAPI
> - please review!
> - Anthony would like to see feedback and plans to commit in a week
>    (assuming agreement and no major issues in review)
> - some concern about the maintainability of code generation
>    - but still nothing concrete on the list, need to review and discuss
>      on the list
> - some concern that implementation details may change the wire protocol
>    - introduces a new mechanism for new signals (mask by default and
>      enabled explicitly)
>    - disagreement over when/how to introduce new extensions

I'm going to try to figure out a better way to do this.  For the short 
term, we don't have an immediate need for the new signaling mechanism 
but I think I've been adequately convinced that we need something better 
for 0.15.

> - libvirt feedback?
>    - no protocol level changes
>      - old and new versions are testable with test suite and proves this
> - 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);

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.

> QCFG -- http://wiki.qemu.org/Features/QCFG
> - command line args translation to objects is complex and buggy
> - schema + code generator to formalize this
> - formally describe each command line option and generate code
>    to build and validate objects
> - provides systematic way to document command line options
> - automatically
> - device_add does multiple conversions to go from qmp to qemuopts to
>    objects
> - move to basic c structures, and autogenerated marshalling code
> - no plan to do this work soon, late in 0.15 cycle
>    - same as qapi, fork a tree, do mass conversion and merge for 0.16 cycle
> - qmp server mode to take all configuation commands before actually
>    starting the guest
> - can provide a config file
> - qdev...
>    - could just bridge to setting and getting qdev properties
>    - OR get to point where device objects go directly to qdev device init

So we'd do something like:

{ 'device': 'ISASerial', 'properties': { 'iobase': 'int', 'irq': 'int', 
'chardev': 'CharDriverState' } }

And we can document all of the parameters in the same fashion as 
everything else.  We can extract that documentation to provide QMP-level 
documentation, CLI-level documentation, and even online documentation 
for qdev.

The only question in my mind is what the C interface ought to be.  It 
could be:

DeviceState * qdev_create_isa_serial(ISASerialProperties *props, Error 
**errp);

And:

DeviceState * libqmp_qdev_create_isa_serial(ISASerialProperties *props, 
Error **errp);

Or we could expand it:

DeviceState * qdev_create_isa_serial(int64_t iobase, int64_t irq, 
CharDriverState * chardev, Error **errp);

And this is much nicer to use internally.

But, this is bad for libqmp because adding parameters breaks the C API.  
The libqmp API really wants to use a structure.

It's not clear to me whether we should have differing internal APIs vs. 
libqmp, or whether we should just use structures in QEMU.

Haven't put too much thought into it but that's pretty much a brain dump 
of where I am right now.

> - why not move command line to qmp instead of new schema?
>    - single schema
> - considerations for -M (didn't capture all of these)
> - for all the details:
>
>    http://wiki.qemu.org/Features/QCFG
>
> Merging big changes
> - in the past, evolving in tree has not worked well, leaving partial
>    conversions
> - QAPI/QCFG method of doing changes in external tree hopes to set new precedent
   - put together a detailed specification and make it available for 
review very early in the process.

I think this is a critical step too.

>    - preserve patch/review on list
>    - do full conversion
>    - provide strong testing to show it works
>
> Kemari merge plans
> - just needs some ACKs
> - Juan, Anthony, anybody else who is familiar with migration to review?
>
> switch from gpxe to ipxe
> - possible 0.15 release w/ ipxe (Alex looking into it)
> - Michael Brown been helpful in fixing bugs, so compat
> - Alex will send out mail soon on the details
> - ipxe releases?  not yet, there are plans for it, should be coming RSN
> - Stefan volunteers to help test

Regards,

Anthony Liguori

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

[Anthony Liguori]

On 03/15/2011 09:53 AM, Chris Wright wrote:
> QAPI -- http://wiki.qemu.org/Features/QAPI
> - please review!
> - Anthony would like to see feedback and plans to commit in a week
>    (assuming agreement and no major issues in review)
> - some concern about the maintainability of code generation
>    - but still nothing concrete on the list, need to review and discuss
>      on the list
> - some concern that implementation details may change the wire protocol
>    - introduces a new mechanism for new signals (mask by default and
>      enabled explicitly)
>    - disagreement over when/how to introduce new extensions

I'm going to try to figure out a better way to do this.  For the short 
term, we don't have an immediate need for the new signaling mechanism 
but I think I've been adequately convinced that we need something better 
for 0.15.

> - libvirt feedback?
>    - no protocol level changes
>      - old and new versions are testable with test suite and proves this
> - 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);

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.

> QCFG -- http://wiki.qemu.org/Features/QCFG
> - command line args translation to objects is complex and buggy
> - schema + code generator to formalize this
> - formally describe each command line option and generate code
>    to build and validate objects
> - provides systematic way to document command line options
> - automatically
> - device_add does multiple conversions to go from qmp to qemuopts to
>    objects
> - move to basic c structures, and autogenerated marshalling code
> - no plan to do this work soon, late in 0.15 cycle
>    - same as qapi, fork a tree, do mass conversion and merge for 0.16 cycle
> - qmp server mode to take all configuation commands before actually
>    starting the guest
> - can provide a config file
> - qdev...
>    - could just bridge to setting and getting qdev properties
>    - OR get to point where device objects go directly to qdev device init

So we'd do something like:

{ 'device': 'ISASerial', 'properties': { 'iobase': 'int', 'irq': 'int', 
'chardev': 'CharDriverState' } }

And we can document all of the parameters in the same fashion as 
everything else.  We can extract that documentation to provide QMP-level 
documentation, CLI-level documentation, and even online documentation 
for qdev.

The only question in my mind is what the C interface ought to be.  It 
could be:

DeviceState * qdev_create_isa_serial(ISASerialProperties *props, Error 
**errp);

And:

DeviceState * libqmp_qdev_create_isa_serial(ISASerialProperties *props, 
Error **errp);

Or we could expand it:

DeviceState * qdev_create_isa_serial(int64_t iobase, int64_t irq, 
CharDriverState * chardev, Error **errp);

And this is much nicer to use internally.

But, this is bad for libqmp because adding parameters breaks the C API.  
The libqmp API really wants to use a structure.

It's not clear to me whether we should have differing internal APIs vs. 
libqmp, or whether we should just use structures in QEMU.

Haven't put too much thought into it but that's pretty much a brain dump 
of where I am right now.

> - why not move command line to qmp instead of new schema?
>    - single schema
> - considerations for -M (didn't capture all of these)
> - for all the details:
>
>    http://wiki.qemu.org/Features/QCFG
>
> Merging big changes
> - in the past, evolving in tree has not worked well, leaving partial
>    conversions
> - QAPI/QCFG method of doing changes in external tree hopes to set new precedent
   - put together a detailed specification and make it available for 
review very early in the process.

I think this is a critical step too.

>    - preserve patch/review on list
>    - do full conversion
>    - provide strong testing to show it works
>
> Kemari merge plans
> - just needs some ACKs
> - Juan, Anthony, anybody else who is familiar with migration to review?
>
> switch from gpxe to ipxe
> - possible 0.15 release w/ ipxe (Alex looking into it)
> - Michael Brown been helpful in fixing bugs, so compat
> - Alex will send out mail soon on the details
> - ipxe releases?  not yet, there are plans for it, should be coming RSN
> - Stefan volunteers to help test

Regards,

Anthony Liguori

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

[Chris Wright]

* Anthony Liguori (anthony@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

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

[Chris Wright]

* Anthony Liguori (anthony@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

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

[Anthony Liguori]

On 03/15/2011 02:06 PM, Chris Wright wrote:
> * Anthony Liguori (anthony@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
>

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

[Anthony Liguori]

On 03/15/2011 02:06 PM, Chris Wright wrote:
> * Anthony Liguori (anthony@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
>

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

[Daniel P. Berrange]

On Tue, Mar 15, 2011 at 12:06:06PM -0700, Chris Wright wrote:
> * Anthony Liguori (anthony@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 :|

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

[Daniel P. Berrange]

On Tue, Mar 15, 2011 at 12:06:06PM -0700, Chris Wright wrote:
> * Anthony Liguori (anthony@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 :|