On 02/23/2011 04:35 PM, Anthony Liguori wrote:
On 02/23/2011 07:01 AM, Avi Kivity wrote:
On 02/23/2011 01:14 AM, Anthony Liguori wrote:
-drive already ties into the qemuopts infrastructure and we have
readconfig and writeconfig. I don't think we're missing any major
pieces to do this in a more proper fashion.
The problem with qemu config files is that it splits the
authoritative source of where images are stored into two. Is it in
the management tool's database or is it in qemu's config file?
I like to use the phrase "stateful config file". To me, it's just a
database for QEMU to persist data about the VM. It's the only way for
QEMU to make certain transactions atomic in the face of QEMU crashing.
The user visible config file is a totally different concept. A
management tool launches QEMU and tells it where to keep it's state
database. The management application may prepopulate the state
database or it may just use an empty file.
In that case the word 'config' is misleading. To me, it implies that
the user configures something, and qemu reads it, not something mostly
internal to qemu.
Qemu does keep state. Currently only images, but in theory also the
on-board NVRAM.
QEMU uses the state database to store information that is created
dynamically. For instance, devices added through device_add. A
device added via -device wouldn't necessary get added to the state
database.
Practically speaking, it let's you invoke QEMU with a fixed command
line, while still using the monitor to make changes that would
otherwise require the command line being updated.
Then the invoker quickly loses track of what the actual state is. It
can't just remember which commands it issued (presumably in response to
the user updating user visible state). It has to parse the stateful
config file qemu outputs. But at which points should it parse it?
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.
For the problem at hand, one solution is to make qemu stop after the
copy, and then management can issue an additional command to
rearrange the disk and resume the guest. A drawback here is that if
management dies, the guest is stopped until it restarts. We also
make management latency guest visible, even if it doesn't die at an
inconvenient place.
An alternative approach is to have the copy be performed by a new
layered block format driver:
- create a new image, type = live-copy, containing three pieces of
information
- source image
- destination image
- copy state (initially nothing is copied)
- tell qemu switch to the new image
- qemu starts copying, updates copy state as needed
- copy finishes, event is emitted; reads and writes still serviced
- management receives event, switches qemu to destination image
- management removes live-copy image
If management dies while this is happening, it can simply query the
state of the copy. Similarly, if qemu dies, the copy state is
persistent (could be 0/1 or real range of blocks).
This is a more elegant solution to the problem than the commit problem
but it's also a one-off. I think we have a generic problem here and
we ought to try to solve it generically (within reason).
Can you give more examples?
I think I demonstrated that hot-plug can be solved via the existing
interfaces.
--
error compiling committee.c: too many arguments to function
