On Tue, Jul 02, 2013 at 11:50:22AM -0300, Leonardo Augusto Guimarães Garcia wrote: > On 07/02/2013 06:20 AM, Daniel P. Berrange wrote: > >On Mon, Jul 01, 2013 at 02:18:27PM -0400, Cole Robinson wrote: > >>On 06/28/2013 01:49 PM, Leonardo Garcia wrote: > >>>From: Leonardo Garcia <lagarcia@xxxxxxxxxx> > >>> > >>>It is sometimes counter intuitive for a desktop user that the virtual machine > >>>continues to run when they left the console viewer application. They are used > >>>that when they close an application all the resources being used by it are also > >>>freed up, and from their perspective, the console viewer is just one more > >>>application running. > >>Hmm, I don't know if I buy this. Closing a VNC client window doesn't shut down > >>the remote machine, nor does exiting an SSH connection. And doing virt-manager > >>--uuid <blah> doesn't auto-start an inactive VM so users are forced to > >>recognize this concept IMO. > >> > >>There's also the issue that reliably shutting down a VM in a safe way is hard: > >>shutdown often doesn't do what's expected, and destroy is potentially > >>dangerous. If we just kick off 'shutdown' on exit then the user may not notice > >>for a long time that the VM never shut down. > >FWIW, on exit, GNOME Boxes will either suspend all VMs, or do a managed > >save on them. It definitely makes sense from Boxes POV, since it is trying > >not to expose "VM" as concept/object that the user needs to manage. They just > >have a number of operating systems they can interact with. > Yes, that might be more in line with the view I am trying to address. > > >I think this POV doesn't really make sense to virt-manager though, since it > >is really about exposing virtual machine management. In addition, virt-manager > >is not tied to a single machine, it can manage arbitrary machines & it definitely > >does not make sense to suspend VMs when disconnecting from any remote host. > > I might agree with that and I can change the code to be only valid > is the VM is running locally. I think that would be just as bad, if not worse. I would not expecting virt-manager to behave differently on shutdown for a connection which is local vs remote. > >>I think I'd be more comfortable with just recommending a wrapper script if > >>someone really wants this functionality, it's basically: > >I'd suggest that people just use GNOME Boxes if they want this kind of > >UI interaction model for their VMs. Different use case, different app. > > I might not completely agree with that. One of the issues I see with > the open source tools is that we have too many tools to do almost > the same thing. I understand and believe that choice is good, but > sometimes we are just replicating too much work IMHO. And end users > not always understand that. virt-manager and Boxes aren't really aiming at the same target. Boxes is aiming to provide a desktop application that is targeted explicitly at the desktop virtualization use case, with a focus on getting good usability in the UI. It explicitly addresses the issue you describe along with many other aspects of the user experiance that are important to desktop users. virt-manager did originally start out targetting desktop virt, but that focus was de-emphasised years ago, with it shifting to be a general tool for managing libvirt across a WAN, covering as much of the libvirt featureset as possible, and not attempting to impose too many clever behavioural policies. The cost of avoiding such policies is that you'll have worse usability if you're trying to use virt-manager only in the desktop virt use case. A big reason why the Boxes project was created, was to put a new stake in the ground for an exclusive desktop virt application, with a strong focus on getting a good user experiance for this scenario. 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 :| _______________________________________________ virt-tools-list mailing list virt-tools-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/virt-tools-list
