10 questions answered about virtualisation

How do I use a virtual machine (VM)?
Virtual machines require a piece of software called a hypervisor or host to run. There are a handful of free or inexpensive hypervisors, such as Virtualbox, VMWare and Hyper V.

Once you've downloaded and installed a hypervisor, you can run as many virtual machines as your machine can handle.

What kind of hardware do I need to run a VM?
Most modern desktop computers are more than capable of running 2-3 small virtual machine instances at the same time. The host machine's resources, such as processor power measured in cores, random access memory (RAM) measured in gigabytes and store space measured in gigabytes, are shared amongst the VMs.

How big does my host machine have to be to accommodate multiple instances?
The capability of a machine to run VMs is dependent on the size of its resources and the demands of each VM. A typical VM today will request 1GB of RAM, 2 processor cores and 30GB of storage space. A typical host desktop today might have 8GB of RAM, of which about 6GB is usable whilst running other applications, 4 cores and around 1000GB of disk space.

How can my host machine run several VMs simultaneously?
Processors have physical cores. These cores are in themselves miniature processors and often contain all the components you'd expect to find in a standalone processor such as arithmetic processing units, registers, but they share critical infrastructure that allows them to communicate with other cores efficiently. The parallel processing this facilitates is the reason one host can support multiple VMs. In fact the algorithms that schedule threads onto these cores are so efficient, you can often over allocate VMs to physical cores.

What are virtual cores?
Most processors use complex pre-processing pipelines that make really effective use of the physical cores. Some processors are capable of scheduling many instructions to run simultaneously, even within a single core. The challenge therefore is keeping the pipelines full. There are fundamentally two ways to do that. Either the chip can delay execution, reorder and optimise the instructions and wait until the pipe is full. It can't predict the future, so the introduction of this delay is a necessary evil, but as users we don't particularly care for these delays. The alternative is to lie to the operating system. The processor pretends to have more cores than it really has, by creating virtual cores. The operating system is running multiple applications, so schedules execution for each of the applications to all of the available cores, not knowing that some are physical and some virtual. The processor then reorders instructions in real-time to execute all the instructions assigned to virtual cores to physical cores. It's a neat trick that can lead to dramatic efficiency improvements.

VMs also refer to virtual cores, albeit in a slightly different context. Virtual cores in the hypervisor are similar to virtual cores in the processor, but rather than the virtualisation happening in hardware (like Intel's Hyperthreading), it's running in software in the hypervisor.

Will running VMs slow down my machine?
Most machines use less than 15% of their available processing power for most of their life. Sharing those resources amongst more applications and virtual appliances, such as VMs, means that figure rises. The aim is to use as much of that power as possible more of the time, without ever creating a resource crunch, when the applications' demand outstrips the host machine's supply. By adding up the combined demand of each VM, and keeping that figure at only 80% of the machine's capacity, you are unlikely to experience any noticeable slow down.

What does a VM provide?
In the same way you can run applications on the host machine, you can run them in a virtual machine. VMs are simply a way of bundling applications (apps), operating systems and their settings. Crucially, those settings are contained. They won't interfere with your host operating system or the other virtual machines. That means that you can be 'rougher' with a virtual machine than you would with your main workstation.

Transportable
VMs are easily transportable. Simply power down the VM on one host, copy the files via a network or USB drive, and power on the VM on a new machine. Say you're a developer, you might like to work on a powerful, multi-screen desktop workstation when in the office, but a lightweight laptop when out and about.

Restorable
You can shutdown and keep a copy of a VM. That means that should you later corrupt your VM, you can destroy it and revert to your previous copy. VM images also tend to compress well, so a gzipped tar (.tar.gz) or zip (.zip) file often reduces to 20-25% of the original size. This is a great feature for major backup events (corrupted drives, power cuts etc.) but it's worth having several backup policies. When creating and destroying machines, physical or virtual, it's easy to forget you've worked on a set of files unless you're careful to back them up or commit to a version control system prior to destruction.

Snapshots
Many hypervisors also support snapshots that allow you to roll a VM back to a previous state. They typically perform some clever analysis to work out and store only what's changed between snapshots, which is very disk efficient, though it does introduce another potential point of failure as you'll need the original VM and the latest snapshot to reliably restore.

Copyable
You can have multiple copies of a VM, which is very handy if you want to set up an array of experiments in identical environments. Similarly if you want to try out a variant of your application, setup or configuration, you can do that on a VM then destroy it afterwards.

Why do I need a VM? Can't I just install all the apps on my host machine?
Often an app provider will supply their app for a number of platforms, but not always.

Why aren't there 10 questions in this article?
Oh but there are.