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:
signature.asc
Description: This is a digitally signed message part.
