Bug 518509

Summary: Data loss/corruption when removing disks from Windows guests
Product: Red Hat Enterprise Linux 5 Reporter: Paolo Bonzini <pbonzini>
Component: xenpv-winAssignee: Paolo Bonzini <pbonzini>
Status: CLOSED ERRATA QA Contact: Virtualization Bugs <virt-bugs>
Severity: high Docs Contact:
Priority: high    
Version: 5.3CC: azarembo, clalance, james.brown, jmh, jskrabal, kxiong, plyons, xen-maint
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 501027 Environment:
Last Closed: 2009-11-16 13:44:46 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 501027, 518405    
Attachments:
Description Flags
mark PV drives as removable none

Description Paolo Bonzini 2009-08-20 16:24:37 UTC 
It is possible to lose data while detaching hard drives from Windows guests running on xenpv-win drivers.  This is likely because windows use disk caching which does not get flushed upon detach.  "xm block-detach" can be compared to hard removing a USB drive and as such can cause data loss for all cached data inside domU.  If you go to disk properties, however, the option to turn off disk caching is grayed out.

In order to safely detach a block device, it's necessary first to force writing all data (sync -r) and detach the volume (mountvol /d).  Before doing so, in turn, one should check that no handles are open within the volume.  Automating this process would be desirable, as it would eliminate the chance of data loss due to not following these steps or not following them properly.

In order to fix this problem, there are different possible options.

1. Figuring out the reason that is graying out the option to turn caching on/off. Can disk PV-drivers be responsible for this in some way? Have you seen similar behavior in your lab testing? We will really appreciate if you can help us track this down.

2.When a backend disk driver receives a request to detach a disk drive from DOMU, does it first send any notification to frontend PV driver in DomU?  If there is any such a notification and if PV driver propagates that notification up the disk driver stack properly, then the volume driver should flush the cache before tearing down the stack.  If there is no such notification, is it possible to add such notification?

3. In Linux, if a disk drive is mounted inside DOMU and a detach command is issued, the command fails with error device busy.  This means that some message exchange happens between DOM0 and DOMU before detaching the device.  Does a similar message exchange happen for windows?  If so can we trap that message in user mode to automate cache flushing if #2 is not possible.

4. Does disk PV driver satisfy all the pnp criteria mentioned in this page http://msdn.microsoft.com/en-us/library/ms802356.aspx
Comment 1 Paolo Bonzini 2009-09-22 16:30:26 UTC 
Created attachment 362118 [details]
mark PV drives as removable

For now we'll be marking Xen PV drives as removable.  This affects Windows in several ways:

1) every user will be able to format the drive

2) only the first partition of the drive will be accessible

3) the context menu for the drive in "My Computer" will show an Eject menu
item.  (At least in Vista and 2008 Server; the details may vary in XP and 2003
Server).

The workaround, then, is to explicitly eject the drive (and wait for Windows to
unmount it, which may take 10-15 seconds) before detaching the block device
from dom0.

I'm moving this bug into POST, seeking a better solution that does not require domU intervention can be done in another bug.
Comment 2 Paolo Bonzini 2009-10-12 08:27:18 UTC 
Fixed for real in 1.0.91-1.
Comment 4 koka xiong 2009-11-02 08:40:20 UTC 
1.Install win2003/32 guest
2.Install xenpv-win driver
3.Run dd if=/dev/zero of=disk1.img bs=1M count=4096
4.Run xm block-attach win03_32 tap:aio:/root/disk1.img /dev/hdb w
5.Format the new attached disk
6.Create a notepad write some text then save it
7.Run xm block-detach win03_32 /dev/hdb
8.Run xm block-attach win03_32 tap:aio:/root/disk1.img /dev/hdb w
9.Verify the saved file is still there.
10.Repeat the step6--step9 several times,the notepad isn't lost.
Verification is passed.
Comment 6 errata-xmlrpc 2009-11-16 13:44:46 UTC 
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHEA-2009-1583.html