[Libvir] Re: [PATCH 1/2] virDomainMigrate implementation (Xen only, no remote, no qemu, no virsh)

[Daniel P. Berrange]

On Mon, Jul 16, 2007 at 06:34:57PM +0100, Richard W.M. Jones wrote:
> Daniel P. Berrange wrote:
> >On Mon, Jul 16, 2007 at 11:30:33AM -0500, Anthony Liguori wrote:
> >>Richard W.M. Jones wrote:
> >>>Anthony Liguori wrote:
> >>>>For instance, let's say at a university they use an ldap directory to 
> >>>>authenticate users and they decide to implement a migration handler 
> >>>>that uses that for authentication.  They may name this "uni://" and 
> >>>>it'll just work.  How would they get at this in libvirt without 
> >>>>exposing URIs directly?
> >>>My latest proposal[1] has a transport parameter (a string) which 
> >>>covers this, in as much as it would allow you to construct URIs which 
> >>>are:
> >>>
> >>> <transport>://<hostname>:<port>
> >>SSH requires:
> >>
> >>ssh://[user@]hostname[:port]
> >>
> >>So that wouldn't work :-(
> >
> >Sure it would - rich was just showing simplified syntax - the URI 
> >rules/spec allow for a username and we already use this syntax with a 
> >username in the remote driver URIs. eg
> >
> >  $ virsh --connect qemu+ssh://root@celery.virt.boston.redhat.com/system 
> >  list --all
> 
> Anthony is right that my revised proposal limits the migration to just 
> three parameters: transport, hostname and port.
> 
> https://www.redhat.com/archives/libvir-list/2007-July/msg00227.html
> 
> Perhaps instead we should replace hostname with a URI parameter, 
> understood as either a simple hostname, IP address, a "hostname:port" 
> string [IPv6?], or a full URI.  However I feel inevitably this is going 
> to cause hypervisor dependencies to come into libvirt code, which should 
> be avoidable.

I think we can expose URIs without directly making the libvirt API hypervisor
specific. Even though Anthony is talking with respect to QEMU/KVM there, 
the concepts is reasonably applicable to Xen too - there's no reason XenD
could not be enhanced to support migration over a user-defined transport.

So, when thinking about URIs for migration we could consider that there are
2 classes of URI

 - Pre-defined 'standard' URIs - TCP, TCP with SSL/TLS, and SSH being the
   most obvious - we can easily define clear & portable semantics for these
   URIs

 - User-define 'custom' URIs - these are really site/deployment specific,
   rather than hypervisor specific. ie, if someone implemented a way to deal
   with foo://bar/, they could provide impls for both Xen & QEMU

We should be able to guarentee that 'standard' URIs work forever, while for
custom URIs we can allow them to be passed through, and not provide any
guarentees about their behaviour/usage  - in particular make no guarentees
that a future libvirt won't define more 'standard' URI schemes which could
potentially clash with use-define custom schemes.

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|