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