Avi Kivity <a...@redhat.com> writes: > 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.
Exactly. And qdev has brought his within our reach. [...]
