Splendid Isolation

Here is my home network (or a bit of it, anyway):

(I apologise in advance for lack of abilities when it comes to using Dia, the Linux equivalent of Visio!)

What you have there is not very exciting: a couple of Centos-running servers called NEWTON and GALILEO, one of which connects to the Internet, thanks to a wireless dongle and the magic of 3G. There’s a wireless access point, handling all the “devices”: Nexus 7, Kindles, Smartphones and the like. Then there’s FEYNMAN, ToH’s Windows 8 PC doing sterling duty as a Photoshop workstation. RUTHERFORD’s the media centre (also running Windows 8, but with Windows Media Centre added). And my new PC is DIRAC, running Fedora 18. Everything is running on a 192.168.0… subnet.

I probably should expand this diagram, though: there are 7 different virtual machines which run routinely on Dirac: they all share the 192.168.0 subnet thanks to ‘bridged networking’ in VMware Workstation and can therefore access Galileo and, from there, the Internet. Though they are merely virtual machines in fact, they behave exactly as real, physical machines would: by sharing the same subnet as the PC they run on, they look just like real machines to all the other real machines on the network. Bridged networking is fine for VMs that are allowed to function as though they were real.

But here’s the problem: what if I want a bunch of new virtual machines to be able to talk amongst themselves as though they were part of a normal network but without any of the existing, physical machines being aware of the fact? For example, I may want to build a DHCP server -but I don’t want any of my ‘real’ PCs accidentally picking up their IP address from it. Similarly, I may want to build a new DNS server -but I wouldn’t want FEYNMAN trying to look up hostnames there.

The underlying reason for needing this ability is, in fact down to my laptop (which isn’t shown in the above diagram). I use it at work, so it needs to see proper, commercial DNS, DHCP, NTP and other servers -but if I want to run VMs on my laptop that are running their own DNS, DHCP, NTP and other servers, I have to be able to ensure that whatever I build can never, ever “leak” out onto the real network. I need, in fact, complete isolation of my network of virtual machines running on my laptop from the real corporate network my laptop is physically connected to.

Fortunately, this is easy to do with VMware Workstation -and VirtualBox: both employ a feature misleadingly called host-only networking. I say ‘misleadingly called’ there, because that name implies (to my mind, anyway) that virtual machines making use of it can only communicate with the physical host. If that were true, you could ‘network’ the host to the VM -but you’d be stuffed trying to network one VM with another VM. But happily, it’s the name that’s wrong, not the functionality: host-only networking in both virtualisation products actually means that any VM built to use the feature can communicate with the physical host and with every other host-only VM, too.

So here’s the network I want to build:

The virtual network is all the grey/brown-coloured stuff at the bottom. My physical PC, DIRAC, will host six different virtual machines, all running in host-only mode, and using the 192.168.42 subnet. Note that DIRAC itself acquires a second IP address, allowing it and it alone both to connect to the rest of the world and to connect to any of the 192.168.42 virtual machines.

How exactly is that to be achieved, then? Well, if I persist with my usual desktop virtualisation software (VMware Workstation), I’d find the menu option for the Virtual Network Editor (in Linux, you can launch it from the command-line by typing /usr/bin/vmware-netcfg -you’ll be prompted to supply root’s password if you’re not root at the point of issuing that command):

When you install VMware Workstation, you get three different network interfaces created for you automatically: one of them is used for bridged networking, one for Network Address Translation …and one for host-only networking. Highlight that last one and you’ll be able to alter its properties in the lower part of the screen. Here you see that I’ve switched off the virtual DHCP server that VMware offers to run for you on this interface; I’ve also altered the default subnet IP so that it matches my desired ’192.168.42…’ subnet address range. Leave the last octet of that address set to zero and you will find that your physical host PC or laptop is automatically assigned a 192.168.42.1 address, which is fine.

You can create as many of these host-only network interfaces as you like: each one will create a new network adapter (if your host is running Windows) or a new network interface, visible via ifconfig, if your host runs Linux), meaning that if your host PC is powerful enough, there’s nothing to stop it running multiple, isolated virtual networks at the same time.

VirtualBox does it slightly differently: just use the File → Preferences menu options to bring up a Settings dialog, then select the Network item:

By default (at least on Fedora 18!), you don’t have any host-only network adapters installed here, but if you click that little green ‘plus’ button, a new one will be created for you and will be automatically named virtualbox0. After creating it, click the third little icon on the right to configure its settings:

 

