public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: James Stevens <James.Stevens@communitydns.net>
To: kvm@vger.kernel.org
Subject: stability issue with KVM using SMP
Date: Tue, 16 Sep 2008 09:25:29 +0100	[thread overview]
Message-ID: <48CF6D79.6090607@communitydns.net> (raw)

Summary - I'm getting stability issues running SMP. The guest will run 
for, typically, 6 to 12 hours before causing a problem.

The first time it happened the guest process that was running SMP went 
Zombie, but in a spin loop clocking huge amount of CPU time, and I had 
to reboot the host to clear it. Needless to say I had no access to the 
guest's qmeu console (Ctrl-Alt-2) and a "kill -9 <pid>" from the host 
had no effect.

However, the kernel had been compiled with a 64Gb memory model and I've 
had problems with that in the past - in fact that's the first time I've 
seen a kernel compiled with the 64Gb memory model actually boot under KVM.


So I replaced the kernel and the next time the guest simply locked up - 
I couldn't access the guest o/s at all (no "ping", no linux console 
response etc - in some cases there was a picture on the console [login 
prompt] but it didn't respond to any key presses), but the qemu console 
still worked. I tried a "system_powerdown" and that failed so I did a 
"system_reset" and that rebooted the client.


I have now switched off SMP and the guest is working fine (just SLOW).


I've had quite a few non-SMP linux guests running on this host for some 
time, using various kernels, and not seen a problem. Its only since I 
tried to introduce SMP that its all gone pear shaped.


> # what cpu model (examples: Intel Core Duo, Intel Core 2 Duo, AMD
> Opteron 2210). See /proc/cpuinfo if you're not sure.

dual "Quad-Core AMD Opteron(tm) Processor 2352" with 32Gb RAM

> # what kvm version you are using. If you're using git directly,
> provide the output of 'git describe'.

"kvm-72"

> # the host kernel version

"2.6.26.2" running on Slackware 12

> # what host kernel arch you are using (i386 or x86_64)

# CONFIG_64BIT is not set
CONFIG_X86_32=y
# CONFIG_X86_64 is not set
CONFIG_X86=y

Should I be using 64 bit ?

> # what guest you are using, including OS type (Linux, Windows,
> Solaris, etc.), bitness (32 or 64), kernel version

Slackware 11, but with a new standard (no patches) kernel - 2.6.26.2

I also have an older Slackware 7 based guest with a 2.4.29 SMP kernel 
that sees the "lock-up, with qemu console working" problem, but not the 
Zombie issue. The 2.4.29 kernel uses a 1Gb memory model.

> # the qemu command line you are using to start the guest

/usr/local/bin/qemu-system-x86_64 -hda /opt/kvm/machine_14/vdisk1.img \
	-m 1024 -vnc :14 -k en-gb -smp 4 \
         -net nic,model=e1000,macaddr=52:54:00:14:00:00 -net tap \
         -net nic,vlan=2,model=e1000,macaddr=52:54:00:14:00:01 \
	-net tap,vlan=2,ifname=tap55 \


> # whether the problem goes away if using the -no-kvm-irqchip or
> -no-kvm-pit switch.

Not tried

> # whether the problem also appears with the -no-kvm switch.

I don't use this switch.



James

             reply	other threads:[~2008-09-16  8:25 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-16  8:25 James Stevens [this message]
2008-09-16 11:46 ` stability issue with KVM using SMP James Stevens

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=48CF6D79.6090607@communitydns.net \
    --to=james.stevens@communitydns.net \
    --cc=kvm@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox