<html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> Thanks for the replies and all the comments. Sorry for taking so long to answer this thread again... Some more comments inline. On 01/21/2013 09:54 AM, Daniel P. Berrange wrote: > On Fri, Jan 18, 2013 at 03:27:32PM -0200, <a class="moz-txt-link-abbreviated" href="mailto:lagarcia@linux.vnet.ibm.com">lagarcia@linux.vnet.ibm.com</a> wrote: >> >> Although I can agree that virt-manager would be more appropriate to hold the >> features I am describing, I think I am trying to address a use case scenario >> that is currently not properly supported by any of these two tools. So, first, >> let me try to define the audience I am interested in: my average end-user here >> is a desktop user. >> >> My view is that currently available virt-viewer and virt-manager tools are >> designed to fit the needs of system administrators or developers managing >> virtual machines. Both of them are targeted to the user dealing with >> virtualization in an enterprise/data-center environment. However, it is >> becoming more and more common that average desktop users, that are usually >> involved in administrative or operational tasks and that might not have any >> knowledge on how virtualization works, need to use virtualized environments >> running on their desktops (or even remotely) to accomplish daily tasks. Using a >> virtualized environment to accomplish some specific tasks would be important >> and necessary due to security reasons: to avoid any kind of contamination >> between the desktop user system and the system running the tools he/she uses to >> accomplish important tasks and that might have confidential/sensitive >> information. Also, it may be the case that customer contracts enforce the use >> of isolated systems to access the customer's IT environment: the use of >> virtualization allows one person to have access to multiple isolated >> environments in an easy way yet avoiding any contamination between the >> environments. >> >> The way I see today, virt-viewer is a too simple tool that only provides access >> to the virtual machine console. And, on the other hand, virt-manager is quite a >> complex tool for a desktop user. A desktop user might not be interested in the >> details involved in creating and managing virtual machines (IT department will >> work on that). But, at the same time, the desktop user would definitely want to >> access the virtual machine console and have some kind of control over the >> machine, even though he/she don't want to interact with any other complexities >> related to the virtual machine infrastructure. In that scenario, I am really >> targeting something in between from what virt-viewer and virt-manager console >> viewer provides today. >> >> The specific use cases I am interested in are: >> >> 1) Pause/Resume virtual machine >> >> As a desktop user I want to be able to pause/resume the execution of the >> virtual machine. This is important in cases in which I want to temporarily >> suspend the work being executed at some point and resume the work in a later >> time. From my point of view, this operation is similar to the suspend operation >> in my desktop/laptop and it is intuitive for me to execute the same action in a >> virtual machine. > > You can just invoke S3 suspend inside the VM > >> 2) Restart virtual machine >> >> As a desktop user I want to be able to restart the virtual machine. This is >> important in cases in which the applications running on the virtual machine >> blocks its operation for some reason (specially when using Windows virtual >> machines, which happens to be a very common case). > > If you're talking about forcing restart when the guest is not co-operating > then this is just the same as item 4). > > If the guest is co-operating, then invoking virDomainReboot is exactly > equivalent to just initiating a reboot from inside the guest. > >> 3) Shutdown >> >> As a desktop user I want to be able to shutdown the virtual machine. The use >> case here is similar to the one above: sometimes it is needed to simply turn >> off the virtual machine to recover from a bad behaving state. Also, it is >> intuitive for myself that I would be able to shutdown the virtual machine the >> same way I do with my desktop/laptop. More importantly, this is the more >> effective way to free up resources being used by the running virtual machine. > > Same comments as 2). Well, if an user can perform #1, #2, and #3 from inside the VM, why shouldn't we provide an easy way for he/she does the same from the virtual interface? In the end, that would be similar to hit power/reset button if the user was in front of the machine. On the other hand, I understand the concerns from Doug Goldstein on this respect. Although in the majority of Linux distros I've seen till now a user with access to the machine console can suspend/restart/shutdown the machine, this might not be the general case for all the OSes. > > >> 4) Forced shutdown >> >> As a desktop user I want to be able to forcefully turn off the running virtual >> machine. This is important in cases where the virtual machine is not responding >> anymore, e.g. BSOD. > > Yep, I can see this could be useful. > >> 5) Delete Virtual Client >> >> As a desktop user I might be interested in deleting the current virtual >> machine. This is important when, for instance, IT is deploying a new version of >> the virtual machine and I need to decide whether I want to continue using the >> old one, whether I want both versions (temporarily or in a definitive way), or >> whether I would, eventually, destroy the old machine and start using the new >> one. > > This is a difficult one in general. While it is easy enough to delete the > definition of the VM, there's the question of what todo with the storage > that goes along with it. I would say that, in general, we should allow the user to choose whether he/she wants to delete the storage. If the user doesn't have enough permission in order to do that, we just show a message error. I think this is similar to what happens with virt-manager today. > > >> 6) Create shortcut on Desktop >> >> As a desktop user I want to be able to easily access my virtual machines. >> Ideally I would be able to do that from a desktop application launcher shortcut >> that would: 1) Check if the virtual machine is running and, if not running, >> start it; 2) Connect to the virtual machine console. >> >> This desktop shortcut will be pre-configured by IT in my machine, but I need an >> easy way to recover it if I mistakenly delete it. >> >> Notice that the desktop shortcut would led me directly to the virtual machine >> console viewer with all the features I am interested in. I don't want to look >> on all the complexities shown by the virt-manager management window, for >> instance. > > I think your talk about shortcuts is a red-herring here. This can be simply > described as "Start the VM upon connect, if not already running". > >> 7) Changes the console viewer exit routine to shutdown the guest when the >> application is terminated. >> >> As a desktop user it is counter intuitive that the virtual machine continues to >> run when I left the console viewer application. I am used that when I close an >> application all the resources being used by it are also freed up. In that case, >> I would want to link the viewer exit routine to the virtual machine shutdown >> action. >> >> Of course that this might be configurable, as little bit more advanced desktop >> user might understand the fact that the virtual machine can continue to run >> even though the viewer is closed. >> >> 8) Leave virtual machine running in the background >> >> As a desktop user, I want to be able to quit the viewer application but leave >> the virtual machine running. This is the default behavior in viewers today, but >> if we introduce the use case #7 (which is interestingly a cause of a good >> amount of desktop users' requests) and the user configures it to be the default >> behavior, we need to leave a way for myself to keep the virtual machine running >> while I quit the viewer application. > >> >> 9) USB redirection functionality >> >> As a desktop user I want to be able to attach a USB device in my laptop/desktop >> and get it available in the running guest if the console viewer has the UI >> focus at the time the USB device is attached. I would also be able to manually >> select which USB devices already attached to the host I want to make available >> to the guest. >> >> Current development status: >> >> Use cases #1, #2, #3, and #4 are currently implemented in virt-manager console >> viewer. It would be useful though to have a way to open it without opening the >> virt-manager management window. >> >> Use case #5 is currently implemented in virt-manager management window, but >> this is not a window in which a desktop user would be interested in as it is >> too complex for the average desktop user. >> >> Use case #9 is currently implemented only in virt-viewer. >> >> Use cases #6, #7, and #8 are currently not implemented in any tools. > > It is quite a perfect fit, but in general I think I'd classify your > arguments as being "Allow the admin todo anything to a VM, that he > could do to a physical machine if he had physical access". Yes, based on the latest discussions, I agree. > > Virt-viewer as an application is really aiming at "Allow a user to > interact with a VM as he would with a physical 'kiosk' display". ie > it presents you access to use the desktop, but provides no physical > interaction / lifecycle control Ok. > > > I still believe that virt-manager could be made to address these, or > alternatively GNOME Boxes also addresses much of this. The problem is > though, that neither of these applications are really ammenable to > running on Windows. Ok... actually I didn't tried GNOME Boxes yet... but this was already in my "to do" list (specially as you and Doug Goldstein suggested it might include some of the features I am looking for. > > I'm kind of loathe to suggest this, but it kind of seems like you'd > be served by a new application "virt-control", which would basically > be the virt-viewer, but with all the extra features you describe. > This could even be done as part of the virt-viewer codebase, so that > we don't end up duplicating too much code. We already have 2 frontends > to our virt-viewer codebase - remote-viewer & virt-viewer - so adding > a 3rd - virt-control wouldn't be the end of the world, assuming we > still shared that 95% of the code. Ok... at the same time, before going down this path, I would try to implement some of these features in the virt-manager console viewer. From what I heard in the latest e-mails on this thread, it seems that everybody agrees that, although these features might not fit well on virt-viewer, they are kind of already available or should fit in virt-manager. So, before creating a 3rd frontend for virt-viewer, I am going to try to fit my requirements on virt-manager console viewer. I think this option would be less intrusive and might be simpler. Best regards, Leonardo Garcia > > > Regards, > Daniel </body> </html>