Recently in Virtualisation Category

The XEN hypervisor uses big files (a couple of gigabytes) as filesystem images for virtual machines. Unlike other virtualisation solutions XEN does not impose its own internal structure on the image file. The big file simply has to contain an ordinary ext3 filesystem and, optionally, a partition table just as if it were a real hard disk. The ability to use big files as hard disks comes in handy if you are running short of space on your main hard disk. With an external hard disk you should be well prepared to run a number of virtual machines as big files. However, having the filesystem of a virtual machine in a big file raises the question of how to boot the virtual machine. Essentially there are two options to do that:

1. Provide the VM's kernel and the init-ramdisk, which are usually stored inside the filesystem (in the /boot directory), as separate files together with the big file, and modify the VM's configuration to use them.

2. leave the kernel and the init-ramdisk in the big file and provide a working boot sector that accesses the kernel inside the big file, using the native XEN pygrub bootloader to start the virtual machine.

Both options require that the big file must be associated with a real, special device file (i.e /dev/loop0) in order to create a filesystem on the big file. While for the first option it is sufficient to simply connect the big file with the loop device, using the "losetup /dev/loop0 bigfile" command, the second option is much more complex, as the big file has to be partitioned like an ordinary hard disk before the filesystem can be created.

For the rest of this article we will focus on the second option which is much more appealing as everything is kept inside the big file. I will show you how exactly the big file is turned into a virtual hard disk and how you can access and modify the information stored in the virtual machine's own filesystem.

Getting Partitions And Filesystem Sizes Sorted

Our journey through the big file's internal structure naturally begins with the creation of the big file.


As a second step we use this chunk of 4141875200 bytes to act as a hard disk and try to partition the bigfile as usual:


As expected, the fdisk program throws a number of error messages at us, because we have given a big file instead of a real hard disk to the program. But let's see how the fdisk program recognizes our new hard disk in detail
.
Obviously there is no partition table yet, but the program assumes that the big file represents a hard disk with 255 heads and 63 sectors of 512 bytes data each. Every cylinder of our virtual hard disk is made of 255 x 63 x 512 bytes = 8225280 bytes which represents the units in which we can chop the hard disk space into partitions now. All in all there are 503 cylinders in our virtual hard disk which makes a total of 503 x 8225280 bytes = 4137315840 bytes to spend on partitions.

But wait, didn't we create 4141875200 bytes in the first place? That's 4559360 bytes less than what we had originally. Well, this loss is due to the fact that for the 504th cylinder we'd need 8225280 bytes which we don't have, so this loss is inevitable. But the important consequence of this reduction of space is that we cannot create a filesystem on the whole bunch of data we supplied. At the moment the size of our filesystem is not determined at all. The next step is to create a new primary partition inside our big file using all the space we have:


After having written the partition table to the big file, have you checked for the new device file /dev/loop0p1? Don't worry, it does not exist! Adding p1 to the disk label is fdisk's way to denote partitions, that does not mean that you'll find such a thing in the /dev directory.

Poking Inside The Big File

From the partition table you can see that 4040316 blocks have been allocated for the new partition. With each block storing 1024 bytes we now know our first partition size, it's 4040316 x 1024 bytes = 4137283584 bytes. This is another number we never saw before! After having written off some 4.5 megabytes because we cannot use half a cylinder, we now face another loss of exactly 4137315840 - 4137283584 = 32256 bytes.

Of course these 32256 bytes at the beginning of the big file are there for a purpose, which is to store the partition table. Our first partition begins right after this amount of data, at an offset of 32256 inside the big file. The amount of 32256 bytes results from the fact that one track (63 sectors of 512 bytes for one head) are put away for the partition table. Now it's time to use a second loop device (/dev/loop1) to poke inside the big file at exactly the point where our first partition begins and create a new filesystem there:


It's essential that we supply the number of blocks as a parameter to the mkfs command to ensure, that our new filesystem on the first partition fits exactly in the space we have allocated. Without this parameter our filesystem would become too big, as the 4.5 megabytes after the first partition would be used for the filesystem too, and when the virtual machine is going to use the filesystem its actual size would conflict with the numbers in the partition table. Either the partition table or the filesystem's superblock is lying, which will cause distress for the virtual machine that expects a consistent filesystem to operate.

