However with VMWare support you’re about 90% less likely to need it, which mitigates that fact.

VMWare is also a *MUCH* more mature platform. More feature friendly, more functionality, and just plain easier to use.

Again – the only person who would choose Hyper-V over VMWare is someone who has drank the Microsoft kool-aid.

T-Mobile did that, didn’t they? Now look what happened.

Actually to find out later that this was a HITACHI problem… (Not sure yet if it was hardware or with their contractors – still trying to find that out)

http://www.channelregister.co.uk/2009/10/12/sidekick_hitachi/

Points to it as a problem during a “Storage Area Network Remediation done by Hitachi Data Systems”

A few other articles I’ve seen are pulling the ‘blame the contractor’ nonsense that they all do. We’re convenient scapegoats, especially when consulting on badly flawed technology.

I do understand that that’s an out-of-date thinking (haven’t had a lot of chance to play with 2007 yet, my Dell 2650′s won’t support 64 bit wintel.) but I’m not sure if a single-transaction-log volume is really the way to go.

That plus I love the “(Make sure these are not crossing spindles)” comment. This is *DEFINITELY* an indicator of the thinking of someone who does not understand modern cached disk arrays.

To clarify. When you’ve got 128G of cache in a disk array, it *REALLY* doesn’t matter in any meaningful way whether or not you’re crossing spindles. All writes happen directly to cache. All reads happen from disk, but due to modern pre-fetch algorithms happen..well…from cache.

DAS = no (or very little) cache.

It seems M$ support really does not ‘get’ shared disk arrays at all (my opinion)…recently we had some heavy latency issues (>200ms across the board!) due to what ended up being a driver problem…anyway…check this M$ response to our issue for a laugh:

—begin snip
“… The other cause is having all databases and all transaction logs going to a single LUN (each on their own S: and L: ). When we have all databases going to a single LUN, in your case 18 databases, we cause an extreme amount of I/O across those spindles happening or trying to happen simultaneously. My recommended action plan as follows and the items are listed in priority as to what I would take care of first if it were my environment, the corresponding data will follow the action plan.

Plan of Action:

1.) Work with your storage team to get 36 LUNS carved out (make sure these are not crossing spindles).
2.) Move each database to its own LUN.
3.) Move each transaction log set to its own LUN.
Here is a link to the Mailbox Server Storage Design and a snippet from it below. Please understand that I know carving out this many LUNs may not be feasible in your environment however, it is best practice and thus it is what I need to recommend to you to resolve your issue. With that said there are a other approaches that I see corporate businesses take and if the above is not feasible we can discuss them if you like.” —end snip

Anyway, the config is 1 lun for DB’s, one for logs. After getting the drivers updated, < 5ms across the board. As, the aggregate of spindles behind each lun are way greater than the IOPS required. 36 luns. Not crossing spindles (come on now). For a single server. How old school is that??? lol.