Cloud-Init Integration

Summary

Cloud-init[1] is a tool used to perform initial setup on cloud nodes, including networking, SSH keys, timezone, user data injection, and more. It is a service that runs on the guest, and supports various Linux distributions including Fedora, RHEL, and Ubuntu.

Integrating support for it into oVirt will help facilitate provisioning of virtual machines. It's already in wide use by cloud software such as OpenStack (via Heat) as well as providers such as Amazon, and its capabilities are a natural fit in our environment.

Owner

Name: Greg Padgett

Email: gpadgett@redhatdotcom

Current Status

Detailed Description

Use Case

Use of cloud-init to help provision a guest requires that the guest have cloud-init installed. For cloud instances, this is typically done during image creation; in our use case, it would be installed on a VM or template.

After package installation, cloud-init will start during the boot process and looks for various "data sources" that supply it with instructions on what to configure. These sources can be local configuration data stored on the VM itself, an attached block device (config disk) identified by a specific volume labels and directory structure, or a metadata server accessible via the network at a predefined IP address. We'll be using a config disk, which will allow the engine to create and attach data to the VMs dynamically based on user preferences, as well as allowing a user to attach their own already-prepared config disks.

Note that there are multiple config disk types supported by cloud-init, each with their own varying structures and capabilities. We are most interested in using config-drive version 2[2], which is also in supported by OpenStack.

Once cloud-init discovers a data source, it scans it for meta-data and user-data. Generally, meta-data contains information about the cloud that is passed to the guest (instance identification, network setup, etc [3]), whereas user-data contains instructions on provisioning the specific system in question (usernames/passwords to configure, timezone, custom scripts to run, packages to install, files to inject, etc [4]). If cloud-init has not previously seen the supplied instance identifier (i.e. this is a new configuration), it will proceed to set up the system accordingly. The end result is a system with all basic provisioning complete before the first login.

In summary, a typical workflow for using cloud-init in oVirt to assist in guest provisioning might involve:

after reboot, cloud-init shouldn't cause a delay due to no data source being present*

(* Items with asterisk indicate that a workaround or bugfix is needed, these are expected by the time the feature is ready.)

Implementation Notes

Config disks will be attached to VMs as ISOs using the VM Payload feature, so both a payload and cloud-init configuration cannot be used at the same time. However, cloud-init can be used to inject files into the guest, effectively an alternate way to deliver a payload.

Payload type configuration (i.e. like sysprep type, also with option to support different config disk types either now or in the future)

Engine/Backend/Db

Create config disk from passed-in configuration options

VDSM

Support custom volume label for vm payloads

Benefit to oVirt

Integrating with cloud-init will make provisioning Linux VMs easier for admins, decreasing the amount of setup time needed and streamlining support for attaching existing config disks to feed data to cloud-init.