Re: [Qemu-devel] feature idea: allow user to run custom scripts

["Daniel P. Berrange" <berrange@redhat.com>]

On Wed, Sep 30, 2015 at 09:48:25AM +0200, Markus Armbruster wrote:
> "Dr. David Alan Gilbert" <dgilbert@redhat.com> writes:
> 
> > * Peter Maydell (peter.maydell@linaro.org) wrote:
> >> On 29 September 2015 at 14:11, Dr. David Alan Gilbert
> >> <dgilbert@redhat.com> wrote:
> >> > * Peter Maydell (peter.maydell@linaro.org) wrote:
> >> >> On 28 September 2015 at 20:43, Programmingkid
> >> >> <programmingkidx@gmail.com> wrote:
> >> >> >
> >> >> > On Sep 28, 2015, at 3:29 AM, Markus Armbruster wrote:
> >> >> >> You didn't mention you're talking about a *GUI* feature.
> >> >> >
> >> >> > I'm thinking it would be easier to send in the patch rather
> >> >> > than talk about
> >> >> > what this feature could be.
> >> >>
> >> >> I think Markus and I are trying to save you that effort by
> >> >> pointing out that this is a VM management layer feature,
> >> >> not a core QEMU feature.
> >> >
> >> > OK, so I'm going to agree with Programmingkid here.
> >> > I think this would be a useful feature to have in QEMU; I've
> >> > got gratuitous hacks in some of my test scripts that work
> >> > around it not being there.
> >> >
> >> > I think there are two possible things, both of which seem fairly
> >> > easy:
> >> >   1) Add a -chardev from file that works in this case
> >> >      (I don't think the current chardev file works does it?)
> 
> In general, character devices provide a bidirectional pipe, but -chardev
> file is write-only.  I think you want -chardev pipe.  I don't use it
> myself, because as socat user, I don't have to learn lesser tools :)
> 
> Here's how I use it.  Set up a local socket (any convenient
> bidirectional pipe would do, actually).
> 
> Example: QMP
> 
>     # Configuration file for -readconfig
>     [chardev "qmp"]
>       backend = "socket"
>       path = "sock-qmp"
>       server = "on"
>       wait = "off"
> 
>     [mon "qmp"]
>       mode = "control"
>       chardev = "qmp"
> 
> Example: HMP
> 
>     [chardev "hmp"]
>       backend = "socket"
>       path = "sock-hmp"
>       server = "on"
>       wait = "off"
> 
>     [mon "hmp"]
>       mode = "readline"
>       chardev = "hmp"
> 
> Then do stuff with it.
> 
> Example: interactive QMP
> 
>     $ socat UNIX:sock-qmp READLINE,history=$HOME/.qmp_history,prompt='QMP> '
> 
> Example: interactive HMP
> 
>     $ socat UNIX:sock-hmp READLINE,history=$HOME/.hmp_history
> 
> Arguably superior to our built-in not-quite readline monitor.
> 
> Example: send QMP input from a file, capture its output in a file
> 
>     $ socat UNIX:sock-qmp STDIO <input >output
> 
> >> >   2) A 'source' like command.
> 
> QMP?  The command would have to take a filename as argument, and return
> a list of replies.  Probably stop on first failed command.  Pretty
> useless for remote clients, because if you have to upload the file, you
> can just as well send it down the QMP pipe.  Actually, that pretty much
> applies to local clients, too.  Except perhaps for interactive use.  I
> feel a QMP client geared for such use would be the appropriate home for
> this feature.  We have some in scripts/qmp/.
> 
> I don't have an opinion on HMP right now.
> 
> >> Yeah, these are both plausible. Neither of them are GUI features,
> >> though...
> >
> > Well, I don't use the GTK gui; I can see that those who do
> > might want features in it.
> 
> GUI users want GUI features, of course.
> 
> In my opinion, QEMU should leave them to separate GUI shells, because
> doing everything in QEMU distracts from our core mission and we don't
> have GUI expertise[*].  One more point: building in the GUI is
> problematic when you don't trust the guest, because then you really want
> to run QEMU with least privileges.

I don't find the lack of expertise argument very compelling in general, as
that's just a self-fullfilling prophecy really. I do agree though, that
building a fully featured mgmt UI in QEMU is a distraction from more
important work in QEMU's core mission.

I also think this last point about having security separation between QEMU
and the GUI layer is really a killer argument against having any kind of
non-trivial GUI built-in to QEMU.

I get the opinion that most maintainers consider that the QEMU GUI is just
there to provide the bare minimum infrastructure to interact with the guest
without relying on external services like SPICE/VNC. IOW it is not there as
a building block for creating a full management UI around QEMU. I think it
would be helpful to explicitly spell this out in docs somewhere, so people
looking at QEMU cna easily identify that we're not looking for patches to
add mgmt features in the QEMU GUI and they should invest their time in GUI
efforts built on top of QEMU.


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 :|