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

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@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 > How would a user define a custom URI?