Today, I want to talk about the challenges of loading VMware appliances into OpenStack Glance and give you a recipe of how to do it.
I migrated my lab to OpenStack but need to be able to test the latest VMware products in order to keep myself up to speed. As VMware provides more and more of its software as virtual appliances in OVF or OVA format it makes sense to have them in Glance for provisioning on OpenStack.
The following procedure is illustrated at the example of vCAC Appliance 6.0:
Challenge 1: Format Conversion
If you get to download the appliance as OVF you are already one step ahead. OVF is simply an XML-based configuration and does not include any information required to run the VM on OpenStack.
OVAs on the other hand need to be unpacked first. Luckily, OVA is nothing but TAR:
$ file VMware-vCAC-Appliance-188.8.131.52-1445145_OVF10.ova
VMware-vCAC-Appliance-184.108.40.206-1445145_OVF10.ova: POSIX tar archive (GNU)
So we continue extracting the archive:
$ tar xvf ../VMware-vCAC-Appliance-220.127.116.11-1445145_OVF10.ova
The .ovf, .mf and .cert files can be deleted right away. We will not need those anymore. After that the VMDK files must be converted to QCOW2 or RAW:
$ qemu-img convert -O qcow2 VMware-vCAC-Appliance-18.104.22.168-1445145-system.vmdk VMware-vCAC-Appliance-22.214.171.124-1445145-system.img
$ qemu-img convert -O qcow2 VMware-vCAC-Appliance-126.96.36.199-1445145-data.vmdk VMware-vCAC-Appliance-188.8.131.52-1445145-data.img
Challenge 2: Multi-Disk Virtual Machines
Unfortunately, OpenStack does not support images existing of multiple disks. Bad luck that VMware has the habit of distributing their appliances with a system disk and a separate data disk (*system.vmdk and *-data.vmdk). To still load this appliance into Glance we need to merge the disks into a single one:
First, we use guestfish to get some information on the filesystems inside the disk images:
Welcome to guestfish, the guest filesystem shell for
editing virtual machine filesystems and disk images.
Type: 'help' for help on commands
'man' to read the manual
'quit' to quit the shell
> add VMware-vCAC-Appliance-184.108.40.206-1445145-system.img
> add VMware-vCAC-Appliance-220.127.116.11-1445145-data.img
It is safe to assume that the EXT3 on /dev/sda1 is the root file system, so we mount it and have a look into /etc/fstab to see where the other filesystems should be mounted:
> mount /dev/sda1 /
> cat /etc/fstab
/dev/sda2 swap swap defaults 0 0
/dev/sda1 / ext3 defaults 1 1
proc /proc proc defaults 0 0
sysfs /sys sysfs noauto 0 0
debugfs /sys/kernel/debug debugfs noauto 0 0
devpts /dev/pts devpts mode=0620,gid=5 0 0
/dev/sdb1 /storage/log ext3 rw,nosuid,nodev,exec,auto,nouser,async 0 1
/dev/sdb2 /storage/db ext3 rw,nosuid,nodev,exec,auto,nouser,async 0 1
Next, as we want to get rid of sdb all together, we remove the entries in /etc/fstab
> vi /etc/fstab
and mount /dev/sdb1 to /mnt. This way we can copy the contents over to /storage/log:
> mount /dev/sdb1 /mnt
> cp_a /mnt/core /storage/log/
> cp_a /mnt/vmware /storage/log/
Of course, the same has to happen for /dev/sdb2:
> umount /mnt
> mount /dev/sdb2 /mnt
> cp_a /mnt/pgdata /storage/db/
And we are done! Please not it is important to use cp_a instead of cp_r as it will preserve permissions and ownership.
Challenge 3: Disk Space
Well, so far so good! But the image that originally served as the system disk now has to hold all the data as well. Therefore, we need more space! So we have to resize the disk image, the partition(s) and filesystem(s). Here is the easiest way I’ve found:
$ qemu-img create -f qcow2 newdisk.qcow2 50G
$ virt-resize --expand /dev/sda1 VMware-vCAC-Appliance-18.104.22.168-1445145-system.img newdisk.qcow2
Examining VMware-vCAC-Appliance-22.214.171.124-1445145-system.img ...
Summary of changes:
/dev/sda1: This partition will be resized from 12.0G to 47.0G. The
filesystem ext3 on /dev/sda1 will be expanded using the 'resize2fs'
/dev/sda2: This partition will be left alone.
Setting up initial partition table on newdisk.qcow2 ...
Copying /dev/sda1 ...
Copying /dev/sda2 ...
Expanding /dev/sda1 using the 'resize2fs' method ...
Resize operation completed with no errors. Before deleting the old
disk, carefully check that the resized disk boots and works correctly.
What’s happening here? First, we create a new empty disk of the desired size with “qemu-img create”. After that, virt-resize copies data from the original file to the new one resizing partitions on the fly. Next, the filesystems are resized using resize2fs.
The image can now be uploaded into Glance. Please make sure to add properties that set the SCSI controller chipset properly. For example, IDE is going to work. The reason for this is the name of disks: using VirtIO we will get /dev/vda1 and would have to adjust those name e.g. in /etc/fstab, too. I have only had luck with ide so far:
glance image-update --property hw_disk_bus=ide 724ad050-a636-4c98-8ae5-9ff58973c84c