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

Regards,

Anthony Liguori

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