You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

Bug Reference

CLOUDSTACK-4757

Introduction

OVA is an archive/envelope spec that can contain a complete VM including multiple 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

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

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
    • Verify if template contains multiple disks.
    • 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.

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 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 don't edit or map the NICS in the OVA to CloudStack networks and also cannot configure the controller type for data disks

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. 

  • No labels