[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-discuss] Guest unresponsive after Virtqueue size exceeded error

From: Fernando Casas Schössow
Subject: [Qemu-discuss] Guest unresponsive after Virtqueue size exceeded error
Date: Tue, 13 Jun 2017 21:08:15 +0000

Hi there,

I recently migrated a Hyper-V host to qemu/kvm runing on Alpine Linux 3.6.1 
(kernel 4.9.30 and qemu 2.8.1).

Almost on daily basis at least one of the guests is showing the following error 
in the log:

qemu-system-x86_64: Virtqueue size exceeded

Is not always the same guest, and the error is appearing for both, Linux 
(CentOS 7.3) and Windows (2012R2) guests.
As soon as this error appears the guest is not really working anymore. It may 
respond to ping or you can even try to login but then everything is very slow 
or completely unresponsive. Restarting the guest from within the guest OS is 
not working either and the only thing I can do is to terminate it (virsh 
destroy) and start it again until the next failure.

In the Windows guest the error seems to be related to disk:
"Reset to device, \Device\RaidPort2, was issued" and the source is viostor

And in Linux guests the error is always (with the process and pid changing):

INFO: task <process>:<pid> blocked for more than 120 seconds

But unfortunately I was not able to find any other indication of a problem in 
the guests logs nor in the host logs except for the error regarding the 
virtqueue size.

All the Windows guests are using virtio drivers version 126 and all Linux 
guests are CentOS 7.3 using the latest kernel available in the distribution 
All the guest disks are qcow2 images with cache=none and aimode=threads (tried 
native mode before but with the same results).

Example qemu command for a Linux guest:

/usr/bin/qemu-system-x86_64 -name guest=DOCKER01,debug-threads=on -S -object 
 -machine pc-i440fx-2.8,accel=kvm,usb=off,dump-guest-core=off -cpu 
-m 2048 -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -uuid 
4705b146-3b14-4c20-923c-42105d47e7fc -no-user-config -nodefaults -chardev 
 -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew 
-global kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -global 
PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device 
ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x4.0x7 -device 
-device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x4.0x1 
-device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x4.0x2 
-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -drive 
 -netdev tap,fd=35,id=hostnet0,vhost=on,vhostfd=45 -device 
-chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 
 -chardev spicevmc,id=charchannel1,name=vdagent -device 
 -device usb-tablet,id=input0,bus=usb.0,port=1 -spice 
port=5905,addr=,disable-ticketing,seamless-migration=on -device 
 -chardev spicevmc,id=charredir0,name=usbredir -device 
usb-redir,chardev=charredir0,id=redir0,bus=usb.0,port=2 -chardev 
spicevmc,id=charredir1,name=usbredir -device 
usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=3 -device 
virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 -object 
rng-random,id=objrng0,filename=/dev/random -device 
virtio-rng-pci,rng=objrng0,id=rng0,bus=pci.0,addr=0x8 -msg timestamp=on

For what it worth, the same guests were working fine for years on Hyper-V on 
the same hardware (Intel Xeon E3, 32GB RAM, Supermicro mainboard, 6x3TB Western 
Digital Red disks and 6x120MB Kingston V300 SSD all connected to a LSI 
LSISAS2008 controller).
Except for this stability issue that I hope to solve everything else is working 
great and outperforming Hyper-V.

Any ideas, thoughts?

Thanks in advance and sorry for the long email but I wanted to be as 
descriptive as possible.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]