vmware: Volume backing not getting relocated to a compliant datastore during re-attach

[satyadev svn]

Create a volume with volume type mapped to gold profile. [gold profile mapped to datastore1]
Now attach to instance and observe that volume is placed in datastore1.
Now detach above volume .
Now change volume type of above volume to Silver profile [Silver profile mapped to datastore2]
Now re attach volume to instance and observe that volume is still placed in datastore1 instead of datastore2.

[Vipin Balachandran (vbala)]

The problem is while attaching a volume to an instance, we skip relocating the volume backing if it is accessible to the nova instance's ESX host.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/117443

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/117443
Committed: https://git.openstack.org/cgit/openstack/cinder/commit/?id=4be8913520f5e9fe4109ade101da9509e4a83360
Submitter: Jenkins
Branch: master

commit 4be8913520f5e9fe4109ade101da9509e4a83360
Author: Vipin Balachandran <email address hidden>
Date: Wed Aug 27 20:26:34 2014 +0530

    VMware: Relocate volume to compliant datastore

    During attach to a nova instance, the backing VM corresponding to the
    volume is relocated only if the nova instance's ESX host cannot access
    the backing's current datastore. The storage profile is ignored and
    the volume's virtual disk might end up in a non-compliant datastore.
    This patch fixes the problem by checking storage profile compliance of
    the current datastore.

    Change-Id: I3865654e219c05dcec3aaab07c4cee0658fe181e
    Closes-Bug: #1301348

[Vipin Balachandran (vbala)]

I don't think the use case mentioned in the bug description is valid. One should retype API in such a case.
However, this bug can be reproduced by the following steps:

* Assign gold_profile to VMFS datastore 'ds-1'
* Create volume with gold_profile
* Attach volume to instance stored in ds-1 and registered with ESX host h-1
* Detach volume
* Remove ds-1's association with gold_profile
* Assign gold_profile to shared datastore 'ds-2' which is connected to h-1
* Attach volume to instance

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/155702

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/155702
Committed: https://git.openstack.org/cgit/openstack/cinder/commit/?id=3b08782e68db1c7173309924a7eb967976544a8f
Submitter: Jenkins
Branch: master

commit 3b08782e68db1c7173309924a7eb967976544a8f
Author: Vipin Balachandran <email address hidden>
Date: Wed Aug 27 20:26:34 2014 +0530

    VMware: Relocate volume to compliant datastore

    During attach to a nova instance, the backing VM
    corresponding to the volume is relocated only if
    the nova instance's ESX host cannot access the
    backing's current datastore. The storage profile
    is ignored and the volume's virtual disk might
    end up in a non-compliant datastore. This patch
    fixes the problem by checking storage profile
    compliance of the current datastore.

    Change-Id: I9f0ed6e179160a51e8c370087e9c903ed28e1728
    Closes-Bug: #1301348