Hi, Quynh Thank you for your comment. I am clearified your question. But I have no good idea to solve. Someone may have a good idea. Thanks Atsushi SAKAI "Nguyen Anh Quynh" <aquynh@gmail.com> wrote:

On Thu, Aug 28, 2008 at 2:52 PM, Atsushi SAKAI <sakaia@jp.fujitsu.com> wrote:

...

Hi, Quynh

Did you see the libvirt access control feature? http://libvirt.org/auth.html You mean current access control feature is not enough for your use.

But that access control is about authenticating/authorizing, and that has nothing to do with the idea of "exposing unique features".

Thanks, Q

...

"Nguyen Anh Quynh" <aquynh@gmail.com> 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.

Idea?

Thanks, Quynh

-- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list

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