Yes, that’s certainly possible, but what I was trying to achieve was having another layer of redundancy with what was already provided “out of the box,” so to speak. I plan to continue testing to see if there is any way to make this work.

I appreciate your comment. Thanks for reading!

Just a theoretical here; what about putting in a FC-to-iSCSI bridge, so that you’re not failing over to a new stack? I think that would simplify this situation, by making the iSCSI path appear to exist in the FC world. Of course, you’d probably need to build an additional seperate fabric, which means additional FC card (ugh), but it would technically be supported right? Really expensive, but then again, we’re talking FC SANs!

-Glenn

If you can try with a linux VM you probably will see the root (/) partition going read only (for example Red Hat Linux 4 Update 4 needs this rpm http://kb.vmware.com/KB/51306 in order to prevent going on Read Only in the event of a fail over)

Hope this helps, congratulations for the blog!
Jon

I thought it worked, too, until I ran the tests with IOmeter. I’m going to keep trying, and I’ll let you know if I get any different results.

Nick,

It seemed to me like it should work, too. I was able to manually fail over the paths as long as IOmeter wasn’t running.

As for the DiskTimeOut value, I’ll try that, but the error really seems to be at the ESX level. The Windows VM just kept on chugging.

Thanks!

Although, it sounds like a good solution, customers tend to be leary using different stacks. In fact we’ve supported this type of config for standalone windows environments and some UNIX environments (i.e HP-UX) for sometime now.

Try setting the Disk TimeOutValue(default=10″) in the Windows registry to be higher than the FC HBA driver timeout. It’s quite possible the Disk Class driver’s timing out the requests prior to the path switch been completed, especially if you’re queuing a whole bunch of requests…which you are.