VMware: create snapshot is not creating virtual disk snapshot

[satyadev svn]

test setps :
create a volume [cinder create 1 --name test]
now take snapshot. [cinder snapshot-create 0d6b77b7-7791-45ad-a191-df2685051562 --name test_snap]
now restore existing backup to above volume [cinder snapshot-create 0d6b77b7-7791-45ad-a191-df2685051562 --name test_snap]
expected : cinder should throw error volume with snapshots not allowed as target volume
actual : user able to restore a volume having snapshot.

observation : it happens only when volume don't have backing vm with virtual center. driver behavior should be same for volumes with backing & with out backin vm in virtual center.

command usage :
ssatya@pr-devstack:~/devstack$ cinder list
+--------------------------------------+-----------------+---------------+------+-------------+----------+-------------+
| ID | Status | Name | Size | Volume Type | Bootable | Attached to |
+--------------------------------------+-----------------+---------------+------+-------------+----------+-------------+
+--------------------------------------+-----------------+---------------+------+-------------+----------+-------------+
ssatya@pr-devstack:~/devstack$ date
Tue Sep 30 15:48:55 SGT 2014
ssatya@pr-devstack:~/devstack$ cinder create 1 --name test
+---------------------------------------+--------------------------------------+
| Property | Value |
+---------------------------------------+--------------------------------------+
| attachments | [] |
| availability_zone | nova |
| bootable | false |
| consistencygroup_id | None |
| created_at | 2014-09-30T07:49:14.000000 |
| description | None |
| encrypted | False |
| id | 0d6b77b7-7791-45ad-a191-df2685051562 |
| metadata | {} |
| name | test |
| os-vol-host-attr:host | None |
| os-vol-mig-status-attr:migstat | None |
| os-vol-mig-status-attr:name_id | None |
| os-vol-tenant-attr:tenant_id | 74562aa6231841869274ad9c0b3f3abb |
| os-volume-replication:driver_data | None |
| os-volume-replication:extended_status | None |
| replication_status | disabled |
| size | 1 |
| snapshot_id | None |
| source_volid | None |
| status | creating |
| user_id | da7ab4f87b994c2a9837c93765bddb4e |
| volume_type | None |
+---------------------------------------+--------------------------------------+
ssatya@pr-devstack:~/devstack$ cinder snapshot-create 0d6b77b7-7791-45ad-a191-df2685051562 --name test_snap
+-------------+--------------------------------------+
| Property | Value |
+-------------+--------------------------------------+
| created_at | 2014-09-30T07:49:46.582513 |
| description | None |
| id | 25875d33-bd96-4543-b7f8-ac9bb9c087d2 |
| metadata | {} |
| name | test_snap |
| size | 1 |
| status | creating |
| volume_id | 0d6b77b7-7791-45ad-a191-df2685051562 |
+-------------+--------------------------------------+
ssatya@pr-devstack:~/devstack$ cinder backup-list
+--------------------------------------+--------------------------------------+-----------+------------------+------+--------------+---------------+
| ID | Volume ID | Status | Name | Size | Object Count | Container |
+--------------------------------------+--------------------------------------+-----------+------------------+------+--------------+---------------+
| 4200b860-739d-4a8c-8541-c0eda1df5cf2 | 44a9106f-e432-449e-a5fb-f76888f0fad8 | available | image_vol_backup | 1 | 2 | volumebackups |
+--------------------------------------+--------------------------------------+-----------+------------------+------+--------------+---------------+
ssatya@pr-devstack:~/devstack$ cinder backup-restore 4200b860-739d-4a8c-8541-c0eda1df5cf2 --volume 0d6b77b7-7791-45ad-a191-df2685051562^C
ssatya@pr-devstack:~/devstack$ cinder list
+--------------------------------------+-----------------+---------------+------+-------------+----------+-------------+
| ID | Status | Name | Size | Volume Type | Bootable | Attached to |
+--------------------------------------+-----------------+---------------+------+-------------+----------+-------------+
| 0d6b77b7-7791-45ad-a191-df2685051562 | available | test | 1 | None | false | |

ssatya@pr-devstack:~/devstack$ cinder backup-restore 4200b860-739d-4a8c-8541-c0eda1df5cf2 --volume 0d6b77b7-7791-45ad-a191-df2685051562
ssatya@pr-devstack:~/devstack$ cinder list
+--------------------------------------+------------------+---------------+------+-------------+----------+-------------+
| ID | Status | Name | Size | Volume Type | Bootable | Attached to |
+--------------------------------------+------------------+---------------+------+-------------+----------+-------------+
| 0d6b77b7-7791-45ad-a191-df2685051562 | restoring-backup | image_vol | 1 | None | true | |

ssatya@pr-devstack:~/devstack$ cinder list
+--------------------------------------+-----------------+---------------+------+-------------+----------+-------------+
| ID | Status | Name | Size | Volume Type | Bootable | Attached to |
+--------------------------------------+-----------------+---------------+------+-------------+----------+-------------+
| 0d6b77b7-7791-45ad-a191-df2685051562 | available | image_vol | 1 | None | true | |

[Duncan Thomas (duncan-thomas)]

I don't think cinder should return any error - overwriting a volume with snapshots is absolutely fine - the snapshots will still contain what they always did, of course

[Duncan Thomas (duncan-thomas)]

> observation : it happens only when volume don't have backing vm with
> virtual center. driver behavior should be same for volumes with backing
> & with out backin vm in virtual center.

This sounds like the real bug, it should work all the time

[Vipin Balachandran (vbala)]

VMDK driver disallows backup restore operation to a volume with snapshot. This is because, we cannot restore the disk contents without losing the snapshot information. The volume snapshot corresponds to a virtual disk snapshot and a check for snapshot existence implies a check for virtual disk snapshot.

For each of the cinder volumes, the VMDK driver creates a virtual disk and uses a VM (backing VM) to manage it. When there is no source specified for a volume create, we delay the creation of the backing VM. This is done to minimize backing VM migrations during attach operations. During attach, we know the exact ESX host which needs to access the volume and creates the backing VM in a datastore accessible to that host.

The bug here is, during snapshot operation we don't create a virtual disk snapshot if there is no backing VM. This will result in a cinder snapshot which doesn't have any corresponding virtual disk snapshot. If such a volume is the target for backup restore, we allow the restore operation instead of failing it.

[Vipin Balachandran (vbala)]

The above limitation is documented here:
http://docs.openstack.org/trunk/config-reference/content/vmware-vmdk-driver.html

[Duncan Thomas (duncan-thomas)]

I consider the above limitation a serious bug, bordering on not meeting the minimal feature set for a cinder driver, and will look at ways it can be fixed in the near future.

Is there a good explanation of /why/, from a technical PoV, this restriction is necessary?

[Vipin Balachandran (vbala)]

Each snapshot operation creates a link (redo log disk) in the virtual disk chain. Restoring a backup to an existing volume with snapshots would mean replacing the leaf link with the contents of the backup. The redo log disks are of the format "sparse" and there is no vCenter API to create a sparse virtual disk by copying another virtual disk. I hope we can have some fix for this in the near future.

[Sean McGinnis (sean-mcginnis)]

Closing stale bug. If this is still an issue please reopen.