Kevin Wolf <[email protected]> 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.