Again, just type in a ‘starting address’ for your new isolated network. With VirtualBox, I find it necessary to specify the ‘.1′ at the end of the IP address, otherwise it doesn’t work properly. By specifying the 192.168.42.1 address in full, therefore, I ensure my physical host is assigned that IP address on its new virtualbox0 interface. (As you can see from that last screenshot, too, I don’t have much use for IPv6 at the moment!)

Finish things off by switching to the DHCP Server tab and uncheck the ‘Enable Server’ option: again, VirtualBox proposes to run a virtual DHCP server for you, which you might find desirable, but which I definitely don’t!

Incidentally, if you happen to have VMware Workstation and VirtualBox installed on the one physical guest, make sure each uses a different isolated subnet, because they can’t both be configured to use the same one meaningfully! In other words, if I’ve created a 192.168.42.x host-only subnet in VMware, I’ll have to create a 192.168.43.x host-only subnet in VirtualBox. Networking won’t work reliably if you try assigning the same IP address to two different interfaces at the same time!

Once your network interfaces are configured properly, it’s simply a matter of choosing the right sort of networking for each new Virtual Machine that you build. In VMware, you do that as part of the ‘create new VM’ wizard:

By default, VMware threatens to create new VMs with a NAT interface, but it’s easy to switch to using a host-only one.

VirtualBox is not as easy, because the wizard you use to create a new VM doesn’t offer you any opportunity to specify anything about the network interface to use at all. It’s therefore necessary to create a new VM ‘blind’, and after it’s been created, right-click it and select Settings. Select the Network item on the left:

You’ll discover that, once again, a NAT interface has been assigned to your new VM by default. Just click that combo-box, though, and you’ll find an item for Host-only adapter. Select that, click OK, and you’re all done.

Once built, you’ll find that all your host-only VMs can ping each other and your physical PC on which they’re running -but they won’t be able to ping beyond your physical PC. That means, in my case, that ALPHER and BETHE can ping each other, or MARCONI, TESLA or DIRAC (my physical PC). But they won’t be able to ping GALILEO -and since GALILEO controls access to the Internet, that means my host-only VMs can’t reach the Internet, either.

For my purposes, that’s fine: why would I need an Oracle server (say) to be able to access the Internet? You wouldn’t normally do that in production (I hope!), so having a set of servers that behave similarly is not a problem for me. It does mean I have to have one of my VMs hosting a software repository from which my other VMs can download packages and so on necessary for running Oracle (or anything else), but that’s usually not difficult to do.

The main issue is easily solved, therefore: host-only networking allows your virtual machines and all the networking services they provide and consume to be completely isolated from the rest of the world -and any real corporate networks your physical PC might be attached to at the time! Splendid!!

(Oh, and as a side benefit: my laptop will be able to run a virtual network of six VMs even when I’m running it on a train and it’s stuck in a tunnel without a 3G signal. The virtual network will keep running just fine, even if the physical one decides to die -or even if you don’t have a physical network at all. Host-only VMs are a great way of virtualising networks on standalone PCs, in other words).

VirtualBox Installations on Scientific Linux

I’ve mentioned previously that my preferred virtualization platform is VMware Workstation. That remains true …but VirtualBox does have the distinct advantage of being free-of-charge. So unless I want to insist that my readers find AU$291.50 for VMware’s offering, it behooves me instead, from time to time, to use the virtualization platform I know we can all afford.

So here is my two-minute recipe guide to getting the latest VirtualBox product installed (for zero dollars!) on Scientific Linux 6.1. (You could always just download the relevant rpm and install it directly, but I prefer to do all my package management via yum wherever possible, so that’s the approach described here).

1. Get the gpg key

VirtualBox is supplied as a bunch of rpm packages which have been digitally signed. By checking the signature, you know no-one’s messed about with the packages before they reached you. It therefore makes sense to obtain and install the digital key needed to do that signature check. It’s easy to do, as root, at a command prompt, by issuing these two commands:

wget http://download.virtualbox.org/virtualbox/debian/oracle_vbox.asc
rpm --import oracle_vbox.asc

2. Create the yum repository

Again as root, issue this command to create a new, blank repository file:

gedit /etc/yum.repos.d/virtualbox.repo

Now paste in these contents to the empty file:

[virtualbox]
name=RHEL/CentOS-$releasever / $basearch - VirtualBox
baseurl=http://download.virtualbox.org/virtualbox/rpm/rhel/6.0/$basearch
enabled=1
gpgcheck=1
gpgkey=http://download.virtualbox.org/virtualbox/debian/oracle_vbox.asc

