Re: [libvirt] Exposing some unique features?

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.