[virt-tools-list] [virt-viewer][PATCH 0/6] Create actions menu

Wed Feb 6 18:34:13 UTC 2013

Sorry for the bad formatting in previous e-mail... Resending now.

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, lagarcia at linux.vnet.ibm.com 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 do 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