Introduction

Purpose

This is the functional specification for Full Clones support for guest VMs on VMWare cluster deployments on CloudStack. The feature is intended for CS deployments on the ESX hypervisor in conjunction with vCenter.

References

http://www.vmware.com/support/ws55/doc/ws_clone_overview.html http://www.vmware.com/support/ws5/doc/ws_clone_typeofclone.html

Glossary

For the driving factors for full clones support in CS, see:

https://cwiki.apache.org/confluence/display/CLOUDSTACK/Configurable+setting+to+use+linked+clones+or+not+on+VMware

Related ACS tickets:

https://issues.apache.org/jira/browse/CLOUDSTACK-670
https://issues.apache.org/jira/browse/CLOUDSTACK-529

Use cases

1) There are multiple ways of specifying that VMs on ESX be created as full clones or linked clones. Three ways would be:

a) Specify a boolean global configuration parameter. If set to true, all new VMs that are created will be created as full clones. If this flag is set to false, all new VMs created will be deployed as linked clones. This can lead to a hybrid environment that has both linked and full clone VMs, and that should be supported.

b) Specify the type of clone for an ESX VM as part of the service offering for that VM.

c) Specify the type of clone for an ESX VM as part of the API to create the VM.

  • Approach a) above will be taken in implementing this feature.

2) Allow full clones and linked clones to exist side by side in the same cluster. This follows from 1a).

3) All operations currently supported with linked clone VMs (snapshots/volumes/migration) will be supported for VMs created as full clones.

Feature Specifications and Architecture and Design description

New global parameter flag : vmware.create.full.clone

Type of the flag: boolean
Default value: False

If set to true, new VMs on ESX will be created as full clones. If set to false, new VMs on ESX will be created as linked clones.

DB Schema changes:

New table: user_vm_clone_setting
Table fields: vm_id (guest VM id), clone_type (full/linked)
    • CS will need to track whether a guest VM is based off a full clone or linked clone. This table will help track that.

Snapshot related changes:

    • Snapshots generated on VMs using full clones also produce delta disks and the management should be no different from what is currently being done in CS for cloudstack. Additional changes are not expected to be required.

Volume lifecycle:

    • VMWare uses a grouping of two vmdk files as the root disk for linked clones. They are named in the format *.vmdk and *-delta.vmdk. In vCenter, these two files are however abstracted and shown as a single file of the name *.vmdk. The *.vmdk file is a metadata file, while *-delta.vmdk serves as the disk file. In the case of a linked clone, this delta file tends to be smaller to serve the purpose of quick provisioning. As its name indicates, it is a delta disk based off a base disk belonging to the base template VM.
    • Similarly, VMWare creates a grouping of two vmdk files for full clones as well. These are named *.vmdk and *-flat.vmdk, with *.vmdk again serving as the abstract file representing the root disk for the VM. The full clone's *-flat.vmdk disk however, is initially a replica of the base vmdk of the VM template from which both full clones and linked clones are created. So, Cloudstack basically follows the same procedure up until VM template creation for both types of VMs, and the process diverges only after that.
    • Care should be taken to remove the appropriate type of vmdk files when deleting volumes, based on what type the VM is.

In the case of a mixed environment, if an entry for a VM is not found in the vm_clone_setting table, it is assumed to be a linked clone VM.

Upgrade path:

    • Upgrade from 4.0 ACS to 4.1 ACS will support incorporation of the global parameter vmware.create.full.clone and the creation of the new table vm_clone_setting.

Community requested sub-feature: Conversion of Linked Clone VMs to Full Clone VMs.

    • Conversion of linked clone VMs to full clone VMs is desirable for reasons of removing scalability bottlenecks and increasing disk reliability. However, this sub-feature will be carried out in phase 2 of this project. It will not be targeted for 4.1 ACS. The implementation of this sub-feature would involve backing up/capturing the entire state of the linked clone VM first, followed by creating it as a full clone using the backed up state, and then deleting the original linked clone VM. Other approaches could be considered.

System VMs:

    • System VMs are also affected by the global flag vmware.create.full.clone. If they are created after vmware.create.full.clone is set to true, they are also created as full clones. If a large deployment involving a large number of system VMs is being planned, it is advisable to first create the system VMs as linked clones by setting the flag as false and then setting it to true and proceeding to create guest VMs.

Test Plans at:

https://cwiki.apache.org/confluence/display/CLOUDSTACK/Configurable+setting+to+use+linked+clones+or+full+clones++on+VMware

  • No labels