...
- No change in user experience during template registration
- Once template is downloaded and installed in the secondary storage it will be post processed
- OVA template custom property "cloud.ova.bootdisk" will be used to determine the ROOT disk. If it is not set the first disk will be identified as the ROOT disk
- For each of the data disks
- An OVF descriptor will be created
- Datadisk template will be created by packaging the disk and OVF into an OVA
- Template post processing will return information about each of the additional data disks present (if any).
- Information about the data disks will include physical and virtual size of the data disk and path where the template has been installed
- For each of the additional disks a Datadisk template will be created
- Entries will be made in vm_templates and vm_template_store_ref table
- Template will be referenced to the corresponding VM template by populating vm_template_details for VM template with key value pair - child_template_id, <datadisk_template_id>
...
- All template i.e. both VM templates and Datadisk templates will be listed.
- They will Datadisk template can be differentiated from VM templates by the property templatetype
- Datadisk templates will have templatetype set to 'Datadisk'
- VM templates will continue to have templatetype set to 'User'
- Following attributes will also be different for the two type of templates – bootable(set to false for Datadisk template), guestos(unset for Datadisk template) 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 entry for the ROOT disk, Volume DB entries will be made corresponding to in volumes table for each of the Datadisk templatetemplates
- 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
Template deletion
- Deletion of DatadiskTemplates Datadisk Templates will be allowed
- When a VM template is deleted, all the corresponding Datadisk templates will remaindeleted
Template copy
- Copy template will not be supported on a individual Datadisk template
- When a VM template is copied to a zone, all the corresponding Datadisk templates will also be copied
- Copy template will not be supported on a individual Datadisk template
- to the zone
Template update
- Users will be allowed to update Datadisk templates
- Template attributes that can be updated - bootable, displayext, format, name, ostypeid, sortkey
...
- 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 VM Template and DatadsikTemplateDatadisk Template(s))
Web Service API
DeployVirtualMachine API
New parameter – disktemplatetodiskofferinglist datadisktemplatetodiskofferinglist
- Mapping from DiskTemplate Datadisk Template to DiskOfferingDatadisk Offering
- 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
...