Let me jump to the topic straight here. I will begin with a few lines on why to convert Para-virtualization (PV) to Hardware-assisted Virtual Machine (HVM), and once the readers are sufficiently motivated, offer ways of doing it.
Para-virtualization (PV):
PV provides software interface to a virtual machine, which is not identical to the underlying environment Hence, PV requires you to modify the guest OS. Para-virtualized guest OS’ are executed by a compiler to replace the instructions which are non-virtualizable to the hyper calls.
Hardware-assisted Virtual Machine (HVM):
HVM provides the ability to run a virtual machine without any modification in the operating system, as if we are running it on the base hardware.
Why PV to HVM:
Technical Perspective:
Traditionally, PV guests perform better with storage and networking as they are provided with the dedicated drivers for I/O operations. These PV drivers are also available for HVM guests. In addition to the above, betterment in the performance HVM virtualization provides access to the native hardware platforms which leads to enhanced performance in the CPU and GPU.
AWS’ current generation instance types use HVM AMIs and some of them (T2, I2, R3, G2, CR1, and CC2) don’t support PV virtualization. Some of the previous generation instance types (T1, C1, M1, and M2) using PV don’t support HVM virtualization. To avail the advantages of the current generation instance types, it becomes necessary to convert PV to HVM.
Business Perspective:
The alternatives to the previous generation instance types in the current generation instance types provide enhanced performance in CPU, Memory, I/O or in all of the three categories, with low costs.
You can find the pricing of the current generation instances on the AWS official page: http://aws.amazon.com/ec2/pricing/
How to convert PV to HVM:
To convert PV to HVM, we need to take the following steps:
- Launch a fresh instance with current generation instance type, say “CurGenInstance”.
- Attach the root volume of the previous generation instance to “CurGenInstance”.
- Make that volume as root volume of the “CurGenInstance”.
- Take AMI of “CurGenInstance”.
- Launch the instance with current generation’s instance type using created AMI.
The above process will ensure that your data on the EBS volumes attached to the concerned instance will be safe and type of the instance will be changed to current generation instance type.
Let’s see how it can be done on CentOS:
Prepare the instance:
- SSH into your instance say “OldGenInstance”, and ensure grub is installed:
- yum install grub –y
- Stop “OldGenInstance”.
- Create a snapshot of the root volume of “OldGenInstance” and create its volume, tag it as “OldGenVolume”.
- Launch an instance with the current generation instance type say ”CurGenInstance”.
- Attach “OldGenVolume” to “CurGenInstance”, attach it is as “/dev/sdc”.
- Create another volume with same size as ”OldGenVolume”, say “CurGenVolume”, attach it as /dev/sdv to the “CurGenInstance
Prepare the volumes:
- SSH in to “CurGenInstance”
- Partition the new volume
- parted /dev/xvdv --script 'mklabel msdos mkpart primary 1M -1s print quit'
- partprobe /dev/xvdv
- udevadm settle
- Minimize the file system size of the “OldGenVolume” to speed up the copying process:
- e2fsck -f /dev/xvdc
- resize2fs -M /dev/xvdc
- Copy down the block size and count values from the resize2fs output.
- For example:
- Resizing the filesystem on /dev/xvdc to 4194048 (4k) blocks.
- Make a raw copy from the old volume to the New Volume, using the exact values of “bs=4K” and “count=4194048” from the previous output:
- dd if=/dev/xvdc of=/dev/xvdv1 bs=4K count=4194048.
- Resize the filesystem on New Volume:
- resize2fs /dev/xvdv1
Setup Grub:
- Prepare the New Volume for the chrooted Grub installation:
- mount /dev/xvdv1 /mnt
- cp -a /dev/xvdv /dev/xvdv1 /mnt/dev/
- rm -f /mnt/boot/grub/*stage*
- cp /mnt/usr/*/grub/*/*stage* /mnt/boot/grub/
- rm -f /mnt/boot/grub/device.map
- Do an offline Grub installation on the New Volume, which is required for the HVM instance
- cat <<EOF | chroot /mnt grub –batch
- device (hd0) /dev/xvdj
- root (hd0,0)
- setup (hd0)
- EOF
- Remove the temporary device from the destination volume, which was required to install Grub:
- rm -f /mnt/dev/xvdv /mnt/dev/xvdv1
- Get the filename of your boot files:
- ls /mnt/boot/vmlinuz*
- ls /mnt/boot/initramfs*
- rm -f /mnt/dev/xvdv /mnt/dev/xvdv1
- Edit the Grub config:
- vim /mnt/boot/grub/grub.conf
Ensure that your configuration looks similar to this example, and that file names match the files in /mnt/boot:
default=0
timeout=0
title XXXXXXXXXXX
root (hd0,0)
kernel /boot/vmlinuz-3.2.28-45.63.amzn1.x86_64 root=LABEL=/ console=ttyS0
initrd /boot/initramfs-3.2.28-45.63.amzn1.x86_64.img
Note:- root(hd0, 0):- refers to disk 0 (the first disk), and the First partition (partition 0), which is /dev/xvda
- Edit the fstab file:
- vim /mnt/etc/fstab
- Ensure the first line for the root (/) entry matches this sample:
- LABEL=/ / ext4 defaults,noatime 1 1
- Create a label on /dev/xvdv1, and un-mount the volume:
- e2label /dev/xvdv1 /
- sync
- umount /mnt
Create a new HVM AMI:
- Configure AWS CLI tools with the temporary IAM Power User account:
- aws configure
- AWS Access Key ID None: XXXXXXXXXXXXXXXXXXXX
- AWS Secret Access Key None: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
- Default region name None: us-east-1
- Default output format None: json
Note: If you are unable to configure aws credentials using “aws configure” then export all the credentials as environment variables.
- Create a snapshot of the New Volume:
- aws ec2 create-snapshot --volume-id vol-xxxxxxxx --description "HVMSnapshot"
- Register new HVM AMI (replace snap-xxxxxxxx with the snapshot ID created above):
- aws ec2 register-image --name "CurGenAMI" --description " CurGenAMI " --architecture x86_64 --root-device-name "/dev/sda1" --virtualization-type hvm --block-device-mappings "[{\"DeviceName\": \"/dev/sda1\",\"Ebs\":{\"SnapshotId\":\"snap-xxxxxxxx\"}}]"
Bingo, now you are ready to launch the newly created AMI with the current generation instance type!
