This article describes a couple of quick steps to speed up VMware Workstation.
These steps will speed up and offer better performance, during normal operation but also during backups with your VMware backup software.
Now, first you would want to merge split VMDKs that VMware Workstation creates by default. This default setting is unfortunately not very useful from a performance perspective. This setting likely exists only because some file systems can’t handle extremely large file sizes. File access in Windows, however, is much better optimized when you are dealing with one large fixed file instead of many interdependent small ones.
The screen looks like this when you create a new VM, note the default is set to ‘split”:
and the files look like this:
Next time you create a new VM, choose ‘store virtual disk as a single file’ to avoid this issue.
Merging Split VMDKs
Unfortunately merging those pieces afterwards requires downtime. You need to power off the VM and use a tool that ships with VMware Workstation.
From the command prompt run the following command:
"C:\Program Files (x86)\VMware\VMware Workstation\vmware-vdiskmanager.exe" -r vmsplittest.vmdk -t 0 vmmerged.vmdk
Where vmsplittest.vmdk is the VMDK file you have right now, which is split in 2GB files.
VMMERGED.VMDK is the new file, which will be created as a single, growable virtual disk. By the way instead of -t 0 you could use -t 2 for a preallocated single disk, which is the best choice for perfomance.
Now that the VMDK has been merged, change the VM’s settings and point to the merged file.
Before you boot up the VM it’s a good idea to run a defrag.
Defragmentation of Virtual Disks and Host Disks is Important
Fragmentation of dynamically growing virtual disks is a major issue on all virtualization platforms. Ideally you would want to go through all your VMDKs and convert them to preallocated disks. Then run a defrag on the host before powering them up again. The advantage is obvious: you only need to do this once. They will never need a defrag on the host again once they are set it place.
Naturally a defrag inside the VM is good, too, provided you have a preallocated VMDK to begin with. If you do not have the space to convert all VMDKs to fixed size, do at least some of them and ensure the host disk is at least 15% free. Drive access is likely to slow down significantly once free disk space falls below that and the potential for fragmentation is also much greater at that point.
It’s best to remove snapshots, aka differencing disks. Those are handy and unfortunately very inefficient at the same time. They multiply the overhead required to perform a simple disk access and slow down reads as well as writes. Unless you absolutely need snapshots, it’s time to delete them and turn off “auto-protect” which generates them automatically. Snapshots can also cause additional disk fragmentation, so you would want to consider whether the convenience is worth the performance impact.
VSS is used internally in Windows to provide file versioning. A backup tool, however, is much better at that and without the performance penalty of VSS shadows. If you want the best performance you would definitely want to delete all VSS shadows on your system (provided you aren’t using a tool that needs them). The command is:
vssadmin delete shadows /all
Then, increase the VSS storage area using vssuirun.exe (on Windows Servers) or vssadmin and set all limits to unbounded:
vssadmin resize shadowstorage /for=c: /on=c: /maxsize=unbounded
Do the above optimization for all drives you have, especially the system drive and the drive containing the VMDKs. Don’t worry it’s not going to use disk space until a backup is run.
If you are using System Restore, turn it off completely. In VSSUIRUN.EXE you may find a scheduled shadow task that created shadows periodically. You’d definitely want that turned off and your VSS will run clean and smooth.
SSD is obviously much faster but keep in mind it has a much faster wear and tear compared to magnetic drives.
It’s best to isolate Windows on a separate hard disk. Striped RAID may help for faster VMDK access; however, don’t expect miracles because random access is often not so much accelerated when you use RAID. RAID will give you awesome performance when you run backups because the VMDK is read from beginning to end and for those kind of sequential read accesses, RAID is superb.
Disk Space and NTFS
Disk space! You should have at least 10 GB or more or 15% of the hard drive’s total space always free. Free disk space does indeed speed up disk access. It sounds weird but it’s true. The explanation is too long to be added here but it basically has to do with how NTFS works internally.
A 4 KB cluster size is probably still the best choice as internally VMware tries to map the virtual sector size to the physical hard disk, so more than 4KB won’t necessarily speed this up.
Spreading the Disk Load, Reducing System Stress
Add additional hard drives, ideally SSD, and split the load. Move certain VMs to their own hard drives for better performance. It’s never good to have them all on just one hard drive as this increases hard drive head movement (aka seek time, in the case of mechanical drives) which can easily exceed 5 msec each. SSDs are also likely to fail sooner when I/O is continuously high.
VSS is also more likely to work much more efficiently when volumes are kept small and when disk writes are rather low during backups.
Set NtfsMemoryUsage = 2 in the registry key:
The above tweak greatly increases NTFS cache size which reduces disk access rates. It likely increases hard disk life expectancy, too, but keeping frequently accessed blocks in RAM definitely speeds things up.
What worked in our tests well was to turn off the VM, then switch the VMDK to SCSI and make it an “independent” disk.
Then close VMware completely and edit the VMX file with Notepad; add these lines (these are recommended by VMware for Windows hosts):
MemTrimRate = "0" mainMem.useNamedFile = "FALSE" sched.mem.pshare.enable = "FALSE" prefvmx.useRecommendedLockedMemSize = "TRUE"
The downside here is a little more RAM is going to be used on the host, but the host should have plenty of RAM available; if it doesn’t you have a bottleneck right there…
Backup Software for VMware Workstation
BackupChain offers numerous ways to customize your VMware Workstation backup: BackupChain offers deduplication for virtual machines, offsite server backup, and time-saving granular backup and granular restore features.
For step-by-step backup instructions, see: backup of a VM while running. Beyond using BackupChain as your VMware Workstation backup software, you could also use it as a copy tool for large files, for cloud backup, and FTP cloud backup.
Our backup software performs incremental backups and differential backups at the file level, using delta compression. Delta compression is not only great for vm backup, it’s also beneficial for Microsoft SQL Server backup and Exchange backup because of the block-based nature of large database files.
As we are always striving to provide the best backup software for Windows and server backup solution on the market, BackupChain provides hypervisor protection also for other platforms, such as automatic VirtualBox backup and backup for Hyper-V, and VMDK backup.
Whether you use BackupChain for virtual machines, databases, or file server backups, BackupChain always uses file versioning backup to create a backup history on a file basis. A backup history is basically a directly accessible backup file in addition to the latest data backup, so you can go back in time and restore older versions of documents or even VMs. Another great advantage of this technology is that BackupChain can be configured in way that allows direct access from the backup folder; i.e., you can boot VMs directly from your backup disk.
Furthermore, we also offer DriveMaker, our free FTP client as part of our freeware for Windows Server library. It mounts a drive to your FTP cloud storage so you can copy and edit files in place, from any application on your desktop or server.