QEMU Windows guest unstable after random amount of time
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
linux (Ubuntu) |
Confirmed
|
High
|
Unassigned |
Bug Description
Ubuntu 14.04, all updates done as of 23/5/2014
Kernel : Linux 3.13.0-24-generic
Qemu : 1.7.1 and 2.0.0 tested
Tested using both Xeon 5620 and 5520 processors, 48GB RAM.
Anywhere from 20 minutes for 3+ hours after booting Windows guests become unstable. Guest appear to freeze intermittently (VNC console unresponsive, network pings dropped to guest, frozen IO) for 20-60 seconds at a time which repeats constantly every few minutes and guests do not recover unless QEMU is killed and the guest is started again. Whilst the guest is frozen CPU usage of the QEMU process jumps to 100-150%.
WORKAROUND: Disable automatic NUMA balancing:
echo 0 > /proc/sys/
---
AlsaDevices:
total 0
crw-rw---- 1 root audio 116, 1 May 24 01:25 seq
crw-rw---- 1 root audio 116, 33 May 24 01:25 timer
AplayDevices: Error: [Errno 2] No such file or directory
ApportVersion: 2.14.1-0ubuntu3.1
Architecture: amd64
ArecordDevices: Error: [Errno 2] No such file or directory
AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1:
CRDA: Error: [Errno 2] No such file or directory
DistroRelease: Ubuntu 14.04
HibernationDevice: RESUME=
InstallationDate: Installed on 2013-03-21 (428 days ago)
InstallationMedia: Ubuntu-Server 12.04.1 LTS "Precise Pangolin" - Release amd64 (20120817.3)
MachineType: Supermicro X8DTT
Package: linux (not installed)
PciMultimedia:
ProcFB: 0 VESA VGA
ProcKernelCmdLine: BOOT_IMAGE=
ProcVersionSign
RelatedPackageV
linux-
linux-
linux-firmware 1.127.2
RfKill: Error: [Errno 2] No such file or directory
Tags: trusty
Uname: Linux 3.13.0-24-generic x86_64
UpgradeStatus: Upgraded to trusty on 2014-05-21 (2 days ago)
UserGroups:
_MarkForUpload: True
dmi.bios.date: 05/20/2010
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 080016
dmi.board.
dmi.board.name: X8DTT
dmi.board.vendor: Supermicro
dmi.board.version: 2.0
dmi.chassis.
dmi.chassis.type: 17
dmi.chassis.vendor: Supermicro
dmi.chassis.
dmi.modalias: dmi:bvnAmerican
dmi.product.name: X8DTT
dmi.product.
dmi.sys.vendor: Supermicro
tags: |
added: latest-bios-2.1c removed: bios-outdated |
Changed in qemu (Ubuntu): | |
importance: | Medium → High |
status: | Incomplete → New |
description: | updated |
Changed in qemu (Ubuntu): | |
importance: | High → Medium |
affects: | qemu (Ubuntu) → linux (Ubuntu) |
Changed in linux (Ubuntu): | |
status: | New → Confirmed |
Changed in linux (Ubuntu): | |
status: | Confirmed → Incomplete |
tags: | added: ksm-numa-guest-perf |
The bug occurred when upgrading from 12.04.1 (3.2 kernel) to 14.04 (3.13 kernel). Booting with the old 3.2 kernel resolves the problem.
Guest command line - 1.4,accel= kvm,usb= off -cpu qemu64,hv_relaxed -m 4096 -realtimemlock=off -smp 2,sockets= 2,cores= 1,threads= 1 -uuid e00d6bde- ca3e-8e6c- 2c92-d5b5ec632b 9a -no-user-config -nodefaults -chardevsocket, id=charmonitor, path=/var/ lib/libvirt/ qemu/test. monitor, server, nowait -monchardev= charmonitor, id=monitor, mode=contro l-rtcbase= localtime, driftfix= slew -no-hpet -no-shutdown -bootstrict=on -devicepiix3- usb-uhci, id=usb, bus=pci. 0,addr= 0x1.0x2 -drive file=rbd: ssd/test: auth_supported= none,if= none,id= drive-virtio- disk0-devicevir tio-blk- pci,scsi= off,bus= pci.0,addr= 0x5,drive= drive-virtio- disk0,id= virtio- disk0,bootindex =2 -drive if=none, id=drive- ide0-1- 0,readonly= on,format= raw-deviceide- cd,bus= ide.1,unit= 0,drive= drive-ide0- 1-0,id= ide0-1- 0,bootindex= 1 -netdevtap, fd=24,id= hostnet0, vhost=on, vhostfd= 25 -devicevirtio- net-pci, netdev= hostnet0, id=net0, mac=52: 54:00:48: 81:8a,bus= pci.0,addr= 0x3-chardevpty, id=charserial0 -device isa-serial, chardev= charserial0, id=serial0- vnc127. 0.0.1:0 -devicecirrus- vga,id= video0, bus=pci. 0,addr= 0x2 -device virtio- balloon- pci,id= balloon0, bus=pci. 0,addr= 0x4
qemu-system-x86_64 -enable-kvm -name test -S-machine pc-i440fx-
Attached is a perf record of the qemu process whilst the fault was occuring.