Page History

...

CLOUDSTACK-4757

Introduction

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

Current scenario

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

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

...

then only the first disk in the OVA is attached to the new instance

...

and the rest of the disks are ignored. 

Purpose

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

...

Changes in the existing code flow

...

VM start orchestration

• Update CopyCmdAnswer to handle a list of disks instead of a single disk
• Once the primary storage has been prepared by the underlying hypervisor resource 
  • 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

Hypervisor storage processor for VM's storage preparation

• 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 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 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
• Today In case of XenServer/XCP and KVM hypervisors since files used for templates are virtual disks (VHD, QCOW2), the templates are one single disk. Hence for 4.4, scope of the storage processor changes is limited to VMware.
  • And in case of VMware 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.
  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

...

• 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
  • All NIC devices present in the OVA need to point to default network ‘VM Network’ as most of vCenter installations will have it.
• The above OVA restriction is because in CS we can’t don't edit or map the NICS in the OVA to CloudStack networks and also cannot configure the controller type for data disksFor 4.4, scope of this enhancement is limited to VMwareBecause 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

...