Virtualisation made easy
Unless you're running a PC more at home in 2001 than today, you can benefit from virtualisation. In fact, we're so utterly convinced that almost every reader will be happier having discovered virtualisation that we've devoted this tutorial to helping you - yes, you - get started with it.
If you've already read our previous Made Easy articles (MythTV made easy, Nagios made easy, LaTeX made easy and LTSP made easy), then you'll know our goal is to help you get up to speed with potentially difficult technologies as fast as possible.
But before we begin, it's important to make sure everyone understands what virtualisation is, how it works, and what kind of computer you need. If you know all that already, go ahead and skip ahead to get moving.
What is virtualisation?
For most people, the operating system is installed directly on to the hard drive and runs on the CPU without any hindrance. This makes a lot of sense, because it's only in the last few years that we've had so much computing power that we can afford to do anything different.
Virtualisation is the process of running one operating system inside another. For example, you can have a perfectly normal Linux distro installed, and install Windows XP inside that distro so that it runs in a window. The Linux distro isn't affected, you don't need to reboot to switch between them, and you get all sorts of extra features for the virtual Windows, such as the ability to pause it to preserve its virtual RAM contents exactly as you left it.
The first attempts at PC virtualisation were essentially very clever software - lots of programmers worked together to create a virtual machine, complete with virtual CPU, virtual RAM and such. The operating system that was being virtualised (usually known as the "guest" to contrast it with the main operating system, known as the "host") didn't realise it was being virtualised at all - all the programs it ran were actually be intercepted by the software and translated on to real hardware.
More recently, a technology known as paravirtualisation has been introduced, which is where the guest OS is modified so that it knows it's not running on real hardware. This allows all sorts of performance improvements, because the virtualisation software (technically known as a "hypervisor") needs to do less work. As you can imagine, this is only possible for operating systems that can be easily modified, giving a strong advantage to the open source world.
Modern CPUs have built-in support for virtualisation, which removes several of the speedbumps in virtualisation so that hypervisors have an even easier job.
The end result of all this technology is that a Linux distro on a virtual machine should be able to run at about 95% of the speed of the same distro on real hardware. Yes, there's definitely a speed hit to using virtual machines, but it's shrinking all the time, and not really that noticeable.
You'll need these
The biggest system requirement is memory: lots and lots of it. In fact, thanks to the, uh, rather rotund size of modern Linux distros, you'll need at least 1GB of RAM to run even one virtual machine - that's 512MB for your main distro (the host) and 512MB for the virtual machine (the guest). If you want to run more than one at a time, just add 512MB RAM more for each one.
Of course, running a distro in 512MB of RAM isn't recommended. In fact, that's the absolute minimum requirements nowadays, and we personally wouldn't recommend serious virtualisation work without 2GB of RAM: 1GB for the host and 1GB for the guest. If you have less than that, everything will work fine, but you'll find there's a substantial speed hit when transferring between the host and the guest.
Once you have enough RAM for your needs, the next most important thing is your CPU. If you have more than one CPU core in your machine, you can run your host OS one one core and your guest on the other. If you have hardware virtualisation, your CPU will be able to take on the hard work of virtualisation, which should guarantee high performance.
If you have one of the following, then you're in great shape:
- A multi-socket motherboard with at least two CPUs installed.
- A dual-core or quad-core CPU.
- Any CPU with hardware virtualisation (VTx for Intel chips, AMD-V for AMD chips).
You probably already know whether you have one of the first two, but the second one can be confusing - particularly because many computers ship with hardware virtualisation disabled in the BIOS. Fortunately, Wikipedia has a cheat sheet - the following chips all support hardware virtualisation:
- Pentium 4 662 and 672, Extreme Edition 955 and 965 (but not Pentium 4 Extreme Edition with HT).
- Pentium D 920 to 960 except 945, 925 and 915.
- Core Duo T2300, T2400, T2500, T2600, T2700, L2000 and U2000.
- Core 2 Solo.
- Core 2 Duo except E6540, E8190, E7xxx, E4xxx, T5200-T5550 and T5750.
- Core 2 Quad except Q8200.
- Core 2 Extreme Duo and Quad.
- Xeon 3000 series.
- Xeon 5000 series.
- Xeon 7000 series.
- Athlon 64 and Athlon 64 X2 with family "F" or "G" for socket AM2 (note: not socket 939).
- Turion 64 X2.
- Opteron 2nd and 3rd generation
Yes, that's a bit tricksy; it's a shame that support can't be universal. If you have an Intel Celeron, Pentium Dual-Core or Pentium M processor, or an AMD Sempron processor, you're out of luck: none of those support hardware virtualisation.
Checking your CPU by hand
There is one way to be almost absolutely sure of whether your CPU supports hardware virtualisation or not, and that's to run this command from a terminal:
We say "almost absolutely" because many motherboards are shipped with hardware virtualisation disabled in the BIOS. To enable it, reboot your PC and go into the BIOS, then make sure any virtualisation options are enabled.
When you run that command, Linux will print out all sorts of information about your CPU. You'll see a large block of acronyms marked as 'flags', containing things such as "fpu", "pae", "cmov" and "mmx". These are all features that your CPU tells Linux it supports. Somewhere in there - probably in the last row - you should see either "vmx" (for Intel) or "svm" (for AMD). If you don't, and you can't see any BIOS option to enable hardware virtualisation, then you don't have it.
Even without hardware virtualisation you can still get good performance from a modern CPU. Not 95%, admittedly, but 80%+, which on a 2GHz+ CPU is barely noticeable.
Reading the output from /proc/cpuinfo will tell you whether hardware virtualisation will work or not.
Getting the software right
There are four main ways to get virtualisation working on Linux: VMware, VirtualBox, Xen/KVM and Qemu. Each has its advantages and disadvantages, so let's summarise the options just quickly...
VMware Workstation is the finest desktop virtualisation system around. You won't get more speed, more ease of use, more features and more operating system support in one bundle no matter how hard you look.
So, that's the good news. The bad news is that VMware Workstation isn't free as in speech or indeed free as in beer - that means you can't get the source code, and it actually costs you money if you want to use it. This is offset a little by the fact that there is a no-cost version available (called VMware Server), but even that must still install a closed-source kernel module that you have to build yourself.
Is it worth the pain? Well, VMware does have multiple snapshots, a super-easy user interface and flawless 64-bit support (even if the host OS is 32-bit).
When we need to distribute virtual machines to readers on the DVD that comes with every issue of Linux Format, we turn to VirtualBox from Sun Microsystems. It's almost as easy to use as VMware, it's almost as fast as VMware (once you enable hardware acceleration if your CPU supports it), and it's slightly more open in terms of its code too.
VirtualBox is closed-source software, but there is an open-source version with some features removed. Sadly those features happen to be support for USB, Serial ATA and Gigabit Ethernet, which makes it rather painful to use. Still, the closed-source version is free to download for personal use.
Xen and KVM
We've grouped these two together, because they are fundamentally similar from an end-user point of view. Both of these work at the kernel level, and both are fully free software, which means they are usually integrated into package managers for easy installation - and are automatically updated if the kernel changes.
Because both of these sit at the lowest level of your system, they are very hard to use. Xen does have some command-line tools for configuration, but KVM was built to work alongside other tools such as Qemu. When it comes to flat-out power and speed, Xen is far away the leader. But unless you want to dive into its tricksy configuration files, you're stuck using Virt Manager to control it, and that limits how flexible it can be.
If you want to keep your system clean of proprietary code, Qemu is the leading virtual machine toolktit around. And we say "toolkit" because you'll find that Qemu exists in various different forms - it's a standalone program, yes, but also acts as a front-end for other virtualisation programs, including Xen and KVM.
When working by itself, Qemu is a bit tricky to learn - all its options are specified from the command line, so you need to be willing to fiddle around to get what you want. On the plus side, Qemu is fantastic for developers because it allows you to peek inside the virtual machine to see its state and can also be configured to work like Valgrind, showing you exactly what a program is up to. It can also, and this sounds less impressive than it actually is from a technical standpoint, emulate non-x86 architectures, which makes cross-platform testing easier.
Let's start with Qemu
The route of least difficulty and most freedom (from a free software perspective) is to use the virtualisation tools built into your distro. And in this respect, Fedora 10 leads the way: if you're looking for quality distro support for virtualisation, Fedora is as good as it gets.
Red Hat has put a lot of work into Xen and Qemu in the past, and purchased the company that produced KVM, so when it came to producing something that allowed people to get to grips with virtualisation without having to make complex choices, Red Hat made something to solve the problem neat: libvirt. This is a programming library for handling virtual machines, and is designed to present a common interface to Qemu, Xen and KVM, so that any other program can say "create me a virtual machine" and not really care about what it uses in the background.
Because libvirt is just back-end stuff, Red Hat has produced a tool called Virt Manager, which is a graphical interface to all the features of libvirt. Because it needs to work with several different virtual machines, Virt Manager offers only a handful of features - if you use Qemu or Xen directly, you have a lot more control. But on the flip side, Virt Manager is very easy to use, and we think that's a worthwhile pay-off.
You can install all the virtualisation software you need to get started using Fedora's Add/Remove Software app (System > Administration > Add/Remove Software). From the category list on the left, choose Virtualization and select all six packages in the group, then click Apply. These will bring in various other dependencies, so it may take a few minutes to download and install it all.
Once that's done, a shortcut to Virtual Machine Manager will appear under Applications > System Tools. Click that, then enter your root password.
By default, you'll have no virtual machines, so the Virtual Machine Manager (VMM) window will be blank. Click File > Add Connection to get started, then change the Hypervisor type to be QEMU and click Connect. This doesn't create any virtual machines - to do that you need to select the item that just appeared in VMM and click the New button.
You'll now be given a short wizard to work your way through. First, give your VM a name. We find it best just to use the distro name and version. You'll then be asked what kind of virtualisation you want. You probably can't change much here, so just click on Forward. It's unlikely you'll use anything other than an ISO or a CD ROM, so just change the operating system type to be Linux and the variant to be whichever distro you want.
Follow the wizard stepthrough to get KVM and Qemu on your side - it's fast and free, but a little short on features.
You will almost certainly want to boot the size of the virtual hard disk file to be 8GB or more. If you want it for serious use, 16GB should be your minimum. You should probably uncheck the Allocate Entire Virtual Disk Now box.
Leave the network settings as the default and click on Forward, then in the next screen allocate at least 512MB of RAM to your virtual machine for both max and startup. You'll get better results with more RAM, but you should keep at least 512MB back for your host OS.
When your virtual machine starts up, Fedora will automatically scale its video resolution to fit into a rather arbitrary size. This inevitably makes the display fuzzy and hard to read, so go to the View menu and disable the Scale Display option.
Once the virtual machine starts, click your mouse in the window to transfer control to it - any mouse movements or keypresses will now be sent to the virtual machine. If you want to get back to the host, just press Ctrl+Alt together. Along the top of the VM's window there are various options: the Play, Pause and Shutdown options function as you might imagine (the VM's RAM gets saved to your host's hard drive for restoring later), but you should definitely take a look in the Overview and Hardware tabs to see what's available to you.
One neat little feature of the Shutdown button is that it interfaces with the guest OS if possible, meaning that pressing Shutdown while running Ubuntu will pop up the Ubuntu shutdown dialog in the guest OS asking you what you want to do.
If you intend to use the virtual machines for server work, you should probably enable Autostart VM - this starts the guest OS when the host OS boots up, which is useful if you rely on it running all the time. Under the Overview tab you can keep track of how much CPU power and RAM the virtual machine is using, and you can even change the amount of RAM allocated to the VM under the Hardware tab.
Back on the Virtual Machine Manager window, you can see the status and resource usage for all the virtual machines you have installed, both those running locally and those running on other machines.
The Virtual Machine Manager shows the activity from all your virtual machines, including how much RAM each one uses and how much CPU power it's drawing.
On to VirtualBox
Installing any closed-source virtualisation system requires you to compile a special module for your kernel. On Fedora that means you need to have the header files for your kernel installed - use Add/Remove programs to install that, as well as GCC. If you followed the previous guide to use the free KVM/Qemu/Virt-Manager combo, you must uninstall KVM before continuing with VirtualBox - the two don't play nicely together.
Once that's done, you need to download and install VirtualBox for your distro. As we write this, there is no VirtualBox RPM file available for Fedora 10, but that's OK - the Fedora 9 one works well enough. Go to www.virtualbox.org/wiki/Linux_Downloads and snag the best file for you - if you're using Fedora 10, that's probably the Fedora 9 i386 RPM file. If there is a newer Fedora 10 RPM, try that first.
If you click on the RPM file from within Firefox, Fedora will offer to open it with Package Installer. Choose that, then go ahead and install the package. There won't be a signed key attached to it, so you'll need to force the install. Once the install completes, a Sun xVM VirtualBox icon will appear in your Appplications > System Tools menu, but before you run that you need to make sure SELinux is OK with VirtualBox running. Go to System Tools > Terminal and run this command:
su chcon -t textrel_shlib_t '/usr/lib/virtualbox/VirtualBox.so'
That will tell SELinux to allow VirtualBox to run normally. Now run VirtualBox from its menu shortcut - click through the EULA then click on Cancel to skip registration, and you're all set to go.
If you want to try using VMware instead, be prepared to mash Enter many (many) times to accept default options, and make sure you have the kernel source for your kernel installed as well as GCC. Be careful: if you're running a PAE kernel you need to install the PAE headers. Also, Fedora doesn't symlink /usr/src/linux to the source for the current Linux kernel, so you'll need to tell the VMware installer to look in /usr/src/kernels/yourkernelversionhere/include.
Our test box uses a PAE-enabled kernel (run uname -r to see what you use), so we need the kernel-PAE-devel package for working with closed-source hypervisors like VMware and VirtualBox.
Once VMware is installed, it will have the same problem as VirtualBox: SELinux will think it's doing something fishy and disallow it from running. Run this command to fix it:
chcon -t textrel_shlib_t '/usr/lib/vmware/vmacore/libvmacore.so.1.0'
Once that's done, VMware should run as normal. Because you're using the VMware Server system rather than VMware Workstation, you need to "connect" to the local computer before creating virtual machines. That's because VMware Server is designed to run in the background on potentially dozens of machines, where one admin can use the user interface to connect to and manage all the machines and their virtual machines at once.
Getting started with VirtualBox
The first thing you'll notice about VirtualBox is that it looks good - the interface shows some helpful information to get you started, and if you've used something like VMware before then you're probably able to dive right in.
Here are the steps you need to follow in order to create any virtual machine:
- Click New from the toolbar, then Next to skip past the first page of the wizard.
- Give your VM a name (eg Intrepid if you're going to virtualise Ubuntu 8.10), then choose the appropriate OS type from the drop-down box.
- Allocate it as much memory as you can afford.
- When prompted for a hard disk, click New then Next to get to a screen specifying how big you want the disk to be. It's probably about 8GB by default; change that to whatever you need. We chose 32GB because we have heaps of free disk space. Click Finish to close the virtual disk wizard.
- Back in the virtual machine wizard, click Next to continue the virtual machine wizard, then Finish to create the virtual machine.
- Right-click on the new VM and click Settings.
- From the left-hand list of options, choose CD/DVD-ROM and check the box marked Mount CD/DVD Drive. This is where you should choose whether you have your distro install disck as a CD/DVD or ISO file.
VirtualBox uses a dynamic disk system, which means space is used only when it's needed.
The following steps are optional:
- From the General category, Drag the Video Memory slider up to 32MB.
- Click the Advanced tab and enable VT-x/AMD-V (if your CPU supports them - see p41) and optionally also PAE/NX.
- Enable Audio (under the Audio category). You should change the Host Audio Driver to PulseAudio if you're using Fedora or Ubuntu as your host OS.
- Enable support for USB and USB 2.0 (under the USB category).
- Once you've configured the settings to your liking, click Start to start the VM. When you click inside the window it will capture all your input until you press the right-hand Ctrl key to return control to the host OS.
VirtualBox isn't free software, and in our experience tends to be about half the speed of KVM/Qemu. So, why use it? Well, apart from the generally very friendly user interface (once you get it installed, that is), VirtualBox also has support for multiple snapshots of a virtual machine. It's not as advanced as VMware's system of allowing snapshots to create trees, but it's better than nothing.
If you haven't tried it before, a snapshot is a complete backup of a virtual machine. For example, if you're about to upgrade Ubuntu from 8.04 to 8.10, there's a small chance that it might go hideously wrong and everything could stop working. Wouldn't it be nice if you could click a button marked "Undo" to go back to 8.04 if such a thing did happen? Sure it would. Of course, that button doesn't actually exist, but Snapshots are a fairly close alternative - save a snapshot before you perform the upgrade, then simply roll back if things go awry.
You can also use snapshots to create a known-working configuration that you can roll back to every time you're finished with the machine. For example, let's say you're a software developer who wants to make sure their app works on Ubuntu. Using this method, you would install Ubuntu then create a snapshot straight away, so you have a completely clean install.
Then you could go ahead and install your software as well as any dependencies you need, and, once you're done, go to Machine > Close and choose "Power off the machine" and check the "Revert to the current snapshot" option - this rolls back any changes you made during that session, so that next time you use the VM it's back to its original clean state again.
At the beginning of this article we said that we were utterly convinced that everyone can benefit from open source, but if you're read this far and you're still not sure, you might just be missing one little point of virtualisation: the full-screen button.
You see, one of Linux's best features is the fact that most distros release updates twice a year. But that in turn happens to be a major weak point, because that means re-installing things, potentially losing data, having to reconfigure basics such as network support (and maybe even having to track down drivers!) and other terrors.
With virtualisation, what you can do is install something like CentOS or an Ubuntu long-term support distro as your main distro. Yes, this means having lots of old software, but bear with us: on top of that distro, you install a virtual machine to use as your main distro. Give it all the RAM you want. Give it a big chunk of your hard disk. Then run it, and switch to full-screen mode. If you're using something super-fast like KVM/Qemu, you'll probably not even be able to tell that you're working inside a virtual machine.
And then you start to enjoy the advantages: snapshots become easy-to-use hard drive backups; saving machine states means you can power off your machine then pick up exactly where you left off the next day; having your hard disk as a file means you can clone your VM or move it to a faster PC without having any fuss at all. You can even install and run multiple VMs at the same time, if you want to - that means you can try every distro that comes free with Linux Format every month, and never have to worry about "will it support my Wi-Fi card?" again - all that is handled by the single, unchanging distro that acts as the host. Virtualisation is the future of computing, but thanks to Linux, you can try it today.
Things to try
Restore sessions: Under the Machine menu is a Close option. Try choosing that then selecting Save The Machine State rather than just powering off - that will allow you to bring the VM back to exactly where it was later.
Save snapshots: VirtualBox lets you save multiple snapshots for each virtual machine. You can switch to any of these at any time, but you only really need one if you're after an emergency backup solution.
Copy VMs: You can move your virtual machines to any other PC, either by copying just the VDI and recreating the virtual machine or by moving the machine and the VDI. Look in the .VirtualBox subdirectory to find the files.
First published in Linux Format magazine