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(a)gmail.com> wrote:
On Thu, Aug 28, 2008 at 2:52 PM, Atsushi SAKAI
<sakaia(a)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(a)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(a)redhat.com
>>
https://www.redhat.com/mailman/listinfo/libvir-list
>
>
>