Feature reference

Jira
server ASF JIRA serverId 5aa69414-a9e9-3523-82ec-879b028fb15b key CLOUDSTACK-9813

...

This work is loosely based on previous work on config drive for Cloudstack as described in “DHCP/DNS offload and Config drive support for adv shared network“. And extended from shared networks to all networks.

Supporting ConfigDrive

...

Extra data is added to the VM profile to enable the creation of the config drive:

...

A new provider “ConfigDrive, implementing the userdata service, will be made available to create, update and delete the ConfigDrive ISO on the secondary store.
When triggered to create userdata, the vmdata is created and added to the virtual machine profile. As is the ConfigDrive label fetched from the global settings.
The secondary store agent is triggered to create the ISO file.
At successful creation the ISO file is added as a new disk to the virtual machine profile.

An update of userdata/password/ssh-keys has a few extra steps as some hypervisors don’t handle the update of the ISO file, while attached to the virtual machine, very well.

• Detach ISO
• Update
• Re-attach

For update of userdata user data, it is important the user VM does not keep the ConfigDrive cdrom mounted all the time, as update will fail if the ConfigDrive cdrom is in use by the user VM.

...

The metadata, userdata en password information associated with the VM are used to create the above directory structure in a the base directory /tmp/<VM-NAME>/configdrive/.
Then the genisoimage utility is used to create the ISO file. The temporary data is removed as soon as the ISO is created.
The ISO is stored on the secondary storage at ConfigDrive/<vmName>/configdrive.iso

Creating the ISO file implies that the SystemVM needs the genisoimage package installed and the cloudstack software updated.

Copying ISO to Primary Storage

 As secondary storage is less guaranteed to be highly available, we need to bring the generated ISO to Primary Storage.
To do this we:

• extend DataObjectType with CONFIG_DRIVE.

• Add copyConfigDriveToPrimaryStorage method to the StorageProcessor interface.
  Returning the path on primary storage in the response.

• Implement added method in all StorageProcessors

• Extend StorageSubsystemCommandHandlerBase.execute(CopyCommand cmd) to support DataObjectType.CONFIG_DRIVE

• Add ConfigDriveObject class and ConfigDriveInfo interface.

• Extend storage system to support calling copyAsync passing a ConfigDriveObject.

• Add a service method to send the copyAsync, and wait until ISO is ready.

• Optionally: Persist ConfigDrive ISO information to DB, so we know when to copy.
  

Call the new service method, after generating the ISO.
And as part of prepare migration, to make sure the ISO is available on the target host.

ConfigDrive availability

At VM start the config drive iso ISO is attached on 2nd cd /dvd rom drive of the user instance, such that any other iso image (e.g. boot image or vmware tools) get gets mounted on 1st cd/dvd drive.
This means existing functionality of supporting 1 1 cd /dvd rom drive is still available.

At Password reset or update userdataof user data, Secondary Storage VM will rebuild the ConfigDrive iso.
That is the existing ISO is mounted on a temporary directory, password, userdata or ssh-keys are updated and a new ISO is build from the updated directory structure.

In case of password reset the new password will be picked-up at VM start.
To access updated userdata the user needs to remount the config drive cdrom.

As When a VM is stopped, the ConfigDrive network element will trigger the Secondary Storage VM  to to remove the ISO from the secondary storage.

Since the ISO is available on the second storage, there is no need for an extra implementation in case of migration

...

Windows VM
For  windows VM the ISO is mounted automatically. So user can browse through the files in the ConfigDrive cd.

Linux VM

Config drive iso is created by-label under /dev/disk/by-label/config.
It can be found using
blkid -t LABEL='config‘ /dev/xvdb: LABEL="config" TYPE="iso9660"
or
blkid -t LABEL=”config” /dev/disk/by-id/*

Hypervisor support

This feature will be implemented and tested for KVM and ESXI.

OpenStack support

Based on the feedback that was received from the community at the CloudStack conference Collaboration Conference in Miami, the config-drive implementation was extended to support make sure the OpenStack config-drive implementationconfigdrive ISO is OpenStack compatible. This allows for easy integration with cloud-init and similar systems. 

...

• <mountdir>

• /cloudstack

• /metadata:

• availability-zone.txt  

• instance-id.txt     

• service-offering.txt

• cloud-identifier.txt  

• local-hostname.txt  

• vm-id.txt

• public-keys.txt

• /password

• vm_password.txt

• vm_password_md5checksum (for windows VM’s)

• /user_data

• user_data.txt        (note about _ characters below in text)

...

Vendor-Data is a way for a vendor to provide site specific information. This can be information on local mirrors, a local proxy, or a one-time registration code.
It is found in the vendor_data.json file residing on ConfigDrive or the Neutron Metadata Service via 169.254.169.254/openstack/latest/vendor_data.json.
By default, Cloud-Init executes the Vendor-Data on every boot.
Currently, we don’t plan to support this.

...

Network-Data is network information found on ConfigDrive. It resides in the network_data.json file. Nova retrieves this info from Neutron.
It includes fixed ip addresses, MAC addresses, port-id's, network-id's, subnet-id's, DNS name-servers, etc.
Currently, we don’t plan to support this.
Is allowed to be empty {}

...

In order for Cloud init to work, OpenStack config-drive provider must be called before the CloudStack (metadata-service) provider.
This can be defined in the cloud.cfg file (for example see arch-linux wiki: https://wiki.archlinux.org/index.php/Cloud-init#Configuration (Configuring data sources))

CoreOS support

CoreOS keeps the CloudStack Config-Drive implementation (Nuage PRs).
Reason: CoreOS uses the ec2 format for Config-drive in combination with OpenStack. We propose to support only the OpenStack (beside the CloudStack) format and not ec2.

...