On 11 Jan 2013, at 12:00, Daniel P. Berrange wrote: > 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 :-) In oVirt we just need an alternative IP to connect to. Providing the target libvirtd has an alternative IP configuration somewhere, in this particular case we could live with a new flag to choose one or the other IP. uglier, but doesn't need a new API, I guess? Thanks, michal > > 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@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list