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

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@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? > 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