qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [patch 6/7] QEMU live block copy


From: Avi Kivity
Subject: Re: [Qemu-devel] [patch 6/7] QEMU live block copy
Date: Tue, 31 May 2011 19:53:44 +0300
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc15 Lightning/1.0b3pre Thunderbird/3.1.10

On 05/31/2011 07:38 PM, Marcelo Tosatti wrote:
>
>  >Disadvantages:
>  >
>  >- Guest write performance is affected during copying (guest writes
>  >    compete with stream of writes from copy).
>
>  Competes anyway with your background task?

No because guest writes are to the source and copy writes are to
destination (which are potentially different disks or set of disks).

Your copy task reads from the source disk and writes to the destination disk. A guest write doesn't touch the destination disk, but schedules a later write due to dirty tracking. In all, the total number of writes should be similar. Background copy is a more efficient since multiple writes to the same location are coalesced, but that's not very common (except perhaps for transaction logs).

>
>  >- Unability to have the mirror functionality in a separate driver.
>
>  Why?

Because you need to handle the interaction between guest writes and
copy writes someplace which can be aware of both.

For example, in-flight copy writes must be invalidated in the guest
write path.

guest -> device -> mirror driver -> [ source disk, destination disk ]

>  >>   It would also remove the conflict with migration.
>  >
>  >There is no fundamental problem with migration, its simply unsupported
>  >now.
>
>  Why?

Don't see the need for that, management can simply wait for livecopy to
finish or cancel livecopy and restart on destination after migration.

They can do it, but I imagine it's pretty hard for them.

But yeah, it should be implemented sometime...



We should make an effort not to introduce interdependencies which make management's life harder.

--
error compiling committee.c: too many arguments to function




reply via email to

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