qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: John Snow <jsnow@redhat.com>, qemu-block@nongnu.org
Cc: kwolf@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com
Subject: Re: [Qemu-devel] [PATCH 1/3] block: prohibit migration during BlockJobs
Date: Mon, 5 Oct 2015 16:55:13 +0200	[thread overview]
Message-ID: <56128F51.4080403@redhat.com> (raw)
In-Reply-To: <560ECA27.2050805@redhat.com>



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

  parent reply	other threads:[~2015-10-05 14:55 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-01 16:34 [Qemu-devel] [PATCH 0/3] block: prohibit migrations during tasks John Snow
2015-10-01 16:34 ` [Qemu-devel] [PATCH 1/3] block: prohibit migration during BlockJobs John Snow
2015-10-01 18:03   ` Paolo Bonzini
2015-10-02 18:17     ` John Snow
2015-10-05  8:13       ` Kevin Wolf
2015-10-05 14:55       ` Paolo Bonzini [this message]
2015-10-01 16:34 ` [Qemu-devel] [PATCH 2/3] block/mirror: allow migration after sync John Snow
2015-10-01 16:34 ` [Qemu-devel] [PATCH 3/3] block: prohibit migration during transactions John Snow
2015-10-01 18:01   ` Paolo Bonzini
2015-10-02 18:20     ` John Snow

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56128F51.4080403@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=jsnow@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).