* KVM call minutes for Mar 15 @ 2011-03-15 14:53 ` Chris Wright 0 siblings, 0 replies; 10+ messages in thread From: Chris Wright @ 2011-03-15 14:53 UTC (permalink / raw) To: kvm; +Cc: qemu-devel 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* [Qemu-devel] KVM call minutes for Mar 15 @ 2011-03-15 14:53 ` Chris Wright 0 siblings, 0 replies; 10+ messages in thread From: Chris Wright @ 2011-03-15 14:53 UTC (permalink / raw) To: kvm; +Cc: qemu-devel 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Qemu-devel] KVM call minutes for Mar 15 2011-03-15 14:53 ` [Qemu-devel] " Chris Wright @ 2011-03-15 16:28 ` Anthony Liguori -1 siblings, 0 replies; 10+ messages in thread From: Anthony Liguori @ 2011-03-15 16:28 UTC (permalink / raw) To: Chris Wright; +Cc: kvm, qemu-devel 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Qemu-devel] KVM call minutes for Mar 15 @ 2011-03-15 16:28 ` Anthony Liguori 0 siblings, 0 replies; 10+ messages in thread From: Anthony Liguori @ 2011-03-15 16:28 UTC (permalink / raw) To: Chris Wright; +Cc: qemu-devel, kvm 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Qemu-devel] KVM call minutes for Mar 15 2011-03-15 16:28 ` Anthony Liguori @ 2011-03-15 19:06 ` Chris Wright -1 siblings, 0 replies; 10+ messages in thread From: Chris Wright @ 2011-03-15 19:06 UTC (permalink / raw) To: Anthony Liguori Cc: Chris Wright, kvm, qemu-devel, Chris Lalancette, Jiri Denemark, libvir-list * 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Qemu-devel] KVM call minutes for Mar 15 @ 2011-03-15 19:06 ` Chris Wright 0 siblings, 0 replies; 10+ messages in thread From: Chris Wright @ 2011-03-15 19:06 UTC (permalink / raw) To: Anthony Liguori Cc: Chris Wright, kvm, libvir-list, qemu-devel, Chris Lalancette, Jiri Denemark * 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Qemu-devel] KVM call minutes for Mar 15 2011-03-15 19:06 ` Chris Wright @ 2011-03-15 21:05 ` Anthony Liguori -1 siblings, 0 replies; 10+ messages in thread From: Anthony Liguori @ 2011-03-15 21:05 UTC (permalink / raw) To: Chris Wright Cc: kvm, libvir-list, qemu-devel, Chris Lalancette, Jiri Denemark 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 > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Qemu-devel] KVM call minutes for Mar 15 @ 2011-03-15 21:05 ` Anthony Liguori 0 siblings, 0 replies; 10+ messages in thread From: Anthony Liguori @ 2011-03-15 21:05 UTC (permalink / raw) To: Chris Wright Cc: libvir-list, Jiri Denemark, Chris Lalancette, qemu-devel, kvm 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 > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [libvirt] [Qemu-devel] KVM call minutes for Mar 15 2011-03-15 19:06 ` Chris Wright @ 2011-03-17 10:34 ` Daniel P. Berrange -1 siblings, 0 replies; 10+ messages in thread From: Daniel P. Berrange @ 2011-03-17 10:34 UTC (permalink / raw) To: Chris Wright; +Cc: Anthony Liguori, kvm, libvir-list, qemu-devel, Jiri Denemark 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 :| ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [libvirt] [Qemu-devel] KVM call minutes for Mar 15 @ 2011-03-17 10:34 ` Daniel P. Berrange 0 siblings, 0 replies; 10+ messages in thread From: Daniel P. Berrange @ 2011-03-17 10:34 UTC (permalink / raw) To: Chris Wright; +Cc: libvir-list, Jiri Denemark, kvm, qemu-devel 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 :| ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2011-03-17 10:34 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-03-15 14:53 KVM call minutes for Mar 15 Chris Wright 2011-03-15 14:53 ` [Qemu-devel] " Chris Wright 2011-03-15 16:28 ` Anthony Liguori 2011-03-15 16:28 ` Anthony Liguori 2011-03-15 19:06 ` Chris Wright 2011-03-15 19:06 ` Chris Wright 2011-03-15 21:05 ` Anthony Liguori 2011-03-15 21:05 ` Anthony Liguori 2011-03-17 10:34 ` [libvirt] " Daniel P. Berrange 2011-03-17 10:34 ` Daniel P. Berrange
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.