Save the file changes and close down gedit. Just in passing, you might note that I’ve changed this file from the version which Oracle themselves makes available on the VirtualBox website. Specifically, their baseurl uses an environment variable, called $releasever, where I have hard-coded in the number 6.0. The trouble, of course, is that if you are using the latest versions of Scientific Linux or Centos, you’ll be picking up a releasever of 6.1 or 6.2 …and no such directory exists on the VirtualBox servers. You’d need to manually check out those server’s directory structure to see if that situation changes over time.

3. Install the Software

As root once more, the following one-liner will display all the different versions of VirtualBox that are available for installation:

yum search VirtualBox

You might see this sort of output in return:

Loaded plugins: refresh-packagekit
virtualbox | 951 B 00:00
virtualbox/primary | 4.4 kB 00:00
virtualbox 17/17
============== N/S Matched: VirtualBox ==============
VirtualBox-3.2.x86_64 : Oracle VM VirtualBox
VirtualBox-4.0.x86_64 : Oracle VM VirtualBox
VirtualBox-4.1.x86_64 : Oracle VM VirtualBox

This shows that Oracle keeps a couple of older versions of the software alive and available, should you need to use them. Most people, though, will really only need the latest version, so pick that from the list and issue an appropriate “yum install” command. In my case, given the above output, this command will do the right thing:

yum -y install VirtualBox-4.1.x86_64

It’s a 58MB download or so, and as it’s installed you might see this message appear:

Running Transaction
 Installing : VirtualBox-4.1-4.1.8_75467_rhel6-1.x86_64 1/1
Creating group 'vboxusers'. VM users must be member of that group!

This gives you the clue to the last stage of the installation process…

4. Assigning Group Privileges

The software installation has created a new O/S group, called vboxusers, but it won’t have made your user account a member of that group. That needs to be fixed.

From the Gnome top panel, click System > Administration > Users and Groups. Find your user details on the Users tab and double-click the entry. Switch to the Groups tab, scroll down and check the vboxusers group name:

Click [OK] to save the change, and you’re done, though you’ll need to log off and back on before the group membership changes take practical effect.

If you prefer doing everything at the command line, just edit /etc/group (as root, of course) and add a :your-username entry to the end of the vboxusers line, which will probably be the last line of the file. In my case, for example, the line ended up reading vboxusers:x:501:hjr -which simply means that user ‘hjr’ is now a member of the vboxusers group. (Again, it’ll take a log off and fresh log on before the new group membership actually takes effect).

Either way, you’re now done and can run the VirtualBox program successfully, with the program launcher being found in Applications > System Tools.

5. USB Support

The version of VirtualBox installed by the above procedure will be unable to access USB 2.0 devices that might be plugged into your physical host. However, this shortcoming can be fixed by installing the “Oracle/VirtualBox Extension Pack”. Download it from the VirtualBox website and then just double-click the file when the download completes. You should see the following appear:

Click the [Install] button there, agree to the license, authenticate as root and all should be done in a matter of seconds. You’re now ready to build and run fully-functional virtual machines.

VirtualBox Boot-time BIOS Error

A slightly annoying error message always appears whenever you boot Ubuntu 11.04 Server as a guest O/S in VirtualBox:

piix4_smbus 0000.00.07.0: SMBus base address uninitialized - upgrade bios or use force_addr=0xaddr

It doesn’t actually do any harm to the guest (as far as I can tell), so one could perfectly well leave it alone. But it’s possible to get rid of it altogether simply by issuing three commands and editing one configuration file. First:

sudo nano /etc/modprobe.d/blacklist.conf

Add the text

blacklist i2c_piix4

…to the end of the file. Finally, issue the commands:

sudo update-initramfs -u -k all
sudo reboot

When the machine comes back up after that last reboot, you won’t see the error message. What this is doing is simply preventing an attempt to load the i2c_piix4 kernel module. VirtualBox doesn’t emulate the hardware for which this module is actually needed, but Ubuntu doesn’t know that and tries to load it anyway. Blacklisting the module prevents Ubuntu doing that and thus makes the error disappear.

VMware Workstation Glitch

