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

[Programmingkid]

On Oct 2, 2015, at 10:28 AM, Daniel P. Berrange wrote:

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

Sorry to say but this belief you have it exactly what is keeping
the GUI in QEMU from being great. Can only deal with one VM at a time?
I can have both qemu-system-ppc and qemu-system-i386 running at the
same time and they both have the same GUI. They are two separate
programs so no problems with them both running. 

Conditional codes can make the GUI more self-customizing to the various
machine emulators. Features like USB can be detected at runtime and
handled accordingly. 

The GUI in QEMU can become great. We just have to let it do so.