* Daniel P. Berrange (berra...@redhat.com) wrote:
> On Mon, Jan 05, 2015 at 12:37:23PM +0000, Dr. David Alan Gilbert wrote:
> > * Daniel P. Berrange (berra...@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 / dgilb...@redhat.com / Manchester, UK
