[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 9/9] block-migration: add named dirty bitmaps mi
From: |
Paolo Bonzini |
Subject: |
Re: [Qemu-devel] [PATCH 9/9] block-migration: add named dirty bitmaps migration |
Date: |
Thu, 08 Jan 2015 23:49:28 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 08/01/2015 23:45, Eric Blake wrote:
>>> The bitmaps are transmitted many times in their entirety, but
>>> only the last copy actually means something. The others are
>>> lost. This means you should use the non-live interface
>>> (register_savevm). This will simplify the code a lot.
> If I understand correctly, you are saying that:
>
> block migration vs. assuming shared storage during migration
>
> is independent from:
>
> current behavior of resetting dirty tracking on destination vs.
> new one-shot non-live dirty bitmap migration
>
> and that all four combinations are potentially useful.
Yes. For example, you could use drive-mirror to snoop writes to an
NBD destination (e.g. to a malware scanner or to a secondary machine
if you have fault tolerance). Then you need to migrate the dirty
bitmap even if you have shared storage.
> Also, by doing dirty bitmap migration as one-shot at the tail end
> of migration (in the small window when things are no longer live)
> you have a lot less effort, although the window of non-live
> activity is now a bit longer if the dirty table migration is not
> efficient.
As of this series, dirty bitmap migration is not attempting to track
the dirtiness of the dirty bitmap itself (you might have to read that
twice :)). So there's nothing to lose in terms of efficiency.
Paolo
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAEBAgAGBQJUrwlwAAoJEL/70l94x66DSN4H+gLqqkghOqdkPzduTmf1hzi1
pwLe/TGZv+gNNWu8G2hO2FfasMlmBxEOVtwODFcwGExvPnH2jv1N7/dplIwKqbLS
g9Hq5cI3UagxfFQts7fyBhjCxeUrHuaKfIvc/A1kfMMwesn8PPGFUGEXNqIs1NGc
I+3qTE5TlcOKWCfL+3zgLDUowvRACbTJngHfveOtoWscVz743yQxhH3NOKPu7jxR
8H5AC9TK7sr3azHrXFgMP53W2qHT0KHTUyLQem+iKagFLsxX6oyOEn0ueMooAndE
tzvw+5EiFj8MfAzPAdQWEPYwxQyDBy/oXQizQTCmAQku2TZIlWi+kStJ3K/qEaM=
=v5Gj
-----END PGP SIGNATURE-----