-----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-----
