Description of problem:
Version-Release number of selected component (if applicable):
# uname -r
# rpm -q kvm
Steps to Reproduce:
1.prepare a iscsi-server.
2.use iscsi-initiator to connected it and create a image on it
#qemu-img create -f raw /dev/mike_cao/win08_5.6.0 20G
3.start guest w/o werror=stop
eg:/usr/libexec/qemu-kvm -m 4G -smp 1,sockets=1,cores=1,threads=1 -name RHEL5u7 -uuid 13bd47ff-7458-a214-9c43-d311ed5ca5a3 -monitor stdio -no-kvm-pit-reinjection -boot c -drive file=/dev/mike_cao/win08_5.6.0,if=ide,format=raw,cache=none,boot=on -net nic,macaddr=54:52:00:52:ed:61,vlan=0,model=rtl8139 -net tap,script=/etc/qemu-ifup,downscript=no,vlan=0 -serial pty -parallel none -usb -vnc :7 -k en-us -vga cirrus -balloon none -notify all
4.in the guest #ping 184.108.40.206 -t
5.stop iscsi target server
after 2-3 mins ,BSOD happend in the guest (referring to the screendump)
no BOSD occurs
Created attachment 505793 [details]
Please upload memory dump file of that crash ( screen dump is just some part of it). That may be memory.dmp file in windows directory or kernel minidump file in windows\minidump directory. Obviously kernel dump include more info than minidump but let's start from something we have. If minidump will have no enough info, I'll ask you to set
"kernel memory dump" in advance options in the property box of the computer and reproduce the crash
After some additional analysis ( just didn't pay attention on the bottom of the bluescreen, I understand that it's impossible to receive dump file because of disk absence. But that was the reason why bsod happen, some critical process ( the one from the list in http://msdn.microsoft.com/en-us/library/aa373646%28VS.85%29.aspx ) tried to write to disk ( e.g. paged memory into swapfile or something else ) and failed on that write op. That caused for this process to terminated and in advance caused current BSOD - CRITICAL_OBJECT_TERMINATION (f4)
A process or thread crucial to system operation has unexpectedly exited or been
When werror=stop exist qemu suspend VM so windows kernel doesn't run and no write error happen in it. When you restart iscsi-target (insert disk back) the guest continue to work without knowledge of the previous write error.
So for the windows guest werror=stop is must, unless you want to remove it for some debug purposes.
I believe that we would like the default to be werror=stop.
Anyhow, we try to do the bare minimum for RHEL-5. How are things with RHEL-6.1
(In reply to comment #6)
> Mike, Arkady,
> I believe that we would like the default to be werror=stop.
no ,Kevin said Default value is werror=enospc
> Anyhow, we try to do the bare minimum for RHEL-5. How are things with RHEL-6.1
In this case, if we'll decide not to change to default werror=stop for guest running windows OS (any) in RHEL 6, possible to stand that it's by design behaviour, as I wrote before.
Closing the bug.
BSOD is the expected guest behavior when its system disk is suddenly removed.
(In reply to comment #9)
> Closing the bug.
> BSOD is the expected guest behavior when its system disk is suddenly removed.
as werror=stop is the recommend param during testing .Can we change to default werror=stop ?
At least for VM running Windows.
In view of https://bugzilla.redhat.com/show_bug.cgi?id=714915#c7
What is your call?