James Harper wrote:
>>> You will almost certainly get some fatal corruption before too long
> if
>>> this is happening. It shouldn't happen obviously...
>> Side note: on an important VM, if you find yourself in this situation
> (two
>> drives pointing at the same underlying data) and don't want to lose
> data,
>> it's best to stop it as soon as possible. Probably an xm destroy is
>> better
>> than a clean shutdown in this case!
>
> Yes, this is something that really can't be understated. Even on a
> system I have booted, checked in device manager, found the duplicates,
> and done an 'xm destroy', it has already been too late - the system
> would no longer boot. A chkdsk from the recovery console fixed it up
> again, but who knows what else was corrupt.
I couldn't agree more. You can never caution people enough when testing
new code anywhere in the storage stack.
> Other PV drivers appear to be able to tell windows that one drive is
> just another path to the other. I'm not sure how to tell windows this
> though. My preference is to hide the qemu device, but this doesn't
> appear to work under all circumstances and the multipath thing would
> prevent data corruption...
We (Virtual Iron) don't actually rely on any multipath detection in
Windows guests (or for that matter, Linux guests, which can have similar
problems). We implement a device hiding mechanism (probe limits) in
dom0/qemu-dm to prevent the ide devices used by the guest BIOS during
bootstrap from responding to ide identify probes by the booting guest
operating system. This has the benefit of working without any necessary
cooperation in the guest operating system. The failure mode is a failed
boot, not a destroyed disk image. Unfortunately, this probe limit
change is currently dependent on other dom0 control stack changes we
use. If there is interest, we could look into breaking out a
standalone patch. The changes to qemu are minimal. Essentially, the
ide devices allow 1 probe each for the BIOS bootstrap and remain silent
after that. No data path changes were required.
> Anyone have any suggestions?
The first issue with multipath is getting Windows to think that the disk
devices are identical. Since the qemu device is ide and your PV device
is scsi, there is no real world example to guide you. You could look at
the way Windows constructs it's disk identifier for ide drives and
attempt to generate an identical string in your driver. If you used a
scsi device in qemu, you should only need to return identical target
identification strings for the same disk.
Steve
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home