I opted to install various updates today to my Debian “Squeeze” PC. I’m afraid I don’t know precisely what updates they were, because (like a lot of people, I suspect!) I didn’t bother to pay a lot of attention to the list of what was about to be done to my system. Whatever it was, where I was happily VMware-ing before the update (and for hours afterwards), after I’d rebooted the PC, I couldn’t start the virtual machine any more: the program kept complaining about “couldn’t find /dev/vmmon”, and when I manually tried to modprobe it, it came up with all sorts of errors indicating kernel troubles.

There being no obvious way to fix things (Google doesn’t help much on this, with all suggestions I saw involving re-running vmware-config.pl, which simply doesn’t exist on my system for some reason!), I resorted to the crowbar method of software maintenance: I ran /usr/bin/vmware-installer -u vmware-workstation and got the software uninstalled. Then I re-ran sh VMware-Workstation-Full-7.1.0-261024.x86_64.bundle to reinstall it… and after the re-install, it all worked as fine as before.

God knows what the trouble was, but let that be a lesson to you: don’t update (especially on a testing branch of Debian!) unless you really need to!

Before I decided on the re-install route, I did dabble with the idea of giving up altogether and using VirtualBox once more. The open source version is available in the Squeeze repositories, and I figured that if it was there, then any updates affecting those repositories is likely to leave VirtualBox at least in working order. Of course, I wouldn’t want to have to rebuild my VMware Workstation virtual machine… a lot of software and OS updates have gone on in it.

So is it possible to open a VMware Workstation VM in VirtualBox?

The answer to that is, ‘yes, very easily’:

  • Make sure your VMware virtual machine has no snapshots. Delete them if it does.
  • Start VirtualBox OSE (Applications → System Tools → VirtualBox OSE)
  • In File → Virtual Media Manager, click Add. Point to the .vmdk file of your VMware virtual machine. Double-click to select and add it, then click OK to close the media manager window.
  • Click the New button to create a new Virtual Machine, fill out the memory details as you think appropriate. Select the Use existing hard disk option when shown, and select the .vmdk file from the combo box.
  • Boot the new VirtualBox virtual machine as normal. Windows will, of course, have an absolute fit at the amount of hardware you’ve changed, but if you give it long enough, it should come good as it detects it all and re-configures itself accordingly. You may need a couple of reboots before everything is detected and installed perfectly.
  • Don’t forget to install the VirtualBox Guest Additions so that you get proper video/mouse handing for the new environment.

When I first did this, the machine would simply boot to a blank screen, sit there doing nothing and otherwise just die. Rebooting a couple of times, the same thing happened each time. When I checked the logs for the VM (found in my /home/hjr/.VirtualBox/Machines/Windows XP/Logs directory), I saw I was getting the error message: BIOS: int13_harddisk: function 15, unmapped device for ELDL=81. I had a bit of a guess at this one: powering down the VM, I went into Settings → System and switched on the option to Enable IO APIC. Once I booted the VM once more, it worked perfectly.

One other gotcha: the networking in the VMware machine was fine, but the guest OS when running in VirtualBox declared that no network was available. The reason for that is that my VMware machine had been built with Bridged networking, but VirtualBox creates new VMs with Network Address Translation (NAT) networking instead. Power the guest down and edit the Settings → Network to switch to the Bridged Adapter option.

One quirk that is probably peculiar to my setup: my VM has Checkpoint Secure Remote installed on it (it’s the VPN I use to connect to work, since they don’t seem to be able to run to a VPN that has a Linux client!). That prevented my new network card from functioning properly -but once I’d uninstalled Checkpoint and rebooted, the network card was detected fine. Then I was able to re-install Checkpoint and connect to work as normal… yet another instance of crowbar software maintenance, I’m afraid, but at least it worked (again)!

Not too painful, all things considered -though I’d suggest trying it out on a copy of your VMware virtual machine before you let rip on the real thing! Getting networking, er, working was probably the hardest part of the entire affair.

The extent of the hardware changes the guest OS has to deal with are enormous, so it was frankly a bit of a surprise that Windows XP coped… whether later versions of Windows would is a matter for speculation, I guess. I would expect such a degree of hardware change to prompt re-activation of Windows, though (the reason I tend to stick with XP in my VMs: no activation required, at least for my ancient installation disk!).

There is an alternative to this approach, which involves using qemu and stuffing around actually transforming a .vmdk into a native .vdi file via a .bin intermediate file, but there’s really no need, so that’s not an option I’ve experimented with.

I’ll probably stick with using VMware Workstation (having paid for it, after all!), but there’s something to be said for having your virtualisation technology available from the repositories… so we’ll see!