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@xxxxxxxxx> wrote: > On Thu, Aug 28, 2008 at 2:52 PM, Atsushi SAKAI <sakaia@xxxxxxxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxxx > >> https://www.redhat.com/mailman/listinfo/libvir-list > > > > > > -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list