Versions Compared

Old Version 11

changes.mady.by.user Likitha Shetty

Saved on

compared with

New Version 12

changes.mady.by.user Likitha Shetty

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Bug Reference

CLOUDSTACK-4757

Branch

master (development branch -> Work is in progress in ova-multiple-disks) branch

Introduction

OVA is an archive or an envelope specification 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 Today in CloudStack, we only support template creation based on OVA files containing that contain a single disk. If an Admin/User registers a template using OVA containing that contains more than 1 disk and launches an instance using this template then only , only the first disk in the OVA is attached to the new instance and the rest of the disks the disks are ignored. 

Purpose

Purpose of this document is to present functional specifications for improvements that are required to extent the current OVA support to include multiple disks.

Glossary

VM template – Represents a ROOT disk contained in an OVA along with other VM related information like Guest OS.

Datadisk Template - An abstraction for a DATA volume contained in an OVA

Goals

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

In case of an instance launched from a template that is an 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 additional 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.

Design decision

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 hypervisor and in the process create additional disks in primary storage 
  • 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 hypervisor host 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 hypervisor and using the results (information about additional disks) provided by the hypervisor 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
      • In case the OVA package contains an ISO then we will error out when a VM is deployed using the template because we use vCenter to gather info about the OVA 
    • 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

Scope

Scope of this proposal is limited to adding support for additional disks present in an OVA that is registered in CloudStack. It is not in the scope to fully support an OVA and hence CloudStack will ignore any other information that is encapsulated in the OVA which may include information about the ISO or networks present.

Feature specifications

Currently in CloudStack, template abstraction is that of a VM template that contains a single disk. To represent the additional disks present in an OVA we will introduce the concept of Datadisk templates.

Datadisk templates will be

  • Used to create a data disk from the volume image that is present in the template
  • Stored in vm_templates tables along with the current CS templates
  • Used only when a user tries to deploy a VM from the corresponding VM template and never independently

Datadisk templates will provide flexibility to orchestrate, deploy and manage additional disks present in an OVA like any other Datadisk in CloudStack.

Work flow changes

Template registration

  • No change in user experience during template registration
  • Once template is downloaded and installed in the secondary storage it will be post processed
    • Template post processing will return information about each of the additional data disks present (if any).
    • Information about the data disks will include size of the data disk, path where the template has been installed and the device id
    • For each of the additional disks a Datadisk template will be created
      • Entries will be made in vm_templates and vm_template_details table
      • Template will be referenced to the corresponding VM template by populating parent_template_id field with the id of the VM template

Listing templates

  • All template i.e. both VM and Datadisk templates will be listed.
  • They will be differentiated by the following attributes present in TemplateResponse – bootable, guestos and parenttemplateid

Virtual Machine deployment

  • If user tries to deploy a VM from a template containing multiple disks, user will have to choose a Datadisk offering for every Datadisk template chosen to be deployed along with the VM template
    • If the actual size of the disk exceeds the size of the disk offering then VM deployment will fail
    • During VM create process, when CloudStack makes DB entries for the ROOT disk, Volume DB entries will be made corresponding to each of the Datadisk template
      •  Volume state will be updated to Uploaded state because the volume is already present in secondary storage and has been packaged into an OVA during template post processing
    • During VM orchestration while the storage is being prepared, a volume will be created in primary storage for each of the additional disks
      • Each of the volumes will be migrated from secondary storage to the primary storage chosen by the deployment planner
      • When VM starts it will be booted with all the chosen disks

Change in the existing behavior

  • When a user downloads a CS template with multiple volumes, the entity that is downloaded will not be same as the one that was registered
    • The downloaded template will only contain the ROOT disk because when a OVA template is registered it is now consumed and split into 2 or more templates (VMTemplate and DatadsikTemplate(s))

Web Service API

DeployVirtualMachine API

New parameter – disktemplatetodiskofferinglist

  • Mapping from DiskTemplate to DiskOffering
  • If a VM is being deployed from an OVA template that contains additional disks, then during the deployment user will have to choose a Datadisk offering for every Datadisk template he/she chooses to deploy along with the VM template
  • Mutually exclusive with the existing parameter diskofferingid
  • Optional
  • Usage - &disktemplatetodiskofferinglist[0].disktemplateid=2&disktemplatetodiskofferinglist[0].diskofferingid=3

UI Flow

Deploy VM wizard

  • While listing all templates list only VM templates i.e. non Datadisk templates (VM templates will have bootable property set to true)
  • Once the user has selected the VM template allow user to pick between disk offering or Datadisk template with the help of radio buttons (user can choose to select neither)
  • If user chooses disk offering then rest of the work flow will remain the same as today
  • If user chooses Datadisk template then list all the Datadisk templates that belong to the VM template chosen in the first step (templates that have parentTemplateId parameter set to that of VM template)

DB Schema changes

 New column parent_template_id will be added to table vm_template

  • Datadisk templates will have parent_template_id set to VM template’s id

...

Upgrade scenario

  • In a setup that has been upgraded to 4.4

...

  • , templates with multiple volumes
    • That were registered prior to upgrade will continue to operate as before. Any VM launched from these templates will only have the ROOT disk
    • That will be registered after upgrade will follow the new behavior. Any VM launched from these templates will have additional data disks attached to them along with the ROOT disk (i.e. if user chooses to)