Description of problem: Version-Release number of selected component (if applicable): # uname -r 2.6.18-267.el5 # rpm -q kvm kvm-83-236.el5 guestinfo : windows 2008 How reproducible: 3/3 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 8.8.8.8 -t 5.stop iscsi target server Actual results: after 2-3 mins ,BSOD happend in the guest (referring to the screendump) (qemu)bdrv_write ret=-5 Expected results no BOSD occurs Additional info:
Created attachment 505793 [details] Screen dump
Hi, Mike! 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 TIA Arkady
Hi, Mike! 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 terminated. 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. Arkady
Mike, Arkady, 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 ? Mike
At least for VM running Windows.
Kevin, In view of https://bugzilla.redhat.com/show_bug.cgi?id=714915#c7 What is your call?