Virtualisation made easy

Enterprise

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:

Intel:

  • 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.

AMD:

  • 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
  • Phenom

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:

cat /proc/cpuinfo

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.

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

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).

VirtualBox

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.

Qemu

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.

Easy installation

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.

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.

Virtual Linux

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.

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.

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:

  1. Click New from the toolbar, then Next to skip past the first page of the wizard.
  2. 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.
  3. Allocate it as much memory as you can afford.
  4. 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.
  5. Back in the virtual machine wizard, click Next to continue the virtual machine wizard, then Finish to create the virtual machine.
  6. Right-click on the new VM and click Settings.
  7. 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.

VirtualBox uses a dynamic disk system, which means space is used only when it's needed.

The following steps are optional:

  1. From the General category, Drag the Video Memory slider up to 32MB.
  2. Click the Advanced tab and enable VT-x/AMD-V (if your CPU supports them - see p41) and optionally also PAE/NX.
  3. 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.
  4. Enable support for USB and USB 2.0 (under the USB category).
  5. 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.

Get snapshotting!

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

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

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

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

First published in Linux Format magazine

You should follow us on Identi.ca or Twitter


Your comments

You have no concept of what

You have no concept of what QEMU is, or how it relates to Xen or KVM. Do your research before spewing this crap onto unsuspecting users!

512M absolut minimum?

I have running virtual linux systems (debian installed via debootstrap) on xen with 64M memory

That is more then enough to run a dns server as example
OK its not enough to run a graphical env but I dont need that

here a top of one of those guests

top - 08:42:46 up 211 days, 12:28, 1 user, load average: 0.07, 0.02, 0.00
Tasks: 44 total, 2 running, 42 sleeping, 0 stopped, 0 zombie
Cpu0 : 0.0% us, 0.0% sy, 0.0% ni, 100.0% id, 0.0% wa, 0.0% hi, 0.0% si
Mem: 65536k total, 63668k used, 1868k free, 7168k buffers
Swap: 131064k total, 1040k used, 130024k free, 14228k cached

KVM @ kernel level?

You are 1 step ahead of the developers i guess. Thanks for spewing nonsense onto the net...

Comments

He gets one thing wrong and you bash the whole article. It's not even that big of a deal. This was just an intro to virtualization. Your overly critical comments are not helpful or even interesting.

Linux Community

The linux community tends to be a bit more critical of this sort of thing, I find...

Great stuff.

This is great stuff, I don't know about you, I find KVM is easy peasy. It's just as easy as qemu and that's easy too. Don't know what these people are moaning about.

Programming emulators tutorials?

Does anyone know where one can get a tutorial on how to start programming a emulator?

qemu rocks but seems somewhat on the slow side

I use qumu to run Windows XP within my Linux system. The hardware I have:

Processor : AMD Athlon 64 X2 Dual Core 6000+
Ram : 4 gigabyte
Native OS : Gentoo (gentoo.org)
OS running in Qemu: Window Xp (service pack 2)
Kernel : 2.6.29

I managed very easily install to Windows XP from a licensed CD I got from the IT guys in our university. Once XP install, I was playing around. I could not install SPSS version 15. Strange. SPSS was the whole reason I wanted install this Windows XP, because SPSS cannot be installed, and it does not even run in XP (even though I have the "offical version" we bought).

I am still keeping this.

The Windows XP starts up relatively quickly. It seems a lot slower, it feels I am running XP on a Windows Pentium 3.

But still, I am really impressed, apart from SPSS, everything I need works. I have a large Windows XP working, it runs in a window 1280x1000 pixels, I have a network connect, I can run the Internet Browser XP comes with (IE6), and it runs the programs like notepad to edit text files, the setting menu.

It takes a little bit to use to Windows, and I find it not so easy to install new software. There is no package manager for free software. I need to go to the web to find software and then download it manually. That seems a hassle.

I successfully installed MINGW, and I am playing around with that to get a linux-like command line with BASH, etc. I guess that is not really the point of installing Windows, but it is a testbed for my linux applications that I want to port from Linux to Windows.

Except for not being able to run SPSS, I am impressed! I generally find XP not a nice as Linux, but at least I can get a look and feel for Windows.

I don't think Windows XP is ready for the deskop though, and I won't install it directly on the harddisk.

...

Gilbert dit you try "-vga std"? then you will have more then 1280x1000
But I dit not test it with windows! (I don't have that game-os)

My portable has 1920x1200 and with the option std My guest has also this resolution

=> "std"
Standard VGA card with Bochs VBE extensions. If your guest OS
supports the VESA 2.0 VBE extensions (e.g. Windows XP) and if
you want to use high resolution modes (>= 1280x1024x16) then
you should use this option.

I also use the option "-vnc" coz there is a bug that if your kvm is not focused it almost stops working

on the comment of "running Xen in 64MB" I think you should give always real information to ppl even for linux n00bs!

You can assume that if you want XP with IE running that it can work with 256M
You only need to disable fantasy stuff like themes (that takes only more memory and cpu for ... nothing?)

You wil have a better performance if you use 256M guest on a 1G memory system then give 512M(exept if your using a program that needs more memory)
This is coz then you will give your main system 256M extra to cache your guest (give it a try, and don't let swap go to high)

It's interesting how much

It's interesting how much stuff uses QEMU/KVM. VMWare does/did to some degree, I think.

I use VirtualBox for all my VM needs, though. Doesn't bother me with regards to Oracle.

VMWare ESXi is the way to

VMWare ESXi is the way to go!

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Post new comment

CAPTCHA
We can't accept links (unless you obfuscate them). You also need to negotiate the following CAPTCHA...

Username:   Password:
Create Account | About TuxRadar