[Libvir] Re: [PATCH 1/2] virDomainMigrate implementation (Xen only, no remote, no qemu, no virsh)
Anthony Liguori
anthony at codemonkey.ws
Mon Jul 16 18:14:32 UTC 2007
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 don't think it's really a bad thing. I think if someone is writing
pretty straight forward code that does something like migrate a VM from
one host to another, then that code ought to be portable between
hypervisors with no effort.
However, if they are doing something more sophisticated like using a
custom migration transport and interacting with KVM through libvirt,
then yes, it's hypervisor dependent. I don't really see this as a
problem though.
Regards,
Anthony Liguori
> Another choice might be to go back to the list of parameters again,
> and have configurable VIR_MIGRATE_TRANSPORT, VIR_MIGRATE_USERNAME and
> so on...
>
> Rich.
>
More information about the libvir-list
mailing list