OpenStack

Creating an OpenStack Image

This is already documented very well but here's some notes.

Essentially, we're going to create a hand built KVM instance which we will boot off an ISO image, we'll add some packages that help it fit with the OpenStack environment and then we'll upload the result into OpenStack.

You should be able to do this for anything you want to create instances of, eg. a router or PBX -- although not everything will allow you to add, say, a cloud-init package or ACPI functionality.

Let's build a CentOS 7.x server image.

Create the KVM image:
```
qemu-img create -f qcow2 centos7-x86_64-if-server.qcow2 8G
```
This creates an 8GB file called centos7-x86_64-if-server.qcow2.
Boot it with the CD attached:
```
virt-install \
 --virt-type kvm \
 --name centos7-x86_64-if-server \
 --memory memory=2048 \
 --disk centos7-x86_64-if-server.qcow2,format=qcow2 \
 --network network=default \
 --graphics vnc,listen=0.0.0.0 \
 --noautoconsole \
 --cdrom=/path/to/CentOS-7-x86_64-DVD-1511.iso
```
--name is just to distinguish this from any other KVM instance (OpenStack instances are called instance-nnnnnnnn). The file we just created is referenced by the --disk parameter.
Note

The network default is sometimes created when you install the virt-* packages, sometimes not. You may need to:
```
yum install libvirt-daemon-config-network
```
possibly followed by:
```
virsh net-define /usr/share/libvirt/networks/default.xml
virsh net-start default
```
--graphics is important, otherwise you're not going to get very far when the default CentOS installer starts. If you're keen you may have the skills to start the Linux boot with install.text or even have a kickstart config set up.

Finally, we choose which CD image to use with --cdrom.

Find out which VNC display it is using:

# virsh vncdisplay centos7-x86_64-if-server
:2

(Assuming you've installed a suitable VNC viewer, e.g. tigervnc):
```
vncviewer :2
```
You can now perform a regular CentOS install configuring disk layouts and packages ("Infrastructure Server" seems to have enough useful tools whilst keeping the size down).

Don't do anything involved with networking! It's going to get trashed by us later on -- unless you need networking to do your configuration.

The root password you set here (and any user account) will be retained. When OpenStack launches an instance of the image it will claim to have assigned an admin password. That may be true but the server will boot with the root password you set here. This means your Production instances of this image will also boot with this root password so set it to be something sensible!

Reboot as per instructions.
Sadly, KVM doesn't appear to eject the CD at this point. In fact, ejecting the CD is rather cumbersome.
1. You need discover the device the CD was in the KVM instance then attach nothing in its place:
```
virsh dumpxml centos7-x86_64-if-server | less +/cdrom
```
  Figure out the device, e.g. hda and replace it:
```
virsh attach-disk --type cdrom --mode readonly centos7-x86_64-if-server '' hda
```
  Splat this running instance (destroy splats the running instance, undefine deletes it from KVM) and restart:
```
virsh destroy centos7-x86_64-if-server

virsh start centos7-x86_64-if-server
```
Now we're back to real work. Find out the current VNC port -- it could have changed!
```
# virsh vncviewer centos7-x86_64-if-server
:2
# vncviewer :2
```
Log in as root -- possibly edit /etc/resolv.conf to point at a sensible local/remote nameserver.
Configure for OpenStack:
```
yum -y install acpid
systemctl enable acpid

yum -y install http://dl.fedoraproject.org/pub/epel/7/x86_64/e/epel-release-7-5.noarch.rpm

yum -y install cloud-init
```
At this point you might tweak the cloud init setup for your local preference. For example, the default CentOS cloud user account is centos. Maybe we want our own account:
```
CLOUD_CFG=/etc/cloud/cloud.cfg
sed -i \
 -e 's/name: centos/name: runscripts/' \
 -e 's/gecos: .*/gecos: Run Scripts/' \
 ${CLOUD_CFG}
```
More required cloud init:
```
echo NOZEROCONF=yes >> /etc/sysconfig/network
```
Note

NOZEROCONF=yes, here, refers to disabling the creation of 169.254.x.y link local addresses on each interface. (Ignoring the negate-action=yeah/nay poor grammar, after all, wouldn't ZEROCONF=no do the same thing?) If the OS create a link local address then there will be a route to 169.254/16 which tramples over OpenStack's ability to use its metadata service on 169.254.169.254.

That done, you might want to performs your own generic environmental/package tweaks that you would do on all your boxes:
- disable NetworkManager
- set up /etc/resolv.conf
- tweak Postfix parameters: myorigin, mydomain, relayhost
- setup /etc/chrony.conf
- install useful tools, e.g. nmap-ncat, yum-cron
Warning

CentOS 7.x has a feature that will bite later in that rsyslog will not log anything. This Redhat bug notes that /etc/machine-id gets the wrong security context -- I'm not sure when. You can fix it with restorecon /etc/machine-id.

At the end of it, though, you must not reboot. Call poweroff but do not reboot.
Having prepped the inside of the image we now need to prep it from the outside. virsh-sysprep diddles about and removes any machine-specific details (udev and other network/previous life details etc.):
```
virt-sysprep -d centos7-x86_64-if-server --selinux-relabel
```
Don't forget the --selinux-relabel!

Finally, we're done. We can delete the instance from KVM -- note that this doesn't delete the file on disk -- and upload the image into OpenStack:

virsh undefine centos7-x86_64-if-server
glance image-create \
 --name centos7-x86_64-if-server \
 --file centos7-x86_64-if-server.qcow2 \
 --disk-format qcow2 \
 --container-format bare \
 --visibility public \
 --progress

Now we have ourselves a starter-for-ten image we can deploy for our server needs.

Warning

Having one all of that we might want to reconsider our options. When you instantiate a cloud image you specify a flavor which includes a root disk size. The cloud init code will, on boot, attempt to resize the server's root disk to match that of the flavor.

However, it can only (or it chooses only to) grow the root disk to match the flavor. It will not shrink a root disk. In fact, if you specify a flavor with a smaller root disk size than the image was built with (eg. a flavor root disk of 4GB for our image's 8GB root disk) then the system will error.

In this case, given our generic server, if we logged in we might note:

# df -h
Filesystem               Size  Used Avail Use% Mounted on
/dev/mapper/centos-root  5.5G  1.8G  3.8G  32% /
devtmpfs                 910M     0  910M   0% /dev
/dev/vda1                497M  305M  192M  62% /boot

Plus a 2GB swap partition:

# lvs
  LV   VG     Attr       LSize Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  root centos -wi-ao---- 5.51g
  swap centos -wi-ao---- 2.00g

Based on which you might want to crank down the initial parameters for your build: a 4GB root disk and 1GB of RAM (which presumably would map to 1GB of swap partition on the root disk).

Of course, you might want to get rid of swap altogether. Another exercise.

Document Actions