Sysconfig's Blog

Be honest: You are running at least one dedicated server, and you certainly have asked yourself whether you should use virtualisation. You might have found “no” to be the answer, as you have one server for each purpose and do not plan to migrate to other hardware machines or to “sub let” your system. That’s ok. But on the other hand, everybody likes to reduce hardware costs, or make more of the hardware they have.

It’s a prejudice that virtualisation is only interesting for so-called Virtual Private Server providers or for big companies who need to run loads of tests for their software releases on different platforms and configurations. Also, you do not need a bunch of servers or a blade-center to take an advantage on virtualisation. In this article I’d like to give an example of what can be achieved with virtualisation apart from those typical and well-known scenarios.

Firstly, have a look at the load average of your own server(s). If it stays below 1 (per CPU/core) most of the time, you are actually not making use of all the power your machine has to offer. Hence, you are actually wasting money! You might say: “I am not yet making use of it, but my business is supposed to grow and some day I will need all of the idle resources.”

That’s absolutely fine, and 90% of all small companies will agree with your approach. However, I would like to outline what virtualisation can do for everybody who owns (or rents) a dedicated server. I’d like to show how

• you can improve access to your system for maintenance tasks
• you can use idle resources and free them when they are needed for other purposes
• virtualisation can increase stability and security of your server

First things first, virtualisation is not as complicated to set up as commonly expected. My favourite implementations are VMware Server and VMware ESXi (free since 28/07/2008), because they enable you to run any operating system within virtual machines without any changes to their kernels whatsoever. Moreover, WMware products have a long history and have proven that they are rock-solid. However, if you are sure that you will not run anything but Linux, you might also want to have a look at XEN, OpenVZ, Linux vserver or other implementations. See the previous article for an overview of available products.

The easiest installation is offered by VMware ESXi Installable. All you have to do is to insert its bootable CD (if you have a SuperMicro KVM-over-IP, a Raritan eRIC G4 card or similar, you can do that remotely as well). It will install itself onto the server, ask you some questions, and that’s it. ESXi is a hypervisor which does not require any host operating system to run on. You are ready to install any piece of operating system you want as a virtual machine through the VMware Infrastructure Client (Windows application, for free, part of ESXi).

If you don’t have KVM-over-IP or local physical access to the server, you could also ask your server provider to do that for you. It takes less than half an hour and is very easy to do.

Anyway, the subject of this article is not how to set up virtualisation. I just wanted to give an example. The topic here is, why you may want to consider using virtualisation.

How to improve access to your system for maintenance tasks

Does you server have KVM-over-IP or do you have physical access to the server? Then this might not apply to you. All others regularly generate costs when they want to do simple things as an ReiserFS or ext3 filesystem check, or when they want to compile a new kernel and it does not work out as expected: They have to ask their server providers to grant access to their servers via KVM-over-IP (if possible). With some hosts that can be kind of a nightmare!

So how does virtualisation help here? In case you are using VMware, each virtual machine can be accessed via a remote console. You can change BIOS settings, monitor the boot process and access your machine even if it does not have a SSH daemon running, as if you were sitting in front of it. The filesystem is corrupted? Just insert an ISO image of your favourite rescue CD into the virtual CDROM drive and boot from it. Do your filesystem maintenance or fix the problems with the custom kernel, eject the CD image, and boot again. There you go: Within minutes your problems can be solved — anytime you want and without any additional costs.

As for VMware you could also have a tftp server running in another virtual machine and boot VMs via PXE! That’s quite advanced but very helpful, should you ever need it.

How to use idle resources

Would be a shame to waste resources (and money!) on a machine, wouldn’t it? So why not running the main VM with most of the resources assigned, while still keeping spare resources available to install completely different things on the same machine?

Of course you can usually do that on a non-virtualised server as well. But how do you control resources of less important services and tasks? And would you really want to mix experimental stuff with your production servers? What about security in that case? Maybe you may want to test other Linux distributions? That’s all easily possible with a virtualised server.

Just tell the hypervisor to prioritize your most important VM(s) or hard-limit resources of your additional VMs. Then you will not see any impact of your experimental stuff on the production services at all! You do not need to worry about security, stability, clean un-installs of failed experiments. You will not experience a single second of downtime of your production VM while you are doing the most sophisticated experiments on another VM!

