Description of problem: Win2008r2 complains file missing after reboot during the installation process. Version-Release number of selected component (if applicable): kvm-83-249.el5 virtio-win-1.0.3-52454.iso How reproducible: 3 / 100+ attempts Steps to Reproduce: 1. qemu-kvm -name 'vm1' -monitor unix:'/tmp/monitor-humanmonitor1-20120320-043211-usaq',server,nowait -serial unix:'/tmp/serial-20120320-043211-usaq',server,nowait \ -drive file='win2008r2-64-virtio.qcow2',if=virtio,media=disk,cache=none,boot=on,format=qcow2 \ -net nic,vlan=0,model=virtio,macaddr='9a:2c:0f:04:d4:1c' \ -net tap,vlan=0,fd=21 -m 4096 -smp 4,cores=2,threads=1,sockets=2 -drive file='x64_dvd_617601.iso',media=cdrom \ -drive file='winutils.iso',media=cdrom \ -drive file='virtio-win.iso.el5',media=cdrom \ -cpu qemu64,+sse2 -soundhw ac97 -fda 'answer.vfd' \ -spice port=8000,disable-ticketing -qxl 1 -rtc-td-hack \ -M rhel5.6.0 -boot d -usbdevice tablet 2. 3. Actual results: as snapshot, but not always missing that file, can be other file. guest complains driver file missing, unable to boot. Expected results: guest works well, not file missing. Additional info: 1) till now, hit it 3 times when guest using virtio-blk, still trying to see if it exist on ide. will update then. 2) this exist on kvm-83-249.el5_8 too.
Created attachment 571283 [details] snapshot
Sounds like a corrupted "Windows" disk.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux release for currently deployed products. This request is not yet committed for inclusion in a release.
Where is the VM image located - locally or on NFS? Thanks, Vadim.
(In reply to comment #6) > Where is the VM image located - locally or on NFS? Hi Vadim, VM image is a local qcow2 file. Thanks, Xiaoqing.
Hi Xiaoqing, Could you please check how it works on raw image? Thank you, Vadim.
Kevin, Does it ring any bell?
Not really. I know the problem of missing files (i.e. data loss) from unclear qemu shutdowns on RHEL 6, where it wouldn't write back the cache, but RHEL 5 doesn't have this cache nor is any qemu kill mentioned here. One option is Windows is issuing patterns that Linux wouldn't do and that therefore it's a real qcow2 bug. I believe that this is rather unlikely, qcow2 code in RHEL 5 hasn't been touched for a long time and we haven't seen any corruption bugs for quite a while. Upstream didn't find and fix any corruption issues either. If we assume that it's the Windows virtio driver, the difference between raw and qcow2 should be mostly in the timing of requests. If you have cluster allocations, the delay tends to be longer, and maybe requests are even more likely to complete in different order than they were issued.
FYI. I tried to install block drivers in virtio-win-1.5.3-1.el6_3.noarch on win7 64 bit guests on RHEL5 hosts (kernel:2.6.18-324.el5 kvm-83-256.el5) .Still hit the same issue . steps: 1.create qcow2 image 2.install win7 64 bit guests: CLI: /usr/libexec/qemu-kvm -M rhel5.6.0 -m 8G -smp 4 -name test -uuid 355ba458-1c94-2cae-77f9-0f1ac838bc4b -monitor stdio -no-kvm-pit-reinjection -boot dc -drive file=/home/win7-64,if=virtio,boot=on,format=qcow2,cache=none -net nic,model=virtio,macaddr=54:52:00:09:e7:e5,vlan=0 -net tap,vlan=0 -serial pty -usb -vnc :0 -k en-us -vga cirrus -fda virtio-win.vfd -cdrom en_windows_7_ultimate_with_sp1_x64_dvd_618240.iso Actual Results: After reboot ,guests complains File :\windows\system32\drivers\atapi.sys Status: 0xc0000098 info： windows failed to load because a critical system driver is missing ,or corrupt"
Regarding bug 835023, bug 840715, and bug 804888 We are late in RHEL5, and we also do not want to put too many resources into RHEL5 bugs, so I am closing these bugs. - These bugs are difficult to reproduce, both Vadim and Kevin failed to reproduce them, for days. - These bugs are related to the initial installation, so no real harm done. - Reproducing it requires a cycle of installation, that takes a minimum of 1/2 an hour, and even more if we want to try it during high load. - This is not a regression. - They were not reported by customers, which probably means that customers rarely install Windows guests on RHEL5.9. They probably install once and use a template (if at all). Since we are talking about RHEL5 host, this probably will not change. - A simple workaround is usually to simply retry. Other workarounds are to use raw file (instead of QCOW), or to add virtio-stor driver only after the initial installation Once any of these bugs is reported by a customer, we will reconsider. In most cases the customer should be able to retry and forget about it. With uncomfortable feelings, Ronen.