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

[Cole Robinson]

On 05/31/2013 08:34 AM, Leonardo Augusto Guimarães Garcia wrote:
> 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).

Yes, snapshot support is something that's definitely missing. It's always on
my todo list but never quite makes it to the top. It's made extra difficult by
the fact that there are 2 types of snapshots (internal and external) and they
both slightly different semantics. Internal snapshots are the simplest and
most end user friendly but their use has been discouraged by some qemu
maintainers. External snapshots at last look were still missing some libvirt
support to make them fully useful to end users, but that may be better nowadays.

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

Yeah that was just a thought, not a hard requirement.

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

It's a common pattern with graphical tools and something we've always done in
virt-manager. It probably creates incoherent debug logs which is fairly minor,
but it might have other side effects. We could work around it by reviving the
dbus interface, which would allow a cli invocation to open a VM window in an
already running virt-manager.

- Cole