Squeezing more from your Linux VMs

There is a way to squeeze a little more from Linux VM's.

The theory

Linux has a number of ways of sharing it's storage IO among different processes, the norm seems to be to use the Completely Fair Queuing (CFQ) scheduler which helps to prevent a single process from using more than it's fair share of storage IO. This is usually helpful in an environment where this one Linux box is the only OS using a storage device but when it is running on an hypervisor the hypervisor is also busy trying to dish out fair access to the storage so we are effectively doubling up calculating fair access. There are other schedulers that we can choose from and for VM's it seems to make the most sense to use either the noop or the deadline schedulers. They are both more simple to calculate then CFQ.

The practice

If you are using the device sda for your drive use the following to check what scheduler you are using :

# cat /sys/block/sda/queue/scheduler

which will return something like

noop anticipatory deadline [cfq]

Which indicates that the scheduler for this device is CFQ.

To change it on the fly you just: 

echo noop > /sys/block/sda/queue/scheduler

If you want to make the change work across reboots you will need to add elevator=noop to your kernel boot parameters, on a Debian system you edit /etc/default/grub and add "elevator=noop" to the GRUB_CMDLINE_LINUX line then run:

# update-grub

To update the grub configuration.

Sources: kb.vmware.com/kb/2011861, http://serverfault.com/questions/360718/kvm-low-io-performance

Setting up a branch office VPN between a Watchguard XTM505 and a Debian linux box.

Lets us say you have two sites and want to build a VPN between them. The first site has a Watchguard XTM device has a public IP address of 99.99.99.99 which protects a private IP address range of 10.0.1.0/24 and your second site has just a Debian Linux box which has a dynamic IP address that protects a private IP address range of 10.0.2.0/24


Debian side

Install needed packages:

# apt-get install ipsec-tools racoon

            Choose "direct" for racoon setup

Edit /etc/ipsec-tools.conf

#!/usr/sbin/setkey -f

# NOTE: Do not use this file if you use racoon with racoon-tool

# utility. racoon-tool will setup SAs and SPDs automatically using

# /etc/racoon/racoon-tool.conf configuration.

#

## Flush the SAD and SPD

#

# flush;

# spdflush;

spdadd 10.0.1.0/24 10.0.2.0/24 any -P in ipsec

           esp/tunnel/99.99.99.99-10.0.2.254/require;

spdadd 10.0.2.0/24 10.0.1.0/24 any -P out ipsec

           esp/tunnel/10.0.2.254-99.99.99.99/require;

Edit /etc/racoon/psk.txt and add the line

99.99.99.99   Somerandomkey

Edit /etc/racoon/racoon.conf

# Simple racoon.conf

#

#

# Please look in /usr/share/doc/racoon/examples for

# examples that come with the source.

#

# Please read racoon.conf(5) for details, and alsoread setkey(8).

#

#

# Also read the Linux IPSEC Howto up at

# http://www.ipsec-howto.org/t1.html

#

path pre_shared_key "/etc/racoon/psk.txt";

path certificate "/etc/racoon/certs";

remote 99.99.99.99 {

        exchange_mode aggressive,main;

        dpd_delay 20;

        dpd_maxfail 5;

        my_identifier user_fqdn "something@company.com";

        proposal {

                lifetime time 28800 second;

                encryption_algorithm 3des;

                hash_algorithm sha1;

                authentication_method pre_shared_key;

                dh_group modp1024;

        }

}

sainfo address 10.0.2.0/24 any address 10.0.1.0/24 any {

        lifetime time 28800 second;

        pfs_group modp1024;

        encryption_algorithm 3des;

        authentication_algorithm hmac_sha1;

        compression_algorithm deflate;

}

Watchguard side

I have simply taken screen shots for the configuration for the watchguard side:

You will need to ensure that the preshared random key is the same as you used in the /etc/racoon/psk.txt file you created above.

Linux giving out wrong MAC address

I recently had a problem where a Linux box with multiple NICs running a iptables firewall script was not accepting connections when it should. I ran tcpdump to find that ARP lookups received by the box were actually giving out the a MAC address from a different NIC. This seemed bizarre at first, but knowing Linux's networking strength I realised that I was missing something and that I probably needed to tweak the kernel to behave the way I wanted.

A quick Google found that I probably wanted to turn on arp_filter in the kernel. So I ran the following:

echo 1 > /proc/sys/net/ipv4/conf/all/arp_filter

Immediately tcpdump showed that the kernel was now behaving the way I wanted it to and handing out only the MAC address for the relevant NIC.

To make the change permanent (i.e. survive a reboot) you could add the above line to a init script or add the following line to /etc/sysclt.conf

net.ipv4.conf.all.arp_filter = 1

Installing VMware tools on a Debian machine

Update: You may not need to do this, check this post.

Another one for the list of things I forget how to do regularly.


Make sure our packages are up to date.

# apt-get update

# apt-get upgrade

Install the packages needed to install the vmware tools:

# apt-get install build-essential psmisc linux-headers-$(uname -r)

In the vmware server console select "Install VMWare tools..." from the VM menu.
Then type the following:

# cd

# mount /media/cdrom

# tar zxvf /media/cdrom/VMware*.tar.gz

# cd vmware-tools-distrib

# ./vmware-install.pl --default

That should be it, you should now have working vmware tools on your Debian distribution.

Optionally you can delete the installation files with:

# cd ..

# rm -rf vmware-tools-distrib

Update: You should consider using more efficient virtual hardware and drivers, check out my post about using paravirtualized drivers