From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47128) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YGr4F-00059r-6Q for qemu-devel@nongnu.org; Thu, 29 Jan 2015 10:31:40 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YGr4E-0000BT-2g for qemu-devel@nongnu.org; Thu, 29 Jan 2015 10:31:39 -0500 Received: from mx1.redhat.com ([209.132.183.28]:33791) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YGr4D-0000BL-RK for qemu-devel@nongnu.org; Thu, 29 Jan 2015 10:31:38 -0500 Date: Thu, 29 Jan 2015 15:31:31 +0000 From: "Daniel P. Berrange" Message-ID: <20150129153131.GF1102@redhat.com> References: <1422543997-22808-1-git-send-email-dgilbert@redhat.com> <1422543997-22808-2-git-send-email-dgilbert@redhat.com> <20150129151527.GE1102@redhat.com> <20150129152255.GC2391@work-vm> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20150129152255.GC2391@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: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. 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 :|