[libvirt] [RFC] Overriding graphics relocation URI

[Michal Skrivanek]

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