1

Getting a kernel panic with this error on my XEN VPS's. (all on 8.04 LTS)

The kernel version on my Dom-0 is 2.6.24-25-xen and the kernel version on the Xen VPS is also 2.6.24-25-xen.

I read something about disabling APIC from here http://muffinresearch.co.uk/archives/2008/08/20/ubuntu-bug-soft-lockup-cpu0-stuck-for-11s/

but that doesn't seem to help as well.

Anyone experienced this and are there any workarounds?

Thanks in advance!

3 Answers3

2

this can happen because of two things:
1. Overcommitted CPUs or RAM
2. Time drifts

You should make sure you are not overloading the host, not assigning more CPU cores or RAM tha n the host can provide, and also set up ntp, and possibly implement some kernel boot options specific to your virtualization platform

dyasny
  • 18,482
  • 6
  • 48
  • 63
0

Did you specify dom0_max_vcpus in grub? I saw this issue on my xen cluster for a while and I eventually discovered it was because I had limited dom0 to two vcpus. After I removed that I haven't seen it again.

Jeff Snider
  • 3,252
  • 17
  • 17
  • Thanks Jeff sorry for the late reply! We eventually moved to KVM instead of Xen, so didn't actually find a solution to our problem. –  Mar 11 '10 at 03:01
0

Are you seeing this on guests with more than 1 vCPU? I've seen this happen a couple of times on my XenServer-based VMs, running Ubuntu in the guest as well. My work-around was to scale back from 2 vCPUs to just 1. YMMV.

ktower
  • 1,161
  • 9
  • 14
  • Thanks! Yes both the Xen VMs which had issues had vcpu > 1. Will try this out and report back. Was this on 8.04 as well? Seems a little wasteful though if a guest can't use more than one vcpu :( Thanks again –  Dec 16 '09 at 06:09
  • Yup. 8.04.3 LTS. Fortunately, my Ubuntu VMs are relatively low-use, so it was easier for me to simply reduce the vCPU count rather than spend the time troubleshooting. :) Not very geeky of me, I'm afraid. – ktower Dec 16 '09 at 14:57
  • Hmm before I tried setting to vcpu=1, I tried three other things: 1. Disable apparmor on the Dom-0 - /etc/init.d/apparmor stop - update-rc.d -f apparmor remove 2. Remove /lib/tls (mv /lib/tls to /lib/tls.disabled) 3. Set loop max_loop=64 in /etc/modules The Domu didn't crash and burn yesterday but it still had some performance problems. Investigating now and will keep posting my findings. –  Dec 17 '09 at 02:58