On Thu, Aug 28, 2008 at 5:33 PM, Daniel P. Berrange <berrange@xxxxxxxxxx> 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 -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list