How to make image?
For a Linux-based image to have full functionality in an OpenStack Compute
cloud, there are a few requirements. For some of these, you can fulfill the
requirements by installing the
cloud-init package. Read this section before you
create your own image to be sure that the image supports the OpenStack features
that you plan to use.
Disk partitions and resize root partition on boot (
When you create a Linux image, you must decide how to partition the disks. The choice of partition method can affect the resizing functionality, as described in the following sections.
The size of the disk in a virtual machine image is determined when you initially create the image. However, OpenStack lets you launch instances with different size drives by specifying different flavors. For example, if your image was created with a 5 GB disk, and you launch an instance with a flavor of
m1.small. The resulting virtual machine instance has, by default, a primary disk size of 20 GB. When the disk for an instance is resized up, zeros are just added to the end.
Your image must be able to resize its partitions on boot to match the size requested by the user. Otherwise, after the instance boots, you must manually resize the partitions to access the additional storage to which you have access when the disk size associated with the flavor exceeds the disk size with which your image was created.
Depending on your distribution, the simplest way to support this is to install in your image:
cloud-utilspackage, which, on Ubuntu and Debian, also contains the
growparttool for extending partitions
With these packages installed, the image performs the root partition resize on boot. For example, in the
If you can install the
cloud-utilspackages, we recommend that when you create your images, you create a single ext3 or ext4 partition (not managed by LVM).
No hard-coded MAC address information
You must remove the network persistence rules in the image because they cause the network interface in the instance to come up as an interface other than eth0. This is because your image has a record of the MAC address of the network interface card when it was first installed, and this MAC address is different each time the instance boots. You should alter the following files:
/etc/udev/rules.d/70-persistent-net.ruleswith an empty file (contains network persistence rules, including MAC address).
/lib/udev/rules.d/75-persistent-net-generator.ruleswith an empty file (this generates the file above).
- Remove the HWADDR line from
/etc/sysconfig/network-scripts/ifcfg-eth0on Fedora-based images.
Note: If you delete the network persistent rules files, you may get a
udev kernelwarning at boot time, which is why we recommend replacing them with empty files instead.
SSH server running
$ sudo ufw status [sudo] password for linuxconfig: Status: inactive
Access instance using ssh public key (
Process user data and other metadata (
Paravirtualized Xen support in Linux kernel (Xen hypervisor only with Linux kernel version < 3.0)
preserve_hostame: false # if you do not change /etc/hostname, it will be updated with the cloud # provided hostname on each boot. If you make a change, then manual # maintenance takes over, and cloud-init will not modify it.
manage_etc_hosts: localhost # cloud-init will generally own the 127.0.1.1 entry, and will update it to the # hostname and fqdn on every boot. All other entries will be left as is. # 'ping `hostname`' will ping 127.0.1.1
Delete the terminal command history
$ sudo -i # rm ~/.bash_history # history -c # exit $ rm ~/.bash_history $ history -c $ exit
Wipe free disk space
Convert the format of image
qemu-img convert -f raw ubuntu.img -O qcow2 ubuntu.qcow2
qemu-img convert -f vdi ubuntu.vdi -O qcow2 ubuntu.qcow2
md5sum ubuntu.qcow2 > ubuntu.qcow2.md5 tar -czf ubuntu.qcow2.tar.gz ubuntu.qcow2 ubuntu.qcow2.md5