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
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.
Fixed for real in 1.0.91-1.
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.
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