On Thu, Jan 10, 2013 at 12:41:50PM +0100, Jiri Denemark wrote: > Hi all. > > Graphics relocation URI is currently transmitted within migration cookie > in the form of graphics type, address, port, tlsPort, and certificate > subject. The cookie is generated by target libvirtd and consumed by > source libvirtd which than forwards this data through QEMU to the > graphics client. > > In case the target libvirtd is not able to provide the data in a way > usable by the client (e.g., because it needs to use different address), > we need to provide a way to override the graphics URI. We already > support similar thing for migration URI. > > So the question is how we can support $SUBJ? The only way I came up with > is to introduce another set of migration APIs (such as > virDomainMigrateToURI3, ...) with an additional graphics URI parameter. > The URI would be formed as > > type "://" address ":" port "?tlsPort=" tlsPort "&subject=" cert > > with various parts being optional. That would allow us to override any > part of the graphics cookie we need.
One thing to bear in mind is that we can now configure VNC and SPICE at the same time. Although VNC doesn't currently have client redirect, in theory we could add that - I've considered creating a VNC extension for this. > However, I don't like the addition of another set of migration APIs and > I'd be glad to hear better ideas :-) Nor do I, but I'm so far lacking better ideas. If we do add another API, we should do a clean slate API design that is more extensible so we don't have to keep doing this ! Perhaps a virDomainMigrateParams struct that is opaque & extensible. Actually one other idea I have is to include something in the domain XML. Currently we provide a listen address in the XML. Perhaps we should also be providing a public connect address in the XML too. This could actually make life better for apps like virt-viewer/virt-manager, because currently they have nasty heuristics to figure out what address to connect too based on the libvirt URI, XML listen address & guesswork Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
