[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [virt-tools-list] [virt-manager][PATCH] Do not show manager window at startup if user requested to show any other window from command line.



On 05/30/2013 12:48 PM, Cole Robinson wrote:
On 05/29/2013 05:53 PM, Leonardo Augusto Guimarães Garcia wrote:
Hey,

It has been quite some time since I last touched this topic here, but I would
like to try to continue the discussion about providing something between
virt-viewer and virt-manager for end-users whose basic necessity is to have
access to the remote console but sometimes need to have some kind of control
over the virtual machine, even though he/she doesn't want to interact with any
other complexities related to the virtual machine management provided by
virt-manager.

My first approach was to make this changes in virt-viewer, which was NACK by
community. Suggestions were: create a third application in virt-viewer source
code besides virt-viewer and remove-viewer to accomplish what I was trying to
do or improve virt-manager to have the features I was looking for. I
definitely prefer the later, and that's what I am trying to acomplish with the
latest patch.

Although virt-manager has an option to start the console viewer (or any other
details window) upon start, the manager window is always started as well. What
I want is to avoid the manager window to be shown by default, so that a user
not interested in dealing with all the details of the manager window can use
the console view with a little bit more of control over the VM than is
provided in virt-viewer.

I agree that for something like this we should make virt-manager more
convenient to use, rather than go down the long path of creating a new app to
meet those needs. If you have any more suggestions I'm interested in hearing them.
I am looking for a console viewer application that can also provide a little bit of control over the running VM. The specific use cases I am interested in are:

1) Pause/Resume virtual machine
2) Restart virtual machine
3) Shutdown
4) Forced shutdown
5) Delete Virtual Client
6) Create shortcut on Desktop
7) Changes the console viewer exit routine to shutdown the guest when the
application is terminated.
8) Leave virtual machine running in the background
9) USB redirection functionality (currently available only in virt-viewer to the best of my knowledge)

A more detailed description of each use case can be found at [1].

With the patch you merged, I can now start virt-manager as a console viewer (so that an end-user will not have to deal with the manager window) and I already have use cases 1 to 4 above from the virt-manager console viewer.

I'll be now working on sending proposals for the other features on top of that. I might also be interested in some way to control snapshot images from virt-manager manager window (I think I read in this list others interested in that as well).

These CLI virt-manager options don't historically have much use, so I'd be
fine with changing their semantics a bit to be more like virt-viewer. So you
could do 'virt-manager --connect [URI] [NAME|UUID|ID]' and it will do the
right thing,
From my point of view, I am only interested in the console viewer. So I'd be fine to change the CLI options the way you suggested. However, I am not sure the other --show* options are not being used by anyone else. Hence, I am fine with the current implementation. I'll just change the man page to make it more clear that when a --show* option is used, the manager window will not be opened at application startup.
  but also disable connection autoconnect for other non-specified
connections,
I will work on that as well.
  not store the passed --connect value in gsettings,
Not sure if I agree with this one. I still view virt-manager as a good management tool for the scenarios it was designed for. If I want to start it once with a new connection in order to visualize a VM console, I might still be able to start virt-manager manager window afterwards and have access to this new connection.
  make it work
with launching multiple instances,
I agree with this one. Is there any requirement for having only one virt-manager instance running right now? Will there be any issues with configuration files if multiple instances are trying to access/change them at the same time?

Best regards,

Leonardo Garcia
  etc.

- Cole



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]