The VMFS-3 Virtual Blockade

If VMFS-3 has you blocked, help has arrived in the form of magic SAN and an attentive Wizard.

Filesystem block size rarely enters the sparkling dialog at your noontime geekfest where movie one-liners and song lyrics replace actual conversation but today is different. The ticking of thumbs halts in mid-text when someone at the table opens up an intellectual volley with, “Have you ever seen the error that there isn’t enough space on the filesystem for the selected operation in Virtual Center?” The puzzled faces stare back as if someone had just announced that iPads are on sale for half price. But, before you, or they, have a chance to react to this obviously simple problem of insufficient disk space, the problem isn’t insufficient disk space.

All the years of accepting the default block size when formatting new disks pass before your mind’s eye with curiosity. Don’t decide at this late date that all your efforts were magnetic dust in the wind. All is not lost. Nor are you sentenced to suffer more painful lyric references.

Hitting the Wall

Your SAN Administrator presents you with a fresh 1TB LUN for your VMware environment. You create a new datastore by accepting all the defaults, including the default block size of 1MB. In a few minutes, your 1TB LUN takes on its new role as VMFS-formatted storage for all your space hungry guest systems.

During your first physical to virtual (P2V) migration, you receive a failure notice that looks similar to: “Failed to create virtual disk: There is not enough space on the file system for the selected operation.”

The entire disk capacity of the physical system is 500GB, so how could this happen? You re-examine the physical system’s disk layout and find that, indeed, you have a total capacity of 500GB.

Physical System’s Disk Layout

  • C: – 30GB
  • E: – 400GB
  • F: – 70GB

You attempt the P2V migration a few more times and carefully consider each option as you step through the wizard. However, it fails each time with the same error message.

Block Party

The solution requires that you take notice of what’s happening when you step through the datastore creation wizard. When you reach the Disk/LUN Formatting step, take pause and examine your choices.

Disk/LUN Formatting

  • 256 GB, Block size: 1 MB
  • 512 GB, Block size: 2 MB
  • 1024 GB, Block size: 4 MB
  • 2048 GB, Block size: 8 MB

Since your E: drive is 400GB in size, and you didn’t resize it during the P2V migration, then you must select a block size of 2MB or larger. Once you do this, the P2V migration will proceed normally. The block sizes and file sizes are limitations of the VMFS-3 filesystem. Yes, limitations. Armed with the knowledge that two whole terabytes should be a single file size large enough for anyone*, it’s also well-known that databases know no such limitations.

VMFS-4 won’t have this limitation. Its maximum file size should follow the ext4 filesystem standard of 16TB.

There are two glaring observations that I can make here. First, it would be great if developers would write errors that are more explicit and more helpful. Generic errors only tend to frustrate technical people into Googling for assistance leading to hours or days of wasted troubleshooting time. Second, shouldn’t VMware move on to VMFS-4 (ext4) or raise the default block size dynamically to the maximum possible for a disk? Feel free to return to your system administrator lunchtime mayhem, chicken strips, fries and Diet Dr. Pepper.

* Sounds a bit like that unattributable quotation, “640K RAM ought to be enough for anyone.” And, like the person who spoke that one into existence, I’ll deny that I ever said it.

Fatal error: Call to undefined function aa_author_bios() in /opt/apache/dms/b2b/linux-mag.com/site/www/htdocs/wp-content/themes/linuxmag/single.php on line 62