Writing The Master Boot Record

You can fill up the filesystem with whatever carefully selected quality open source software you can find on the planet, but in the end we need to write the new virtual disk's master boot record to boot the jewel. There is one step of preparation to be done before we can use the grub shell to write the MBR. We have to make a symbolic link named /dev/loop to the device that points to the master boot record, that is to the beginning of the big file, /dev/loop0 in the example above.


Now your spick-and-span virtual hard disk is ready to boot.

A few weeks ago I happened to install CentOS-5.3 on a HP blade server, and while scrolling through the software selection dialog, I ticked everything that had to do with Virtualisation and Clustering. Consequently, the new system came up with a shiny Xen kernel and displayed a new icon in the system tools menu, the "Virtual Machine Manager".

Everything else was still pretty normal, but the XEN kernel was constantly reminding me to use it for what it's for, starting a virtual machine. As you may know Xen is not the easiest way to get such a virtual system in place even thought there is a graphical frontend for Xen as well. But there is one advantage of Xen that makes up for all the trouble you are having to get the thing going and that is speed.

Unlike other virtualisation software like VirtualBox that are designed to run unmodified operating systems within an application environment that emulates everything, Xen aims at running on bare hardware as directly as possible. Xen promises to achieve near native performance by putting a kernel software called hypervisor between the hardware and the guest operating system. The hypervisor occupies the privileged part of the CPU driving the guests away into the non-privileged areas of the CPU, but offering to execute privileged code on behalf of the guests whenever they need to use privileged code. It is this design, that speeds up performance but on the other hand makes it necessary that the guests find their way to the hypervisor by using a special Xen-enabled kernel themselves. So operating systems that cannot be modified to have a Xen kernel (like Microsoft Windows) cannot run in the speedy paravirtualized mode.
 

Beware Of Using Defaults

In my experience, what makes Xen very tricky to use at first, is that the default values after a fresh installation can easily break your network connection, leaving you with plenty new network interfaces but without a working local network, let alone the internet. On boot there are two services that are being started for the Xen system, the libvirtd and the xend daemons. These services read a single, very short  configuration file "/etc/xen/xend-config.sxp" which consists of only nine lines:


And line no. 4 is the culprit that renames a working ethernet interface, recreates it and introduces two bridge interfaces leaving a mess in which nothing does work any more. I strongly suspect that this is not what defaults are for. Fortunately a small modification gets Xen on track again. Simply don't use the script "network-bridge" and replace it by /bin/true, problem solved. It seems to me that the Xen defaults are striving to isolate the new virtual machines from the ethernet as much as possible, while someone starting to use Xen might want the virtual machine to use the already working internet adapter with a new fixed IP address in the LAN.

Use Your Own Bridge

If you are after a new virtual machine on the same LAN you can create a config file for a bridge (br0) that replaces your ethernet interface and connect your ethernet interface to that bridge. All firewall settings for your host can remain the same as your new bridge takes over the old fixed IP address and nothing seems to have changed for the LAN. Once your virtual machine is ready to run, just use the new bridge br0 as network interface in the config file and you can assign an unused IP for the guest on the LAN with the default gateway for internet access, and everything works well.

/etc/xen/xend-config.sxp

/etc/sysconfig/network-scripts/ifcfg-br0

/etc/sysconfig/network-scripts/ifcfg-eth0

Try it, and you are beginning to love Xen!

Maybe you have followed my guide to easy virtualisation with Sun's VirtualBox software and you are familiar with the basics of running a virtual machine inside your normal Windows or Linux system by now. I hope that you enjoy the many features of your new virtual machine as most devices used by the virtual machine just work out of the box. Reading CDs and using the audio device for playback should work right away and setting up a printer via the network connection is a matter of few clicks.

But the one problem you have certainly run into by now is the low display resolution which defaults to 800x600 pixels, considerably impeding your freedom on the screen. Two simple steps will sort out this problem forever. First select a suitable "Monitor Type" in the Administration - Display dialog and save the setting. Then edit the file "/etc/X11/xorg.conf" and add something like the following in the SubSection "Display" part:


