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

["Dr. David Alan Gilbert" <dgilbert@redhat.com>]

* Daniel P. Berrange (berrange@redhat.com) wrote:
> On Mon, Jan 05, 2015 at 12:37:23PM +0000, Dr. David Alan Gilbert wrote:
> > * Daniel P. Berrange (berrange@redhat.com) 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.
> 
> True, the QMP command would need to support a union of different options
> switched depending on the protocol type. Not sure if QMP can do that or
> not ?
> 
> > > 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?
> 
> Historically the use of -incoming would block use of the monitor commands
> while the migration data was being loaded, but I'm not sure if that is
> still the case. Libvirt has a had long time desire to be able to query
> the 'info migration' on the target side to be able to report on progress
> reading the migration data stream. Last time we discussed this all someone
> mentioned that perhaps a long time option is switch to replace the use of
> the '-incoming' arg, with a 'migrate-incoming' QMP command. I don't know
> if that's practical or not.

I've just checked, and qmp seems to be happy with -incoming  and we see:

{ "execute": "query-status" }
{"return": {"status": "inmigrate", "singlestep": false, "running": false}}

> Back to your question though, libvirt's handling of the URIs for the
> -incoming side is completely separate from handling of URIs for the
> outgoing side. So I've not objection to changes to the -incoming arg
> syntax as that's completely isolated from applications/users.

OK, thanks, I'll have a think about it.

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 / dgilbert@redhat.com / Manchester, UK