Bug 1220849

From Kashyap Chamarthy ...

Some notes on libvirt blockRebase API and offline migration:

As it was correctly identified, libvirt's 'blockRebase' API works only
(and that's not a bug) when the guest is online -- the main
functionality of blockRebase is that it allows the guest to concurrently
read/write while the copy is taking place. So the behavior of libvirt
(blockRebase API, to be precise) throwing an error when it doesn't see a
running domain (guest) is expected.

Some notes from an IRC discussion with Matthew Booth, Dan Berrange and
Peter Krempa).

  - It is pointless to allow blockRebase to work when a guest is
    offline, because one can use more efficient methods like `dd` (or 
    similar) to perform a copy.

  - Matthew Booth tried to explore an idea where libvirt driver could 
    try to create an ephemeral (transient) domain (guest in libvirt's
    parlance) to do a block migration. To However that's might not be
    acceptable in a 'Cloud environment', rationale from libvirt 
    developers:

      - Creating a guest consumes resources from the host whic his not
        acceptable if the guest is supposed to be shutoff. We've
        previously rejected this as an approach for migrating offline
        guests for this reason.

      - Allowing blockRebase to work offline probably will require to
        spawn a instance of QEMU anyway, so it will be rather ugly to
        implement.

*** Bug 1220526 has been marked as a duplicate of this bug. ***

From https://bugs.launchpad.net/nova/+bug/1454252/comments/2:

> Today when Cinder understands that the volume is attached to VM it calls Nova's
> swap_volume feature to migrate a volume. The problem is that swap_volume uses
> libvirt's blockRebase which fails if libvirt doesn't find a VM and that's
> exactly what happens in this case because VM is shutoff so the qemu process for
> this VM doesn't exist.
>
> In order to fix it we probably have to change the flow. Nova should detect
> that VM is off and instead of calling blockRebase it has to attach a new
> volume to compute node and perform simple copy (dd) as Cinder does in generic
> case. Once it done, Nova must update a path to the new volume in all relevant 
> places. Important to mention that VM must be locked during the process to 
> prevent the user to run it.

@sgotliv: would performing a simple copy (in the sense of dd) require cinder-driver-specific knowledge on the nova side?

Or would this generic approach be completely agnostic to the underlying cinder-driver in use?

(In reply to Eoghan Glynn from comment #5)
> From https://bugs.launchpad.net/nova/+bug/1454252/comments/2:
> 
> > Today when Cinder understands that the volume is attached to VM it calls Nova's
> > swap_volume feature to migrate a volume. The problem is that swap_volume uses
> > libvirt's blockRebase which fails if libvirt doesn't find a VM and that's
> > exactly what happens in this case because VM is shutoff so the qemu process for
> > this VM doesn't exist.
> >
> > In order to fix it we probably have to change the flow. Nova should detect
> > that VM is off and instead of calling blockRebase it has to attach a new
> > volume to compute node and perform simple copy (dd) as Cinder does in generic
> > case. Once it done, Nova must update a path to the new volume in all relevant 
> > places. Important to mention that VM must be locked during the process to 
> > prevent the user to run it.
> 
> @sgotliv: would performing a simple copy (in the sense of dd) require
> cinder-driver-specific knowledge on the nova side?

"dd" doesn't cover the case where the volume is not locally attachable [1] for example RBD volume migration scenario. To be honest I am not a huge fan of the code duplication and this Cinder patch [1] introduce changes to the generic migration behavior anyway so I guess we need to get it merged first and then see how to correctly build the flow.

[1] https://review.openstack.org/#/c/187270/

> 
> Or would this generic approach be completely agnostic to the underlying
> cinder-driver in use?

This does not appear to have progressed in Mitaka, moving to 10.

Does not appear to have progressed in Newton, moving to Ocata.