Re: [Qemu-devel] KVM call agenda for Tuesday 28th

[Stefan Hajnoczi]

On Mon, Feb 27, 2012 at 10:06 PM, Anthony Liguori <address@hidden> wrote:
> On 02/27/2012 03:58 PM, Paolo Bonzini wrote:
>>
>> Il 27/02/2012 18:21, Eric Blake ha scritto:
>>>>>
>>>>> Please send in any agenda items you are interested in covering.
>>>
>>> Given all the threads on snapshot/mirror/migrate/reopen in the blockdev
>>> layer, that sounds like a worthwhile topic to discuss on a phone call.
>>
>>
>> I put a description of the existing proposals here:
>>
>> http://wiki.qemu.org/Features/SnapshotsMultipleDevices/CommandSetProposals
>
>
> Thanks!  One thing I'm having trouble following on your proposal: What
> commands are valid within
> blockdev-start-transaction/blockdev-commit-transaction?
>
> If I do:
>
> blockdev-start-transaction
> stop
> drive-reopen
> drive-mirror
> blockdev-end-transaction
>
> What state should I expect that my guest is in (paused or running)?

I'm not a fan of transactions or freeze/thaw (if used to atomically
perform other commands).

We should not export low-level block device operations so that
external software can micromanage via QMP.  I don't think this is a
good idea because it takes the block device offline and possibly
blocks the VM.  We're reaching a level comparable to an HTTP interface
for acquiring pthread mutex, doing some operations, and then another
HTTP request to unlock it.  This is micromanagement it will create
more problems because we will have to support lots of little API
functions.

I think we're only exposing low level operations because:
1. We haven't designed a block model that works.
2. Therefore, upper layers of the management stack have felt forced to
implement these operations on our behalf.  They want a micromanagement
interface in order to do that.

What we should really do is design the block device model for QEMU:

* What responsibilities does QEMU have for handling image files?  We
seem to go back and forth between file descriptor passing for security
and reopening images while QEMU is running.

* What user-visible operations does it need to support (snapshotting
groups of images, eject/insert media, hotplug disk, etc)?

We can look at existing hypervisors and virtualization APIs as inspiration.

Let's provide high-level commands via QMP and let's do it with -blockdev.

Or if we decide that QEMU shouldn't be in the business of doing these
operations then we need to radically simplify to a model that just
passes file descriptors and freezes/thaws I/O but doesn't do any of
the high-level operations at all.  Right now we have a half-way house
and adding more snapshot/transaction APIs isn't the answer.

Stefan