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

[Daniel P. Berrange]

On Fri, Oct 02, 2015 at 02:33:22PM +0100, Dr. David Alan Gilbert wrote:
> * Daniel P. Berrange (address@hidden) wrote:
> > On Wed, Sep 30, 2015 at 09:48:25AM +0200, Markus Armbruster wrote:
> > > "Dr. David Alan Gilbert" <address@hidden> writes:
> 
> > 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.
> 
> We already have a GUI (at least 2...)

Right, but they're very feature limited in what they do - essentially only
used by developers for ad-hoc testing - few people are using them in the
real world for production deployments. That's a reasonably well constrained
scenario with no need for growth in features.

> Defining a 'core mission' is very difficult.  While it's true that many
> of us have to mostly worry about security in big farms of servers, some people
> just want to run another OS on their desktop, and while they want it secure
> they also want it to have fast graphics.   I'm not sure we currently have
> a story for how to do separation from QEMU and fast graphics.

IIUC, the intention with virgl is to allowing QEMU to pass an FD back to the
SPICE/VNC client which they can use to access the render context to avoid
expensive copying.

> > 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.
> 
> But how bare do you want it to be?  Many users get put off by the sparsity
> of the GUI and just use something else instead.

Even if it were a fancier GUI, I don't think it would really go very far to
providing users a solution which is on a par with VirtualBox or VMWare Desktop
which are the benchmarks, as the GUI will forever be limited to only dealing
with a single VM at a time. As soon as you want to deal with more than 1 VM
at a time, a GUI built-in to QEMU is a non-starter as you need to manage many
QEMUs. So encouraging new users to use a built-in QEMU GUI is sending them
down a dead-end - we should be ensuring they can find the viable long term
UI straight away. This means directing them to things like GNOME Boxes or
virt-manager or one of the other UIs that exist.


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