After logging out and restarting the X server again you should have a much bigger screen that almost covers the whole display if you switch into FULLSCREEN mod with <Ctl>F.

Guest Extensions pave the way for a seamless desktop experience

During the installation of VirtualBox a custom kernel module was being built that enables the host system to manage the guest, but the guest system runs without any consciousness of the fact that it is only a virtual machine. To ensure a better integration between the host and the guest, SUN have developed a package called "Guest Extensions" that must be installed inside the guest to make it VBox-aware. The installation of Guest Extensions culminate in compiling another kernel module that is being used by the guest to improve communications with the host and to make additional features like shared folders available.

Before we can use these desired features we still have to prepare the guest system to compile kernel modules, that means we have to install a full development stack inside the guest system for kernel modules first, and then install the Guest Extensions. Use the following yum command to prepare the CentOS/Fedora host:
 

The Guest Extensions come as an iso-file "VBoxGuestAdditions.iso" that could be found in the directory "/usr/share/virtualbox". Make sure that this iso file is available as a CD-iso-image to the guest system by adding it to the appropriate section in the Virtual Media Manager menu. Restart your virtual machine to make sure the new, updated kernel is actually running and start the setup script "VBox LinuxAdditions-x86.run" on the CD image after you have mounted the iso-file from within the guest system. After rebooting the virtual machine the new kernel module for the guest becomes active and the extensions are ready to use. The first thing you'll notice ist that the mouse pointer is no longer confined to the guest window, you can click on everything that is visible on the screen, no matter if it is a host or a guest window. And, of course, you now can copy and paste text between the host and the guest as you like it. A much more important change took place behind the curtain, your access to the hard disk is faster now. Let's have a look at the following table which gives an overview over transfer rates measured on my laptop.

Action	CentOS 5.2 HOST	Fedora 10 GUEST WITH Guest Extensions	Fedora 10 GUEST without Guest Extensions
creating files with zeroes	27.1 MByte/sec	21.8 MByte/sec	14.1 MByte/sec
copying files	12.47 MByte/sec	11.96 MByte/sec	N/A
writing to network shares	12.26 MByte/sec	5.6 MByte/sec	5.4 MByte/sec
writing to shared folders	18.0 MByte/sec	6.7 MByte/sec	not available

As you can see the performance has considerably improved for writing files to disk and is almost the same for writing normal files while there is still a huge difference when network attached storage is used to extend the usually poor disk space of the virtual machine. But the use of virtual folders at least enables the host system to write data to the guest's file system rather quickly, while the guest does not really gain any speed doing the reverse operation.

Anyway, installing SUN's Guest Extension truly polishes your virtual guest machine and lets it shine brighter than before.

Virtualisation is one of the big next things to become mainstream technology. But it's a complex technology as there are many different software solutions available that differ greatly in terms of usability, flexibility and performance. As always there is a trade-off between ease-of-use and the performance of the guest system on your hardware. This time we will try to get a virtual machine up and running with a minimum of possible obstacles on our way to success, and we will try to install a cutting-edge Linux OS, Fedora-11-Preview, which will finally be released in about two weeks, today!

After all, trying out a new Linux distribution without the risk of making a mess of your hard disk is one of the most attractive features of virtualisation. What makes creating a guest virtual machine easy is the graphical user interface of VirtualBox from Sun Microsystems, that will guide us through the process in an intuitive way. Nevertheless the downside of this software is that even though it's open source, it's not entirely free. According to Sun's "VirtualBox Personal Use and Evaluation License (PUEL)" the software is free to use for personal and educational purposes as well as for product evaluation:

Sun grants you a personal, non-exclusive, non-transferable, limited license without fees to reproduce, install, execute, and use internally the Product a Host Computer for your Personal Use, Educational Use, or Evaluation. "Personal Use" requires that you use the Product on the same Host Computer where you installed it yourself and that no more than one client connect to that Host Computer at a time for the purpose of displaying Guest Computers remotely. "Educational use" is any use in an academic institution (schools, colleges and universities, by teachers and students). "Evaluation" means testing the Product for a reasonable period (that is, normally for a few weeks); after expiry of that term, you are no longer permitted to evaluate the Product.

