From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40518) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zi1KF-0003dP-SM for qemu-devel@nongnu.org; Fri, 02 Oct 2015 10:28:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zi1KC-00061r-3v for qemu-devel@nongnu.org; Fri, 02 Oct 2015 10:28:43 -0400 Received: from mx1.redhat.com ([209.132.183.28]:41763) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zi1KB-00061e-Th for qemu-devel@nongnu.org; Fri, 02 Oct 2015 10:28:40 -0400 Date: Fri, 2 Oct 2015 15:28:35 +0100 From: "Daniel P. Berrange" Message-ID: <20151002142835.GG28469@redhat.com> References: <371B9FFB-14FD-4707-9094-29EC9F6B508F@gmail.com> <87vbavm27u.fsf@blackfin.pond.sub.org> <20150929131109.GI3810@work-vm> <20150929133124.GK3810@work-vm> <8737xw9wl2.fsf@blackfin.pond.sub.org> <20151002123030.GA10222@redhat.com> <20151002133321.GG2605@work-vm> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20151002133321.GG2605@work-vm> Subject: Re: [Qemu-devel] feature idea: allow user to run custom scripts Reply-To: "Daniel P. Berrange" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Dr. David Alan Gilbert" Cc: Peter Maydell , qemu-devel qemu-devel , Michael Roth , Markus Armbruster , Programmingkid , Peter Crosthwaite On Fri, Oct 02, 2015 at 02:33:22PM +0100, Dr. David Alan Gilbert wrote: > * Daniel P. Berrange (berrange@redhat.com) wrote: > > On Wed, Sep 30, 2015 at 09:48:25AM +0200, Markus Armbruster wrote: > > > "Dr. David Alan Gilbert" 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 :|