qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC 0/1] Incoming migration vs early monitor commands


From: Eric Blake
Subject: Re: [Qemu-devel] [RFC 0/1] Incoming migration vs early monitor commands
Date: Thu, 29 Jan 2015 08:25:36 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0

On 01/29/2015 08:06 AM, Dr. David Alan Gilbert (git) wrote:
> From: "Dr. David Alan Gilbert" <address@hidden>
> 
> The attached patch allows you to execute QMP commands from the command
> line prior to -incoming or loadvm.
> 
> I've hit a few cases where we need to pass some state to an incoming
> migration, either:
>   1) Before it starts processing data
>     e.g. Liang Li's compression patches that have a parameter for the
>     number of decompression threads
> 
>   2) Before the socket is set up
>     so we can influence the connection made; e.g. specify we need to
>     have a return path for postcopy, or potentially open multiple connections
> 
> For tcp migration you can use the monitor for (1) prior to the accept;
> but it's no use for exec or fd.
> 
> I'd previously suggested adding option parsing to the -incoming URI;

That may still be feasible; we have QemuOpts for that purpose.

> but
> then I realised just being able to execute arbitrary QMP commands might
> be simpler, and we get reuse of all the migrate capability/parameter
> stuff for free, and maybe the arbitrary QMP commands are useful for
> something else.

It feels like command-line QMP would be write-only - there's no sane way
to issue query commands and react to what was queried.  The full power
of QMP is made possible with a bidirectional path, but the command line
is not bidirectional.  This hack may have uses, but I'm not sure it is
my first choice for any situation.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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