Introduction

Currently, CloudStack does not allow passing of additional configuration metadata to guest VMs during deployment when required. This feature aims to provide operators the functionality to pass arbitrary additional configuration metadata that will be included every time the guest VM is started.

Feature Specification

In CloudStack, when a new guest VM is deployed by the user and answers questions about the template/iso, service offerings and networking e.t.c, these answers are used to produce the VM's primary configuration file. This file format is dynamically determined according to the supported hypervisor in the cluster which the VM is being deployed. CloudStack supports 3 major hypervisors i.e. KVM, XenServer and VMware, and this feature is implemented to support all of them.

Use cases

CloudStack users wish to have the ability to add “extra configuration” metadata to a user VM during deployment in a manner that is similar across the 3 major supported hypervisors. This data could be anything ranging from instructions to install hypervisor specific required tools and drivers in each VM that is deployed from a template which does not have these tools installed. To simplify the implementation, the user will pass this additional configuration as URL encoded string that will be decoded and parsed for each hypervisor type. These additional metadata must be included in the VM instance definition.

• KVM

The primary configuration file for KVM host guest instances is a domain XML. The additional configuration for KVM should be provided in XML format in a URL encoded string which will be parsed and append to the KVM instance XML configuration file builder.

Example: the following metadata can be passed to specify guest VM NUMA topology using the <numa> element in the domain XML

<cpu>
   <numa>
      <cell cpus='0-3' memory='512000'/>
      <cell cpus='4-7' memory='512000'/>
   </numa>
</cpu>

User needs to pass the following URL encoded string:

20cpus%3D%270-3%27%20memory%3D%27512000%27%2F%3E%0D%0A%20%20%20%20%20%20%3Ccell%20cpus%3D%274-7%27%20memory%3D%27512000%27%2F%3E%0D%0A%20%20%20%3C%2Fnuma%3E%0D%0A%3C%2Fcpu%3E

Another Example: the following examples allows user to add EHCI controller to VM

<controller type='usb' index='1' model='ehci'></controller>

User input URL encoded string:

%3Ccontroller%20type%3D%27usb%27%20index%3D%271%27%20model%3D%27ehci%27%3E%3C%2Fcontroller%3E

• XenServer

Similar for this hypervisor, the primary configuration file of the guest VM is built by CloudStack, therefor, the additional metadata will also be parsed and append to the builder.

Example: the following metadata can passed to pass a USB controller to the guest VM:

vm-param-set other-config:pci=0/0000:00:1a.0

User needs to pass the following URL encoded string:

vm-param-set%20other-config%3Apci%3D0%2F0000%3A00%3A1a.0

• VMware

Similar for this hypervisor, the primary configuration file of the guest VM is built by CloudStack, therefor, the additional metadata will also be parsed and append to the VMX file builder.

Example: the following is an example to set Hyper-V to run on ESXi

hypervisor.cpuid.v0 = "FALSE" – to run Hyper-V on ESXi

User needs to pass the following URL encoded string:

hypervisor.cpuid.v0%20%3D%20%22FALSE%22%20%E2%80%93%20to%20run%20Hyper-V%20on%20ESXi

Admin users will be allowed to use this feature with very few restrictions, whilst normal users will be constrained to several restrictions that are controlled by the admin.

High Level Specifications

Hypervisor support

KVM, XenServer and VMware

API and Service Layer

The ‘deployVirtualMachine’ , and (updateVirtualMachines) API commands are refactored to include a new parameter ‘extraconfig’. This parameter will accept the URL encoded string and CloudStack will store in the 'user_vm_details' under the key 'extraconfig'.

Global configuration settings are added with Account scope  in the Service Layer for the admin user to allow and control passing of additional data;

• A Boolean setting to allow sending of additional data from the API
• A new setting with a list of options that are not allowed to passed as additional data. The admin user will populate this setting with a list of tags/commands that will be used for validating against user supplied additional configuration.

UserVmManageImpl class is refactored to include the new Boolean configuration setting to allow/disallow passing of additional data during VM deployment/updating,  and stores the data in the 'user_vm_details' table.

VirtualMachineManagerImpl class is refactored to include methods for retrieving 'extraconfig' from the database and validating against the global setting that contains the list of unwanted arguments before orchestrating the starting of the guest VM.

VirtualMachineTO class is refactored to carry the additional configuration data from the Service Layer to Hypervisor Layer.

KVM : LibvirtComputingResource class is refactored to include additional configuration metadata into the VM domain XML before starting it.

XenServer: CitrixResourceBase class is refactored as well to include additional metadata in the primary configuration file builder of the VM before starting it.

VMware: VmwareResource is also refactored to include additional configuration into the VMX configuration file builder before starting the VM.

UI integration

N/A