Should I split VMware virtual disk into multiple files or not?

Question

I'm using VMware Workstation 12 to create Win7 virtual machine that I can use it on Linux for programs like Photoshop and After Effects.

VMware is asking for this option to split virtual machine files into 2Gb parts. This is not something I noticed for the first time, BUT I want to know whether there's a noticeable performance drop or not.

A screenshot of related window:

No I'm not going to move this VM anytime soon, although If I move I can perfectly wait for files being transferred.

Solution 1

There seems little point in splitting an image file unless you're creating it on a FAT32 volume or network share that has file size restrictions.

VMware has this to say:

Select Split virtual disk into multiple files if the virtual disk is stored on a file system that has a file size limitation.

Another reference has this to say:

Choosing to split VMDK into 2GB files has quite no impact on performance.

Anyway, the largest disk image file I've currently got (on my NTFS-formatted portable USB hard drive) is ~150GB. I've even backed it up using 7-zip to a network share overnight. No problems at all.

Performance-wise, seriously, for what you're doing you simply won't notice the difference between single and split images. I imagine a perceivable difference would start to appear with images into the 100s of GB in size. Still, if you want to go with what is technically the most performant, then that's a single monolithic image file which is what you're doing already. You're all good ;-)

Solution 2

Disadvantages of monolithic disks:

• If you delete snapshots and need to consolidate unused .vmdk files, if you need to defragment .vmdk files, etc., then your host needs as much free space as the entire .vmdk file. In contrast, if you use split disks, then your host needs only as much free space as one of the individual .vmdk extents.
• If you want to copy or back up a VM, you might be copying it to a file system that doesn't support such large files.
• If you're in the middle of copying or backing up a VM but need to cancel the operation and to resume it later, using split disks is much less painful.

Advantages of monolithic disks:

• Less file system clutter (and in that sense it's easier to manage).
• The VM will require fewer open file handles. Some host operating systems have a somewhat low limit on the maximum number of open file handles, and this can matter if you take a lot of snapshots.

Solution 3

If you are using very large VMs like 1TB or greater then you should look at all the problems that come with copying files this large. In fact some people have had issues where they can't be moved at all. Programs like robocopy or xcopy will hang or error out.

I also tried other programs like TeraCopy Pro and when it came to 2TB files it would never finish.

Comments

[emrecnl]

Thanks for the reply. I went for monolithic disk option.

[jamesdlin]

"no point in splitting the image file ... unless ... on a FAT32 volume" isn't correct. See my answer.

[misha256]

@jamesdlin Valid points, I shall update my answer to be less err "dogmatic" in that respect.

[cxrodgers]

Isn't it the case that it is much easier to increase the size of the disk if it is stored as split files? Because then it only needs to create a few more files, instead of copying over the entire monolithic file. Besides taking longer, this also means you cannot grow the monolithic file beyond 50% of the size of its partition. kb.vmware.com/selfservice/microsites/…

[FreeSoftwareServers]

@cxrodgers that is why I always use "thin" type disk images, but make them larger then needed. But, you could just add a disk vs growing a disk. I always separate OS and data. I just throw 50/100 GB's extra to the OS and it never gets close. The data drive is usually a NAS so no issue with virtual disks. -- Regardless that is a good point to consider though!

[SaeX]

See also sanbarrow.com/vmdk-howtos.html#monolithicversussplit for a comparison with the pros and cons of using monolithic vs. split/chunked disks.