VMWare Server 2 RC2 fails to boot VMs

For a couple of days now, VMWare Server 2 RC2 was refusing to start virtual machines. It kept waiting at 95%.

It turns out that VMWare cannot boot virtual machines (or upgrade them) when kernel modules kvm_intel, kvm etc are loaded.

Here is the error message from hostd.log:

Question info: The virtualization capability of your processor is already in use. Disable any other running hypervisors before running VMware Server.

Of course the obvious solution is to rmmod the kvm related modules:

# lsmod |grep kvm
# rmmod kvm_intel
# rmmod kvm_amd
# rmmod kvm

The modules are most probably auto-loaded by /etc/init.d/kvm (but there may be other reasons too).

Run secureley wireshark as a user

Sometimes there is the need to allow normal users to run wireshark and capture packets from the network. Running wireshark with sudo is a security hole since anyone can overwrite any file.

A secure one-liner that solves this problem is:

# (sudo dumpcap -w -) | wireshark -k -i -

Assuming that sudo is configured to allow the user to run "dumpcap -w -" as root.

This should be 100% secure (except from the traffic monitoring issue) and will work well in (for example) labs.

fglrx (Catalyst 8.8) + kernel 2.6.26 + PAT

It seems that PAT support that is included in linux kernel 2.6.26 has some problems. If you are using a recent ATI Catalst (fglrx) driver (at the time of this writting, the lattest was 8.8) with 2.6.26 kernel with PAT support you may have problems.

Problems may include freezes every couple of seconds when playing videos or full-screen 3D apps/games.

To solve this problem you will have to disable PAT support in kernel. Fortunately there is a kernel boot parameter that does with without requiring recompilation. Just add "nopat" to kernel boot parameters and you should be OK. Debian users should not worry since PAT is disabled in the default kernel.

The above is half the truth. When disabling PAT you should make sure that MTRR is being set-up correctly. Start the X server and look at Xorg.0.log for the string "Linear":

$ grep Linear /var/log/Xorg.0.log
(--) fglrx(0): Linear framebuffer (phys) at 0xc0000000

Then look at lspci -v outpout:

01:00.0 VGA compatible controller: ATI Technologies Inc Mobilitiy Radeon HD 3600 Series
Subsystem: ASUSTeK Computer Inc. Device 01e4
Flags: bus master, fast devsel, latency 0, IRQ 16
Memory at c0000000 (64-bit, prefetchable) [size=256M]
Memory at ff6f0000 (64-bit, non-prefetchable) [size=64K]
[...]

("size=256M" is what we need). Don't worry if you have more than 256MB of memory in your graphics card but it only shows 256MB. This is expected behaviour.

Then look at /proc/mtrr for a line like this one:

reg04: base=0xc0000000 (3072MB), size= 256MB: write-combining, count=1

The base address is from the Xorg.0.log file and the size is from lspci output (0x10000000 is 256MB (=256*1024*1024 bytes)). For most cases this should be taken care of by the X server

If you don't see it then you'll have to setup MTRR by yourself. There are many documents on the web but at the end you'll be running something like this:

echo "base=0xc0000000 size=0x10000000 type=write-combining" > /proc/mtrr