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

[Anthony Liguori <anthony codemonkey ws>]

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.