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: Anthony Liguori
Subject: Re: [Qemu-devel] Re: [patch 2/3] Add support for live block copy
Date: Wed, 23 Feb 2011 14:06:57 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.15) Gecko/20101027 Lightning/1.0b1 Thunderbird/3.0.10

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).

Regards,

Anthony Liguori

[...]





reply via email to

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