On Tue, Dec 09, 2014 at 11:19:22PM -0700, Chun Yan Liu wrote:
>>> On 12/9/2014 at 05:44 PM, in message
<20141209094444.GB29167(a)redhat.com>,
"Daniel P. Berrange" <berrange(a)redhat.com> wrote:
> On Tue, Dec 09, 2014 at 11:27:46AM +0800, Chunyan Liu wrote:
> > libxl supports sysrq. Add .domainSendKey function to support
> > sending sysrq key.
>
> I think this is really bending the semantics of the virDomainSendKey
> API too much. This API is documented to inject *any* scancodes into
> the guest operating system. Implementing it in such a way that you
> can only send sysrq key sequences to the guest kernel is not what
> applications will expect when they try to use this API. So NACK to
> this patch
>
> I'm open to the idea of adding an explicit API for triggering the
> sysrq sequence though. eg virDomainSendSysRequest or something
> like that, if you really want access to sysrq via the API.
Libxl now has no ability to send any key sequence to guest kernel
but supports sending sysrq key. We just want a way to send sysrq key,
so adding new virDomainSendSysRequest API is OK to me.
Meanwhile, that means:
Adding .domainSendSysRequest to virHypervisorDriver?
And in virsh, add a new 'virsh sysrq' command or update code of
cmdSendKey to handle sysrq key sequence? (like if .domainSendKey is
not supported by driver, check if it is sysrq key sequence, if yes, try
virDomainSysRequest if driver supports that.)
Yes pretty much, but I wouldn't do anything with domainSendKey. Apps can
choose to try to use domainSendKey if domainSysRequest isn't supported.
Regards,
Daniel
--
|:
http://berrange.com -o-
http://www.flickr.com/photos/dberrange/ :|
|:
http://libvirt.org -o-
http://virt-manager.org :|
|:
http://autobuild.org -o-
http://search.cpan.org/~danberr/ :|
|:
http://entangle-photo.org -o-
http://live.gnome.org/gtk-vnc :|