[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



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.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]