[libvirt] Exposing some unique features?

[Nguyen Anh Quynh]

On Thu, Aug 28, 2008 at 5:33 PM, Daniel P. Berrange <berrange at redhat.com> wrote:
> 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.

I agree this is the way to go. Will get back to this in the future.

Thanks,
Q