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

Wed Feb 6 16:15:58 UTC 2013

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/virt-tools-list/attachments/20130206/879c134e/attachment.htm>