This article discusses the recent change that has taken place with AWS EC2 virtualization options. We will look into AWS’ virtualization backend and what it means for AWS users in general and N2WS, in particular. For a bit of background, up until recently, the AWS cloud supported a virtualization type called Hardware Virtual Machine (HVM) for Windows instances as well as ParaVirtualization (PV) for Linux instances.
While these are both Xen technologies, they are slightly different. PV requires an added layer of software (i.e. kernel) between the designated hardware and virtual machines, and HVM runs directly on hardware and can make use of special hardware extensions.
The EC2 Move
A few months ago, AWS started to give users the option to run Linux instances on HVM, which, as mentioned above, is the virtualization type that is used for Windows. AWS is probably encouraging users to move to a new generation of instances so that HVM virtualization can become the new standard for Linux and they can stop supporting PV at some stage.
The one disadvantage of running PV as opposed to HVM was the fact that you needed a region-specific kernel object for each Linux instance. That way, if you wanted to recover an instance in another region, you had to find a kernel that matched, which could be a very cumbersome task.
However, with the new HVM, the OS runs directly on the virtual hardware, so there is no need for a kernel object. While PV used to be considered more efficient than HVM, and provided better performance in terms of networking and storage, according to Amazon, that is no longer the case with their new EC2 drivers.
“Historically, PV guests had better performance than HVM guests in many cases, but because of enhancements in HVM virtualization and the availability of PV drivers for HVM AMIs, this is no longer true. This virtualization type provides the ability to run an operating system directly on top of a virtual machine without any modification, as if it were run on the bare-metal hardware.”
Amazon encourages the use of the latest generation of instances. All of the new instance types, which are often times better and cheaper than the old instance types, do not support PV at all (e.g. the t2.micro vs. the old t1.micro). So, if you want to use a new instance type, you have to use an HVM based instance.
They even took it one step further by not supporting most of the instance types that are needed for PV in Europe’s new central region in Frankfurt. While you can still migrate a PV based instance to Frankfurt, the cheapest instance type you can use is the m3.medium instance, which is not exactly cheap. So, if you wanted to run a small machine instance with a PV recommendation in Frankfurt, think again. One has to assume that all new regions from now on will not support PV properly, if at all.
Our Experience
A previous issue that the move to HVM has resolved was that of backing up an instance in one region and recovering it in another. With PV, we had to help customers that were interested in doing this find a suitable kernel ID in the recovery region.
This was quite a challenge at times if the initial kernel ID was unique or not standard, which could result in a mismatch. This method is cumbersome and not bulletproof. So, the fact that this process is now taken out of the equation makes life much easier.
In light of AWS’ recent move, and the fact that our product wouldn’t be viable to run in Frankfurt and newer regions, we are now undergoing migration efforts to HVM. Nowadays, a lot of companies in and out of Europe want to move around their resources for a variety of reasons. Even if it weren’t for the new region, you would probably want to migrate to new instance types and take advantage of their benefits. The fact that you don’t need a kernel object for the new HVM instance is a big advantage for companies that perform backup and DR, including us.
