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