With all the interest in Cloud Computing and virtualization, the OS vendors are providing ever more easier ways to deploy VMs. Most of them now come with cloud images. This makes it really easy for users to deploy VMs with the distro of their choice on a cloud platform like OpenStack or AWS.
Here are a few mentions of the available cloud images
https://cloud-images.ubuntu.com/
https://getfedora.org/en/cloud/download/
http://cloud.centos.org/centos/
Complete Lock-down
But, what about users wanting to deploy virtual machines on standalone Hypervisors? With so many pre-built images available, why should anyone need to install virtual machines from scratch?
With this thought in mind I decided to give these cloud images a try on my Hypervisor. I use libvirt with KVM on a physical server as my Hypervisor.
I realized quickly that these images are completely locked down, there is no default password, no web interface and most of then are configured with serial console.
Auto configuration deamon
These VM images are configured with a configuration daemon called cloudinit. When these cloud image based VM boots for the first time the cloudinit daemon tries to retrieve configuration information from various data sources and sets up things like password for the default user, hostname, SSH keys etc. A complete manual of cloudinit is available here
The cloudinit daemon can retrieve these configuration settings from sources like a ConfigDrives, CDROM attached to the VM(NoCloud) or from the network(EC2).
A Simple Solution
In my previous attempts to use a cloud image I followed the CDROM (attached ISO) based approach to provide the configuration data to the VMs. This quickly gets very cumbersome.
So the obvious thought was to try to mimic the metadata service provides by the cloud platform. The metadata service is a web service that provides the configuration data to the cloud images. As the cloud images boot, they send a DHCP request to get an IP address, then it contacts the metadata service on the network and try to retrieve the configuration for the VM. The metadata service is expected to be available at the well-known IP address of 169.254.169.254.
The libvirt configuration provides a default network to the VMs. It also provides a DHCP service to allocate IP to the VMs from a subnet pool of 192.168.122.0/24. All the VMs connect to the default network bridge; virbr0. This bridge also acts at the network Gateway and is configured with the IP 192.168.122.1. The topology is shown in the image below.
With some trial and error I could come up with a Simple Metadata Service that can be used on a standalone libvirt/KVM based hypervisor to support booting cloud images. The metadata service is a python bottle app and you will need to install bottle web framework.
# pip install bottle
To make the metadata service work add the metadata IP to the bridge interface as follows:
# ip addr add 169.254.169.254 dev virbr0
Download the server code from
https://bitbucket.org/xchandan/md_server
Build and Install the mdserver package
# python setup.py bdist_rpm # rpm -ivh dist/mdserver-<version>.noarch.rpm
or
# python setup.py install
Then start the metadata server as follows
# systemctl start mdserver
or
# mdserver /etc/mdserver/mdserver.conf
Setting password and ssh-key
You can set the password and ssh public key using the /etc/mdserver/mdserver.conf file. An example cam be found here (md_server/etc/mdserver/mdserver.conf.test in the source tree)
[mdserver] password = password-test [public-keys] default = ssh-rsa ....
Note: The Hostname of the VM is set to the libvirt domain name. Although the mdserver can be run on ports other then 80, this is only for testing, the cloud images will always contact 169.254.169.254 on port 80 for metadata
With the metadata server running you should be able to start VMs with cloud images.
The simple metadata service is able to set the hostname, password for the default user, set SSH authorized key and enables password based SSH access.
I was able to test it with cirros, Ubuntu and Fedora images.
Chandan Dutta Chowdhury 