Install Oracle Virtual Box on Windows 7
Create 64 bits Ubuntu Server
Download the Elastix 2.4 64 bits iso file
Start the virtual server and select the Elastix iso
CentOS 5.9 and Elastix 2.4 installed on virtual server
1. My virtualbox image is the vanilla Centos 5.8 installation. Amazon needs the xen kernel installed:
yum install kernel-xen
2. The hard disk consists of a boot partition,and a logical volume located on the second partition. This means that the menu.lst file will be different than any of the examples out there – the key is root=/dev/VolGroup00/LogVol00. Symptom: kernel panic at AWS. Settings which worked for me below:
3.Even if you have the right kernel installed with the correct menu.lst file, it doesn’t matter if it’s not associated correctly. Get this wrong you get a kernel panic. We need the magicmkinitrdcommand to make it work:
Separate /boot: kernels with “hd00” in their name like pv-grub-hd00_1.03-i386 One big disk: kernels with “hd0” in their name like pv-grub-hd0_1.03-i386
Once you’ve located the correct kernel, in the correct availability zone,permanently associate it with your snapshot using the ec2-register command- otherwise if you launch your kernel from the AWS dashboard with the defaults, you’ll get, wait for it, Kernel panic:
6. If you’re paranoid like I am, then you’ll be taking all sorts of snapshots of your Virtualbox instance, just in case things go badly. Good practice. Of course, when we need to get a copy of the running machine’s disk we use the following command:
This command takes a copy of the virtual hard disk, and converts it to an img file, which we can then compress and transfer up to AWS and write onto a volume which we snapshot and turn into an AMI. I’ll outline this process later, don’t panic.
I did everything correctly. What did I get? Kernel panic.It’s especially heartwarming since this happens after having waited the excruciating amount of time to upload 500mb to Amazon. So this debugging is a slow and painful process, which is why I’m documenting it.
Here’s what went wrong. If you’ve snapshotted a Virtualbox machine, the changes are not reflected at the “top level” in my case, centos5.8.vdi. That file is still the state of your machine before any snapshots.
You must delete all snapshots from the top, down. Each time you delete a snapshot, your changes are merged with the later snapshots. When you no longer have any snapshots, your changes have been rolled into the top level machine instance, which you can now copy and send to Amazon. You can verify this by checking the date on your .vdi file.
script: volume to running instance(steps 4-6 above)
This script is run from your local machine – make any changes to your volume, then run the script and it’ll try to fire up an instance… which may or may not work. At least you’ll know what the steps to follow are.