From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59476) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y88XK-0001go-Ip for qemu-devel@nongnu.org; Mon, 05 Jan 2015 09:21:42 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y88XG-0005bN-OV for qemu-devel@nongnu.org; Mon, 05 Jan 2015 09:21:38 -0500 Received: from mx1.redhat.com ([209.132.183.28]:52161) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y88XG-0005am-Gj for qemu-devel@nongnu.org; Mon, 05 Jan 2015 09:21:34 -0500 Date: Mon, 5 Jan 2015 14:21:25 +0000 From: "Dr. David Alan Gilbert" Message-ID: <20150105142124.GH5244@work-vm> References: <20150105121424.GF5244@work-vm> <20150105122930.GK29381@redhat.com> <20150105123723.GG5244@work-vm> <20150105124559.GM29381@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150105124559.GM29381@redhat.com> Subject: Re: [Qemu-devel] More structured migration URIs? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: amit.shah@redhat.com, david@gibson.dropbear.id.au, qemu-devel@nongnu.org, quintela@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