All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: qemu-block@nongnu.org
Cc: qemu-devel@nongnu.org, stefanha@redhat.com, famz@redhat.com,
	quintela@redhat.com, dgilbert@redhat.com
Subject: [Qemu-devel] migrate -b problems
Date: Wed, 12 Apr 2017 11:18:19 +0200	[thread overview]
Message-ID: <20170412091819.GB4955@noname.str.redhat.com> (raw)

Hi all,

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?

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.

Kevin

             reply	other threads:[~2017-04-12  9:18 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-12  9:18 Kevin Wolf [this message]
2017-04-12  9:51 ` [Qemu-devel] migrate -b problems 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 ` [Qemu-devel] [Qemu-block] " Stefan Hajnoczi
2017-04-18 15:32   ` 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=20170412091819.GB4955@noname.str.redhat.com \
    --to=kwolf@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=famz@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.