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 t
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 is
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
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 use
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 res
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 blk_store_
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 (regist
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 lo
-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
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).
>>
>> Skip
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
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).
Skipping
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