You’re not new to Virtualization, this isn’t your first VMware rodeo, but you find yourself starting to question… OMG DO I HAVE VMFS3 DATASTORES STEATHILY HIDING IN MY SYSTEM?! I mean you do your due diligence, you check and confirm that it says VMFS5 and that it has a 1MB (Universal) block size, but yet… you’re still not sure… Hell, you might even be saying WTF? 1MB BLOCK SIZES? WTFS?! Well, hopefully this helps break through some of the barriers to not only identify whether you have VMFS3 datastores period, whether they’re actually stealthily hiding!
What’s the big deal with upgrading VMFS3 to VMFS5?
Yea, you read the VMware documentation like this; How VMFS5 Differs from VMFS3 – Basically by reading that you come to the conclusion of ITS EASY, JUST DO IT, YAY! But to quote Jason Corbett @NGTJason “migrate > upgrade”
Why exactly though? I mean if you read what Cormac Hogan @VMwareStorage wrote so long ago vSphere 5.0 Storage Features Part 1 – VMFS-5 you might be pressured to believe that it’s all good, caveats aside that your VMFS5 upgraded datastores will rock out just like VMFS3, but take a gander at Jason Boche @JasonBoche VMFS-5 VMFS-3, What’s the Deal?
Differences between upgraded and newly created VMFS-5 datastores:
VMFS-5 upgraded from VMFS-3 continues to use the previous file block size which may be larger than the unified 1MB file block size. Copy operations between datastores with different block sizes won’t be able to leverage VAAI. This is the primary reason I would recommend the creation of new VMFS-5 datastores and migrating virtual machines to new VMFS-5 datastores rather than performing in place upgrades of VMFS-3 datastores.
VMFS-5 upgraded from VMFS-3 continues to use 64KB sub-blocks and not new 8K sub-blocks.
VMFS-5 upgraded from VMFS-3 continues to have a file limit of 30,720 rather than the new file limit of > 100,000 for newly created VMFS-5.
VMFS-5 upgraded from VMFS-3 continues to use MBR (Master Boot Record) partition type; when the VMFS-5 volume is grown above 2TB, it automatically switches from MBR to GPT (GUID Partition Table) without impact to the running VMs.
VMFS-5 upgraded from VMFS-3 will continue to have a partition starting on sector 128; newly created VMFS-5 partitions start at sector 2,048.
I THINK I HAVE VMFS3 VOLUMES HOW DO I TELL, OMG WHAT IS THAT BURNING SENSATION
Hey, calm down, calm down… I think we can solve this problem pretty easily! And if the burning sensation continues, get that checked out!
I don’t know about you, you might have 1 vCenter, 3 Servers and a handful of Datastores. I have thousands… of EACH, so I needed something to do my scans and checks at scale with PowerCLI because I’m a baller, and apparently I pull that off rather well. :)
Methods of detecting whether you have VMFS3, VMFS3 upgraded to VMFS5 or otherwise mismatched sets..
- Block Size is greater than 1MB
- Partition type is msdos instead of gpt (*Detected by checking whether the StartSector is 128 instead of 2048)
- And of course, your VMFS version is VMFS3 or 3.46
But wait, didn’t you say above that partition types will change from MSDOS to GPT if they’re expanded? Doesn’t that make tracking harder? Yes.
Let’s get our PowerCLI on so we can crack this nut!
Get-Datastore | Get-View | Select-Object Name,@{N="VMFS version";E={$_.Info.Vmfs.Version}},@{N="BlocksizeMB";E={$_.Info.Vmfs.BlockSizeMB}}
// To check VMFS version & block sizes – Really useful to just check in general that your version is 5.54 and your blocksize is 1MB though if you VMFS3->5 In-place upgrade when VMFS3 was 1MB, this won’t reveal itself to you
Get-Datastore | Get-View | Where {$_.Info.Vmfs.Version –eq “3.46”} | Where {$_.Info.Vmfs.BlockSizeMB -eq "1"} | Select-Object Name,@{N="VMFS version";E={$_.Info.Vmfs.Version}},@{N="BlocksizeMB";E={$_.Info.Vmfs.BlockSizeMB}}
// To Check VMFS Version and Block Sizes but only listing mismatches you specify – so if you want to see if you specifically have any 3.46 VMFS and various block sizes
Busting out the mad $esxcli syntax!
This is where we start to get real. The following examples are simple ‘one-liners’ which are cute and all if you’re checking one host, but I also give you one which will scan EVERYTHING so you can just sit back and bask in the glow of figuring out WTF IS GOING ON WITH THIS BURNING, HELP HELP HELP!
$esxcli.storage.core.device.partition.list() | Select Device, StartSector
// Dumps all Offsets – This can be useful if you want to see a lot of data… but less so if you’re looking for something specific…
$esxcli.storage.core.device.partition.list() | group-Object -Property Device | Where {$_.StartSector –eq “128”} | Select Device, StartSector
// Dumps only offsets which "equal" a startsector, in this case 128 – Now we’re cooking with oil, a StartSector of 128 leans on a datastore being VMFS3 or VMFS5 which had been upgraded from VMFS3
$esxcli.storage.core.device.partition.list() | Where {$_.StartSector -eq "128"} | Select Device, StartSector
// This will dump all of your partitions which have a starting offset of 128, same as above but shorter
Script me baby one more time!
OMG YOU JUST MADE A HORRIBLY DATED REFERENCE TO BRITNEY SPEARS. For what its worth, I believe she did some scripting in her days… The scenarios below will just ‘do it’ based upon whatever hosts you connected to with Connect-VIServer, obviously the difference being ‘comments’ or not.
foreach ($myHost in get-VMHost)
#This tells the system to do a run the command against all "VMHosts" that you have defined as part of your Connect-VIServer
{
Write-Host ‘$myHost = ‘ $myHost
#Display the ESXi Host that it is operating against, helps if you’re scanning multiple vCenters
$esxcli = Get-EsxCli -VMHost $myHost
#This sets the syntax and the context for the Get-EsxCli command to operate, a requirement for running $esxcli.Commands
$esxcli.storage.core.device.partition.list() |
#Use Get-EsxCli to list the core storage devices
Where {$_.StartSector -eq "128"} |
#This specifies we’re only looking for partitions which have a StartSector of 128, which could mean either VMFS3 or VMFS3 upgraded to VMFS5 Datastores
Select Device, StartSector
#When all is said and done, it’s nice to see it in a ‘pretty’ format to see what work you need to do!
}
Without Comments
foreach ($myHost in get-VMHost)
{
Write-Host ‘$myHost = ‘ $myHost
$esxcli = Get-EsxCli -VMHost $myHost
$esxcli.storage.core.device.partition.list() |
Where {$_.StartSector -eq "128"} |
Select Device, StartSector
}
Now technically you could use partedUtil but that’s a pain in the ass. – But for the sake of continuity here is the syntax/results!
~ # partedUtil getptbl "/vmfs/devices/disks/naa.60a98000646e4f4b475a6a4975422d66"
msdos
261083 255 63 4194304000
1 128 4194298394 251 0
~ # partedUtil getptbl "/vmfs/devices/disks/naa.60a98000646e4f4b475a70516f34416f"
gpt
534698 255 63 8589934592
1 2048 8589934558 AA31E02A400F11DB9590000C2911D1B8 vmfs 0
~ #
So in case you’re wondering if the script is working properly you should end up with results similar to this below;
Results:
$myHost = 103.domain.local
Device StartSector
—— ———–
naa.60a98000323764703424434e6246775a 128
$myHost = 102.domain.local
naa.60a98000323764703424434e6246775a 128
$myHost = 101.domain.local
naa.60a98000323764703424434e6246775a 128
$myHost = 037.domain.local
And that is basically all it takes! This hopefully should give you the fuel you need to scan your environment with minimal effort and identify any VMFS3 datastores so you can clean that stuff up and MIGRATE! I discovered a bunch of them which aren’t so kind, and what ensues is massive migrations!
Good luck out there! and if you can find some good way to hack esxcli to ALSO have it then correlate that data to what the datastore name is… I FAILED :)
