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

[Daniel P. Berrange]

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
-- 
|=- 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  -=|