[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] migrate -b problems
From: |
Juan Quintela |
Subject: |
Re: [Qemu-devel] migrate -b problems |
Date: |
Tue, 18 Apr 2017 14:22:03 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) |
Kevin Wolf <address@hidden> 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.
- [Qemu-devel] migrate -b problems, Kevin Wolf, 2017/04/12
- Re: [Qemu-devel] migrate -b problems, 858585 jemmy, 2017/04/12
- Re: [Qemu-devel] migrate -b problems,
Juan Quintela <=
- Re: [Qemu-devel] [Qemu-block] migrate -b problems, Stefan Hajnoczi, 2017/04/18
- Re: [Qemu-devel] [Qemu-block] migrate -b problems, Kevin Wolf, 2017/04/18
- Re: [Qemu-devel] [Qemu-block] migrate -b problems, Stefan Hajnoczi, 2017/04/19
- Re: [Qemu-devel] [Qemu-block] migrate -b problems, Dr. David Alan Gilbert, 2017/04/19
- Re: [Qemu-devel] [Qemu-block] migrate -b problems, Juan Quintela, 2017/04/19
- Re: [Qemu-devel] [Qemu-block] migrate -b problems, Dr. David Alan Gilbert, 2017/04/19
- Re: [Qemu-devel] [Qemu-block] migrate -b problems, Juan Quintela, 2017/04/19
- Re: [Qemu-devel] [Qemu-block] migrate -b problems, Kevin Wolf, 2017/04/19