AWS, Cloud Computing, News, Tutorials

5 Mins Read

Steps to convert RHEL-BASED PV instances to HVM

My previous blog will give you an idea as to why HVM instances in AWS are better than PV instances and why people prefer using HVM instances over PV instances. Moreover, the HVM instances offered by Amazon are cheaper than the PV ones. For example, PV m1.medium costs $0.087 per Hour whereas, HVM m3.medium costs $0.070 per Hour. Inspite of the reduced price, we get same memory plus one more extra core with HVM. If you have a PV machine, you should definitely convert it to HVM because of the lower cost and also, PV instances might retire eventually.

Here are the detailed steps for doing so:

These steps are strictly for RHEL based PV instances like Amazon Linux, CentOS, RedHat etc.

1. Login to your instance (SSH) .

2. Install grub on it.

*Grub selects a specific kernel configuration available on a particular operating system’s partitions.

3. Stop the instance and create snapshot of the root volume.

*To overcome the downtime here, you can alternatively create an image of your instance and launch another machine.

4.  Launch an Amazon Linux ‘working‘ instance (PV) and login to that instance.

5. Create a new ‘source’ volume (in the same AZ) from the snapshot created in step 3 and attach it to the ‘working‘ instance as /dev/xvdf. The ideal size of this volume could be kept same as your source instance (Step 1) or it can even be increased.

6. Create a new ‘destination’ volume (in the same AZ) from the snapshot created in step 3 and attach it to the ‘working‘ instance as /dev/xvdo.

7. Next, we partition the destination volume.

a. We use parted for partitioning the destination volume.

*Parted is a program for creating and manipulating partition tables.

Output:

b. The OS  kernel checks the partition table of destination volume which was modified and updates the table.

*partprobe to informs the operating system kernel of partition table changes, by requesting that the operating system re-read the partition table.

c. Update the destination information.

*udevadm settle waits for udevd to process the device creation events for all hardware devices, thus ensuring that any device nodes have been created successfully before proceeding.

8.  Check the ‘source’ volume.  

a. e2fsck is used to check a Linux second extended file system.

Output:

b. Minimize the size of original filesystem to speed up the process and also to eliminate a copy free disk space in the next step.

*resize2fs program will resize ext2, ext3, or ext4 file systems. Run resize2fs to resize the ext2 filesystem to use all of the space in the newly enlarged partition.

Output:

Note: Write down the blocks and 4k values.

9. Duplicate the source volume to the newly partitioned destination volume.

*dd is a command on Unix systems whose primary purpose is to convert and copy a file. Note: Make sure you specify the exact number of bs and count values. (returned from the previous command). The execution of this command might take some time.

Output:

10.  Resize the filesystem on the newly partitioned destination volume.

11.  Next, we have to prepare the newly partitioned destination volume for the chrooted grub installation.

a. Mount the newly partitioned destination.

b. Copy all the files archived from old destination to the newly partitioned one.

c.

d.

e.

12. Next, we do an offline grub installation on the destination device in the chroot environment, which is required for the HVM instance. You need to be a root user to perform this step:

Execute the code below:

13.   Remove the old destination volume from the new destination volume.

14. Updating the new grub configuration.  

*tty prints the filename of the terminal connected to standard input.

Change root (hd0) to root (hd0,0)

– Add (or replace console=*) console=ttyS0 to kernel line.

– Replace root=* with root=LABEL=/ in the kernel line.

– Go to /mnt/boot/grub/menu.lst – *ensure the filenames match the files in /mnt/boot

a.

b.

Output:

c. Once you verify that the filenames are same, save and quit the file (:wq).

15. Update.

*fstab gives you the static information about the filesystems.

Update the root (/) entry in /mnt/etc/fstab, as per the sample fstab below:

Output:

16. Change the label on the filesystem.

a. e2label command changes the label on an ext2 filesystem i.e; /dev/xvdo1

b.

c. Come out of mnt directory and unmount the device:

17. Final Steps. Create a snapshot of the ‘destination’ volume. Select your snapshot and under Actions click Create Image as shown in the below image. Screen Shot 2014-11-04 at 4.43.00 PM

Select Virtualization type as Hardware-assisted virtualization, use the default Kernel ID and click Create.

Screen Shot 2014-11-04 at 4.44.33 PM (1)

Launch instance from the above AMI. The new HVM instance should now boot successfully and will be an exact copy of the old source PV instance (if you used the correct source volume). Once you have confirmed that everything is working, the source instance can be stopped. Cleanup by removing all temporary volumes (source and destination).

Stay tuned to my next blog where I talk about converting Ubuntu-based PV to HVM along with detailed steps.

Let me know if you have any questions by commenting below.

WRITTEN BY CloudThat

SHARE

Comments

  1. Thadikaran

    Feb 12, 2019

    Reply

    The instance is running but not able to connect(SSH). Is there anyone facing the same issue. Our OS is Amazon Linux 2.

  2. Steps to convert UBUNTU-BASED PV instances to HVM | CloudThat's Blog

    Dec 5, 2014

    Reply

    […] previous blog will help you convert Rhel-based PV instances to […]

  3. Click to Comment

Get The Most Out Of Us

Our support doesn't end here. We have monthly newsletters, study guides, practice questions, and more to assist you in upgrading your cloud career. Subscribe to get them all!