Chapter 3. OpenStack Linux image requirements

If you are using the OpenStack XenAPI driver, the Compute service will automatically adjust the partition and filesystem for your instance on boot. Automatic resize will occur if the following are all true:

Therefore, if you are using Xen, we recommend that when you create your images, you create a single ext3 or ext4 partition (not managed by LVM). Otherwise, read on.

Your image must be configured to deal with two issues:

Then, during the boot process:

The simplest way to support this in your image is to install the cloud-utilspackage (contains the growpart tool for extending partitions), the cloud-initramfs-tools package (which will support resizing root partition on the first boot), and the cloud-init package into your image. With these installed, the image will perform the root partition resize on boot (e.g., in /etc/rc.local). These packages are in the Ubuntu nd Debian package repository, as well as the EPEL repository (for Fedora/RHEL/CentOS/Scientific Linux guests).

If you are not able to install cloud-initramfs-tools, Robert Plestenjak has a github project called centos-image-resize that contains scripts that will update a ramdisk using growpart so that the image will resize properly on boot.

If you are able to install the cloud-utils and cloud-init packages, we recommend that when you create your images, you create a single ext3 or ext4 partition (not managed by LVM).

If you cannot install cloud-init and cloud-tools inside of your guest, and you want to support resize, you will need to write a script that your image will run on boot to modify the partition table. In this case, we recommend using LVM to manage your partitions. Due to a limitation in the Linux kernel (as of this writing), you cannot modify a partition table of a raw disk that has partition currently mounted, but you can do this for LVM.

Your script will need to do something like the following:

You do not need to have a /boot partition, unless your image is an older Linux distribution that requires that /boot is not managed by LVM. You may elect to use a swap per

The cloud-init package will automatically fetch the public key from the metadata server and place the key in an account. The account varies by distribution. On Ubuntu-based virtual machines, the account is called "ubuntu". On Fedora-based virtual machines, the account is called "ec2-user".

You can change the name of the account used by cloud-init by editing the /etc/cloud/cloud.cfg file and adding a line with a different user. For example, to configure cloud-init to put the key in an account named "admin", edit the config file so it has the line:

user: admin

If you are unable or unwilling to install cloud-init inside the guest, you can write a custom script to fetch the public and add it to a user account.

To fetch the ssh public key and add it to the root account, edit the /etc/rc.local file and add the following lines before the line “touch /var/lock/subsys/local”. This code fragment is taken from the rackerjoe oz-image-build CentOS 6 template

if [ ! -d /root/.ssh ]; then
  mkdir -p /root/.ssh
  chmod 700 /root/.ssh
fi

# Fetch public key using HTTP
ATTEMPTS=30
FAILED=0subl
while [ ! -f /root/.ssh/authorized_keys ]; do
  curl -f http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key > /tmp/metadata-key 2>/dev/null
  if [ \$? -eq 0 ]; then
    cat /tmp/metadata-key >> /root/.ssh/authorized_keys
    chmod 0600 /root/.ssh/authorized_keys
    restorecon /root/.ssh/authorized_keys
    rm -f /tmp/metadata-key
    echo "Successfully retrieved public key from instance metadata"
    echo "*****************"
    echo "AUTHORIZED KEYS"
    echo "*****************"
    cat /root/.ssh/authorized_keys
    echo "*****************"
done

	Note
	Some VNC clients replace : (colon) with ; (semicolon) and _ (underscore) with - (hyphen). If editing a file over a VNC session, make sure it's http: not http; and authorized_keys not authorized-keys.