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@xxxxxxxxxxxxxxxxxx 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
_______________________________________________
virt-tools-list mailing list
virt-tools-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/virt-tools-list
