qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC 1/1] Execute arbitrary QMP commands from command l


From: Dr. David Alan Gilbert
Subject: Re: [Qemu-devel] [RFC 1/1] Execute arbitrary QMP commands from command line
Date: Thu, 29 Jan 2015 15:22:55 +0000
User-agent: Mutt/1.5.23 (2014-03-12)

* Daniel P. Berrange (address@hidden) wrote:
> On Thu, Jan 29, 2015 at 03:06:37PM +0000, Dr. David Alan Gilbert (git) wrote:
> > From: "Dr. David Alan Gilbert" <address@hidden>
> > 
> > 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.

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 / address@hidden / Manchester, UK



reply via email to

[Prev in Thread] Current Thread [Next in Thread]