Running multiple operating systems on a single desktop system has become relatively commonplace. In this video, you’ll learn about client-side virtualization and the steps required to run, secure, and network virtual machines.
Virtualization technology allows us to run multiple operating systems on one single desktop at the same time. For example, you could have a macOS desktop, and on that desktop you’re running Windows 11, Linux Ubuntu, and other operating systems all simultaneously. To each individual operating system, it looks like the OS has its own CPU, its own memory, and its own storage. But the reality is that all of those operating systems are sharing the same hardware on your single device.
Some virtualization software can run on your desktop, so you might be running macOS and running all of these other operating systems on top of your primary operating system. Or you might have a standalone server that hosts multiple virtual machines on that hardware. This would be the type of virtualization you would commonly find in a data center or enterprise environment.
As it turns out, this is not new technology. It’s something we’ve been using since the ’60s with IBM mainframes. But we’ve taken the idea, moved it into the PC environment, and now we’re able to virtualize across all of these different operating systems. One use of this virtualization is to use legacy software on an older operating system, while at the same time running the latest operating system on your desktop.
So you could run Windows 10 on one virtual machine, Windows 11 on another virtual machine, and run different software in each of those operating systems. This can be especially helpful if you have a very old or legacy type of software that will only run on a very specific type of operating system. You could create a VM, or virtual machine, just for that older operating system. Run your old software while at the same time still running your modern OS.
Here’s a better view of running these multiple versions of operating systems on one single desktop. I’m running macOS on my primary desktop, and I have a virtual machine running Windows 10 Pro and another virtual machine running Windows 11 Pro. This means that I could use my macOS desktop, or I could run things in Windows 11, but I could still run different types of software that may be limited to only using Windows 10.
This virtualization is also useful if you need to run different operating systems at the same time. We’ve already mentioned the ability to run macOS, Windows, and Linux all on the same desktop at the same time. This allows us to use one single physical device but still take advantage of all of the strengths associated with these different operating systems. This also means that we don’t have to create different partitions or reboot every time we’d like to use a new operating system.
With virtualization, we can simply move our mouse from one window to another, and we’re instantly using that OS. This obviously saves a lot of time and a lot of resources, and we don’t have to purchase a lot of different devices. We can simply use our existing desktop to run many different operating systems at the same time.
Here’s a better view of this macOS desktop. I’ve got a macOS browser running on the left side. We’ve got Linux running in the middle, and over on the right, we’re running a copy of Windows. The software that’s able to keep track of our storage our memory, our CPU, and everything else between all of these different virtual machines is called the hypervisor. Sometimes you’ll hear this referred to as the virtual machine manager, which really does describe exactly what the software is doing.
We’re able to run multiple operating systems, but the memory the storage, the networking, and everything else is managed as if it is its own single OS. It’s not uncommon for a hypervisor software to be able to take advantage of virtualization capabilities that are already in your system. For example, many CPUs have hardware-based virtualization built into the CPU itself, and indeed, some hypervisors require that you’re running that type of CPU. So make sure you check the documentation for your system to ensure that your CPU is ready to be used with virtualization software. Once that capability is enabled in your CPU, you can load the virtualization manager, which will be able to manage the CPU, the networking, security, and anything else between all of these virtual systems.
If you’re running on an Intel platform, the hardware that’s built into the CPU is called virtualization technology, or VT. If you’re using an AMD CPU, the technology you’re looking for is AMD-V. If you’re planning to do any virtualization on your desktop, you want to be sure you have plenty of RAM. Every operating system is going to use a significant amount of memory, so you want to be sure you have plenty of RAM available for all of the VMs that you plan to run.
Along with memory, we need somewhere to store all of these virtual machines, and it’s not unusual for a single operating system to require multiple gigabytes of storage space. So make sure you have plenty of room on your storage devices to be able to install and store all of the information associated with that operating system. And of course, that virtual machine will probably need to communicate to other devices on the network or perhaps the internet, so you want to be sure that each guest operating system is configured with the proper network configuration.
The term “sandboxing” has a lot of different definitions in information technology, but for this video, we’re going to talk about sandboxing in the context of doing application development. And virtualization is a perfect resource for someone who will be building their own applications. An example of how a developer might take advantage of a VM is through the use of an isolated testing environment. So you could load all of your software that you’re developing onto a single VM but limit how much access that virtual machine might have to other parts of the network or to production data.
The developer could run all of their test code within this VM and know that they would not have any effect on any production systems. This gives the developers some space to try some different things. So they could implement some changes to the code, run that code in a VM, and see what results might occur. Virtual machines also have the ability to create snapshots. So we could take a snapshot of one VM configuration, make changes to that VM, and then later on, if we wanted to go back to the original configuration, we simply click on an older snapshot, and we’re back to where we started.
Working in a VM, especially a virtual machine that is exactly the same as a production network, is perfect for a developer. They can begin writing code in an environment that is a mirror image of the production systems. And then once the application is finished, that can be moved into a virtualized environment used for testing. This allows the developers to test in an environment that is very close to what the production network might be without having any effect on the availability of the production systems.
One of the concerns when you’re using all of these different operating systems and virtualized environments on one physical device is how secure each one of those VMs may be from each other. And of course, this is always a concern for the IT security professionals. One major concern when running these virtual environments is VM escaping. This is when malware might run on an existing virtual machine and somehow gain access to parts of the hypervisor itself.
Once the malware gains access to the hypervisor, it’s then able to hop to any of the other virtualized systems that are managed by that hypervisor. Obviously, this would be a significant vulnerability, but in the past we have identified certain hypervisors where we were able to perform a VM escape. These vulnerabilities were not in the wild. So they were found and fixed before any hacker had a chance to take advantage of them. But it certainly speaks to the capabilities of having VM escaping, and it’s always something IT professionals have to think about with security in a virtualized environment.
This is an obvious concern if you’re using hosted services for your virtual machines, where there are many different customers on the same physical platform. If someone was able to perform a VM escape, they could potentially gain access to data from many different customers. Just because you’re running an operating system as a virtual machine doesn’t somehow make it more secure. You still have to provide the same security controls that you might use for a traditional physical device running a single operating system. So you might install a host-based firewall. There might be antivirus software running on your operating systems and anything else that you might use to help keep that operating system safe.
If you go look for pre-installed virtual machines on the internet, you will find thousands of options available for you to download and immediately start using. But if you’re not the one who created that VM, you have no idea what software might be running inside of that operating system. The attackers know this, and they will encourage you to download and use their rogue VM on your system. As a general rule, any virtual machine that comes from someone other than yourself does have the potential to have this malware inside of it, so it’s always best to build your own virtual machines and to never download and use a VM from a third-party source.
There are many different ways to configure the networking that is used between all of these different VMs that might be running on a system. Every single virtual machine has its own network configuration, and you on the hypervisor can determine how that virtual machine is able to communicate. One configuration you might choose is a shared network address, where the virtual machine has exactly the same IP address as the physical host that it’s running on.
The virtual machine itself would be using a private IP address and then it would be using network address translation to be able to communicate using the IP address of the hypervisor. A more traditional networking configuration would be a bridged network address, where every VM has its own IP address. When you start up a virtual machine, it goes through exactly the same process for obtaining an IP address as any physical device that’s connected to the network. This means that every virtual machine has a different IP, other devices on the network are able to access the virtual machine using that unique IP, and you don’t have to worry about network address translation or the hypervisor doing any type of translating.
And if you wanted to lock down a VM so there was no communication outside of that local virtualized environment, you might want to configure a private address. In that case, you’re not receiving an address on the network. You’re not performing network address translation. Instead, that virtual machine is not able to communicate outside of the virtual network used amongst all of the other VMs.