You also might to do more than just experiments on the same server. For example, you are starting with your business and want to keep costs at a minimum in the beginning. However, you expect your business to grow quickly. What you could do is to start with a single virtualised dedicated server and split it into logical units, each of them running on a separate virtual machine. As soon as you realise that the server may reach its performance limits, you simply migrate one or more of the virtual machines onto another physical virtualised server. The interesting thing here is, that you do not need to worry about the hardware it is running on. All VMs can have the same set of virtual hardware components. To the guest operating system, they all look the same, no matter what network cards or RAID controllers physically exist in a server. That makes migration quite easy, even if you do not use VMware or its migration tools.

Virtualisation can increase stability and security of your server

Okay, this one is a bit more complicated to explain. So when does a server usually become unstable?

• when it runs out of memory and swap space, so that the kernel randomly has to kill tasks/services
• when the load gets too high (often in conjunction with heavy swapping due to lack of memory)
• when it is being attacked from outside (DDoS)

The problem with these reasons is that the results are unpredictable and may lead to data loss or data inconsistency. Sometimes a hardware reset is necessary, as no remote access is possible any more (SSH daemon might have crashed already or takes ages to establish the SSH session).

As long as it’s not a DDoS attack which causes the problems, virtualisation together with it’s resource limitations for VMs and a remote console (as in VMware) can help to log onto your VM and fix the issues. In the worst case you might have to shut it down, but that’s not a hard-reset via remote power bar control (which is the worst thing you can do to a server). You just have to restart the VM, which is so much faster than restarting a physical server!

And even in case of a DDoS attack, you might be better of with virtualisation, if you have two NICs connected one of which is on a local/maintenance network. Then you still could have full access from there and could use the remote console to block ports or source IPs. That works even better, if you run a firewall within one of the VMs and have a virtual local network infrastructure set up within the virtualisation.

Now that sounds a bit complicated, doesn’t it? You might want to read about my example setup, which is not very complicated but very effective.

My example setup

To start playing with the free VMware ESXi, I ordered a nice machine from SoftLayer which comes with KVM-over-IP (and allows remote CD image mounts). So I literally do have full control over the server. But you could also choose any other host and do not need a KVM at all, if the host agrees to install VMware ESXi for you (which is easy and does not take more than half an hour).

After successful installation, I used the Virtual Infrastructure Client to set up a couple of virtual switches:

• vSwitch 0 is connected to the public interface card
• vSwitch 1 is a host-only switch for local networking between the VMs (not accessible from outside)
• vSwitch 2 is connected to the interface card on the management network (SoftLayer provides access to this special infrastructure via VPN — very nice!)

My first VM was meant to become the firewall. Now, you may ask: “Why the hell do you put the firewall onto a VM? You could use iptables, pf, ipfw within the VM.” Sure, I could. But why should I want to maintain firewalls for each single VM when I can do that centrally? Moreover, why should I reinvent the wheel? There are plenty of good firewall solutions out there, which come with so many extra features out of the box.

I went for pfSense. It comes with literally everything you might want to implement:

• stateful firewall
• NAT port-forwarding and 1:1 NAT (interesting if your dedicated machine has multiple IPs)
• web interface
• different VPN services (PPTP, IPSec, OpenVPN)
• traffic shaping (queues, prioritisation etc.)
• bandwith monitoring
• netflow hooks
• SNMP
• DHCP/DNS
• and a bunch of other packages which can easily be added to the configuration

The pfSense VM connects exclusively to vSwitch0 (public network) and to vSwitch1 (host-only local network). That means, all traffic to the other VMs goes through this firewall. There’s no way to circumvent that — neither for public sources nor for the VMs, which are only connected to vSwitch1 locally and listening on private IP ranges (192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12). The VMs get their local IPs assigned by  pfSense’s DHCP (nice for quick experimental VM setups) and have to use pfSense also as gateway and DNS.

Currently I am experimenting with TFTP to boot VMs via the network/PXE, which is possible with VMware ESXi and VMware Server. That will allow extremely quick and slim VM installations.

Thanks to the many features of VMware ESXi, you can literally set up a virtual data centre in a box. Ok, a small one. And you gain full control about everything which happens in your small data centre.

So, to cut a long story short: Virtualisation helps to

• increase control over and maintainability of your services
• centralise certain tasks (like the firewall or bandwith control)
• make use of spare resources and reduce costs
• ease migration in case the hardware is no longer sufficient (you don’t need to worry about the hardware platform the VMs are running on)
• speed up development/experiments as a VM is deployed much quicker than a dedicated box

I hope, this article helped at least a bit to make you curious about virtualisation. Personally, I think that virtualisation does not only target big companies or VPS hosts. It is interesting for everybody who owns/rents dedicated boxes. And it is certainly worth the effort to give it a go!