On Fri, Oct 02, 2015 at 02:33:22PM +0100, Dr. David Alan Gilbert wrote: > * Daniel P. Berrange (berra...@redhat.com) wrote: > > On Wed, Sep 30, 2015 at 09:48:25AM +0200, Markus Armbruster wrote: > > > "Dr. David Alan Gilbert" <dgilb...@redhat.com> 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 :|
