[libvirt] Exposing some unique features?

[Daniel P. Berrange]

On Thu, Aug 28, 2008 at 02:39:57PM +0900, Nguyen Anh Quynh wrote:
> Hi,
> 
> Though libvirt tries very hard to hide the difference between
> hypervisors behind an abstraction layer, there are still differences
> that we might want to expose to the users. For example, QEMU has the
> monitor interface, which provides some unique functions. Users might
> want to have access to the monitor interface and send command to it
> (like "gdbserver" command?).
> 
> So how can we expose such information? We can have a new driver
> function, which return an opaque structure. The content of the
> structure is of course depends on the hypervisor type.
> 
> One problem is that this might be dangerous if users relies on the
> QEMU monitor to execute some functions that should be done under
> control.

Our policy for adding new APIs to libvirt is that the conceptual 
representation has to be applicable to multiple hypervisors, and
not be exposing a specific implmentation detail of one hypervisor.

Exposing the QEMU monitor fails this requirement because it is
clearly an ad-hoc QEMU specific access channel that has no 
equivalent in other hypervisors.

This doesn't mean that the functionality available via the QEMU
monitor is not wanted in libvirt. Instead we have to think about
each individual monitor command and decide how best to expose it.
Some examples we've dealt with already

 - "info blockstats" - exposed via virDomainBlockStats()
 - "stop"            - exposed via virDomainSuspend()
 - "cont"            - exposed via virDomainRestore()
 - "migrate"         - exposed via virDomainMigrate()
  etc, etc.

With the recent addition of USB device hotplug I think we have pretty good
coverage of commonly needed monitor commands, all via APIs which are 
conceptually sane for any hypervisor we implement.

So basically the answer to your question is that we don't allow  hypervisor
specific implementation details to be exposed via libvirt. We will allow
unique concepts to be exposed if they can be represented in a way which
would also make sense for other hypervisors in the future.

So if you have new functionality you'd like to expose in libvirt, send a
message to this list providing details of what the functionality is, how
/ why an application would use it and a proposed public API. We can then
all discuss the pros/cons and decide whether its suitable for libvirt and
the optimal representation.

Regards,
Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|