VMwareEsxVmdkDriver: clone ends up corrupting data in case of vSAN datastore

[Kartik Bommepally]

VMwareEsxVmdkDriver treats VMDK files as regular files at the time of cloning.
It does the clone by simply copying the folder containing the files.

This does not play well with a vSAN enabled ESX datastore, where the descriptor will get copied over, but the data file will still be shared with other source volume. The same is the issue with creating from snapshot point.

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/48915
Committed: http://github.com/openstack/cinder/commit/fc7c36c9ca94de6bd2481c59d7710566dd4a1ddb
Submitter: Jenkins
Branch: master

commit fc7c36c9ca94de6bd2481c59d7710566dd4a1ddb
Author: Kartik Bommepally <email address hidden>
Date: Mon Sep 30 02:45:37 2013 -0700

    VMware ESX: Fixes vol clone & clone from snapshot

    The driver was earlier performing create from a source volume and create from
    a snapshot point by copying the source volume container folder.

    This is not valid in case of vSAN datastore where the volume data is not a
    'file' in the container folder unlike VMFS/NFS datastores. So copying folder
    will only copy descriptor file and hence the source and cloned volume will
    end up writing to the same data location, eventually corrupting it.

    The fix is to copy only the VMDK file (descriptor + data) and not the entire
    container folder. The implementation does the following:
    1. Create a volume backing
    2. Delete the current VMDK
    3. Make a copy of source volume's VMDK file to the destination using virtual
       disk manager. In case of create from snapshot, we copy the VMDK file
       corresponding to the snapshot point.

    Fixes bug: 1233034

    Change-Id: I51c9870c11a6d66f9f47c1ad9aaa2abc3dd0533a