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