But even though you'll need a commercial license from SUN to use VBox after evaluation, the download is free of charge and the PUEL allows for intense testing and is practicable for a number of non-commercial environments.

Getting VirtualBox for Your Linux Distribution

As we are going to install a new Fedora 11 as a guest on top of your current Linux system, the host, the first step is obviously to get VirtualBox for your host system and install it there. Fortunately SUN has prepared binaries for a number of different Linux distributions for download, so go to Sun's download page here and choose your package. Binaries are available in rpm or deb format, so your system's native installation tool should do the job. Just bear in mind to install the kernel headers and the gcc compiler first, to enable VirtualBox to compile a kernel module that will be loaded on boot after installation.

Unlike XEN which changes the way your usual Linux system works fundamentally, VirtualBox is just another application that runs inside your normal environment without changing anything on your host, except that it relies on the new kernel module created on installation.

Preparing VirtualBox for Installation of Fedora

Do you have two hours to burn? Let's get going.

To get to the point where we can start to install Fedora, we basically have to prepare a virtual disk and attach a boot medium to the virtual machine.

By now you will have found the VirtualBox GUI in the System Tools menu and have started to create a new virtual machine. First, we have to give it a name and select the OS type. Adjust the memory slider to at least 512 MB or even more if you can afford it. The more memory you assign to the virtual machine the faster it will run eventually.

In a second step we need to create a virtual hard disk in a file. During installation of the guest system this file will be used as the device "/dev/sda". All formatting and partitioning is being performed inside this file although it seems to be a normal block device for the guest system to use. Later, when Fedora uses its hard disk you will be asked to erase all your data on the device "/dev/sda". I can see the sweat on your face when you click the OK button for the first time. Your real hard disk, called /dev/sda as well, will survive this procedure, believe me. You have to choose the final size of your filesystem for the Fedora installation here, so think twice how much space you will need.

As you can see I have only spent 4 Gigabytes for my Fedora test system, enough to finish a default installation. But your mileage may vary, you know, and it's not easy to expand your virtual disk after finishing the installation.

Initialising the file that represents your virtual disk will take a while. Check that the correct vdi-file is selected and finish this part of the job.

Before you can start the new virtual machine (to install Fedora) some minor changes to the default settings have to be made. First of all I would recommend to change the network configuration.

Usually the VirtualBox GUI selects NAT, but I think it's more straightforward to configure the network interface to share the physical host interface with the new guest system. I don't know whether or not this is really necessary in your situation, but it does not hurt anyway.

As a last step we need to tell VirtualBox where to find the installation media. If you have a download of the Fedora packages at hand stored in ISO format, you can use it here. For the sake of simplicity I would like to go a different route and would ask you to download the 166 MB netinstall.iso file from the Fedora downloads page. This file could be burned to a CD making up for a nice boot CD, but we can use the downloaded iso-file here as the requested "Image File". The only problem is, that we did not attach the file to the virtual machine yet.

To make it available we have to go back to the "Virtual Media Manager" in the File menu and choose the downloaded iso-file as a CD/DVD image.

I hope you have come this far and I'd like to encourage you to start your new virtual machine to go ahead with the installation. Once you've hit the start button again, you should be greeted with the Fedora installation window, and from this point onwards everything should work as if you had inserted a real CD and tried to install on bare hardware. In the course of installation you will inevitably reach the point where the hard disk has to be formatted, so keep an eye on the size of your install disk, it is exactly the size of your vdi-file. It does not matter that your real hard disk is also referenced by /dev/sda, your new /dev/sda is entirely separate, so dont't hesitate to repartition it to your hearts content. And you can safely install the GRUB boot loader in the master boot record, your original one will not be overwritten by the new installation. That's the magic of virtualisation.

After finishing your Fedora installation, there is one thing to remember, you have to remove the installation media before booting (the virtual machine) again. Well, you know how we had attached the iso-file to the machine, simply untick the box to detach it, then power off the virtual machine and start it again. Congratulations to your new Fedora 11 almost two weeks ahead of schedule.