[et-mgmt-tools] multiple connections in virt-manager first draft now on tip

[Daniel P. Berrange]

On Tue, Aug 14, 2007 at 12:43:59PM -0400, Hugh Brock wrote:
> Hi all.
> 
> I have just committed the first cut at a UI for handling multiple 
> connections from a single manager window in virt-manager. Opening a new 
> connection with File->Open Connection... will now display that 
> connection and its guests (if any) in a tree layout in the manager 
> window. The "new" button is gone, in favor of a right-click option for 
> creating guests for a particular connection. If you click the 
> expand/collapse arrow to collapse a connection, virt-manager will avoid 
> polling that connection for resource updates until you expand the arrow 
> again (handy for avoiding excessive network traffic in the remote 
> connection case).
> 
> Things that still need to be dealt with:
> 
> 1. I have temporarily disabled restoring guests from the UI. It's 
> necessary to specify a connection when restoring a guest, and this 
> brings up issues around how to choose that connection and the whole 
> guest checkpointing question.

Ultimately I think the save/restore stuff needs to be re-thought, perhaps
with extra APIs at the libvirt layer. The current stuff is what I term
'unmanaged save/restore' - ie once you save it the image, libvirt  (or the
underlying tools like XenD) have no tracking of the saved VM. As of Xen
3.1, or QEMU 0.9 there is a concept of 'managed save/restore' (and even
checkpoints) where the save images are permanently associated with the 
VM. So for an inactive VM, you can list available saved images, and pick
one to restore to. This would work quite nicely in the virt-manager UI,
since we'd just see the inactive VM and when starting, one could let the
user start it from scratch, or pick a saved image to start from.

> 2. There should really be a little "new" or "create" button on each 
> connection line along with the right-click menu.

Definitely add it to the right-click menu. We should try having it inline
too just to see whether it works as a UI concept. I'm in half a mind to
say that we should kill the row of buttons along the bottom of the main
window completely. Double-clicking lets you easily display the console
window, and from there you can view details. It might even make sense to
put the console & details into one  window - just as separate tabs.

> 3. We should store connection info in gconf rather than having them 
> vanish on disconnection. This way when you start virt-manager all your 
> connections would come up inactive, and actually connect only when you 
> activate them.

Yes, that'd work nicely. Future ideas also include having the libvirt
daemon advertise itself using Ahavi, so virt-manager could browse for
virt capable hosts on the LAN.

> 4. Creating a new guest still works only on local connections. Guest 
> creation for remote connections depends on resource discovery which we 
> still haven't worked out yet.

Tested it very quickly and it seemed to work in a couple of cases - good
stuff !

Regards,
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|