Virtualisation lets a single physical server run several independent virtual machines. Its benefits, risks such as a single point of failure, snapshots and licensing, and how to plan the migration.
In many businesses the number of servers grows with each new need: one server for accounting, another for file sharing, one more for a new application. Each needs its own hardware, warranty, power and maintenance, and most run using only a small part of their capacity. Virtualisation is a common way of bringing this sprawl together, but alongside its benefits it brings risks of its own.
What is virtualisation?
Virtualisation means sharing the processor, memory, disk and network resources of a single physical server among several independent virtual machines. Each virtual machine runs its own operating system and applications as if it were a separate computer; a software problem or restart in one does not affect the others.
The software that manages this sharing is called a hypervisor, and the physical server the virtual machines run on is called the host.
Two types of hypervisor
Hypervisors used on servers are usually installed directly on the hardware (bare-metal, or type 1). With no separate operating system in between, they run more efficiently and reliably. Hypervisors that run like an application inside the existing operating system of a desktop computer (type 2) suit tasks such as testing, training or trying out an old program; they are not the choice for a company's live systems.
Virtual servers you rent in the cloud are based on the same technology; the difference is that the host is run for you by the service provider. This article focuses on using virtualisation on your own premises.
What does it bring to the business?
Less hardware, less energy
Several old servers each using a small part of their capacity can be consolidated onto one or two powerful hosts. Fewer physical devices means less electricity, less cooling, and fewer warranties and maintenance contracts to keep track of.
Independence from hardware
A virtual machine is really a handful of files sitting on the host. When hardware ages or fails, the virtual machine can be moved to a new host without reinstalling the operating system and applications. The familiar physical-server problem of "the old system doesn't recognise the new hardware" largely disappears.
Fast setup and safe testing
A new server can be created quickly from a ready-made template. It becomes easier to try an update or a new application version in a copied environment without putting the live system at risk.
Easier backup and recovery
Backup tools that understand virtualisation can back up an entire virtual machine in one go. After a failure, instead of rebuilding the server from scratch, you can restore the whole virtual machine from backup onto another host, which can shorten recovery time.
Adjusting resources as needed
Adding memory or disk to a virtual machine can often be done from spare capacity on the host, without buying new parts. As long as the host has room, growth can be planned more flexibly.
| Topic | A separate physical server for each job | Virtualised environment |
|---|---|---|
| Hardware and energy | Each server is a separate device with its own power and maintenance | Fewer devices; resources are shared |
| Need for a new server | Hardware must be bought and installed | Quick setup from a template if the host has capacity |
| Hardware renewal | The system is reinstalled on new hardware or migrated with effort | The virtual machine is moved to another host |
| Impact of a failure | A device failure usually affects a single service | A host failure affects every virtual machine on it |
Things to watch out for
One host, one point of failure
When you consolidate five servers onto a single host, a motherboard or disk controller failure in that machine stops five services at once. To reduce this risk there are high availability setups using two or more hosts and shared storage: when one host fails, its virtual machines are restarted on another. This does not provide uninterrupted operation; there is a short outage while the virtual machines start up again. Remember too that the shared storage can itself be a point of failure.
Staying with a single host is also a valid choice. What matters is that the risk is taken knowingly, that response time is shortened with a hardware support agreement or spare parts, and that restoring backups to different hardware has been tested.
A snapshot is not a backup
A snapshot records the state of a virtual machine at a given moment; for example, you take one just before an update and return to it if something goes wrong. But a snapshot sits on the same storage as the host and depends on the original disk. If the disk fails or ransomware reaches the storage, the snapshot is lost too. Snapshots left in place for a long time grow, fill the disk and degrade performance.
Use snapshots as a short-term undo tool and delete them when you are done. A real backup is a copy of the virtual machine kept on separate storage, with a tested restore. On servers such as databases and user directories, reverting to an old snapshot can cause data inconsistencies, so follow the backup method the manufacturer recommends.
Over-allocating resources
Hypervisors can allow you to assign more processor or memory to virtual machines in total than physically exists. This can be efficient when the virtual machines are not busy at the same time, but when they all come under load together the whole system slows down. Be especially cautious with memory.
Disk performance is often overlooked too. When several virtual machines share the same disks, a database doing heavy reads and writes can slow the others down. In small environments, enough memory and fast disks (SSDs) often matter more than the number of processors.
Licensing
In a virtual environment, the licensing rules for the operating system and some applications can differ from those on a physical server; the licence requirement may depend, for example, on the number of physical processor cores in the host or the number of virtual machines running. The hypervisor itself may also come in different editions with annual support subscriptions. Before migrating, confirm the licensing terms with an authorised reseller or the manufacturer's documentation.
Securing the management interface
Anyone who reaches the hypervisor's management console can shut down, delete or copy every server, which makes it an attractive target for attackers. Keep the management interface on a separate management network away from the user network, don't expose it to the internet, use multi-factor authentication where possible and give each administrator a personal account. Follow hypervisor updates as closely as you do server operating system updates.
Applications that need special hardware
Applications that depend on a physical connection, such as a USB licence key, a special expansion card or a serial port, need extra planning when moved to a virtual environment. Identify them before migration and test in advance how they will work in the virtual environment.
How to plan the migration
- Take an inventory. List your current servers, the applications on them and how they depend on each other.
- Measure real usage. Monitor each server's processor, memory and disk usage for a few weeks, covering busy periods such as month-end. Size the host on this data, not on guesswork, and leave room for growth.
- Check compatibility. Confirm that the chosen server hardware is among the hardware the hypervisor supports, and that your applications are supported in a virtual environment.
- Set up backup first. Have the backup routine ready, and a restore tested, before the first virtual machine goes live.
- Migrate in stages. Tools that convert a physical server into a virtual machine make the job easier; even so, move servers one at a time, starting with the non-critical ones, and verify each with its users afterwards. Keep the old physical server switched off but ready for a while.
Checklist
- Has the real processor, memory and disk usage of the current servers been measured?
- Is it clear where, and how quickly, virtual machines will be restored if the host fails?
- Are snapshots used only short term, with real backups kept on separate storage?
- Is the total memory assigned to virtual machines monitored against the host's physical memory?
- Were operating system, application and hypervisor licensing terms confirmed before migration?
- Is the management interface on a separate network and protected with multi-factor authentication?
- Are hypervisor and host firmware updates being followed?
- Have applications that need special hardware or a USB licence key been identified?