qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] mirror: add sync mode incremental to drive-mirr


From: Denis V. Lunev
Subject: Re: [Qemu-devel] [PATCH] mirror: add sync mode incremental to drive-mirror and blockdev-mirror
Date: Wed, 10 May 2017 15:25:31 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0

On 05/09/2017 06:52 PM, Stefan Hajnoczi wrote:
> On Mon, May 08, 2017 at 05:07:18PM -0400, John Snow wrote:
>>
>> On 05/08/2017 05:02 PM, Denis V. Lunev wrote:
>>> On 05/08/2017 10:35 PM, Stefan Hajnoczi wrote:
>>>> On Thu, May 04, 2017 at 12:54:40PM +0200, Daniel Kucera wrote:
>>>>
>>>> Seems like a logical extension along the same lines as the backup block
>>>> job's dirty bitmap sync mode.
>>>>
>>>>> parameter bitmap chooses existing dirtymap instead of newly created
>>>>> in mirror_start_job
>>>>>
>>>>> Signed-off-by: Daniel Kucera <address@hidden>
>>> Can you pls describe the use case pls in a bit more details.
>>>
>>> For now this could be a bit strange:
>>> - dirty bitmap, which can be found via bdrv_create_dirty_bitmap
>>>   could be read-only or read-write, i.e. being modified by writes
>>>   or be read-only, which should not be modified. Thus adding
>>>   r/o bitmap to the mirror could result in interesting things.
>>>
>> This patch as it was submitted does not put the bitmap into a read-only
>> mode; it leaves it RW and modifies it as it processes the mirror command.
>>
>> Though you do raise a good point; this bitmap is now in-use by a job and
>> should not be allowed to be deleted by the user, but our existing
>> mechanism treats a locked bitmap as one that is also in R/O mode. This
>> would be a different use case.
>>
>>> Minimally we should prohibit usage of r/o bitmaps this way.
>>>
>>> So, why to use mirror, not backup for the case?
>>>
>> My guess is for pivot semantics.
> Daniel posted his workflow in a previous revision of this series:
>
> He is doing a variation on non-shared storage migration with the mirror
> block job, but using the ZFS send operation to transfer the initial copy
> of the disk.
>
> Once ZFS send completes it's necessary to transfer all the blocks that
> were dirtied while the transfer was taking place.
>
> 1. Create dirty bitmap and start tracking dirty blocks in QEMU.
> 2. Snapshot and send ZFS volume.
> 3. mirror sync=bitmap after ZFS send completes.
> 4. Live migrate.
>
> Stefan
thank you very much. This is clear now.

If I am not mistaken,  this can be very easy done with
the current implementation without further QEMU modifications.
Daniel just needs to start mirror and put it on pause for the
duration of stage (2).

Will this work?

Den




reply via email to

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