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

[Leonardo Augusto Guimarães Garcia]

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
>