All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Hajnoczi <stefanha@gmail.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: qemu-block@nongnu.org, dgilbert@redhat.com, famz@redhat.com,
	qemu-devel@nongnu.org, stefanha@redhat.com, quintela@redhat.com
Subject: Re: [Qemu-devel] [Qemu-block] migrate -b problems
Date: Tue, 18 Apr 2017 15:47:25 +0100	[thread overview]
Message-ID: <20170418144725.GJ21261@stefanha-x1.localdomain> (raw)
In-Reply-To: <20170412091819.GB4955@noname.str.redhat.com>

[-- Attachment #1: Type: text/plain, Size: 1979 bytes --]

On Wed, Apr 12, 2017 at 11:18:19AM +0200, Kevin Wolf wrote:
> after getting assertion failure reports for block migration in the last
> minute, we just hacked around it by commenting out op blocker assertions
> for the 2.9 release, but now we need to see how to fix things properly.
> Luckily, get_maintainer.pl doesn't report me, but only you. :-)
> 
> The main problem I see with the block migration code (on the
> destination) is that it abuses the BlockBackend that belongs to the
> guest device to make its own writes to the image file. If the guest
> isn't allowed to write to the image (which it now isn't during incoming
> migration since it would conflict with the newer style of block
> migration using an NBD server), writing to this BlockBackend doesn't
> work any more.
> 
> So what should really happen is that incoming block migration creates
> its own BlockBackend for writing to the image. Now we don't want to do
> this anew for every incoming block, but ideally we'd just create all
> necessary BlockBackends upfront and then keep using them throughout the
> whole migration. Is there a way to get some setup/teardown callbacks
> at the start/end of the migration that could initialise and free such
> global data?

It can be done in the beginning of block_load() similar to
block_mig_state.bmds_list, which is created in init_blk_migration() at
save time.

We can also move the if (blk != blk_prev) blk_invalidate_cache() code
out of the load loop.  It should be done once when setting up
BlockBackends.

> The other problem with block migration is that is uses a BlockBackend
> name to identify which device is migrated. However, there can be images
> that are not attached to any BlockBackend, or if it is, the BlockBackend
> might be anonymous, so this doesn't work. I suppose changing the field
> to "device name if available, node-name otherwise" would solve this.

Yes, that sounds good and is backwards compatible.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

  parent reply	other threads:[~2017-04-18 14:47 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-12  9:18 [Qemu-devel] migrate -b problems Kevin Wolf
2017-04-12  9:51 ` 858585 jemmy
2017-04-18 14:40   ` [Qemu-devel] [Qemu-block] " Stefan Hajnoczi
2017-04-18 12:22 ` [Qemu-devel] " Juan Quintela
2017-04-18 14:47 ` Stefan Hajnoczi [this message]
2017-04-18 15:32   ` [Qemu-devel] [Qemu-block] " Kevin Wolf
2017-04-19  9:14     ` Stefan Hajnoczi
2017-04-19 11:13     ` Dr. David Alan Gilbert
2017-04-19 11:18       ` Juan Quintela
2017-04-19 11:20         ` Dr. David Alan Gilbert
2017-04-19 11:55           ` Juan Quintela
2017-04-19 12:32       ` Kevin Wolf

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=20170418144725.GJ21261@stefanha-x1.localdomain \
    --to=stefanha@gmail.com \
    --cc=dgilbert@redhat.com \
    --cc=famz@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.