On 01/17/2015 12:17 PM, Vladimir Sementsov-Ogievskiy wrote:
Best regards,
Vladimir
On 09.01.2015 01:05, John Snow wrote:
CCing migration maintainers, feedback otherwise in-line.
On 12/11/2014 09:17 AM, Vladimir Sementsov-Ogievskiy wrote:
Just migrate parts of dirty bitmaps, corresponding
Best regards,
Vladimir
On 09.01.2015 01:05, John Snow wrote:
CCing migration maintainers, feedback otherwise in-line.
On 12/11/2014 09:17 AM, Vladimir Sementsov-Ogievskiy wrote:
Just migrate parts of dirty bitmaps, corresponding to the block being
migrated. Also, skip block migration if it
On 12.01.2015 17:42, Paolo Bonzini wrote:
On 12/01/2015 15:20, Vladimir Sementsov-Ogievskiy wrote:
On 09.01.2015 01:36, Paolo Bonzini 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
On 01/13/2015 04:16 AM, Vladimir Sementsov-Ogievskiy wrote:
On 12.01.2015 17:42, Paolo Bonzini wrote:
On 12/01/2015 15:20, Vladimir Sementsov-Ogievskiy wrote:
On 09.01.2015 01:36, Paolo Bonzini wrote:
The bitmaps are transmitted many times in their entirety, but only the
last copy actually
Best regards,
Vladimir
On 09.01.2015 01:36, Paolo Bonzini 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
On 12/01/2015 15:20, Vladimir Sementsov-Ogievskiy wrote:
On 09.01.2015 01:36, Paolo Bonzini 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
On 12/01/2015 18:31, John Snow wrote:
How do you track which parts of the disk have been acted upon (e.g.
mirrored in the case of the drive-mirror command), so that they have
become 0?
Hm... so your question here is, What happens if the named bitmap you
are transferring gets reset to 0
On 01/12/2015 11:48 AM, Paolo Bonzini wrote:
On 11/12/2014 15:17, Vladimir Sementsov-Ogievskiy wrote:
Just migrate parts of dirty bitmaps, corresponding to the block being
migrated. Also, skip block migration if it is disabled (blk parameter
of migrate command is false).
So I have misread
On 11/12/2014 15:17, Vladimir Sementsov-Ogievskiy wrote:
Just migrate parts of dirty bitmaps, corresponding to the block being
migrated. Also, skip block migration if it is disabled (blk parameter
of migrate command is false).
So I have misread the patch. blk here:
+static void
CCing migration maintainers, feedback otherwise in-line.
On 12/11/2014 09:17 AM, Vladimir Sementsov-Ogievskiy wrote:
Just migrate parts of dirty bitmaps, corresponding to the block being
migrated. Also, skip block migration if it is disabled (blk parameter
of migrate command is false).
On 11/12/2014 15:17, Vladimir Sementsov-Ogievskiy wrote:
Just migrate parts of dirty bitmaps, corresponding to the block being
migrated. Also, skip block migration if it is disabled (blk parameter
of migrate command is false).
Skipping shared sectors: bitmaps are migrated independently of
On 01/08/2015 03:36 PM, Paolo Bonzini wrote:
On 11/12/2014 15:17, Vladimir Sementsov-Ogievskiy wrote:
Just migrate parts of dirty bitmaps, corresponding to the block being
migrated. Also, skip block migration if it is disabled (blk parameter
of migrate command is false).
Skipping shared
-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
Just migrate parts of dirty bitmaps, corresponding to the block being
migrated. Also, skip block migration if it is disabled (blk parameter
of migrate command is false).
Skipping shared sectors: bitmaps are migrated independently of this,
just send blk without block data.
Signed-off-by: Vladimir
14 matches
Mail list logo
