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

Remote desktop gateway connections failing when KB2592687 installed.

While setting up a lab running Remote Desktop Gateway on Windows Server 2012 R2 I came across a strange problem. I was able to connect through the RD Gateway using some machines but not others.
On the machines that were failing I got the following message when trying to connect:
"Your computer can't connect to the remote computer because an error occurred on the remote computer that you want to connect to. Contact your network administrator for assistance."

After much pulling of hair I narrowed it down to something to do with the KB2592687 update. This update installs RDP version 8.0 on Windows 7 SP1 machines. This update was present on both the machine I was trying to connect to and on the clients that were failing. There is a list of known problems in knowledge base article but none of them applied to my setup.

More searching found loads of red herrings, then I discovered this post. It mentions LAN manager authentication level settings (Local security policy->Local Policies->Security Options->Network Security: LAN Manager authentication level). On the failing client it was set to "Send LM & NTLM - user NTLMv2 session security if negotiated." Changing it to "Send NTLMv2 response only" (which seems is the default on Vista and above) made the connection work.