There are many different methods to virtualize an operating system. In this video, you’ll learn about hypervisors, type 1 and type 2 virtualization, CPU support, network requirements, virtual desktop infrastructure (VDI), and containerization.
To be able to take advantage of virtualization, you need something that is going to manage the process of keeping all of these different systems running. This is the Virtual Machine Manager, often referred to as the hypervisor. The hypervisor is the software that manages this entire interaction between the virtual world and the physical system it’s running on.
Hypervisors can run on almost any system, but many modern hypervisors can take advantage of CPUs that have specifically been built with virtualization in mind. And once this hypervisor is running, it can allocate CPU cycles, memory, networking information, and keep all of that separated between all of the different virtual machines.
To understand more about how all of these different operating systems interact with the hypervisor, I’ve created this block diagram that starts at the very bottom with the hardware. This is the physical system that the hypervisor is running on. On top of that hardware is the hypervisor, and above the hypervisor are all of the different virtual machines. You’ll notice that each virtual machine has its own guest operating system and applications running within that OS.
Since each one of these virtual machines has its own guest operating system installed and running, there is a significant amount of overhead that takes place every time you start a new VM. This means you’ll need enough CPU cycles, enough memory, enough drive space for all of these VMs to operate simultaneously on the same physical piece of hardware.
This type of hypervisor that sits right on top of the hardware is known as a type 1 hypervisor. You might also hear this referred to as a bare metal hypervisor. That’s because there’s no operating system down at the lowest level. The hypervisor effectively is the primary operating system that is running on top of this hardware. Examples of a type 1 hypervisor would be VMware’s ESXi or Microsoft’s Hyper-V.
If you’re running a hypervisor on your own desktop, then you’re running a type 2 hypervisor, or a hosted hypervisor. This means you would have the hardware that you’re currently using for your computer. You have the normal operating system that you’re using. You might be running Windows as the primary operating system on your computer. I’m running MacOS 10 on my computer. And that operating system is where you would use all of your native applications.
On top of that operating system, we would then run some hypervisor software. On your system, you might be running VMware Workstation, Oracle VirtualBox, or Parallels Desktop to be able to provide that hypervisor running on top of your current operating system. At that point, the type 1 hypervisor VMs and the type 2 hypervisor VMs are exactly the same. The only difference is how you’re running those VMs. With type 1, it’s running on bare metal, and on type 2, it’s running on a hosted operating system.
We mentioned earlier that some CPUs have been specifically constructed to work in a virtualized environment. If you’re running an Intel processor with this support, they refer to this as Virtualization Technology, or VT. If you’re running an AMD processor, this same type of functionality is called AMD-V.
The hypervisor is allocating memory to each of these virtual machines, and it’s using parts of your physical memory inside of your system. So you have to make sure that you have enough RAM in your computer to be able to support all of these different virtual machines running simultaneously.
And of course, each of those virtual machines contains a complete installed operating system, the applications that run in that operating system, and the data that you store in those applications. That means you’ll need enough drive space to be able to support a fully built operating system and all of the necessary applications in each one of those VMs. And from the networking perspective, you have complete control over how that virtual machine is able to interact with other devices in the outside world.
Most of the hypervisors that you’ll run on your local computer, the client-side virtual machine managers, have their own virtual networks that are configured internally to your system. This means the hypervisor will be in control of determining whether that VM can only communicate to itself, or if it can communicate outside of that VM to other devices.
Some hypervisors will configure a shared network address. This means that the hypervisor has its own IP subnet that’s different than any other network that you’re currently using. And when devices on that network need to communicate out to the physical network, it performs a network address translation to be able to communicate outside the scope of that hypervisor.
You can also configure a virtual machine to look and act as if it’s any other device that’s on your local network. We refer to this as a bridge network address. There’s no network address translation, and all of your virtual machines have the same IP subnet and act as if they are on your same local network. And if this is a highly secure virtual machine that should not be communicating to any other devices, you can configure your hypervisor with a private address so that virtual machine can only communicate with itself and any other devices that you decide.
Security is always a concern when you’re running so many different operating systems on one physical device. Fortunately, there have not been any significant security breaches relating to hypervisors, but this is something that hypervisor manufacturers and developers are always aware of.
One type of security vulnerability that is top of mind for these hypervisor developers is a VM escape. This is when malware might find itself onto one virtual machine and use a flaw in the hypervisor to be able to communicate to other virtual machines that are supported by that same hypervisor.
This would obviously be a significant issue if someone was able to do this. This would allow malware that would normally be isolated on one single virtual machine to be able to reach out and control or access data that might be on a different virtual machine. This would obviously be a significant security concern, and thankfully, we’ve not seen any significant breaches that are related to a VM escape.
Of course, each of these virtual machines is its own self-contained operating system, and we have to be sure that we configure the security for that virtual machine as if it was a standalone workstation or standalone server. This means we would use traditional security controls on those devices. We would configure a firewall. We would install the appropriate anti-malware software and configure the operating system to be hardened, just like any other OS.
One technique that some attackers like to use is to publish a virtual machine on the internet for anyone to be able to download and use. But of course, these malware authors are embedding their malware inside of that VM. And when you start running that virtual machine on your own environment, you’re running an operating system that is already infected with the malware.
This is why it’s always a good idea to build your own virtual machines so you know exactly what software is running in those devices. And if you are downloading a virtual machine from the internet, make sure that you are completely aware of the information that is contained on that VM and that you’re taking the appropriate security mechanisms to keep that VM and all of your data safe.
Well, if we can run a separate operating system in a window on our desktop, why can’t we virtualize the entire desktop? That is a technology known as Virtual Desktop Infrastructure, or VDI. This means that your desktop would run as a virtual machine on a separate device, commonly across the network or in the cloud, and the only thing that you would really need on your desk is a keyboard, a mouse, and some type of display. Sometimes you may hear this referred to as Desktop as a Service, or DaaS.
This means you don’t need a significant CPU, a lot of memory, or even a lot of storage on your local computer. All of the work is done on the virtualized client that’s running on that virtual system. Obviously, we are sending information to update the screen that is running on our local device, so we obviously need some type of network communication. But these days, we tend to have significant bandwidths available to us, which allow us to run technologies such as virtual desktop infrastructure.
Once you’re running the virtual desktop, it looks, acts, and interacts with you exactly like a normal OS. From the user’s perspective, they’re running an operating system that’s running on their local device, even though they’re really running this OS as a virtualized system across the cloud.
We mentioned earlier that virtual machines need their own operating system installed on each individual VM, and that adds some significant overhead to the entire virtualization process. But what if you could remove that operating system component and only virtualize the applications? That’s the idea behind application containerization, where you have separate containers that are built for every application that you’d like to run on that operating system.
Just like a virtual machine, each one of these apps is self-contained. It has no idea that other application containers happen to be running on that same physical system, and none of those containers are able to interact with each other unless you configure that in the containerization software.
And since there is no operating system, the entire container image is much smaller than the traditional virtual machine. This makes this very lightweight. You’re able to transfer them very quickly from one place to the other, and they’re very portable, which means you can move them from one physical device to another without making any changes to the application container.
So here’s a side-by-side view of a traditional virtualized application configuration and a containerized application configuration. You can see in the virtualized applications that each one of the VMs has their own guest operating system, but the containerized applications have a single-host operating system. This certainly simplifies the process of managing the operating system, since there’s only one OS that you’ll need to patch, update, and maintain.
On top of the host operating system, you would run containerization software. One of the most popular is Docker. And then on top of Docker, you would have the individual Docker containerized applications.
One significant difference in containerized applications is they’re relying on that host operating system, which generally means that each one of these applications must be configured to run on that host OS. You generally would not be able to run a Windows container, a Linux container, and a MacOS container all on the same version of Docker. Of course, if you were running VMs, you could have different guest operating systems on each of those, but of course, your trade-off is the overhead that you have with a virtualized application.