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

[Hans de Goede]

Hi,

To throw my 2 cents into this discussion:

On 01/18/2013 06:27 PM, lagarcia at linux.vnet.ibm.com wrote:
> From: Leonardo Garcia <lagarcia at br.ibm.com>
>
> On 01/07/2013 08:42 PM, Daniel P. Berrange wrote:
>> On Mon, Jan 07, 2013 at 05:52:54PM -0200, lagarcia at linux.vnet.ibm.com wrote:
>>> From: Leonardo Garcia <lagarcia at br.ibm.com>
>>>
>>> This menu would hold entries related to the connected guest life-cycle management:
>>>   - Restart
>>>   - Shutdown
>>>   - Forced Shutdown
>>>   - Redefine Hardware Settings
>>>   - etc.
>>>
>>> The inclusion of these new actions in virt-viewer would allow an end-user to be
>>> able to have some control over the running VM without the need of opening
>>> virt-manager or other management tools. This is specially useful in
>>> environments in which the end-user is not using a management tool to start the
>>> VMs, but, instead, have a direct link setup to connect to a local or remote VM
>>> in his/her desktop.
>>
>> I don't really think this is somewhere that I want virt-viewer to go.
>> I really view virt-viewer as a minimal application for interacting with
>> the guest. In particular the intent is that the user of virt-viewer
>> should not need to have administrative privileges to libvirtd, which
>> your suggested menu options would require.
>
> Ok, I understand your point.
>
>> IMHO the use case you're describing really is one for virt-manager to
>> have. There is no requirement that virt-manager display its main manager
>> window - it has a command line flag to make it immediately display the
>> GUI console of a single VM, which pretty much provides the functionality
>> you describe.
>
> 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.
>
> 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).
>
> 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.
>
> 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.
>

I think having the above 4 make sense, esp. since 1-3 are things which can be
triggered from inside the guest using guest specific menus too, so we're just
adding a more convenient way to do this, not adding new options.


But everything below to me clearly belongs in the realm of a management tool,
not virt-viewer.

> 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.
>
> 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.
>
> 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.

As said all management tool things.


> 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.

??? This is already supported in virt-viewer in combination with using spice
as display protocol and works exactly as you describe.

> Use case #9 is currently implemented only in virt-viewer.

Ah, right, that is something which we ought to fix, is that why point 9 is
on your list ?

> Use cases #6, #7, and #8 are currently not implemented in any tools.

We are working an a virt-viewer ini-like vm-connection description
format, whereby you can create a simple text file with some
connection-details + settings in there, and a file-association
to this new file-format and then double-clicking such a file will
open virt-viewer and connect to the specified vm.

Regards,

Hans