All of lore.kernel.org
 help / color / mirror / Atom feed
From: Juan Quintela <quintela@redhat.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: qemu-block@nongnu.org, qemu-devel@nongnu.org,
	stefanha@redhat.com, famz@redhat.com, dgilbert@redhat.com
Subject: Re: [Qemu-devel] migrate -b problems
Date: Tue, 18 Apr 2017 14:22:03 +0200	[thread overview]
Message-ID: <878tmxj47o.fsf@secure.mitica> (raw)
In-Reply-To: <20170412091819.GB4955@noname.str.redhat.com> (Kevin Wolf's message of "Wed, 12 Apr 2017 11:18:19 +0200")

Kevin Wolf <kwolf@redhat.com> wrote:
> Hi all,

Hi

> 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. :-)

migration/block.c  is a classic.  Anyone that touches it last is the
maintainer.


> 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?

Two answers:

- Easy one (for me).  look at how spice/qxl use migration notifiers (no,
  it is not pretty, but its what is already done).

- More difficult
  I am trying to get an easier to use way migration notifiers.  What we
  need is to be able to schedule:
     - when we start a migration
        * this thing that you need
     - when we finish a migration (either complete, error or cancel)
        * basically to do a free
        * or spice to handle the screen seamlesly to the new client
     - when we are about to start last stage of migration
        * so devices can write things to memory
          Look at new arm GIC (or PIC) or whatever on the list

And probably something more that I haven't yet think about.

> 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.

That is above my knowledge.

Later, Juan.

  parent reply	other threads:[~2017-04-18 12:22 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 ` Juan Quintela [this message]
2017-04-18 14:47 ` 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=878tmxj47o.fsf@secure.mitica \
    --to=quintela@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=famz@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 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.