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

[Doug Goldstein]

On Sat, Jan 19, 2013 at 3:04 AM, Hans de Goede <hdegoede at redhat.com> wrote:
> 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.
>

I'll agree with you for users that would have sudo/root privileges
inside of the guest, but users that have access limited accounts
inside the guest this would very clearly open up more access than they
have in the guest and would need to be correctly managed via ACLs,
which is something that hasn't landed in libvirt yet.

-- 
Doug Goldstein