Versions Compared

Key

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

...

  • 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 store_ref table
      • Template will be referenced to the corresponding VM template by populating parentvm_template_id field with the id of the VM templatedetails for VM template with key value pair - child_template_id,  <datadisk_template_id>

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

...

  • 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

Template deletion

  • Deletion of DatadiskTemplates will be allowed
  • When a VM template is deleted, the corresponding Datadisk templates will remain

Template Copy

  • When a VM template is copied, all the corresponding Datadisk templates will be copied
  • Copy template will not be supported on a individual Datadisk template

Change in the existing behavior

...

  • 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

...

 No schema changes

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)