[libvirt] [RFC] Overriding graphics relocation URI
Michal Skrivanek
michal.skrivanek at redhat.com
Fri Jan 11 11:37:25 UTC 2013
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 :|
More information about the libvir-list
mailing list