Re: [Qemu-devel] More structured migration URIs?

[Dr. David Alan Gilbert]

* Daniel P. Berrange (address@hidden) wrote:
> On Mon, Jan 05, 2015 at 12:14:25PM +0000, Dr. David Alan Gilbert wrote:
> > Hi,
> >   I keep thinking of things where it might make sense to add
> > options onto the migration URIs and wondered if it makes
> > sense to restructure the migration URIs; my proposal would be:
> > 
> >   a) Restructure tcp:hhhh:pppp into   protocol=tcp,host=hhhh,port=pppp
> >   b) Have a requirement that protocol= is the first entry in the list
> >   c) If it doesn't start protocol= then it's the old format.
> >   d) This would also change in the 'migrate' command to keep it symmetric
> > 
> > Eric/Daniel does this make sense for libvirt?
> > 
> > My current set of things I might want to add are:
> >   1) A flag saying if a return channel is needed
> >      For sockets qemu can open this afterwards when needed, but Dave 
> > Gibson's
> >      review of my postcopy world pointed out that it might not be that
> >      easy for all protocols to open the reverse later.
> >   2) Flags for opening multiple sockets/FDs - e.g. to pass the pages down
> >      a separate fd.
> > 
> > Thoughts?
> 
> The QEMU migration URI is exposed via the libvirt API to applications, so
> they can control the host/port of the target explicitly (to override
> libvirt's default guess of a suitable host/port).

Ah OK, that's a shame.

> These extra things that you suggest adding are not things we neccessarily
> want to expose to applications. So if QEMU changed the format, libvirt
> would probably not accept this new format from applications - we would
> force applications to always use the URI syntax and only allow host+port
> to be specified. Internally libvirt would translate that to the new
> key/value pair format, and add the extra flags / options as needed. We
> would possibly add some options to our public API to configure extra
> features as desired, separately from the URI.

It all gets a bit more complicated when an application could specify
an arbitrary exec: uri through that API, rather than you knowing what it's
doing.

> More generally though, what is the advantage of encoding new things in
> the migration URI, as opposed to adding new parameters to the QMP
> migration command. The use of URIs in this scenario is really a hang
> over from days of HMP. If we were designing the migration command today
> I don't think we'd use URIs at all - we'd just have a QMP command with
> explicit parameters for the hostname, the port number and anything else
> we might want to set.  So if there are new features I'd be inclined to
> just add more optional parameters to the QMP migration command and not
> touch the URI format at all.

I was only interested in adding options to the -incoming side rather than the
'migrate' side, but thought if I was changing the URI syntax I may as well
make it consistent.   If you wanted to add options to the -incoming side
what would be easiest for you?

Dave

> 
> Regards,
> Daniel
> -- 
> |: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
> |: http://libvirt.org              -o-             http://virt-manager.org :|
> |: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
> |: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK