Bug Reference

CLOUDSTACK-4757

Introduction

CloudStack templates in case of VMware are in OVA format. OVA is an archive that can contains a complete VM including multiple VMDKs/disks and other files such as ISOs.

Current scenario

CloudStack only supports template creation based on OVA files containing a single disk.

If Admin/User registers a template using OVA containing more than 1 disk and launches an instance using this template

• Only the first disk in the OVA is attached to the new instance
• Other disks are ignored. 

Purpose

The current behavior needs to be improved to support OVA files with multiple disks

In case of an instance launched from a template that is a OVA containing more than 1 disk - 

• First disk should be attached to the new instance as the ROOT disk
• Volumes should be created for the additional disks and attached to the instance as DATA disks

Architecture and Design description

Changes in the existing code flow

• VMware’s storage processor during storage preparation for the VM
  • Copying registered template from secondary storage to primary storage
    • No change
  • Creating volumes for the VM from the template copied to primary storage
    • Using vCenter APIs verify if template contains multiple disks.
    • If template contains more than one disk then use full-clone to create the VM
      • Because with full clone all the disks contained in the OVA will automatically be created in primary storage.
    • Using vCenter API collect information about every disk that has been created from the template
      • Identify root disk and additional disks
      • Retrieve size and storage path information for each of the disks
• Orchestration layer after VMware’s storage processor has prepared primary storage for the VM
  • For all data disks 
    • Create corresponding custom disk-offering with the disk size info
    • Create volume entry in cloud DB using the disk offering created in the previous step
    • Create usage event for the data volume created
  • For root disk 
    • Save disk controller info (IDE or SCSI) into vm_details table in cloud DB

Once started, VM will contain ROOT disk, disks requested by the user in the deployVM API and additional disks contained in the template OVA.

For the additional disks present in the OVA we first create them in storage and then create an entry for them in DB

Traditionally in CloudStack, for any resource entity we first make a DB entry and then create the resource. But with the proposed workflow CS will

• Import the OVA using vCenter and in the process create additional disks 
• And then persist information about these disks in DB

Reason for the above design choice - 

• To first create DB entries we will need to parse the OVA and fetch all the necessary info.
• Ideally parsing and deploying an OVA would consist of the following steps –
  • Open OVF
  • Make cloud DB entries based on the configurations present in the OVF
  • Edit and map various configurations present in OVF to target environment
  • Import OVA into vCenter with modified configuration

But today in CloudStack, we lack the capability to understand i.e. parse and manipulate OVA format. And hence offloading the import job to vCenter and using the results (information about additional disks) provided by vCenter will be simpler and reliable.

Limitations

• Certain OVA restrictions that will continue to hold true
  • All NIC devices present in the OVA need to point to default network ‘VM Network’ as most of vCenter installations will have it.
  • All Data disk should be of device type SCSI
    • In CS all data disks are by default of device type SCSI
  • OVA package should not contain ISO disk
• The above OVA restriction is because in CS we can’t edit or map the NICS in the OVA to CloudStack networks and also cannot configure the controller type for data disks
• For 4.4, scope of this enhancement is limited to VMware
  • Because today In case of XenServer/XCP and KVM hypervisors, CloudStack templates are one single virtual disk since the files used for templates are virtual disks (VHD, QCOW2).

API/UI/DB Schema

No changes

Upgrade scenario

In a setup that has been upgraded to 4.4 any new VM that is deployed from a template with multiple disks will have multiple volumes attached to it.