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

[Anthony Liguori]

Daniel P. Berrange wrote:
> 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. 
>   

I would like that :-)

Regards,

Anthony Liguori

> Dan
>