«

»

Aug 22 2011

VM Block Size & Max. Storage Size (vSphere 4)

I was working on a virtual environment recently and come across a problem with the maximum storage size for a VMDK. Upon looking further into this, I found that the block size for the datastores across our environment were mixed between, 1MB, 2MB and 4MB.

After some investigation, I found some great sites detailing the differences, best practices and recommendations. Below I will try to summarize this information for all interested.

If you run the below powerCLI script you will get a list of your Datastores, the driver version and the block size assigned…

Results…

Name Version BlocksizeMB
ABC-0211-0028-TIER1-500GB-0080 3.31 2
ABC-0212-0028-TIER1-1TB-0052 3.33 4
ABC-0213-0028-TIER1-500GB-0057 3.31 2
ABC-0214-0028-TIER1-500GB-0055 3.31 1
ABC-0215-3518-TIER2-1TB-0017 3.46 1
ABC-0215-3528-TIER1-1TB-0025 5.54 4

… from this script you can easily determine if the blocks sizes are different in your environments.

As stated above these blocks sizes determine the maximum size of your VMDK files and therefore default drives in the guest OS. This may also affect your Storage vMotion where you want to move a VMDK from one datastore to another. If the destination datastore has a smaller block size and the image is larger than the maximum volume size (above) then you will receive an error and the svMotion will not work. The block size and maximum volume size is shown below (Table 1)

Block Size Max Volume Size (VMFS-3)
1MB 256GB
2MB 512GB
4MB 1TB
8MB 2TB
Table 1: Block and Max Volume Size

In the event where you may want to resize all or all of your datastores, all data must be removed and the datatore itself must be reformatted with the new block size.

Having the larger block size will waste some disk space, but due to the number of files for each  VM (~10-15) wasting a small amount of disk space (~100MB) will far outweigh the advantaged of having Storage vMotion working effectively throughout your VMware environment.

Issues also come into play when Snapshots are left on disk for a period of time and the size of the image grows larger than the datastores maximum file size. Although the typical scenario suggests that snapshots shouldn’t be left on disk for this to occur, this can still be an issue.

In Table 2, below, the version of the file system, and from which ESX version they were formatted is shown. Where environments have been upgraded over time, you may find that you have mixed file system versions. For versions above 3.21 (ESX 3.0.0) no additional work is necessary if mixed version are found. The information presented here is only for information purposes only.

FS Version Formatted with ESX version
3.21 ESX 3.0.0
3.31 ESX 3.5.0
3.33 ESX 4.0
3.46 ESX 4.1
5.54 ESX 5.0
Table 2: FS Version & VM Version

After looking at all the problems above, the best solution to this potential problem, is to analyse all the current and future disk sizes you require and create a block size that will accommodate for these. If for instance you have a single server that will require a single disk image of 750GB, and all others only require 200GB, it would be advisable to create the datastore with a 4MB block size to allows for any potential storage vMotion you may require in the future.

Further information on these two topics can be found on the VMware knowledge base at the following URL’s:

http://bit.ly/nuHHeZ – Block Size Limitations
http://bit.ly/pgyx80 – Snapshot Size Limitations

Leave a Reply