qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] This patch adds a new block driver : iSCSI


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH] This patch adds a new block driver : iSCSI
Date: Fri, 23 Sep 2011 12:16:05 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2

On 09/23/2011 11:15 AM, Mark Wu wrote:
I tested this patch with the following command:
x86_64-softmmu/qemu-system-x86_64 --enable-kvm rhel54_1.img -m 1024 -net
tap,ifname=tap0,script=no -net nic,model=virtio -sdl -drive
file=iscsi://127.0.0.1/iqn.2011-09.com.example:server.target1/
And I found that the whole qemu process would get freezed, not reachable
via ping and no response on desktop if there's I/O targeted to the iscsi
drive and the iscsi target was forcefully stopped. After checking the
backtrace with gdb, I found the I/O thread got stuck on the mutex
qemu_global_mutex , which was hold by the vcpu thread. It should be
released before re-entering guest. But the vcpu thread was waiting for
the completion of iscsi aio request endlessly, and therefore couldn't
get chance to release the mutex. So the whole qemu process became
unresponsive. But this problem doesn't exist with the combination of
virtio and iscsi. Only the I/O process got hung on guest in this case.
It's more acceptable.  I am not sure how to fix this problem.

You don't. :( It's a problem in IDE emulation and anything else that uses qemu_aio_flush; luckily it's only called in a few places.

It would be the same with NFS instead of iSCSI, for example.

Otherwise, you could implement some kind of timeout+reconnect logic in the iSCSI driver or in libiscsi.

Paolo



reply via email to

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