[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Restoring bitmaps after failed/cancelled migration

From: Vladimir Sementsov-Ogievskiy
Subject: Re: [Qemu-devel] Restoring bitmaps after failed/cancelled migration
Date: Mon, 14 May 2018 13:09:24 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0

14.05.2018 09:41, Fam Zheng wrote:
On Wed, 04/18 17:00, Vladimir Sementsov-Ogievskiy wrote:
Hi all.

We now have the following problem:

If dirty-bitmaps migration capability is enabled, persistance flag is
dropped for all migrated bitmaps, to prevent their storing to the storage on
Why do we prevent source storing persistent bitmaps by clearing the flag instead
of making the bitmap code more BDRV_O_INACTIVE-aware, so it is _not_ stored
when/after inactivation?

Bitmaps are stored exactly on inactivation. So, we need some
flag, that on following inactivation, we don't want to save them. And this flag
is .persistent flag.

Of course, we can't save them if BDRV_O_INACTIVE is already set

It works ok, persistence itself is migrated through the
migration channel. But on source, bitmaps becomes not persistent, so if we,
for some reasons, want to continue using source vm, we'll lose bitmaps on

It's simple to fix it: just make bitmaps persistent again on invalidate
[1].. But I have some questions.

1. What are possible cases? I think about the following:

a. migration cancel or fail, then invalidate
b. migration success, then qmp cont => invalidate
Is this "cont" on the source even though dst is already up? How will this work?
Isn't it expected that dst is using the image?

Dr. David described this case, look at his answer.

c. migration success, then stop/start (there was no invalidate, so [1] will
not work)

2. Is it safe at all, saving bitmaps after inactivate, even without
This is not safe. No I/O should be done to the image after inactivation.

Inactive disk implies, that it may be changed by somebody other, isn't it?

Is it possible, that target will change the disk, and then we return control
to the source? In this case bitmaps will be invalid. So, should not we drop
all the bitmaps on inactivate?
Yes, dropping all live bitmaps upon inactivate sounds reasonable. If the dst
fails to start, and we want to resume VM at src, we could (optionally?) reload
the persistent bitmaps, I guess.

Reload from where? We didn't store them.

So, you agree, that dropping all bitmaps after inactivation is good idea.. The second question, is it possible to not drop them? Is there a way, to check that disk was not changed after pair of inactivate-invalidate? I have an idea: we can create small-bitmap, which will not migrate through migration channel, but remain persistent. It will be very small (big granularity, to not increase downtime of migration), so after invalidate we can check this bitmap. If it is empty, we are happy, we can "activate" all our bitmaps and make them persistent again. If not, we have two ways:

1. drop all bitmaps
2. merge small-bitmap to all our bitmaps

Best regards,

Best regards,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]