Linux Format|December 2018

Jonni Bidwell learns to master containers and VirtualBox, enabling him to run Linux any time, any place and anywhere…

Jonni Bidwell

Virtualisation has been around since the mainframes of the 60s, where the activities of one program were separated from another. Later, IBM’s CP-40 introduced the notion of a hypervisor and the ability to run multiple OSes concurrently.

Virtualisation proper took off in earnest in the mid-2000s, when 64-bit processors appeared with explicit features for running guest OSes more efficiently. Being able to virtualise machines (in theory) made sysadmins’ lives much easier. Whole systems could be snapshotted, backed up and restored as easily as files. Critical updates could be tested in a virtual sandbox, which vastly reduced the possibility of things catching fire when they were rolled out to physical systems. Multiple VMs could exist on the same system, yet for all intents and purposes be isolated from one another, improving security and efficiency. Home users as well could enjoy the benefits of trying out this “Lye-nux” thing without risking ruination of their incumbent OS.

The hardware has evolved even more since, and you can now pass whole devices to virtual machines (VMs). This makes possible, among other things, running a Windows VM with its own fully accelerated, dedicated graphics card.

After VMs came containers, which rather than implementing a whole OS re-use the host’s kernel and contain just the bits needed to run a particular service or set of services. This enables them to ship with the libraries they require, obviating the problem of conflicting versions when software is installed on a different machine. This makes them more portable than VMs, and to some extent offers a similar level of isolation.

Docker is the industry posterchild here, but there’s more to containers than a single company. Snaps and Flatpaks (see our tutorial on page 72) leverage container technology and are already being used in the stead of traditional packages. This means developers can easily build and rapidly ship distro-agnostic packages, rather than waiting for distro packagers to include their software in the next release.

So whether you want to try out Hannah Montana Linux in a safe environment, or instantiate an entire LAMP stack on your server with a single command, read on!

Virtualisation in a nutshell

We summarise the tech that makes virtualisation possible and fun.

Any old computer can run a virtual machine. People have been running emulators for years a after all. But impersonating a foreign architecture is hard work, so those emulation tends to focus on machines much less powerful than the host.

However, when we emulate a machine that’s architecturally similar to our host, we can take some shortcuts. Instead of emulating the CPU and other hardware we can pass instructions to that hardware. The more of this we do, the more we move from the emulation to the virtualisation end of the spectrum.

To do virtualisation properly, we need a hypervisor that sits above the VM and marshals calls between the guest and host. We don’t want our hypervisor to do nothing, otherwise it would be pointless and allow for a guest to do undesirable things to the host, but we also don’t want it to do too much, either.

Since around 2006, new CPU features (Intel’s VT-x and AMD-V) have enabled the development of elegant hypervisors that fit the bill perfectly. Linux has KVM, Windows has Hyper-V, then there’s the Xen hypervisor, which runs above a privileged, virtualised OS domain (dom0, which can run any OS you like) . Less-privileged (domU) VMs use dom0 for all their hardware access, and the hypervisor at the top ensures everything’s isolated. The security-focused Qubes OS uses Xen virtualisation to keep applications separated. Further CPU innovations (Intel’s VT-d and AMD-Vi) give VMs direct access to peripherals. It’s this magic, together with Open Virtual Machine Firmware (OVMF) and the wonders of the VFIO driver, that allow us to pass a whole graphics card to a Windows 10 VM and have it perform within a whisker of native speed and run all those games that don’t yet work properly with Steam Play.

Virtualisation is also a great way of backing up a physical server. Once you have a virtual mirror or your server, you can snapshot it and experiment with various configuration changes or updates that it would be imprudent to apply in production. If they fail miserably then it’s trivial to roll back and try again. If your physical server fails, then it’s straightforward (in principle) to physicalise (that’s really not a word – Ed) your virtual backup on new hardware. Alternatively, just spin up a copy of this VM – the cloud is full of virtual machines.

Virtual Box

Enjoy a gentle introduction to the world of virtual boxes with the aptly named VirtualBox.

Making your first virtual machine is easy – the hardest part is deciding which platform to use. VMWare and VirtualBox provide free tools for all operating systems (including Linux). On Windows you can use Hyper-V which, with its new Quick Create feature, can spin up an Ubuntu instance faster than you can say “Microsoft’s patent practice evolving in lock-step with the company’s views on Linux and open source more generally”. We’re going to go with VirtualBox because it’s licenced under the GPL version 2 (except for the Extension Pack which provides features like USB passthrough and NVMe devices, not to be confused with the Guest Additions which are now GPL’d too) and because it looks the same on all OSes. Follow the stepby-step guide (below) to getting started, or if you already know the ropes then read on and delve into some of its lesser-known features.

Virtual tweaks

Let’s assume you’ve followed our guide, booted the install medium and installed Ubuntu into your Virtualbox. If not, perhaps you should – just as in the real world, live OSes are much slower than installed ones in the virtual world. When the VM starts you’ll see a message about mouse pointer integration. This is a terribly helpful feature that enables seamless mouse movement between guest and host. When you use guest OSes that don’t support this feature, it’s necessary to use a keyboard shortcut (right-Ctrl) to free the pointer from its imprisonment within the guest window.

The default Virtualbox settings work fine for installing most Linux guest OSes, but there’s always room for improvement. The first thing you probably noticed is that the VM has a low resolution and that moving/resizing windows is painfully slow. This is because our virtual video card has a paltry 16MB of memory and no acceleration features. We’ll need to shut down the VM to address this. Once that’s done, select the VM from the list on the left and hit the Settings button in the toolbar and proceed to the Display section. Here you can define the specifications of the virtual video card. In order to display higher resolutions at higher colour depths, it’ll need more video memory. With the default settings, this uses system RAM rather than video RAM, so you can probably spare at least 64MB here. It’s actually possible to set this higher than the slider allows using the VboxManage command line tool. More on that later…

Modern desktops, despite appearing on a twodimensional surface, all use some kind of 3D acceleration (be it OpenGL, OpenGL ES, or latterly Vulkan) to move windows around and draw nice shadows beneath them. By clicking the Enable 3D acceleration box we let our VM pass these primitives more or less directly to the host’s video card, as well as access its video RAM directly. So if you’re using onboard graphics (or a very old and short of VRAM graphics card) make sure you don’t over-allocate here. It’s tempting to click the 2D acceleration box too, but that’s only for DirectDraw acceleration on Windows guests.


You can read up to 3 premium stories before you subscribe to Magzter GOLD

Log in, if you are already a subscriber


Get unlimited access to thousands of curated premium stories, newspapers and 5,000+ magazines


December 2018