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