qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 1/3] block: prohibit migration during BlockJobs


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH 1/3] block: prohibit migration during BlockJobs
Date: Mon, 5 Oct 2015 16:55:13 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0


On 02/10/2015 20:17, John Snow wrote:
> 
> 
> On 10/01/2015 02:03 PM, Paolo Bonzini wrote:
>>
>>
>> On 01/10/2015 18:34, John Snow wrote:
>>> Unless we can prove this to be safe for specific cases,
>>> the default should be to prohibit migration during BlockJobs.
>>
>> Block jobs do not affect the current block, only other block device,
>> hence they *are* safe for migration.
> 
> Can you elaborate for me here?

Migration should be blocked if it causes e.g. data corruption or guest
failures.

However, a block job started on BDS bds0 does _not_ modify the data on
bds0.  It does one of the following:

1) modifies bds0 without changing the data that guests see (example:
streaming)

2) modifies a block device in bds0's backing chain without changing the
data that the guests see in bds0 (example: commit)

3) modifies another block device unrelated to bds0 (example: mirror, backup)

Doing this across migration requires some care (and there is a bug; see
a patch I'll send soon) but generally works.

>> What you want, I think, is the target not to be garbage when migration
>> ends.  Based on this you can block specific cases, namely mirror which
>> you already do allow (patch 2) and backup except for sync='none'.
> 
> It would be nice if the target wasn't garbage, yes :)

It would also be acceptable if it was, though, as long as following the
proper protocol (e.g. wait for the sync phase before triggering
migration) never makes the target garbage.

> I can try to do a more exhaustive audit of what should and should not
> work, but my thought was "guilty before proven innocent."

For (1) and (2) there's no way to be guilty.  For (3)... well, there's
just two block jobs in that category and you do cover one of them; if we
want to block migration in some cases, doing it for the remaining one is
not a big request. :)

Paolo



reply via email to

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