The Windows You Know™ formerly assigned letters of the alphabet to storage volumes. With the introduction of Cluster Shared Volumes (CSV), drive letters are no longer used — relying instead on a 128-bit globally unique identifier (GUID). In other words, what used to be called the “F drive” is now known as \\?\Volume{d5ad02f4-4e30-11ed-b1db-ca8c6df4064b}\.
While in some contexts the difference is minimal, one obviously affected area is monitoring with System Center Operations Manager 2007 (SCOM), which exposes volume GUIDs in various user interfaces:
In related news, an interesting report recently published by a top medical journal found that those in a relatively new information technology position known as “Hyper-V Administrator” exhibited strongly enhanced memory recall capabilities. This correlation is thought to be a result of the rigorous, albeit unintentional, mental training these personnel undergo in the course of their daily responsibilities.
“It appears to be a classic case of the Von Restorff effect,” said Dr. Sedgwick McCaskey, primary contributor to the research and author of the best-seller Don’t Forget IT.
The report also went on to explain that some “Hyper-V Administrators” have found mnemonic devices to be a great help in their jobs. “Instead of trying to remember all of those random letters and numbers, I sometimes make up songs or rhymes,” said one anonymous participant in the study.
It’s great to see nimble professionals that are able to quickly adapt in the face of change. Especially considering the fact that every new Windows Server 2008 R2 system has a hidden 100 MB partition created automatically during installation by default. And since that volume has no drive letter, it shows up in SCOM with – you guessed it – the volume GUID:
Ouch. Pass the Ginkgo.
Just to be clear: three paragraphs of this article are satire; the rest is factual. If you can’t figure out which is which, feel free to ask.
Pingback: Tweets that mention Hyper-V CSV volumes must be monitored by a complex GUID instead of drive letter | VCritical -- Topsy.com
Windows has supported mount points since windows 2000. What’s preventing mount points from being used for these. The GUIDS for volumes have always been there, every drive letter still has a GUID associated with the actual backend volume..
I get it ! Rain Man was an Hyper-V admin 🙂
I don’t understand the irony, it soooo easy to deal with friendly names such as “\\?\Volume{d5ad02f4-4e30-11ed-b1db-ca8c6df4064b}\” !
Pingback: VMFS UUID numbering explained « DeinosCloud
VMFS Volume UUID is also undecipherable… Is it really? -> http://wp.me/pvGaC-dZ
But you never need to deal with them directly, specially for monitoring.
Exactly.
When you use Hyper-V R2 with CSV, if you follow the correct steps, you will get a mount point like this c:\ClusterStorage\Volume1 where “Volume1, Volume2 etc..” is your fabulous GUID… It’s just a different approach rater than use D:\ E:\ F:\…
Steeve, what you say is true on each individual host, but not when monitoring from SCOM.
How do you propose we address volumes on systems with more than 26? What about interconnected systems where there are thousands of volumes that are not necessarily associated with a particular system?