Live migration support when using permanent volumes not ephemeral disks

edit

Hi all,

I'd like to request a new feature for the nova-compute service: it should support Live Migration when not the default ephemeral disk (local storage) is used to store the VHD, but a permanent Cinder volume (for example in our case it is attached via iSCSI as a direct disk - so when creating the instance the image contents gets written to a new iSCSI volume which is then attached to the instance). Currently the nova-compute driver dies with the following error message:

2015-09-29 17:00:47.331 3924 DEBUG nova.compute.resource_tracker [req-e55effff-e3ba-47be-add7-33c335a703f2 - - - - -] Migration instance not found: Instance 5e8ce432-7792-452c-b966-d427367d0c4d could not be found.
Traceback (most recent call last):

  File "/usr/lib/python2.7/dist-packages/nova/conductor/manager.py", line 422, in _object_dispatch
    return getattr(target, method)(*args, **kwargs)

  File "/usr/lib/python2.7/dist-packages/nova/objects/base.py", line 163, in wrapper
    result = fn(cls, context, *args, **kwargs)

  File "/usr/lib/python2.7/dist-packages/nova/objects/instance.py", line 559, in get_by_uuid
    use_slave=use_slave)

  File "/usr/lib/python2.7/dist-packages/nova/db/api.py", line 651, in instance_get_by_uuid
    columns_to_join, use_slave=use_slave)

  File "/usr/lib/python2.7/dist-packages/nova/db/sqlalchemy/api.py", line 233, in wrapper
    return f(*args, **kwargs)

  File "/usr/lib/python2.7/dist-packages/nova/db/sqlalchemy/api.py", line 1744, in instance_get_by_uuid
    columns_to_join=columns_to_join, use_slave=use_slave)

  File "/usr/lib/python2.7/dist-packages/nova/db/sqlalchemy/api.py", line 1756, in _instance_get_by_uuid
    raise exception.InstanceNotFound(instance_id=uuid)

InstanceNotFound: Instance 5e8ce432-7792-452c-b966-d427367d0c4d could not be found.

Steps to reproduce the issue: We try to perform a simple live migration from Horizon - simply going to Admin -> Instances, selecting an instance and then saying "Live migrate" and choosing the other hypervisor as target. The instance was created by using the Boot from an image (create volume) option. We tried this so far with Ubuntu guests, but I guess this shouldn't matter. What we expect from the nova-compute service: to behave the same as the KVM service does or the way HyperV behaves with ephemeral-local disks used. I'm not sure how much of this is implemented already in Cinder, but this is kind of the steps we thought it should go through: 1. Attach volume to target hypervisor 2. Do HyperV's live migrate 3. Detach volume from previous hypervisor

Thanks a lot! Let us know if you need anything - more logs, testing code, whatever, we are ready to assist as much as we can!

Domi