Converting an AWS Linux PV Server to a HVM Server

/ Information Technology / By

I’ve had several Fedora servers at AWS for years. I keep the servers updated with the latest releases of packages and Fedora versions, run with SELinux enforcing, etc. Back when I first created the servers we set up paravirtual (PV) servers which use PV-GRUB (a special boot loader) to start them. The problem I ran into is that Fedora 27 64-bit 4.15 kernels would not start. Period. I had everything up to date, including the version of PV-GRUB used to start the server. After some digging around the root issue looked like an issue at the PV-GRUB level and not something with Fedora. As a test I launched a new F27 hardware virtual machine (HVM) system and updated it with the latest packages and kernel. No problem starting.

OK, time to try converting a PV server to HVM. Digging around for that turned up all kinds of how-to posts but they started off with steps such as setting up grub, populating the device (/dev) directory, etc. My virtual server already has grub and the usual /boot separate partition already set up just like a physical server system. The /dev directory is a devtmpfs file system and the device nodes there are added by the kernel. It all sounded like lots of unnecessary work, so as an experiment I decided to try a much more straightforward process. Below is what I did and it all worked perfectly.

For more information on AWS Linux AMI virtualization types check out https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/virtualization_types.html.

Before Starting

General virtual server instance configuration notes for the new HVM server:

  • You can use the key pair that you used for the server you’re replacing. No need to create a new key pair. It’s for the same Fedora system after all.
  • You don’t really care about the size of the storage volume when you’re launching the new HVM instance (step 5 below) since it will be replaced and deleted at the end. The default size for the HVM instance when I created it was 8GB.
  • Create all instances in a virtual private cloud (VPC) if possible. You can change the security group, for example, of a system in a VPC.
  • If you want to create the new instance in a VPC and the security group for the existing PV system isn’t in that VPC then make a copy of the security group and specify in the “make the copy” dialog the VPC you plan to use.
  • Important: Review your /etc/fstab file for any additional storage volumes used by the PV server. Note the device names so that you can attach them with the same names to the new HVM server being created.

One comment that I did find in a few posts that detailed steps to switch to HVM is to add “serial” and “terminal” lines at the top of your grub.conf file (/boot/grub/grub.conf). My grub.conf file now starts like this:

default=0
fallback=1
timeout=0
serial — unit=0 — speed=9600
terminal — dumb — timeout=5 serial console

Problem

Convert a F27 64-bit PV virtual server to a HVM server. No real change to the virtual volume (disk) used by the server. Just change the underlying server virtualization type.

Solution

Create a new HVM server of the same instance type, e.g., m4.medium, as the PV server being replaced. Once created replace the HVM boot volume (disk) with the PV server’s boot volume. This isn’t a true “convert” but rather a replace but it gets the job done and it’s straightforward.

The Steps

1. On your existing PV server run “dnf upgrade” to be sure you have all the latest packages and the latest 4.15 kernel.

2. Edit your grub.conf file (/boot/grub/grub.conf) so that the default kernel that’s used is the latest, i.e., set “default=0”

3. Create a snapshot of the /dev/sda1 volume for the existing PV system. This is so that we can create a separate volume to use for the new server and keep our original volume just in case.

4. Create a new volume from the snapshot. Give the new volume a good, short descriptive name so you can at a glance know which one you should use for the new HVM system, e.g., “Web Server HVM.”

5. Launch a new Fedora HVM instance.

One way:

  • On the “Imgaes” EC2 page click the “Launch Instance” blue button.
  • Select “Community AMIs” on the left.
  • Select Fedora and 32-bit ot 64-bit (should match what your PV system is).
  • Select the latest Fedora cloud HVM-gp2 or HVM-standard image you can find there. Gp2 and standard refer to if you want to faster SSD storage (=gp2) or not. It doesn’t matter what type the storage volume is for the instance since we’ll delete the volume at the end.
  • Finish configuring it and launch it.
  • Update the new HMV server to the latest F27 packages and kernel. If it reboots fine after that then you know it’ll run the 4.15 kernel that’s installed on your PV server since it has the same updates (step 1 above).

Better way:

  • Go to cloud.fedoraproject.org
  • Scroll down to “Fedora 27 Cloud Base Images for Amazon Public Cloud”
  • Click on “Click to launch” on one of the two rows.
  • Click on the little blue cloud image in the row for your AWS region.
  • You’re taken to the AWS EC2 page that’s after where you pick the AMI in the “Launch Instance” sequence of steps. Just like above, finish configuring the instance and launch it.
  • Update the F27 HVM server via “dnf upgrade” to the latest packages and 4.15 kernel.

6. Give the new instance a short, clear descriptive name, e.g., “Web Server HVM.”

7. Stop the new instance after you see that it comes up and passes all the checks.

8. Go to “Volumes” under “ELASTIC BLOCK STORE.”

  • Give the volume created for your new instance a good name, e.g., “Temp Server Root.”
  • Detach it from the new instance.
  • Attach the volume created in step 4 to the new instance and have it use device /dev/sda1 since it’s the boot device. Note: it’s “sda1” and not just “sda.”
  • If your PV server had any other volumes then detach those from the PV server and attach them to the new HVM server. If they need to have specific device names, e.g., /dev/xvdg, then be sure to attach them to the new server with the same names, e.g., /dev/sdg.

9. Go back to the list of instances and start the new instance. After a few minutes it should finish starting and pass all checks.

10. If your old PV server has an elastic IP associated with it then disassociate it with the old server, associate it with the new server, then reboot the new server.

At this point your new server should be ready to go as a HVM server that is identical to the old PV server. Note that on the system you use to ssh to your AWS servers go into your .ssh/known_hosts file and remove all entries for the old server and the elastic IP address.

Cleanup

After a few days to monitor and verify that the new server is working fine you probably want to clean up old resources:

  • Terminate the old server.
  • Delete the old storage volume.
  • Delete the snapshot.
  • If you made a copy of the security group to use for the new server and if the old group isn’t used by any other server then you can delete the old security group.

Other Linux Distros

Will the above work for Ubuntu, Debian and other Linux distributions? I haven’t tested it but the approach above wasn’t specific to Fedora except for the details such as updating packages.

Conclusion

Hope this is helpful. All comments, corrections, etc., are very welcome. If there’s anything I can assist someone with please feel free to contact me at mark.allman@seehowyouski.com.