From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52802) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YGrUW-0003yO-RN for qemu-devel@nongnu.org; Thu, 29 Jan 2015 10:58:50 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YGrUT-00025P-Kd for qemu-devel@nongnu.org; Thu, 29 Jan 2015 10:58:48 -0500 Received: from mx1.redhat.com ([209.132.183.28]:42694) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YGrUT-00025J-Di for qemu-devel@nongnu.org; Thu, 29 Jan 2015 10:58:45 -0500 Date: Thu, 29 Jan 2015 15:58:40 +0000 From: "Daniel P. Berrange" Message-ID: <20150129155839.GH1102@redhat.com> References: <20150129154634.GD2391@work-vm> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20150129154634.GD2391@work-vm> Subject: Re: [Qemu-devel] [RFC 1/1] Execute arbitrary QMP commands from command line Reply-To: "Daniel P. Berrange" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Dr. David Alan Gilbert" Cc: amit.shah@redhat.com, liang.z.li@intel.com, qemu-devel@nongnu.org, quintela@redhat.com On Thu, Jan 29, 2015 at 03:46:35PM +0000, Dr. David Alan Gilbert wrote: > * Daniel P. Berrange (berrange@redhat.com) wrote: > > On Thu, Jan 29, 2015 at 03:22:55PM +0000, Dr. David Alan Gilbert wrote: > > > * Daniel P. Berrange (berrange@redhat.com) wrote: > > > > On Thu, Jan 29, 2015 at 03:06:37PM +0000, Dr. David Alan Gilbert (git) wrote: > > > > > From: "Dr. David Alan Gilbert" > > > > > > > > > > For an incoming migration it's potentially useful to be able to set > > > > > capabilities and parameters prior to opening the connection, while > > > > > a separate option for that would have been possible it seems better > > > > > to give access to all the existing migration capabilities, parameters > > > > > etc. The least restrictive way of doing this is to allow arbitrary > > > > > QMP commands to be executed prior to the -incoming being processed. > > > > > > > > > > As an example: > > > > > > > > > > ./bin/qemu-system-x86_64 -nographic -nodefaults -qmp-command '{"execute": "migrate-set-capabilities", "arguments":{"capabilities":[{"capability":"xbzrle","state":true}]}}' -qmp-command '{"execute": "query-migrate-capabilities"}' -incoming tcp::444 > > > > > > > > I'm unclear how we'd easily deal with the response from commands > > > > invoked this way, to get replies and/or errors. Also, it might > > > > be the case that we need to conditionally run certain commands > > > > depending on the result of earlier commands. > > > > > > > > Wouldn't it make more sense to simply add a 'migrate_incoming' QMP > > > > command, and stop using -incoming altogether, so we just have normal > > > > QMP access ? > > > > > > > > eg, > > > > > > > > # qemu-system-x86_64 ....device args... -S > > > > (qmp) ....arbitrary QMP commands .. > > > > (qmp) {"execute":"migrate-incoming", "arguments": { "uri": "tcp::44" }} > > > > > > I'm a bit worried about whether starting an incoming migrate afterwards is > > > different in any subtle way. I can see there are a handful of devices that > > > have 'runstate_check(RUN_STATE_INMIGRATE)' calls in, and thus I'm not sure > > > that starting a paused VM and then flipping to RUN_STATE_INMIGRATE would > > > be quite the same. > > > > > > Having said that, we do have 'loadvm' that's similar to an incoming migration. > > > > Yep, existance of 'loadvm' does give confidence that this should work with > > migration, hopefully only needing a few cleanups for the state check you > > mention above. > > Hmm I'm not sure; I've had a dig and the tests for INMIGRATE do a lot of random > things; qxl, usb, and blockdev for starters, and the block stuff sets a flag > that is then passed to qcow and other backends that do stuff all over with it. > > Howver, something like: > > -incoming pause > > followed by the monitor command later should work - how do you feel > about that? That's workable from the libvirt POV. We'll probe the existance of the 'migrate-incoming' QMP command when getting capabilities, so we'll know upfront that we can use the "-incoming pause" approach. 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 :|