Major issues running OpenVPN inside of KVM

Major issues running OpenVPN inside of KVM

[Elias Probst]

[-- Attachment #1: Type: text/plain, Size: 2840 bytes --]

Hi,

I'm a really happy KVM user - I've been running several hosts (mostly servers) 
using KVM and I'm quite satisfied with it.

2 days ago I wanted to  add 2 hosts to our VPN but I ran into serious trouble 
which - after some analysis by the OpenVPN guys - seem to be caused by KVM.

What happens?
I can start the OpenVPN connection fine, but as soon as there are data 
transferred it starts hanging - sometimes for 4-5 seconds - sometimes for 60 
seconds.
The OpenVPN connection is completely dead during this time while a lot of 
lines like these appear in the log:

Wed Feb 25 10:26:27 2009 read UDPv4 [EHOSTUNREACH]: No route to host 
(code=113)

The strange thing about this is the fact, that while the OpenVPN connection is 
completely stuck and tells me it couldn't reach the host of the VPN server - 
everything else works quite fine. If I connect via SSH directly to the KVM host 
I can still work as usual - only connections tunneled through OpenVPN are 
dead.

First I've suspected it's related to the virtio network driver, but replacing 
'virtio' with 'e1000' didn't change anything at all.

Another thought was using a more precise timer as I've thought this issues 
could be caused by an unprecise timer and the catch-ups of it cause the 
trouble - but as clocksource=tsc caused some trouble in the past I've changed 
to acpi_pm, which - according to some people in #kvm is the best solution at 
the moment and the problem still exists.

How could I debug this issue further? Neiher could I find any suspicious 
messages in 'dmesg' nor in the logfile created by libvirtd.

Some information about the system:

Host machine:
CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 5600+
KVM: 84 (82 was tested too)
Kernel: 2.6.28
Distribution: Gentoo

KVM Guest:
Kernel: 2.6.28
OpenVPN: 2.1_rc15 (2.0.7 showed the same behaviour)

The KVM process is started by libvirt as follows:
/usr/bin/kvm -S -M pc -m 768 -smp 2 -name evsrv003.evaluba.com -uuid 
a5a81c35-4c07-47eb-8efb-302c8ec61169 -monitor pty -pidfile 
/var/run/libvirt/qemu//evsrv003.evaluba.com.pid -boot c -kernel 
/var/lib/libvirt/kernel/evsrv003.evaluba.com/kernel-genkernel-x86_64-2.6.28-
gentoo-r2 -initrd /var/lib/libvirt/kernel/evsrv003.evaluba.com/initramfs-
genkernel-x86_64-2.6.28-gentoo-r2 -append root=/dev/ram0 
real_root=/dev/storage/root dolvm clocksource=acpi_pm -drive 
file=/var/lib/libvirt/ISO/grml64-
medium_sid_latest.iso,if=ide,media=cdrom,index=0 -drive 
file=/var/lib/libvirt/images/evsrv003.evaluba.com.img,if=virtio,index=0,boot=on 
-net nic,macaddr=00:95:2b:0e:aa:3c,vlan=0,model=e1000 -net 
tap,fd=17,script=,vlan=0,ifname=vnet0 -serial none -parallel none -usb -vnc 
10.5.3.1

Has anyone any ideas where to look for further information how this happens?

Best regards,

Elias P.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Major issues running OpenVPN inside of KVM

[Avi Kivity]

Elias Probst wrote:
> Has anyone any ideas where to look for further information how this happens?
>
>   

You could try running tcpdump on the guest, the host tap interface, and 
the host bridge.  By comparing the logs, we could see which packets are 
lost or delayed and try to figure out why they're special.

-- 
error compiling committee.c: too many arguments to function