qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Re: [patch 2/3] Add support for live block copy


From: Markus Armbruster
Subject: Re: [Qemu-devel] Re: [patch 2/3] Add support for live block copy
Date: Thu, 24 Feb 2011 13:15:41 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)

Anthony Liguori <address@hidden> writes:

> On 02/23/2011 11:26 AM, Markus Armbruster wrote:
>>> I don't think it's reasonable to have three different ways to interact
>>> with qemu, all needed: the command line, reading and writing the
>>> stateful config file, and the monitor.  I'd rather push for starting
>>> qemu with a blank guest and assembling (cold-plugging) all the
>>> hardware via the monitor before starting the guest.
>>>      
>> Exactly.  And qdev has brought his within our reach.
>>    
>
> Actually, QMP is the star of the show here, not qdev.
>
> The way we get here is by incrementally converting the option handling
> to be qmp calls.  For instance, instead of:
>
> case QEMU_OPTION_name:
>       qemu_name = optarg;
>       break;
>
> We do:
>
> case QEMU_OPTION_name:
>        qmp_set_name(optarg, NULL);
>        break;
>
> When we can compile vl.c with nothing more than QMP dependencies,
> we've achieved the goals here.  This will mean adding a lot of new QMP
> commands.
>
> There are some command line options that must be handled before the
> machine is initialized and QMP is normally run.  For 0.16, we can
> introduce a new QMP mode whereas the event loop gets to run before
> doing machine init and explicit create_machine() command is needed.
> This is the final bit that will be needed to realize this goal.
>
> A lot of good things come out of this.  Quite a lot of these new
> commands don't strictly need to run before machine init (like -name)
> which means we'll get the ability to change a lot of parameters
> without rebooting the guest which couldn't be changed before.
>
> And this is all incremental stuff that can be done in parallel of the
> QAPI work.  We just need to do the work of adding the function calls
> (or function call wrappers where appropriate).

Well, I wouldn't put "let's create a sane separation between option
parsing and machine configuration" under the "QEMU *Monitor* Protocol"
flag, but I certainly don't mind you hoisting whatever flag pleases you.



reply via email to

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