Re: [Qemu-devel] [PATCH v2 1/1] Add QMP bits for blockdev-snapshot-sync.

[Anthony Liguori]

On 04/29/2011 08:38 AM, Jes Sorensen wrote:
> On 04/28/11 17:10, Anthony Liguori wrote:
> > No, the command does too many things and as such, makes it impossible
> > for a management tool to gracefully recover.
>
> It is exactly the same for the management tool:
> - Creation of the new image either succeeds or fails
> - Switchover either succeeds or fails


Creating an image can be treated as an atomic operation.  It either 
fully succeeds or you assume it failed and throw the image away since 
you can always try again.

When you combine creating an image with another operation, you create a 
a single operation that cannot be treated as atomic which makes recovery 
from failure much more difficult.

> > But the new image is always valid once it's been created as pending
> > writes are lost no matter what in a hard power failure.  That suggests
> > the following flow:
> >
> > 1) Create new image with a backing file
> > 2) Completion ACK
> >
> > At this stage, the management tool should update it's internal state to
> > point to the new image.
>
> This can still be done with the existing code - it's not the ideal
> setup, but it is possible due to evil things such as selinux labeling


I don't follow.


> > 3) Begin switch over to new image
> > 4) Switch over image.
> > 5) Receive notification when it's complete
>
> Sorry but this isn't an accurate description of the process. Once you
> have a new image ready, you need to halt writes, flush buffers, and then
> you can do the switch, which has to be atomic.


You need to queue writes, you can still let the guest run while the 
remaining writes are sent to disk.

But if this is a background task, then as a management tool, don't I 
want a notification when it's been completed?

Don't I want to have a little spinning box in my GUI or something like 
that while this is happening?

> > If (4) is happening asynchronously, things get kind of complicated.  You
> > can either wait for things to quiesce on their own or you can queue
> > pending requests.  It's unclear to me what the right strategy is or if
> > there's a mixed strategy that's needed.  I think it makes sense to treat
> > 3/4 as a command with (5) being an event notification.
>
> The actual guest application freeze (what some strange people use the
> quiicannotspell word for) is done prior to the switchover, you cannot do
> it in parallel with it.


I'm not even talking about application quiescing here.  And yeah, I have 
to frequently google that word because Thunderbird doesn't have it in 
it's dictionary :-)

> > But combining 1-5 in a single interface creates a command that while
> > convenient on the command line, is not usable for a robust management tool.
>
> As I explained you can already use an externally created image with the
> current interface, the only issue that may be worth doing async is the
> buffer flushing. However once you do that, guest writes are going to
> stall anyway, and eventually the guest applications will all stall.

The interface shouldn't have the option to create an image... because if 
you have that, the interface is difficult to use.

Why present an option to do something that we know is broken?  We can't 
blame management tools for not doing a good job managing KVM if we're 
giving them poor interfaces to work with.

Regards,

Anthony Liguori

> The single command is both better from a consistency perspective, and it
> will do the right job. Things are not going to get any easier from the
> management tool's perspective than they are with the current interface.
>
> Cheers,
> Jes