[jira] [Commented] (CLOUDSTACK-1872) Do not accept OVAs with multiple VMDKs for uploaded volumes or templates

["Kirk Kosinski (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CLOUDSTACK-1872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13621195#comment-13621195 ] 

Kirk Kosinski commented on CLOUDSTACK-1872:
-------------------------------------------

After further testing I found that if you delete a multi-VMDK volume in CloudStack that was attached and subsequently detached to a VM, only the first VMDK will actually be deleted from primary storage. The extra VMDKs will remain and likely never removed, wasting potentially expensive space on primary storage. To reproduce:

1. Upload an OVA containing multiple VMDKs as a volume in CloudStack.
2. Once it is uploaded, attach it to a VM.
3. Notice that two VMDKs will be deployed to primary storage, but only one will be attached to a VM. The file names of the VMDKs will be uuid.vmdk, uuid_1.vmdk, and so on (get "uuid" from the "path" for the volume from the database).
4. Detach the volume.
5. Delete the volume. 
6. Notice that uuid.vmdk will be removed successfully, but uuid_1.vmdk will remain.
                
> Do not accept OVAs with multiple VMDKs for uploaded volumes or templates
> ------------------------------------------------------------------------
>
>                 Key: CLOUDSTACK-1872
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1872
>             Project: CloudStack
>          Issue Type: Bug
>      Security Level: Public(Anyone can view this level - this is the default.) 
>          Components: API, Template, VMware, Volumes
>    Affects Versions: 4.0.1
>            Reporter: Kirk Kosinski
>
> CloudStack volumes and templates are meant to be one single virtual disk. This is always the case with KVM and XenServer/XCP since the files used for volumes and templates are virtual disks (QCOW2, VHD). However, VMware volumes and templates are in OVA format, which are archives that can contain a complete VM including multiple VMDKs and other files such as ISOs. 
> Currently, CloudStack will accept an OVA with an invalid configuration, extract it to secondary storage, and allow end-users to use it. This can cause unintended behavior or possibly failures when an end-user does try to use it. At the very least, it wastes space on secondary and possibly primary storage. For example, here is a uploaded volume that contained two VMDKs on secondary storage:
> # ll /mnt/secondary/volumes/12/
> total 332
> -rw-rw-rw- 1 root root 146944 Apr  1 16:38 3ab61094-8170-3139-a6b4-8edd2b4942ef.ova
> -rw-r--r-- 1 root root  68608 Apr  1 16:35 blankvm2-disk1.vmdk
> -rw-r--r-- 1 root root  68608 Apr  1 16:35 blankvm2-disk2.vmdk
> -rw-r--r-- 1 root root    200 Apr  1 16:35 blankvm2.mf
> -rw-r--r-- 1 root root   5930 Apr  1 16:35 blankvm2.ovf
> -rw-rw-rw- 1 root root    328 Apr  1 16:38 volume.properties
> Attaching this volume to a VM will result in both VMDKs being copied to primary storage, but only one will be attached to the VM.
> CloudStack should verify whether or not an OVA contains a supported configuration, and should give an error and reject the OVA if it is not supported. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira