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

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.