On Mon, Jul 16, 2007 at 02:23:32PM -0500, Anthony Liguori wrote: > Daniel P. Berrange wrote: > >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@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx/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 > > > > How would a user define a custom URI? A good question, to which I don't have any answer :-) Could just say that any unrecognised URI is passed down to the underlying driver without libvirt applying any interpretation of its own. 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 -=| -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list