VI-Toolkit - User contributions [en]

Shrink guest on hosted platform

2024-01-06T12:02:29Z

Wila: /* Zero out using fstrim */

== Important ==
Note that the technique described below to zero out the unused space on the guest OS will in fact make your guest virtual disk grow to the maximum size first. For each byte that is changed to zero the virtual disk will need to claim a byte. This means that while you can use the technique to reclaim disk space after the unused space is zero'd out, it is important to have enough space before you start.

If you don't have that kind of free disk space then you can skip the zero-ing out part. You can still reclaim space, but it will be less optimal.
Alternatively you can use the "Partially zero out" trick described below.

=== How much free space do you need before shrinking? ===
Also please note that you need more free space in order to be able to run the shrinking process.
The shrinking process consists of making a copy of your virtual disk while omitting the zero'd out blocks.
So how much extra space you need depends on how you configured the virtual disk for your Virtual Machine.
If your Virtual Disk is a single file, then your free space requirement can grow up-to the full size of that virtual disk.

If OTOH you are using the split disk scheme where a virtual disk is sliced into multiple files the maximum free space you need is the maximum size a slice can be. Nowadays there's not a fixed slice size, it depends on how big your virtual disk actually is.

The split disk scheme since VMware Workstation 11 (VMware Fusion 7), older version of Workstation/Fusion use a 2GB split disk scheme.

Capacity Extent size
================================
<=128GB 4GB (increased from 2GB)
>128GB && <2TB Capacity / 32 (so maximum of 32 extents)
>=2TB 2TB

For extra safety I recommend to make sure you have an additional 2GB of free space on top of those requirements as mentioned above.

As side note, this also explains why it is generally recommended at the forum by the regulars to use a split disk scheme over single disk files.
This same problem also exists when you want to commit snapshots.

=== Using the clean up option in the menu ===

When you use the "Clean Up Disks" option in the menu in VMware Workstation 12 or later, then you do not require extra disk space for reclaiming space (see also: [https://docs.vmware.com/en/VMware-Workstation-Pro/14.0/com.vmware.ws.using.doc/GUID-421A1073-BF16-4BC7-AA76-46B954CA438D.html Clean Up a Virtual Hard Disk on Windows Hosts] )

Currently this only works for Windows guests where the filesystem is NTFS.

== Zero out unused space in a Linux VM ==

Before we try to shrink the virtual disk files, we should try to remove any unneeded files from the virtual machine to free space.
More free space means more disk space that can get reclaimed.

One of the areas in a VM that can take up a lot of disk space is the repository cache. So I personally tend to clean the cache in the VM before reclaiming disk space at the host.

Clean up your repositories:

For example, on Debian-based VMs, you can run the following command (in the VM)

apt-get clean all

to clear out the local repository of retrieved package files.

On red hat based VMs that would be:

yum clean

The next step is important:

Shut down any services that depend on having enough available disk space to run.

The reason for this is that we are going to write out zero's to the file system until the file system is full and we do not want any application - for example a database system like mySQL or postgreSQL - to run out of disk space while we are zeroing out the file system. If mySQL would try to write when your disk is full you risk a corrupted database. So this step is important!

Next run (also from within the VM):

cat /dev/zero > zero.fill;sync;sleep 1;sync;rm -f zero.fill

to fill the unused space with zeros and then remove the "zero.fill" that has all the zero's.

As this command writes to the disk until it runs out of disk space, you will get an error "No space left on the device". This is expected.

Note that you have multiple partitions that you have to repeat the above command to zero out for each partition.
Adjust "zero.fill" to the relevant mountpoint, for example if you have a separate partition for home it would become:

cat /dev/zero > /home/zero.fill;sync;sleep 1;sync;rm -f /home/zero.fill

=== Zero out a part of your virtual disk ===

If your virtual machine cannot be taken down and you do not want to shut down services that might end up corrupting files because of the "No space left on the device" problem then an idea that might work is to zero out a part of your partition.

This for example creates a 100MB size file filled with zero's

# dd if=/dev/zero of=zero.fill bs=1024 count=102400
102400+0 records in
102400+0 records out
104857600 bytes (105 MB) copied, 0.3839 s, 273 MB/s

So if you want to zero out 10GB instead, add two more zero's to the count parameter, eg: count=10240000

If you want to fill up in steps, just change the output file name from "zero.fill" into "zero.fill2" etcetera..

Then run the "sync; sleep 1; sync" from above and remove the zero.fill files.

If your VM is running on VMware vSphere and you have a NFS LUN with enough free space then one way to reclaim your space is to Storage vMotion the VM to NFS storage and back. Once done the zero'd out data has been reclaimed. No need to shut down the VM.

If this is not for you, then do read on.

=== Zero out using fstrim ===

These days there's an alternative way for zero-ing out the parts of the disk that are not used using [https://www.man7.org/linux/man-pages/man8/fstrim.8.html fstrim].

eg:
# fstrim -a -v
/var: 274.3 MiB (287592448 bytes) trimmed on /dev/sda3
/tmp: 63 MiB (66060288 bytes) trimmed on /dev/sda5
/home: 125 MiB (131072000 bytes) trimmed on /dev/sda6
/boot/efi: 505.2 MiB (529735680 bytes) trimmed on /dev/sda1
/: 5 MiB (5242880 bytes) trimmed on /dev/sda2

The great thing about this is that it only zero's out the parts of the disk that are not zero and as such the disk does not inflate to its full size.

* [https://forums.freebsd.org/threads/ssd-trim-maintenance.56951/post-328912 Detail comment from Theodore Ts'o on using fstrim]

* [https://github.com/vmware/open-vm-tools/issues/457 Avoid disk expansion while shrinking (github issue tracker)]

On most modern systems fstrim is being run automatically using systemctl. You can check if it is enabled:

# systemctl status fstrim.timer
● fstrim.timer - Discard unused blocks once a week
Loaded: loaded (/lib/systemd/system/fstrim.timer; disabled; vendor preset: enabled)
Active: inactive (dead)
Trigger: n/a
Triggers: ● fstrim.service
Docs: man:fstrim

Oh-huh, our system does not have it enabled.. might there be a reason, such as that the UNMAP command is not supported?
If so, the following command would return 0.
# cat /sys/block/sda/queue/discard_max_bytes
1073741824

So UNMAP is supported, but fstrim still is not enabled, lets fix that.
# systemctl enable fstrim.timer
Created symlink /etc/systemd/system/timers.target.wants/fstrim.timer → /lib/systemd/system/fstrim.timer.
and reload systemctl plus check that it now works...

# systemctl start fstrim.timer
# systemctl daemon-reload
# systemctl status fstrim.timer
● fstrim.timer - Discard unused blocks once a week
Loaded: loaded (/lib/systemd/system/fstrim.timer; enabled; vendor preset: enabled)
Active: active (waiting) since Sat 2024-01-06 13:00:46 CET; 6s ago
Trigger: Mon 2024-01-08 01:17:59 CET; 1 day 12h left
Triggers: ● fstrim.service
Docs: man:fstrim

see also:
* https://www.suse.com/support/kb/doc/?id=000019447

== Zero out unused space on a Windows VM ==

To do the same with a windows VM, you can use Microsoft's tool [http://technet.microsoft.com/en-us/sysinternals/bb897443.aspx sdelete].

Run it as
sdelete -z c:

To clean out the free space on disk c:

Careful!

As of sdelete v1.6 -c and -z have changed meanings, many instructions say -c zeros free space, this is no longer the case, it zeros the space then fills with random data in accordance with DOD spec: DOD 5220.22-M, random data will prevent the reclaim logic from working.

The trigger to zero space with 0x00 has changed to -z!

== Zeroing an encrypted disk ==

If you use disk encryption in the guest OS then zero'ing out the disk won't help.

The reason is that a good disk encryption scheme will write out random data to the disk when you write out zero's.

In other words, if you have enabled full disk encryption in the guest then you can not shrink the disk anymore as there is no space to reclaim.

== Shrink the disk ==

Then power down the VM and open a terminal on the Linux host.

Navigate to the directory where the .vmdk files are located, e.g.:

cd /var/lib/vmware/Virtual\ Machines/Ubuntu\ Desktop/

You can shrink the .vmdk file as follows:

vmware-vdiskmanager -k Ubuntu\ Desktop.vmdk

On Windows the command also uses the -k option, so I leave that for you as an exercise.

Note that vmware-vdiskmanager is probably not in your search path, so you might have to prepend the vmware-vdiskmanager command with the actual path with the command is located.

On macOS you run it as:
/Applications/VMware\ Fusion.app/Contents/Library/vmware-vdiskmanager -k Ubuntu\ Desktop.vmdk

If you need to use "sudo" in order to be able to run the above then beware that the ownership of the .vmdk files might get changed to root. So certainly try it first without running as root!

You will have to change the ownership back to your own user, eg:
sudo chown username: *.vmdk
If you don't change the ownership back you might see errors like:
"Unable to open file .../Virtual Disk.vmdk: Insufficient permission to access file".

== Shrink using vmware tools ==

Nowadays you can also shrink the guest by using the shrink feature as offered via vmware tools.

So for clarity all of the following commands are run from within the guest to shrink the disk while the guest is running.

On linux in order to use this run:
sudo vmware-toolbox-cmd disk shrink /

Where "/" is the mount point of the partition that you want to shrink.

On Windows in order to use this run (as administrator):

C:\Program Files\VMware\VMware Tools>VMwareToolboxCmd.exe disk shrink <location>

where <location> is the drive you want to shrink

For example:
C:\Program Files\VMware\VMware Tools>VMwareToolboxCmd.exe disk shrink c:\
Please disregard any warnings about disk space for the duration of shrink process.
Progress: 62 [=======> ]
The progress you see here is VMware Tools blanking out the unused space.

At 99% it will popup the "Shrinking Disk" progress dialog at the host that takes care of the actual shrinking process.

If you are logged in via remote desktop then do expect to loose the connection for a bit while the actual shrinking is taking place.

On OS X / macOS the command to use is:

sudo /Library/Application\ Support/VMware\ Tools/vmware-tools-cli disk shrink /

== Shrink macOS VM with APFS ==

[https://communities.vmware.com/thread/581576 Solved: Shrink an APFS virtual disk]

== External links ==

* [https://docs.vmware.com/en/VMware-Workstation-Pro/16.0/com.vmware.ws.using.doc/GUID-421A1073-BF16-4BC7-AA76-46B954CA438D.html Clean Up a Virtual Hard Disk on Windows Hosts - Workstation 16 Pro documentation]

* [https://docs.vmware.com/en/VMware-Workstation-Pro/16.0/com.vmware.ws.using.doc/GUID-3F94C7B5-19A5-4E91-9709-B17FAA93FF75.html Configuring and Maintaining Virtual Hard Disks - Workstation 16 Pro documentation]

* [https://docs.vmware.com/en/VMware-Fusion/12/com.vmware.fusion.using.doc/GUID-6BB29187-F47F-41D1-AD92-1754036DACD9.html#GUID-6BB29187-F47F-41D1-AD92-1754036DACD9 Clean up a Virtual Machine - VMware Fusion 12 documentation]

Shrink guest on hosted platform

2024-01-03T16:33:19Z

Wila: /* Zero out using fstrim */ adding a small example

== Important ==
Note that the technique described below to zero out the unused space on the guest OS will in fact make your guest virtual disk grow to the maximum size first. For each byte that is changed to zero the virtual disk will need to claim a byte. This means that while you can use the technique to reclaim disk space after the unused space is zero'd out, it is important to have enough space before you start.

If you don't have that kind of free disk space then you can skip the zero-ing out part. You can still reclaim space, but it will be less optimal.
Alternatively you can use the "Partially zero out" trick described below.

=== How much free space do you need before shrinking? ===
Also please note that you need more free space in order to be able to run the shrinking process.
The shrinking process consists of making a copy of your virtual disk while omitting the zero'd out blocks.
So how much extra space you need depends on how you configured the virtual disk for your Virtual Machine.
If your Virtual Disk is a single file, then your free space requirement can grow up-to the full size of that virtual disk.

If OTOH you are using the split disk scheme where a virtual disk is sliced into multiple files the maximum free space you need is the maximum size a slice can be. Nowadays there's not a fixed slice size, it depends on how big your virtual disk actually is.

The split disk scheme since VMware Workstation 11 (VMware Fusion 7), older version of Workstation/Fusion use a 2GB split disk scheme.

Capacity Extent size
================================
<=128GB 4GB (increased from 2GB)
>128GB && <2TB Capacity / 32 (so maximum of 32 extents)
>=2TB 2TB

For extra safety I recommend to make sure you have an additional 2GB of free space on top of those requirements as mentioned above.

As side note, this also explains why it is generally recommended at the forum by the regulars to use a split disk scheme over single disk files.
This same problem also exists when you want to commit snapshots.

=== Using the clean up option in the menu ===

When you use the "Clean Up Disks" option in the menu in VMware Workstation 12 or later, then you do not require extra disk space for reclaiming space (see also: [https://docs.vmware.com/en/VMware-Workstation-Pro/14.0/com.vmware.ws.using.doc/GUID-421A1073-BF16-4BC7-AA76-46B954CA438D.html Clean Up a Virtual Hard Disk on Windows Hosts] )

Currently this only works for Windows guests where the filesystem is NTFS.

== Zero out unused space in a Linux VM ==

Before we try to shrink the virtual disk files, we should try to remove any unneeded files from the virtual machine to free space.
More free space means more disk space that can get reclaimed.

One of the areas in a VM that can take up a lot of disk space is the repository cache. So I personally tend to clean the cache in the VM before reclaiming disk space at the host.

Clean up your repositories:

For example, on Debian-based VMs, you can run the following command (in the VM)

apt-get clean all

to clear out the local repository of retrieved package files.

On red hat based VMs that would be:

yum clean

The next step is important:

Shut down any services that depend on having enough available disk space to run.

The reason for this is that we are going to write out zero's to the file system until the file system is full and we do not want any application - for example a database system like mySQL or postgreSQL - to run out of disk space while we are zeroing out the file system. If mySQL would try to write when your disk is full you risk a corrupted database. So this step is important!

Next run (also from within the VM):

cat /dev/zero > zero.fill;sync;sleep 1;sync;rm -f zero.fill

to fill the unused space with zeros and then remove the "zero.fill" that has all the zero's.

As this command writes to the disk until it runs out of disk space, you will get an error "No space left on the device". This is expected.

Note that you have multiple partitions that you have to repeat the above command to zero out for each partition.
Adjust "zero.fill" to the relevant mountpoint, for example if you have a separate partition for home it would become:

cat /dev/zero > /home/zero.fill;sync;sleep 1;sync;rm -f /home/zero.fill

=== Zero out a part of your virtual disk ===

If your virtual machine cannot be taken down and you do not want to shut down services that might end up corrupting files because of the "No space left on the device" problem then an idea that might work is to zero out a part of your partition.

This for example creates a 100MB size file filled with zero's

# dd if=/dev/zero of=zero.fill bs=1024 count=102400
102400+0 records in
102400+0 records out
104857600 bytes (105 MB) copied, 0.3839 s, 273 MB/s

So if you want to zero out 10GB instead, add two more zero's to the count parameter, eg: count=10240000

If you want to fill up in steps, just change the output file name from "zero.fill" into "zero.fill2" etcetera..

Then run the "sync; sleep 1; sync" from above and remove the zero.fill files.

If your VM is running on VMware vSphere and you have a NFS LUN with enough free space then one way to reclaim your space is to Storage vMotion the VM to NFS storage and back. Once done the zero'd out data has been reclaimed. No need to shut down the VM.

If this is not for you, then do read on.

=== Zero out using fstrim ===

These days there's an alternative way for zero-ing out the parts of the disk that are not used using [https://www.man7.org/linux/man-pages/man8/fstrim.8.html fstrim].

eg:
# fstrim -a -v
/var: 274.3 MiB (287592448 bytes) trimmed on /dev/sda3
/tmp: 63 MiB (66060288 bytes) trimmed on /dev/sda5
/home: 125 MiB (131072000 bytes) trimmed on /dev/sda6
/boot/efi: 505.2 MiB (529735680 bytes) trimmed on /dev/sda1
/: 5 MiB (5242880 bytes) trimmed on /dev/sda2

The great thing about this is that it only zero's out the parts of the disk that are not zero and as such the disk does not inflate to its full size.

* [https://forums.freebsd.org/threads/ssd-trim-maintenance.56951/post-328912 Detail comment from Theodore Ts'o on using fstrim]

* [https://github.com/vmware/open-vm-tools/issues/457 Avoid disk expansion while shrinking (github issue tracker)]

== Zero out unused space on a Windows VM ==

To do the same with a windows VM, you can use Microsoft's tool [http://technet.microsoft.com/en-us/sysinternals/bb897443.aspx sdelete].

Run it as
sdelete -z c:

To clean out the free space on disk c:

Careful!

As of sdelete v1.6 -c and -z have changed meanings, many instructions say -c zeros free space, this is no longer the case, it zeros the space then fills with random data in accordance with DOD spec: DOD 5220.22-M, random data will prevent the reclaim logic from working.

The trigger to zero space with 0x00 has changed to -z!

== Zeroing an encrypted disk ==

If you use disk encryption in the guest OS then zero'ing out the disk won't help.

The reason is that a good disk encryption scheme will write out random data to the disk when you write out zero's.

In other words, if you have enabled full disk encryption in the guest then you can not shrink the disk anymore as there is no space to reclaim.

== Shrink the disk ==

Then power down the VM and open a terminal on the Linux host.

Navigate to the directory where the .vmdk files are located, e.g.:

cd /var/lib/vmware/Virtual\ Machines/Ubuntu\ Desktop/

You can shrink the .vmdk file as follows:

vmware-vdiskmanager -k Ubuntu\ Desktop.vmdk

On Windows the command also uses the -k option, so I leave that for you as an exercise.

Note that vmware-vdiskmanager is probably not in your search path, so you might have to prepend the vmware-vdiskmanager command with the actual path with the command is located.

On macOS you run it as:
/Applications/VMware\ Fusion.app/Contents/Library/vmware-vdiskmanager -k Ubuntu\ Desktop.vmdk

If you need to use "sudo" in order to be able to run the above then beware that the ownership of the .vmdk files might get changed to root. So certainly try it first without running as root!

You will have to change the ownership back to your own user, eg:
sudo chown username: *.vmdk
If you don't change the ownership back you might see errors like:
"Unable to open file .../Virtual Disk.vmdk: Insufficient permission to access file".

== Shrink using vmware tools ==

Nowadays you can also shrink the guest by using the shrink feature as offered via vmware tools.

So for clarity all of the following commands are run from within the guest to shrink the disk while the guest is running.

On linux in order to use this run:
sudo vmware-toolbox-cmd disk shrink /

Where "/" is the mount point of the partition that you want to shrink.

On Windows in order to use this run (as administrator):

C:\Program Files\VMware\VMware Tools>VMwareToolboxCmd.exe disk shrink <location>

where <location> is the drive you want to shrink

For example:
C:\Program Files\VMware\VMware Tools>VMwareToolboxCmd.exe disk shrink c:\
Please disregard any warnings about disk space for the duration of shrink process.
Progress: 62 [=======> ]
The progress you see here is VMware Tools blanking out the unused space.

At 99% it will popup the "Shrinking Disk" progress dialog at the host that takes care of the actual shrinking process.

If you are logged in via remote desktop then do expect to loose the connection for a bit while the actual shrinking is taking place.

On OS X / macOS the command to use is:

sudo /Library/Application\ Support/VMware\ Tools/vmware-tools-cli disk shrink /

== Shrink macOS VM with APFS ==

[https://communities.vmware.com/thread/581576 Solved: Shrink an APFS virtual disk]

== External links ==

* [https://docs.vmware.com/en/VMware-Workstation-Pro/16.0/com.vmware.ws.using.doc/GUID-421A1073-BF16-4BC7-AA76-46B954CA438D.html Clean Up a Virtual Hard Disk on Windows Hosts - Workstation 16 Pro documentation]

* [https://docs.vmware.com/en/VMware-Workstation-Pro/16.0/com.vmware.ws.using.doc/GUID-3F94C7B5-19A5-4E91-9709-B17FAA93FF75.html Configuring and Maintaining Virtual Hard Disks - Workstation 16 Pro documentation]

* [https://docs.vmware.com/en/VMware-Fusion/12/com.vmware.fusion.using.doc/GUID-6BB29187-F47F-41D1-AD92-1754036DACD9.html#GUID-6BB29187-F47F-41D1-AD92-1754036DACD9 Clean up a Virtual Machine - VMware Fusion 12 documentation]

Fixing a VM that had AutoAddVTPM set

2023-09-22T17:05:55Z

Wila:

You might have made the mistake to use an experimental solution that was offered for a while by VMware to install Windows 11 as guest OS.
It involved adding a line to the .vmx file and after that you could add a TPM and thus install Windows 11.
This would encrypt parts of the VM, but not give you a password and as such some people to find out that their VM won't work on some other hosts.
The good part is that your data isn't actually encrypted, the bad part is that it isn't easy perse to get the data out.

The following article: https://www.vimalin.com/blog/what-you-should-know-about-vmwares-experimental-vtpm/ has the technical background on what happens if you have used this experimental feature and is good background knowledge if you try to start trying to recover your VM.

=== Here's one solution where you have a few manual steps ===

The steps to recover your VM are as follows:

This reddit thread here has the steps: https://www.reddit.com/r/vmware/comments/qy9wns/comment/hmokzl7/ where I helped a user getting back their VM.

For this type of VM none of the data is encrypted and only the descriptor files are encrypted.
You can recreate the descriptor files and get back to a functional VM. If you haven't resized the virtual disks over time then it is a matter of creating a new VM with the exact same virtual disk in size.

That would be enough to get the descriptor data to copy over into the currently encrypted descriptor files. That should work.

If OTOH you have increased the size of your virtual disks over time then you have to repeat that increase in the exact same manner.

The steps are basically:

* Create a new VM with a virtual disk of the same size as the encrypted one, make sure it has the same name.
* use the new descriptor file ('MK Win Desktop.vmdk')
* use the old vmdk data files ('MK Win Desktop-s001.vmdk' (001 to 016)
* use the old .vmx file, but remove the lines that start with:
managedVM.autoAddVTPM
managedVM.ID
encryption.encryptedKey
encryption.keySafe
encryption.data

If there's no snapshots then you don't need .vmsd (don't copy it in the new vm, delete if there)

Normally also no need for .nvram and .vmxf

That ''should'' be all.

One final note is that it is highly recommended to never touch your original VM and instead work with copies of the data while you try to get your VM back up and running. That way if you make a mistake you can just redo the steps. Otherwise you might introduce more problems and who needs yet another problem?

Fixing a VM that had AutoAddVTPM set

2023-09-22T17:02:12Z

Wila: /* Here's one solution where you have a few manual steps */

You might have made the mistake to use an experimental solution that was offered for a while by VMware to install Windows 11 as guest OS.
It involved adding a line to the .vmx file and after that you could add a TPM and thus install Windows 11.
This would encrypt parts of the VM, but not give you a password and as such some people to find out that their VM won't work on some other hosts.
The good part is that your data isn't actually encrypted, the bad part is that it isn't easy perse to get the data out.

=== Here's one solution where you have a few manual steps ===

The steps to recover your VM are as follows:

This reddit thread here has the steps: https://www.reddit.com/r/vmware/comments/qy9wns/comment/hmokzl7/ where I helped a user getting back their VM.

For this type of VM none of the data is encrypted and only the descriptor files are encrypted.
You can recreate the descriptor files and get back to a functional VM. If you haven't resized the virtual disks over time then it is a matter of creating a new VM with the exact same virtual disk in size.

That would be enough to get the descriptor data to copy over into the currently encrypted descriptor files. That should work.

If OTOH you have increased the size of your virtual disks over time then you have to repeat that increase in the exact same manner.

The steps are basically:

* Create a new VM with a virtual disk of the same size as the encrypted one, make sure it has the same name.
* use the new descriptor file ('MK Win Desktop.vmdk')
* use the old vmdk data files ('MK Win Desktop-s001.vmdk' (001 to 016)
* use the old .vmx file, but remove the lines that start with:
managedVM.autoAddVTPM
managedVM.ID
encryption.encryptedKey
encryption.keySafe
encryption.data

If there's no snapshots then you don't need .vmsd (don't copy it in the new vm, delete if there)

Normally also no need for .nvram and .vmxf

That ''should'' be all.

Fixing a VM that had AutoAddVTPM set

2023-09-22T16:55:34Z

Wila:

Fixing a VM that had AutoAddVTPM set

2023-09-22T16:53:59Z

Wila: Created page with "You might have made the mistake to use an experimental solution that was offered for a while by VMware to install Windows 11 as guest OS. It involved adding a line to the .vmx file and after that you could add a TPM and thus install Windows 11. This would encrypt parts of the VM, but not give you a password and as such some people to find out that their VM won't work on some other hosts. The good part is that your data isn't actually encrypted, the bad part is that it is..."

Vmware-vdiskmanager

2022-09-12T11:38:39Z

Wila: Update vddk link to version 7.0

== vmware-vdiskmanager ==

With this tool that comes with VMware Workstation and VMware Fusion you can perform special disk actions such as:
* [[Shrink guest on hosted platform|shrink]]
* defragment
* repair

=== Peculiarities ===

* VMware vdisk manager throws a bogus error in all version from VMware Workstation 7 to Workstation 11, Fusion 3 to Fusion 7

The error looks like:
VixDiskLib: Invalid configuration file parameter. Failed to read configuration file.
and can be safely ignored.

This has been fixed in Fusion 8 / Workstation 12.0

* Disk repair option -R was mostly broken from Workstation 8 to Workstation 11.

This works much better since Fusion 8 / Workstation 12.0

* You cannot reduce the capacity of a virtual disk. Eg. if you have defined a virtual disk of 10GB in size then you cannot change it to be 8GB in size. This is because any resizing the tool does is irregardless of the partition definitions, as this is potentially a destructive operation it is not allowed.
Even if you grow a disk in size you will have to adjust the partitions after the resize.

You can shrink a disk if you have a non pre allocated disk, in this case it will wipe out the unused parts on your disk and give that space back to the host OS.

* The remote host fusion in Fusion 8 and Workstation 12 via the -h option is broken. See also [https://communities.vmware.com/thread/527749 BUG: vmware-vdiskmanager does not accept advertised -h option]

* VMware Player does not come with this tool, but in case of need you can download the [https://developer.vmware.com/web/sdk/7.0/vddk Virtual Disk Development Kit (VDDK)] which does include a copy of the program.

=== Command line help ===

Here's an excerpt from the command line help:
VMware Virtual Disk Manager - build 3160714.
Usage: vmware-vdiskmanager.exe OPTIONS <disk-name> | <mount-point>
Offline disk manipulation utility
Operations, only one may be specified at a time:
-c : create disk. Additional creation options must be specified. Only local virtual disks can be
created.
-d : defragment the specified virtual disk. Only local virtual disks may be defragmented.
-k : shrink the specified virtual disk. Only local virtual disks may be shrunk.
-n <source-disk> : rename the specified virtual disk; need to specify destination disk-name. Only local virtual
disks may be renamed.
-p : prepare the mounted virtual disk specified by the mount point for shrinking.
-r <source-disk> : convert the specified disk; need to specify destination disk-type. For local destination disks
the disk type must be specified.
-x <new-capacity> : expand the disk to the specified capacity. Only local virtual disks may be expanded.
-R : check a sparse virtual disk for consistency and attempt to repair any errors.
-e : check for disk chain consistency.
-D : make disk deletable. This should only be used on disks that have been copied from another product.

Other Options:
-q : do not log messages

Additional options for create and convert:
-a <adapter> : (for use with -c only) adapter type
(ide, buslogic, lsilogic). Pass lsilogic for other adapter types.
-s <size> : capacity of the virtual disk
-t <disk-type> : disk type id

Disk types:
0 : single growable virtual disk
1 : growable virtual disk split in 2GB files
2 : preallocated virtual disk
3 : preallocated virtual disk split in 2GB files
4 : preallocated ESX-type virtual disk
5 : compressed disk optimized for streaming
6 : thin provisioned virtual disk - ESX 3.x and above

The capacity can be specified in sectors, KB, MB or GB.
The acceptable ranges:
ide/scsi adapter : [1MB, 8192.0GB]
buslogic adapter : [1MB, 2040.0GB]
ex 1: vmware-vdiskmanager.exe -c -s 850MB -a ide -t 0 myIdeDisk.vmdk
ex 2: vmware-vdiskmanager.exe -d myDisk.vmdk
ex 3: vmware-vdiskmanager.exe -r sourceDisk.vmdk -t 0 destinationDisk.vmdk
ex 4: vmware-vdiskmanager.exe -x 36GB myDisk.vmdk
ex 5: vmware-vdiskmanager.exe -n sourceName.vmdk destinationName.vmdk
ex 6: vmware-vdiskmanager.exe -r sourceDisk.vmdk -t 4 -h esx-name.mycompany.com \
-u username -f passwordfile "[storage1]/path/to/targetDisk.vmdk"
ex 7: vmware-vdiskmanager.exe -k myDisk.vmdk
ex 8: vmware-vdiskmanager.exe -p <mount-point>
(A virtual disk first needs to be mounted at <mount-point>)

=== Split disks ===

Up until Workstation 11 / Fusion 7 a split disk would never be larger as 2GB.

Due to the virtual disk sizes growing and the extra limitations - such as max open files - that could be hit with larger disks, this is no longer the case for split virtual disks.

Nowadays the split disk size (= extent size) depends on the size you have set your virtual disk to be.

The new split disk scheme

Capacity Extent size
================================
<=128GB 4GB (increased from 2GB)
>128GB && <2TB Capacity / 32 (so maximum of 32 extents)
>=2TB 2TB

This means that if you want to keep your Virtual Disks to be transportable via FAT32 that you probably should keep your disk sizes under 128GB.

Note that NTFS or HFS has no such limitation, so choosing your maximum virtual disk size depends on need.

=== External links ===

* [http://kb.vmware.com/kb/1023856 Repairing a virtual disk in Fusion 3.1 and Workstation 7.1]

Shrink guest on hosted platform

2022-09-07T20:37:45Z

Wila: /* Shrink the disk */

== Important ==
Note that the technique described below to zero out the unused space on the guest OS will in fact make your guest virtual disk grow to the maximum size first. For each byte that is changed to zero the virtual disk will need to claim a byte. This means that while you can use the technique to reclaim disk space after the unused space is zero'd out, it is important to have enough space before you start.

If you don't have that kind of free disk space then you can skip the zero-ing out part. You can still reclaim space, but it will be less optimal.
Alternatively you can use the "Partially zero out" trick described below.

=== How much free space do you need before shrinking? ===
Also please note that you need more free space in order to be able to run the shrinking process.
The shrinking process consists of making a copy of your virtual disk while omitting the zero'd out blocks.
So how much extra space you need depends on how you configured the virtual disk for your Virtual Machine.
If your Virtual Disk is a single file, then your free space requirement can grow up-to the full size of that virtual disk.

If OTOH you are using the split disk scheme where a virtual disk is sliced into multiple files the maximum free space you need is the maximum size a slice can be. Nowadays there's not a fixed slice size, it depends on how big your virtual disk actually is.

The split disk scheme since VMware Workstation 11 (VMware Fusion 7), older version of Workstation/Fusion use a 2GB split disk scheme.

Capacity Extent size
================================
<=128GB 4GB (increased from 2GB)
>128GB && <2TB Capacity / 32 (so maximum of 32 extents)
>=2TB 2TB

For extra safety I recommend to make sure you have an additional 2GB of free space on top of those requirements as mentioned above.

As side note, this also explains why it is generally recommended at the forum by the regulars to use a split disk scheme over single disk files.
This same problem also exists when you want to commit snapshots.

=== Using the clean up option in the menu ===

When you use the "Clean Up Disks" option in the menu in VMware Workstation 12 or later, then you do not require extra disk space for reclaiming space (see also: [https://docs.vmware.com/en/VMware-Workstation-Pro/14.0/com.vmware.ws.using.doc/GUID-421A1073-BF16-4BC7-AA76-46B954CA438D.html Clean Up a Virtual Hard Disk on Windows Hosts] )

Currently this only works for Windows guests where the filesystem is NTFS.

== Zero out unused space in a Linux VM ==

Before we try to shrink the virtual disk files, we should try to remove any unneeded files from the virtual machine to free space.
More free space means more disk space that can get reclaimed.

One of the areas in a VM that can take up a lot of disk space is the repository cache. So I personally tend to clean the cache in the VM before reclaiming disk space at the host.

Clean up your repositories:

For example, on Debian-based VMs, you can run the following command (in the VM)

apt-get clean all

to clear out the local repository of retrieved package files.

On red hat based VMs that would be:

yum clean

The next step is important:

Shut down any services that depend on having enough available disk space to run.

The reason for this is that we are going to write out zero's to the file system until the file system is full and we do not want any application - for example a database system like mySQL or postgreSQL - to run out of disk space while we are zeroing out the file system. If mySQL would try to write when your disk is full you risk a corrupted database. So this step is important!

Next run (also from within the VM):

cat /dev/zero > zero.fill;sync;sleep 1;sync;rm -f zero.fill

to fill the unused space with zeros and then remove the "zero.fill" that has all the zero's.

As this command writes to the disk until it runs out of disk space, you will get an error "No space left on the device". This is expected.

Note that you have multiple partitions that you have to repeat the above command to zero out for each partition.
Adjust "zero.fill" to the relevant mountpoint, for example if you have a separate partition for home it would become:

cat /dev/zero > /home/zero.fill;sync;sleep 1;sync;rm -f /home/zero.fill

=== Zero out a part of your virtual disk ===

If your virtual machine cannot be taken down and you do not want to shut down services that might end up corrupting files because of the "No space left on the device" problem then an idea that might work is to zero out a part of your partition.

This for example creates a 100MB size file filled with zero's

# dd if=/dev/zero of=zero.fill bs=1024 count=102400
102400+0 records in
102400+0 records out
104857600 bytes (105 MB) copied, 0.3839 s, 273 MB/s

So if you want to zero out 10GB instead, add two more zero's to the count parameter, eg: count=10240000

If you want to fill up in steps, just change the output file name from "zero.fill" into "zero.fill2" etcetera..

Then run the "sync; sleep 1; sync" from above and remove the zero.fill files.

If your VM is running on VMware vSphere and you have a NFS LUN with enough free space then one way to reclaim your space is to Storage vMotion the VM to NFS storage and back. Once done the zero'd out data has been reclaimed. No need to shut down the VM.

If this is not for you, then do read on.

=== Zero out using fstrim ===

These days there's an alternative way for zero-ing out the parts of the disk that are not used using [https://www.man7.org/linux/man-pages/man8/fstrim.8.html fstrim].

The great thing about this is that it only zero's out the parts of the disk that are not zero and as such the disk does not inflate to its full size.

* [https://forums.freebsd.org/threads/ssd-trim-maintenance.56951/post-328912 Detail comment from Theodore Ts'o on using fstrim]

* [https://github.com/vmware/open-vm-tools/issues/457 Avoid disk expansion while shrinking (github issue tracker)]

== Zero out unused space on a Windows VM ==

To do the same with a windows VM, you can use Microsoft's tool [http://technet.microsoft.com/en-us/sysinternals/bb897443.aspx sdelete].

Run it as
sdelete -z c:

To clean out the free space on disk c:

Careful!

As of sdelete v1.6 -c and -z have changed meanings, many instructions say -c zeros free space, this is no longer the case, it zeros the space then fills with random data in accordance with DOD spec: DOD 5220.22-M, random data will prevent the reclaim logic from working.

The trigger to zero space with 0x00 has changed to -z!

== Zeroing an encrypted disk ==

If you use disk encryption in the guest OS then zero'ing out the disk won't help.

The reason is that a good disk encryption scheme will write out random data to the disk when you write out zero's.

In other words, if you have enabled full disk encryption in the guest then you can not shrink the disk anymore as there is no space to reclaim.

== Shrink the disk ==

Then power down the VM and open a terminal on the Linux host.

Navigate to the directory where the .vmdk files are located, e.g.:

cd /var/lib/vmware/Virtual\ Machines/Ubuntu\ Desktop/

You can shrink the .vmdk file as follows:

vmware-vdiskmanager -k Ubuntu\ Desktop.vmdk

On Windows the command also uses the -k option, so I leave that for you as an exercise.

Note that vmware-vdiskmanager is probably not in your search path, so you might have to prepend the vmware-vdiskmanager command with the actual path with the command is located.

On macOS you run it as:
/Applications/VMware\ Fusion.app/Contents/Library/vmware-vdiskmanager -k Ubuntu\ Desktop.vmdk

If you need to use "sudo" in order to be able to run the above then beware that the ownership of the .vmdk files might get changed to root. So certainly try it first without running as root!

You will have to change the ownership back to your own user, eg:
sudo chown username: *.vmdk
If you don't change the ownership back you might see errors like:
"Unable to open file .../Virtual Disk.vmdk: Insufficient permission to access file".

== Shrink using vmware tools ==

Nowadays you can also shrink the guest by using the shrink feature as offered via vmware tools.

So for clarity all of the following commands are run from within the guest to shrink the disk while the guest is running.

On linux in order to use this run:
sudo vmware-toolbox-cmd disk shrink /

Where "/" is the mount point of the partition that you want to shrink.

On Windows in order to use this run (as administrator):

C:\Program Files\VMware\VMware Tools>VMwareToolboxCmd.exe disk shrink <location>

where <location> is the drive you want to shrink

For example:
C:\Program Files\VMware\VMware Tools>VMwareToolboxCmd.exe disk shrink c:\
Please disregard any warnings about disk space for the duration of shrink process.
Progress: 62 [=======> ]
The progress you see here is VMware Tools blanking out the unused space.

At 99% it will popup the "Shrinking Disk" progress dialog at the host that takes care of the actual shrinking process.

If you are logged in via remote desktop then do expect to loose the connection for a bit while the actual shrinking is taking place.

On OS X / macOS the command to use is:

sudo /Library/Application\ Support/VMware\ Tools/vmware-tools-cli disk shrink /

== Shrink macOS VM with APFS ==

[https://communities.vmware.com/thread/581576 Solved: Shrink an APFS virtual disk]

== External links ==

* [https://docs.vmware.com/en/VMware-Workstation-Pro/16.0/com.vmware.ws.using.doc/GUID-421A1073-BF16-4BC7-AA76-46B954CA438D.html Clean Up a Virtual Hard Disk on Windows Hosts - Workstation 16 Pro documentation]

* [https://docs.vmware.com/en/VMware-Workstation-Pro/16.0/com.vmware.ws.using.doc/GUID-3F94C7B5-19A5-4E91-9709-B17FAA93FF75.html Configuring and Maintaining Virtual Hard Disks - Workstation 16 Pro documentation]

* [https://docs.vmware.com/en/VMware-Fusion/12/com.vmware.fusion.using.doc/GUID-6BB29187-F47F-41D1-AD92-1754036DACD9.html#GUID-6BB29187-F47F-41D1-AD92-1754036DACD9 Clean up a Virtual Machine - VMware Fusion 12 documentation]

Vmx hacks

2022-07-18T10:10:55Z

Wila: Player - disable mitigations

=== VMX hacks ===

Here's my internal list of the .vmx hacks that I collected over time.

Beware that editing a .vmx file manually and adding any of these options is unsupported.

If you end up breaking your VM by editing the .vmx ... then restore the backup! (If you had no backups before hacking on your config, you are doing something wrong)

Also note that some options might no longer be active as they might be for an earlier version of a VMware product.

==== Wait 5 seconds on booting ====
Wait 5 seconds on booting:
bios.bootDelay = "5000"
Time is in milliseconds, change it accordingly.
==== Open BIOS settings on next boot ====
Open BIOS settings on next boot:
bios.forceSetupOnce = "TRUE"
In VMware Server 2, this setting is also in the web management interface, choose "Configure VM", power tabdialog, near the bottom.

[http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1648 Automatically Connecting USB Devices at Virtual Machine Power On]
==== Disable all Power menu and keyboard shortcuts====
gui.restricted="true"
This disables all power menu and keyboard shortcuts. It also disables suspend button

==== Fix repeating keys ====

To reduce these effects, increase the time threshold necessary for auto-repeat in the remote console.

Power off the virtual machine.
Add a line, similar to this, at the end of your virtual machine's configuration (.vmx) file:

keyboard.typematicMinDelay = "2000000"

The delay is specified in micro-seconds, so the line in the example above increases the repeat time to 2 seconds. This should ensure that you never get auto-repeat unless you intend it.

[http://kb.vmware.com/kb/196 Repeated characters when typing in remote console]

==== Disables suspend option ====
suspend.disabled = "TRUE"
This disables the suspend option in a virtual machine.

==== Fix Caps Lock synchronisation issues ====
This tip fixes the caps lock sync issue in Fusion 2.0.x and Tech Preview. I found it to be invaluable, add this to your VM's configuration file (.vmx):

mks.keyboard.syncLEDs = "TRUE"
==== Run a VM without a suspend file====
isn't there an option to run a VM without a suspend file (which is a file named like abcdef01-abcd-abcd-abcd-abcdef012345.vmem)
you mean
mainmem.useNamedFile = "false"
only works in windows

==== Use FT in a VM under Workstation ====
To use FT in a nested VM, you will still have to supply the entirely unsupported option (for the inner VM):

replay.allowBTOnly = "TRUE"

[http://communities.vmware.com/message/1343622 VMTN Anyone had sucess setting up a ESX40 Lab on Workstation 7.0?]

==== Disable VIX ====

An interesting tidbit if you’re super security cautious you can disable VIX by adding

“Guest.Command.Enabled”=”False”

to either the VM or the host. Be aware that this WILL break upgrading of VMware tools, and Guest customization as they both use vix as the underlying technology!

==== Optimize performance linux VM ====

mainmem.useNamedFile is no longer longer used on Linux hosts that run VMplayer 3 or Workstation 7.

New parameters are :
mainmem.backing = "swap"
mainmem.backing = "named"
mainmem.backing = "unnamed"

see http://sanbarrow.com/vmx/vmx-advanced.html#mainmem

==== Optimize troubleshooting ====
Please power off your VM and add the following configuration option to your .vmx file:
vmx.buildType = stats
Boot the VM and run your benchmark.
Shut down the VM and send me the contents of the stats directory that will be created in the same folder as the VM.

from: https://communities.vmware.com/message/2408159#2408159

==== Hardening your vmx file for security ====

http://virtualfoundry.blogspot.com/2009/04/hardening-vmx-file.html

==== Spurious APIC interrupt on CPU#1, should never happen ====

These messages are the result of an optimization Workstation 11 uses for inter-processor interrupts between virtual CPUs. The interrupt vector used for this purpose is 0xff, which is the Linux spurious APIC interrupt vector. In some cases, an inter-processor interrupt may arrive on a physical processor after Workstation has relinquished the processor to the host OS. Linux will discard the interrupt and print this message.

Unless these messages occur with high frequency, they should be innocuous.

The following configuration option should disable the optimization and make the messages stop:
monitor_control.disable_hostedIPI = TRUE

You can add this setting to /etc/vmware/config, and it will take effect for all VMs the next time they are powered on

from: [https://communities.vmware.com/message/2456565#2456565 Spurious APIC interrupt on CPU#1, should never happen]

==== CPU Masking ====

Yes, it is possible to mask the CPUID values in a VM (except for user mode code when using binary translation). However, masking only changes what CPUID reports; it doesn't change the way the processor behaves. Thus, masking may cause unexpected guest behavior.

The general format for CPUID masking is:

cpuid.<leaf>.<register> = xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx

The right hand side is a binary representation of the desired value, most significant bit first. Aside from '0' and '1,' two other important symbols are 'h,' which means to pass through the bit from the host CPUID and '-,' which means not to override the normal handling for this bit.

Specifying a different CPU vendor is not recommended.

from [https://communities.vmware.com/thread/405727 thread masking] Mr JMattson

In any event, the first thing to do is to pretend to be an AMD CPU. These settings should accomplish that:

cpuid.0.ebx = "0110:1000:0111:0100:0111:0101:0100:0001"
cpuid.0.ecx = "0100:0100:0100:1101:0100:0001:0110:0011"
cpuid.0.edx = "0110:1001:0111:0100:0110:1110:0110:0101"

Then you want to claim the family, model, and stepping of an actual AMD CPU. This setting should do that (claiming to be an early 64-bit Opteron):

cpuid.1.eax="----:0000:0000:0000:----:1111:0100:0110"

Even with these settings, some guests may still be unhappy.

=== Workstation ===

==== USB debugging ====

from [https://communities.vmware.com/message/2473661#2473661 Conversion from Workstation 10 to 11 breaks USB connections]
usb.quirks.device0 = "0x04e8:0x685b skip-reset"

==== USB Passthrough on Linux Host ====
'Passthrough' mode was disabled on Linux host as it conflicted with shared mode provided via pcscd

from [https://communities.vmware.com/message/2462510#2462510 Gemalto Smart Card Reader only appears as "Shared" not "Passthrough"]

* 1) Go to the VM's installation directory. Typically C:\Users\<username>\Documents\Virtual Machines\
* 2) Open <virtual-machine-name>.vmx file
* 3) Append the following lines:
usb.generic.allowCCID = "TRUE"
usb.ccid.disable = "TRUE"
* 4) Kill the process corresponding to the PCSC daemon on the Linux host

Do a # ps -ef | grep -i pcsc on your Linux host
sudo kill -9 <pid of the process that corresponds to pcscd>

Notes:
* 1) The first line in step 3 enables the passthrough mode
* 2) The second line in step 3 disables shared mode
* 3) Since you are killing the pcscd on your host, you wont be able to use the smart card on the host. You can passthrough the smart card now and use it in the VM

==== Change thumbnail speed ====

From Workstation 14 including 15, the thumbnail views are not in real time any more and the default refresh interval value is 3000 ms.

You can add

pref.thumbnailRefreshIntervalMs = 1000

(or other values) in the preference file %appdata%/vmware/preferences.ini to change the refesh rate. But keep in mind that this way may cause high CPU usage.

If you really need the previous real time thumbnail, you can use

pref.closeInactiveMKSWindows = "false"

But this way may cause mouse/keyboard functions under multi tabs not working well.

Both these settings are not documented or tested, so I cannot guarantee they working normally.

Note that you should make changes to the preferences.ini file with VMware Workstation shut down.

from: https://communities.vmware.com/message/2807350#2807350

==== Linux Host - switch back from Vulkan to X11 ====
Workstation 16.2.0 and higher

Add to .vmx if changing for one VM, or ~/.vmware/config if you want to change this systemwide:

mks.enableX11Presentation=TRUE
mks.enableVulkanPresentation=FALSE

That will force us to draw the window using X11 instead of Vulkan, which is normally less performant, but might work better on some setups?

from: [https://communities.vmware.com/t5/VMware-Workstation-Pro/VMware-16-2-1-Display-3D-acceleration-not-working-Windows-10/m-p/2877574#M172414 VMware 16.2.1 Display 3D acceleration not working Windows 10]

Has a great explanation on the difference by banackm

Beware that if you have this issue -and your host has more than one GPU- that it also might be because the wrong GPU was selected for Vulkan.

There's another switch to use the openGL renderer instead of Vulkan:

mks.enableVulkanRenderer = "FALSE"
mks.enableGLRenderer = "TRUE"

and a switch to allow the Vulkan rendered use unsupported devices:

mks.vk.allowUnsupportedDevices = "TRUE"

There's even a way to force your VM to use a specific GPU, such as the discrete GPU instead of the integrated GPU.. if your host has both.

mks.forceDiscreteGPU = "TRUE"

See the tips from BlueFireStorm here: [https://communities.vmware.com/t5/VMware-Workstation-Pro/VMware-Workstation-cannot-connect-to-the-virtual-machine-Vmware/m-p/2899481/highlight/true#M174703 VMware Workstation cannot connect to the virtual machine]

==== Dark Mode ====

In Workstation 16.2 Dark Mode had disappeared by accident, it was discovered that adding the following setting to the preferences.ini file makes it re-appear.

wsFeatureDarkModeSupported = "TRUE"

from: [https://communities.vmware.com/t5/VMware-Workstation-Pro/Vmware-Workstation-16-2-dark-mode/m-p/2874723/highlight/true#M172025 forum user mrdow2000]

==== All USB devices are disabled ====

Check your .vmx file for the following line:

usb.restrictions.defaultAllow = "FALSE"

If it has this then remove that line and try again.

It seems that this line is automatically added for Workstation/Player 16.2.x when using "Easy Setup".

More details here: [https://communities.vmware.com/t5/VMware-Workstation-Player/All-USB-devices-are-greyed-out/m-p/2878067#M37999 All USB devices are greyed out]

=== VMware Player ===

==== Disable mitigations ====

A message about disabling side channel mitigations shows up only when the ULM is used instead of the ring 0 VMM as the hypervisor monitor.

That means the Windows host has been detected to have Hyper-V enabled.

https://blogs.vmware.com/workstation/2020/05/vmware-workstation-now-supports-hyper-v-mode.html

There is no advanced options in VMware Workstation Player.

To disable the side channel mitigation, shut down the VM and add the following to the VM vmx configuration file.

ulm.disableMitigations = "TRUE"

from: [https://communities.vmware.com/t5/VMware-Workstation-Player/Poor-performance-after-update-with-message-about-side-channel/m-p/2811455/highlight/true#M35855 Poor performance after update with message about side channel mitigation]

=== Fusion ===
==== Applying a setting over all VMs ====

Instead of editing each .vmx file manually, you can also apply config options to all VMs, by creating/editing the user global config file that can be found at: ~/Library/Preferences/VMware\ Fusion/config

There's already a 'preferences' file in the same directory, but normally the config file has to be created.

If an individual .vmx file contains the same config options as the global file, the .vmx file will take precedence.

==== Hide the Full Screen application menu ====

It's unsupported, but try editing /Users/$USER/Library/Preferences/VMware Fusion/preferences and add the line:

fusion.showFullScreenTitleBar = "FALSE"

See also: http://communities.vmware.com/message/1348663#1348663

==== Delay drop down Full Screen application menu ====

Edit /Users/$USER/Library/Preferences/VMware Fusion/preferences and add the line:

fusion.fullScreenMenuDelay = "2"

The delay is in seconds and the default is 1.5 seconds, added since Fusion 4.1
A value of "0" removes the delay.

See also: http://communities.vmware.com/message/2273022

On VMware Workstation you would add the following lines to the preferences.ini file.

pref.fullscreen.showDelay = "5000"
to delay the showing of the toolbar 5000ms (5 seconds)
pref.fullscreen.hideDelay = "1000"
to hide the toolbar after 1000ms (1 second)

For Win7 the preferences.ini file is located under:
C:\Users\<username>\AppData\Roaming\VMware

==== debug menu ====

fusion.enableDebugMenu

(never tried)

==== Turn off full screen autofit to host ====

Here's another way to stop the guest from automagically being resized at each swipe:

* Open Finder, select the "Go" menu then select "Go To Folder..." and type in: ~/Library/Preferences/VMware Fusion/
* Open the preferences file in a text editor and add/append the following lines at the end of the file:

pref.autoFitGuestToWindow = "FALSE"
pref.autoFitFullScreen = "stretchGuestToHost"

Taken from: https://communities.vmware.com/message/2293562

==== Pass through host model ====

It's unsupported, but try editing /Users/$USER/Library/Preferences/VMware Fusion/preferences and add the line:

hw.model.reflectHost = "TRUE"

This will cause the VM to see the same model ID as the host. The default for this option is FALSE. Be aware that using this option may cause VM portability issues since the guest may now depend on this behavior and the type of the underlying Mac.

See also: http://communities.vmware.com/thread/336922

==== VM power options always display "Force" ====

If the Virtual Machine was not originally created in VMware Fusion then you will notice that the Fusion Virtual Machine menu has the word "Force" inserted before any power option.
For example copying a VM from a Windows systems to Mac it displays the "Force ..." commands by default. In other words, pressing the Option Key is backwards of what it is supposed to be. This is because the following options are missing from the Virtual Machine's .vmx configuration file.

powerType.powerOff = "soft"
powerType.powerOn = "soft"
powerType.suspend = "soft"
powerType.reset = "soft"

By default, VMware Fusion creates these options in the Virtual Machine's .vmx configuration file while VMware Player/Workstation does not. So, add the above options to the Virtual Machine's .vmx configuration file and the "Force ..." commands will then exhibit VMware Fusion normal behavior. Meaning in order to access the "Force ..." commands one will need to press the Option Key.

See also: http://communities.vmware.com/thread/402281

==== kernel debugging ====

You can attach a remote debugger such as gdb to your vm to do kernel debugging.

DebugStub knows nothing at all about the guest OS. Think of debugStub as an In-Circuit Debugger for the virtual CPU(s).

debugStub.listen.guest64 = "TRUE"
debugStub.listen.guest64.remote = "TRUE"
debugStub.hideBreakpoints=1
specify a custom port with:
debugStub.port.guest64 = "8865"
other options:
debugStub.listen.guest32 = "TRUE" # Enable listener for 32 bit guest
debugStub.listen.guest32.remote = "TRUE" # Allow remote connection
debugStub.port.guest32 = "32001" # Listen on specified port NNN

see also: [https://communities.vmware.com/thread/470936 Using debugStub to debug a guest linux kernel]

==== Additional logging ====
For troubleshooting boot issues etcetera you can increase the log level in vmware.log

monitor_control.log_vmsample = "TRUE"

[https://communities.vmware.com/thread/471833 Fusion 6.0.2 / OS X 10.9.2 Host / OS X 10.9 Guest VM running >100% CPU no matter what]

==== memory hole ====

At 3.2 GB there's a 1024kB memory hole.

You can use the pciHole.start option to adjust the start of the memory hole, measured in megabytes from address 0x00000000. The default is

pciHole.start = 3072

which corresponds to 0xC0000000.

from [https://communities.vmware.com/thread/478739 Memory hole at 3.2GB]

==== Disable Shared Folder event notification ====

isolation.tools.hgfs.notify.enable = "FALSE"

See also: http://kb.vmware.com/kb/2011360

==== Shared folder size check ====

The other workaround is to stop the VM, edit the VM's .vmx file and add the following setting:

tools.hgfs.volumeInfoType = "max"

Then start the VM again, and this time you will not need to disable the other shares which are on smaller sized volumes.

The default setting causes the shares to be aggregated to the smallest volume size that a share resides on when our file system is queried for size and free space.

The above setting overrides this to pick the largest volume size. The downside is that you can start a copy to a share on volume with a smaller amount of free space and it will only fail when it actually fails to write when the free space is exhausted.

If you know you are not going to run into that type of scenario yourself or you verify prior to starting the copy operation then you will be fine.

Note, the above can only be set to "min" or "max" and if not set at all, then "min" is the default.

from: [https://communities.vmware.com/message/2381223#2381223 Folder copy on Windows 7 vm fails for "not enough space", but there is.]

==== Disable location services ====

sensor.location = "disable"

to vmx.

[https://communities.vmware.com/message/2383410#2383410 how-to disable location services]

==== Disable automatic USB connect to guest feature ====

1. Suspend or shut down any running VMs and quit Fusion.

2. Ensure that the vmware-usbarbitrator process is no longer running.

3. Create/edit the host-global configuration file, with root privileges: (this example uses nano, but feel free to use any other editor)

sudo nano /Library/Preferences/VMware\ Fusion/config

4. Add the following line to disable the automatic claiming of USB devices:

usbarb.autoconnect.claimAll = "FALSE"

5. Save the file and quit the editor.

With this change, all USB devices should automatically connect to the host even when VMs are running. Note that it will completely disable the USB connection prompt, and will prevent devices from automatically connecting to VMs (even if the option is selected in settings). However it should still be possible to manually connect USB devices to a running VM (except possibly in cases where the reset command is not correctly issued via the hub).

from: [https://communities.vmware.com/message/2393343#2393343 2014 Preview still has USB 3 hub issue]

==== Open file with host OS application ====
When a file is located on a shared folder (VMware HGFS) then you can choose to be able to open this file with the host OS default application.
For example. Your png file can open in macOS Preview.

proxyApps.publishToGuest = "TRUE"

See also: [https://communities.vmware.com/t5/VMware-Workstation-Pro/Has-there-ever-been-a-solution-to-opening-a-host-application/m-p/2841711/highlight/true#M169663 Has there ever been a solution to opening a host application from a guest OS?]

==== Pass OS X host serial number ====

If you want an OS X guest to use the host's serial number, you'll need to add this option to the VM's configuration:

serialNumber.reflectHost = "TRUE"

==== Pass OS X host hardware model ====

To pass hardware model to the guest (not even sure this works, as it does not seem to do anything for me, but ... Fusion does not error on starting the VM )

hw.model.reflectHost = "TRUE"

==== Pass OS X host hardware model ID ====

If you want an OS X guest to use the host's hardware model ID (i.e. "MacPro5,1"), board ID (i.e. "Mac-12345678") and serial number all together:

smbios.reflectHost = "TRUE"

=== Any platform ===

==== Disable scoreboard files ====

In VMware Fusion 12.2 and Workstation 16.2 new files have been introduced for keeping some sort of statistics.

These are called scoreboard files.

You can disable that feature.

vmx.scoreboard.enabled = "FALSE"

See: [https://communities.vmware.com/t5/VMware-Workstation-Pro/VMware-Workstation-16-2-0-and-scoreboard-files-What-it-is/m-p/2881784/highlight/true#M172906 Suggestion by DaveP on VMware Workstation 16.2.0 and .scoreboard files. What is it?]

==== Slow down time in guest ====

You can't quite stop time, but you can make it go extremely slowly. Set the following in your system-wide configuration file (/etc/vmware/config on Linux; C:\ProgramData\VMware\VMware Workstation\config.ini on Windows):

host.cpukHz = 1000

This is probably not all that useful in practice, unless the guest OS has no reliance on any time sources.

from [https://communities.vmware.com/message/2431592#2431592 System time]

==== Set max number of snapshots ====

snapshot.maxSnapshots = 100

==== Enable DX11 or OpenGL Host Renderer ====

Courtesy @bluefirestorm at [https://communities.vmware.com/message/2812499#2812499 setting *.vmx]

mks.enableDX11Renderer

When 3D accelerated graphics is enabled in Workstation 12/14/15 the default value is "TRUE" (i.e. the line does not have to be present in the vmx file), VMware Workstation uses DX11 of the Windows host to deliver the DX10/OpenGL 3.3 core profile capability inside the VMs. For Linux hosts, the equivalent is mks.enableGLRenderer = "TRUE"

==== Enable D3D Renderer ====
Courtesy @bluefirestorm at [https://communities.vmware.com/message/2812499#2812499 setting *.vmx]

mks.enableD3DRenderer

Default is "FALSE" from Workstation 12.x and later. This is only useful in version 12.x if the host graphics card does not have DX11 capability and setting this to TRUE and enableDX11Renderer to FALSE let the VM have some limited 3D accelerated graphics capability. This looks like is already ineffective in version 14/15.

==== Select host Graphics card to use ====
Courtesy @bluefirestorm at [https://communities.vmware.com/message/2812499#2812499 setting *.vmx]

mks.dx11.vendorID

valid values are the vendor ID of the graphic card, 0x8086 for Intel, 0x10DE for Nvidia, 0x1002 for AMD.

If this line is not present, VMware Workstation will use the default graphic card of the Windows host system. This line is useful if the system has two graphic cards from two different vendors that are simultaneously active on the host machine (example: Intel integrated graphics in the CPU and a discrete graphics card from Nvidia or AMD).

==== ReflectHost ====
Courtesy @bluefirestorm at [https://communities.vmware.com/message/2812499#2812499 setting *.vmx]

SMBIOS.reflectHost

Default is "FALSE". If set to "TRUE" some of the DMI info will use the host values (example: manufacturer will change from VMware to the host value). You can see this difference by using msinfo32 in Windows VM or dmidecode in Linux VM. This is not so useful anymore to hide the fact that the VM is a VM.

==== vmx.buildType ====
Courtesy @bluefirestorm at [https://communities.vmware.com/message/2812499#2812499 setting *.vmx]

vmx.buildType

Valid values are "release" and "debug". The "debug" is the default for the beta versions (aka Tech Preview). When set to "debug", vmware-vmx-debug.exe will be used instead of vmware-vmx.exe and the vmware.log file will be larger.

=== External sites ===

There's only one .vmx site that has most .vmx options and that's Ulli's reference over at sanbarrow:

http://sanbarrow.com/vmx/vmx-advanced.html

Vmx hacks

2022-03-19T10:30:24Z

Wila: /* Linux Host - switch back from Vulkan to X11 */

=== VMX hacks ===

Here's my internal list of the .vmx hacks that I collected over time.

Beware that editing a .vmx file manually and adding any of these options is unsupported.

If you end up breaking your VM by editing the .vmx ... then restore the backup! (If you had no backups before hacking on your config, you are doing something wrong)

Also note that some options might no longer be active as they might be for an earlier version of a VMware product.

==== Wait 5 seconds on booting ====
Wait 5 seconds on booting:
bios.bootDelay = "5000"
Time is in milliseconds, change it accordingly.
==== Open BIOS settings on next boot ====
Open BIOS settings on next boot:
bios.forceSetupOnce = "TRUE"
In VMware Server 2, this setting is also in the web management interface, choose "Configure VM", power tabdialog, near the bottom.

[http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1648 Automatically Connecting USB Devices at Virtual Machine Power On]
==== Disable all Power menu and keyboard shortcuts====
gui.restricted="true"
This disables all power menu and keyboard shortcuts. It also disables suspend button

==== Fix repeating keys ====

To reduce these effects, increase the time threshold necessary for auto-repeat in the remote console.

Power off the virtual machine.
Add a line, similar to this, at the end of your virtual machine's configuration (.vmx) file:

keyboard.typematicMinDelay = "2000000"

The delay is specified in micro-seconds, so the line in the example above increases the repeat time to 2 seconds. This should ensure that you never get auto-repeat unless you intend it.

[http://kb.vmware.com/kb/196 Repeated characters when typing in remote console]

==== Disables suspend option ====
suspend.disabled = "TRUE"
This disables the suspend option in a virtual machine.

==== Fix Caps Lock synchronisation issues ====
This tip fixes the caps lock sync issue in Fusion 2.0.x and Tech Preview. I found it to be invaluable, add this to your VM's configuration file (.vmx):

mks.keyboard.syncLEDs = "TRUE"
==== Run a VM without a suspend file====
isn't there an option to run a VM without a suspend file (which is a file named like abcdef01-abcd-abcd-abcd-abcdef012345.vmem)
you mean
mainmem.useNamedFile = "false"
only works in windows

==== Use FT in a VM under Workstation ====
To use FT in a nested VM, you will still have to supply the entirely unsupported option (for the inner VM):

replay.allowBTOnly = "TRUE"

[http://communities.vmware.com/message/1343622 VMTN Anyone had sucess setting up a ESX40 Lab on Workstation 7.0?]

==== Disable VIX ====

An interesting tidbit if you’re super security cautious you can disable VIX by adding

“Guest.Command.Enabled”=”False”

to either the VM or the host. Be aware that this WILL break upgrading of VMware tools, and Guest customization as they both use vix as the underlying technology!

==== Optimize performance linux VM ====

mainmem.useNamedFile is no longer longer used on Linux hosts that run VMplayer 3 or Workstation 7.

New parameters are :
mainmem.backing = "swap"
mainmem.backing = "named"
mainmem.backing = "unnamed"

see http://sanbarrow.com/vmx/vmx-advanced.html#mainmem

==== Optimize troubleshooting ====
Please power off your VM and add the following configuration option to your .vmx file:
vmx.buildType = stats
Boot the VM and run your benchmark.
Shut down the VM and send me the contents of the stats directory that will be created in the same folder as the VM.

from: https://communities.vmware.com/message/2408159#2408159

==== Hardening your vmx file for security ====

http://virtualfoundry.blogspot.com/2009/04/hardening-vmx-file.html

==== Spurious APIC interrupt on CPU#1, should never happen ====

These messages are the result of an optimization Workstation 11 uses for inter-processor interrupts between virtual CPUs. The interrupt vector used for this purpose is 0xff, which is the Linux spurious APIC interrupt vector. In some cases, an inter-processor interrupt may arrive on a physical processor after Workstation has relinquished the processor to the host OS. Linux will discard the interrupt and print this message.

Unless these messages occur with high frequency, they should be innocuous.

The following configuration option should disable the optimization and make the messages stop:
monitor_control.disable_hostedIPI = TRUE

You can add this setting to /etc/vmware/config, and it will take effect for all VMs the next time they are powered on

from: [https://communities.vmware.com/message/2456565#2456565 Spurious APIC interrupt on CPU#1, should never happen]

==== CPU Masking ====

Yes, it is possible to mask the CPUID values in a VM (except for user mode code when using binary translation). However, masking only changes what CPUID reports; it doesn't change the way the processor behaves. Thus, masking may cause unexpected guest behavior.

The general format for CPUID masking is:

cpuid.<leaf>.<register> = xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx

The right hand side is a binary representation of the desired value, most significant bit first. Aside from '0' and '1,' two other important symbols are 'h,' which means to pass through the bit from the host CPUID and '-,' which means not to override the normal handling for this bit.

Specifying a different CPU vendor is not recommended.

from [https://communities.vmware.com/thread/405727 thread masking] Mr JMattson

In any event, the first thing to do is to pretend to be an AMD CPU. These settings should accomplish that:

cpuid.0.ebx = "0110:1000:0111:0100:0111:0101:0100:0001"
cpuid.0.ecx = "0100:0100:0100:1101:0100:0001:0110:0011"
cpuid.0.edx = "0110:1001:0111:0100:0110:1110:0110:0101"

Then you want to claim the family, model, and stepping of an actual AMD CPU. This setting should do that (claiming to be an early 64-bit Opteron):

cpuid.1.eax="----:0000:0000:0000:----:1111:0100:0110"

Even with these settings, some guests may still be unhappy.

=== Workstation ===

==== USB debugging ====

from [https://communities.vmware.com/message/2473661#2473661 Conversion from Workstation 10 to 11 breaks USB connections]
usb.quirks.device0 = "0x04e8:0x685b skip-reset"

==== USB Passthrough on Linux Host ====
'Passthrough' mode was disabled on Linux host as it conflicted with shared mode provided via pcscd

from [https://communities.vmware.com/message/2462510#2462510 Gemalto Smart Card Reader only appears as "Shared" not "Passthrough"]

* 1) Go to the VM's installation directory. Typically C:\Users\<username>\Documents\Virtual Machines\
* 2) Open <virtual-machine-name>.vmx file
* 3) Append the following lines:
usb.generic.allowCCID = "TRUE"
usb.ccid.disable = "TRUE"
* 4) Kill the process corresponding to the PCSC daemon on the Linux host

Do a # ps -ef | grep -i pcsc on your Linux host
sudo kill -9 <pid of the process that corresponds to pcscd>

Notes:
* 1) The first line in step 3 enables the passthrough mode
* 2) The second line in step 3 disables shared mode
* 3) Since you are killing the pcscd on your host, you wont be able to use the smart card on the host. You can passthrough the smart card now and use it in the VM

==== Change thumbnail speed ====

From Workstation 14 including 15, the thumbnail views are not in real time any more and the default refresh interval value is 3000 ms.

You can add

pref.thumbnailRefreshIntervalMs = 1000

(or other values) in the preference file %appdata%/vmware/preferences.ini to change the refesh rate. But keep in mind that this way may cause high CPU usage.

If you really need the previous real time thumbnail, you can use

pref.closeInactiveMKSWindows = "false"

But this way may cause mouse/keyboard functions under multi tabs not working well.

Both these settings are not documented or tested, so I cannot guarantee they working normally.

Note that you should make changes to the preferences.ini file with VMware Workstation shut down.

from: https://communities.vmware.com/message/2807350#2807350

==== Linux Host - switch back from Vulkan to X11 ====
Workstation 16.2.0 and higher

Add to .vmx if changing for one VM, or ~/.vmware/config if you want to change this systemwide:

mks.enableX11Presentation=TRUE
mks.enableVulkanPresentation=FALSE

That will force us to draw the window using X11 instead of Vulkan, which is normally less performant, but might work better on some setups?

from: [https://communities.vmware.com/t5/VMware-Workstation-Pro/VMware-16-2-1-Display-3D-acceleration-not-working-Windows-10/m-p/2877574#M172414 VMware 16.2.1 Display 3D acceleration not working Windows 10]

Has a great explanation on the difference by banackm

Beware that if you have this issue -and your host has more than one GPU- that it also might be because the wrong GPU was selected for Vulkan.

There's another switch to use the openGL renderer instead of Vulkan:

mks.enableVulkanRenderer = "FALSE"
mks.enableGLRenderer = "TRUE"

and a switch to allow the Vulkan rendered use unsupported devices:

mks.vk.allowUnsupportedDevices = "TRUE"

There's even a way to force your VM to use a specific GPU, such as the discrete GPU instead of the integrated GPU.. if your host has both.

mks.forceDiscreteGPU = "TRUE"

See the tips from BlueFireStorm here: [https://communities.vmware.com/t5/VMware-Workstation-Pro/VMware-Workstation-cannot-connect-to-the-virtual-machine-Vmware/m-p/2899481/highlight/true#M174703 VMware Workstation cannot connect to the virtual machine]

==== Dark Mode ====

In Workstation 16.2 Dark Mode had disappeared by accident, it was discovered that adding the following setting to the preferences.ini file makes it re-appear.

wsFeatureDarkModeSupported = "TRUE"

from: [https://communities.vmware.com/t5/VMware-Workstation-Pro/Vmware-Workstation-16-2-dark-mode/m-p/2874723/highlight/true#M172025 forum user mrdow2000]

==== All USB devices are disabled ====

Check your .vmx file for the following line:

usb.restrictions.defaultAllow = "FALSE"

If it has this then remove that line and try again.

It seems that this line is automatically added for Workstation/Player 16.2.x when using "Easy Setup".

More details here: [https://communities.vmware.com/t5/VMware-Workstation-Player/All-USB-devices-are-greyed-out/m-p/2878067#M37999 All USB devices are greyed out]

=== Fusion ===
==== Applying a setting over all VMs ====

Instead of editing each .vmx file manually, you can also apply config options to all VMs, by creating/editing the user global config file that can be found at: ~/Library/Preferences/VMware\ Fusion/config

There's already a 'preferences' file in the same directory, but normally the config file has to be created.

If an individual .vmx file contains the same config options as the global file, the .vmx file will take precedence.

==== Hide the Full Screen application menu ====

It's unsupported, but try editing /Users/$USER/Library/Preferences/VMware Fusion/preferences and add the line:

fusion.showFullScreenTitleBar = "FALSE"

See also: http://communities.vmware.com/message/1348663#1348663

==== Delay drop down Full Screen application menu ====

Edit /Users/$USER/Library/Preferences/VMware Fusion/preferences and add the line:

fusion.fullScreenMenuDelay = "2"

The delay is in seconds and the default is 1.5 seconds, added since Fusion 4.1
A value of "0" removes the delay.

See also: http://communities.vmware.com/message/2273022

On VMware Workstation you would add the following lines to the preferences.ini file.

pref.fullscreen.showDelay = "5000"
to delay the showing of the toolbar 5000ms (5 seconds)
pref.fullscreen.hideDelay = "1000"
to hide the toolbar after 1000ms (1 second)

For Win7 the preferences.ini file is located under:
C:\Users\<username>\AppData\Roaming\VMware

==== debug menu ====

fusion.enableDebugMenu

(never tried)

==== Turn off full screen autofit to host ====

Here's another way to stop the guest from automagically being resized at each swipe:

* Open Finder, select the "Go" menu then select "Go To Folder..." and type in: ~/Library/Preferences/VMware Fusion/
* Open the preferences file in a text editor and add/append the following lines at the end of the file:

pref.autoFitGuestToWindow = "FALSE"
pref.autoFitFullScreen = "stretchGuestToHost"

Taken from: https://communities.vmware.com/message/2293562

==== Pass through host model ====

It's unsupported, but try editing /Users/$USER/Library/Preferences/VMware Fusion/preferences and add the line:

hw.model.reflectHost = "TRUE"

This will cause the VM to see the same model ID as the host. The default for this option is FALSE. Be aware that using this option may cause VM portability issues since the guest may now depend on this behavior and the type of the underlying Mac.

See also: http://communities.vmware.com/thread/336922

==== VM power options always display "Force" ====

If the Virtual Machine was not originally created in VMware Fusion then you will notice that the Fusion Virtual Machine menu has the word "Force" inserted before any power option.
For example copying a VM from a Windows systems to Mac it displays the "Force ..." commands by default. In other words, pressing the Option Key is backwards of what it is supposed to be. This is because the following options are missing from the Virtual Machine's .vmx configuration file.

powerType.powerOff = "soft"
powerType.powerOn = "soft"
powerType.suspend = "soft"
powerType.reset = "soft"

By default, VMware Fusion creates these options in the Virtual Machine's .vmx configuration file while VMware Player/Workstation does not. So, add the above options to the Virtual Machine's .vmx configuration file and the "Force ..." commands will then exhibit VMware Fusion normal behavior. Meaning in order to access the "Force ..." commands one will need to press the Option Key.

See also: http://communities.vmware.com/thread/402281

==== kernel debugging ====

You can attach a remote debugger such as gdb to your vm to do kernel debugging.

DebugStub knows nothing at all about the guest OS. Think of debugStub as an In-Circuit Debugger for the virtual CPU(s).

debugStub.listen.guest64 = "TRUE"
debugStub.listen.guest64.remote = "TRUE"
debugStub.hideBreakpoints=1
specify a custom port with:
debugStub.port.guest64 = "8865"
other options:
debugStub.listen.guest32 = "TRUE" # Enable listener for 32 bit guest
debugStub.listen.guest32.remote = "TRUE" # Allow remote connection
debugStub.port.guest32 = "32001" # Listen on specified port NNN

see also: [https://communities.vmware.com/thread/470936 Using debugStub to debug a guest linux kernel]

==== Additional logging ====
For troubleshooting boot issues etcetera you can increase the log level in vmware.log

monitor_control.log_vmsample = "TRUE"

[https://communities.vmware.com/thread/471833 Fusion 6.0.2 / OS X 10.9.2 Host / OS X 10.9 Guest VM running >100% CPU no matter what]

==== memory hole ====

At 3.2 GB there's a 1024kB memory hole.

You can use the pciHole.start option to adjust the start of the memory hole, measured in megabytes from address 0x00000000. The default is

pciHole.start = 3072

which corresponds to 0xC0000000.

from [https://communities.vmware.com/thread/478739 Memory hole at 3.2GB]

==== Disable Shared Folder event notification ====

isolation.tools.hgfs.notify.enable = "FALSE"

See also: http://kb.vmware.com/kb/2011360

==== Shared folder size check ====

The other workaround is to stop the VM, edit the VM's .vmx file and add the following setting:

tools.hgfs.volumeInfoType = "max"

Then start the VM again, and this time you will not need to disable the other shares which are on smaller sized volumes.

The default setting causes the shares to be aggregated to the smallest volume size that a share resides on when our file system is queried for size and free space.

The above setting overrides this to pick the largest volume size. The downside is that you can start a copy to a share on volume with a smaller amount of free space and it will only fail when it actually fails to write when the free space is exhausted.

If you know you are not going to run into that type of scenario yourself or you verify prior to starting the copy operation then you will be fine.

Note, the above can only be set to "min" or "max" and if not set at all, then "min" is the default.

from: [https://communities.vmware.com/message/2381223#2381223 Folder copy on Windows 7 vm fails for "not enough space", but there is.]

==== Disable location services ====

sensor.location = "disable"

to vmx.

[https://communities.vmware.com/message/2383410#2383410 how-to disable location services]

==== Disable automatic USB connect to guest feature ====

1. Suspend or shut down any running VMs and quit Fusion.

2. Ensure that the vmware-usbarbitrator process is no longer running.

3. Create/edit the host-global configuration file, with root privileges: (this example uses nano, but feel free to use any other editor)

sudo nano /Library/Preferences/VMware\ Fusion/config

4. Add the following line to disable the automatic claiming of USB devices:

usbarb.autoconnect.claimAll = "FALSE"

5. Save the file and quit the editor.

With this change, all USB devices should automatically connect to the host even when VMs are running. Note that it will completely disable the USB connection prompt, and will prevent devices from automatically connecting to VMs (even if the option is selected in settings). However it should still be possible to manually connect USB devices to a running VM (except possibly in cases where the reset command is not correctly issued via the hub).

from: [https://communities.vmware.com/message/2393343#2393343 2014 Preview still has USB 3 hub issue]

==== Open file with host OS application ====
When a file is located on a shared folder (VMware HGFS) then you can choose to be able to open this file with the host OS default application.
For example. Your png file can open in macOS Preview.

proxyApps.publishToGuest = "TRUE"

See also: [https://communities.vmware.com/t5/VMware-Workstation-Pro/Has-there-ever-been-a-solution-to-opening-a-host-application/m-p/2841711/highlight/true#M169663 Has there ever been a solution to opening a host application from a guest OS?]

==== Pass OS X host serial number ====

If you want an OS X guest to use the host's serial number, you'll need to add this option to the VM's configuration:

serialNumber.reflectHost = "TRUE"

==== Pass OS X host hardware model ====

To pass hardware model to the guest (not even sure this works, as it does not seem to do anything for me, but ... Fusion does not error on starting the VM )

hw.model.reflectHost = "TRUE"

==== Pass OS X host hardware model ID ====

If you want an OS X guest to use the host's hardware model ID (i.e. "MacPro5,1"), board ID (i.e. "Mac-12345678") and serial number all together:

smbios.reflectHost = "TRUE"

=== Any platform ===

==== Disable scoreboard files ====

In VMware Fusion 12.2 and Workstation 16.2 new files have been introduced for keeping some sort of statistics.

These are called scoreboard files.

You can disable that feature.

vmx.scoreboard.enabled = "FALSE"

See: [https://communities.vmware.com/t5/VMware-Workstation-Pro/VMware-Workstation-16-2-0-and-scoreboard-files-What-it-is/m-p/2881784/highlight/true#M172906 Suggestion by DaveP on VMware Workstation 16.2.0 and .scoreboard files. What is it?]

==== Slow down time in guest ====

You can't quite stop time, but you can make it go extremely slowly. Set the following in your system-wide configuration file (/etc/vmware/config on Linux; C:\ProgramData\VMware\VMware Workstation\config.ini on Windows):

host.cpukHz = 1000

This is probably not all that useful in practice, unless the guest OS has no reliance on any time sources.

from [https://communities.vmware.com/message/2431592#2431592 System time]

==== Set max number of snapshots ====

snapshot.maxSnapshots = 100

==== Enable DX11 or OpenGL Host Renderer ====

Courtesy @bluefirestorm at [https://communities.vmware.com/message/2812499#2812499 setting *.vmx]

mks.enableDX11Renderer

When 3D accelerated graphics is enabled in Workstation 12/14/15 the default value is "TRUE" (i.e. the line does not have to be present in the vmx file), VMware Workstation uses DX11 of the Windows host to deliver the DX10/OpenGL 3.3 core profile capability inside the VMs. For Linux hosts, the equivalent is mks.enableGLRenderer = "TRUE"

==== Enable D3D Renderer ====
Courtesy @bluefirestorm at [https://communities.vmware.com/message/2812499#2812499 setting *.vmx]

mks.enableD3DRenderer

Default is "FALSE" from Workstation 12.x and later. This is only useful in version 12.x if the host graphics card does not have DX11 capability and setting this to TRUE and enableDX11Renderer to FALSE let the VM have some limited 3D accelerated graphics capability. This looks like is already ineffective in version 14/15.

==== Select host Graphics card to use ====
Courtesy @bluefirestorm at [https://communities.vmware.com/message/2812499#2812499 setting *.vmx]

mks.dx11.vendorID

valid values are the vendor ID of the graphic card, 0x8086 for Intel, 0x10DE for Nvidia, 0x1002 for AMD.

If this line is not present, VMware Workstation will use the default graphic card of the Windows host system. This line is useful if the system has two graphic cards from two different vendors that are simultaneously active on the host machine (example: Intel integrated graphics in the CPU and a discrete graphics card from Nvidia or AMD).

==== ReflectHost ====
Courtesy @bluefirestorm at [https://communities.vmware.com/message/2812499#2812499 setting *.vmx]

SMBIOS.reflectHost

Default is "FALSE". If set to "TRUE" some of the DMI info will use the host values (example: manufacturer will change from VMware to the host value). You can see this difference by using msinfo32 in Windows VM or dmidecode in Linux VM. This is not so useful anymore to hide the fact that the VM is a VM.

==== vmx.buildType ====
Courtesy @bluefirestorm at [https://communities.vmware.com/message/2812499#2812499 setting *.vmx]

vmx.buildType

Valid values are "release" and "debug". The "debug" is the default for the beta versions (aka Tech Preview). When set to "debug", vmware-vmx-debug.exe will be used instead of vmware-vmx.exe and the vmware.log file will be larger.

=== External sites ===

There's only one .vmx site that has most .vmx options and that's Ulli's reference over at sanbarrow:

http://sanbarrow.com/vmx/vmx-advanced.html

Vmx hacks

2021-12-08T01:41:26Z

Wila: /* Any platform */

=== VMX hacks ===

Here's my internal list of the .vmx hacks that I collected over time.

Beware that editing a .vmx file manually and adding any of these options is unsupported.

If you end up breaking your VM by editing the .vmx ... then restore the backup! (If you had no backups before hacking on your config, you are doing something wrong)

Also note that some options might no longer be active as they might be for an earlier version of a VMware product.

==== Wait 5 seconds on booting ====
Wait 5 seconds on booting:
bios.bootDelay = "5000"
Time is in milliseconds, change it accordingly.
==== Open BIOS settings on next boot ====
Open BIOS settings on next boot:
bios.forceSetupOnce = "TRUE"
In VMware Server 2, this setting is also in the web management interface, choose "Configure VM", power tabdialog, near the bottom.

[http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1648 Automatically Connecting USB Devices at Virtual Machine Power On]
==== Disable all Power menu and keyboard shortcuts====
gui.restricted="true"
This disables all power menu and keyboard shortcuts. It also disables suspend button

==== Fix repeating keys ====

To reduce these effects, increase the time threshold necessary for auto-repeat in the remote console.

Power off the virtual machine.
Add a line, similar to this, at the end of your virtual machine's configuration (.vmx) file:

keyboard.typematicMinDelay = "2000000"

The delay is specified in micro-seconds, so the line in the example above increases the repeat time to 2 seconds. This should ensure that you never get auto-repeat unless you intend it.

[http://kb.vmware.com/kb/196 Repeated characters when typing in remote console]

==== Disables suspend option ====
suspend.disabled = "TRUE"
This disables the suspend option in a virtual machine.

==== Fix Caps Lock synchronisation issues ====
This tip fixes the caps lock sync issue in Fusion 2.0.x and Tech Preview. I found it to be invaluable, add this to your VM's configuration file (.vmx):

mks.keyboard.syncLEDs = "TRUE"
==== Run a VM without a suspend file====
isn't there an option to run a VM without a suspend file (which is a file named like abcdef01-abcd-abcd-abcd-abcdef012345.vmem)
you mean
mainmem.useNamedFile = "false"
only works in windows

==== Use FT in a VM under Workstation ====
To use FT in a nested VM, you will still have to supply the entirely unsupported option (for the inner VM):

replay.allowBTOnly = "TRUE"

[http://communities.vmware.com/message/1343622 VMTN Anyone had sucess setting up a ESX40 Lab on Workstation 7.0?]

==== Disable VIX ====

An interesting tidbit if you’re super security cautious you can disable VIX by adding

“Guest.Command.Enabled”=”False”

to either the VM or the host. Be aware that this WILL break upgrading of VMware tools, and Guest customization as they both use vix as the underlying technology!

==== Optimize performance linux VM ====

mainmem.useNamedFile is no longer longer used on Linux hosts that run VMplayer 3 or Workstation 7.

New parameters are :
mainmem.backing = "swap"
mainmem.backing = "named"
mainmem.backing = "unnamed"

see http://sanbarrow.com/vmx/vmx-advanced.html#mainmem

==== Optimize troubleshooting ====
Please power off your VM and add the following configuration option to your .vmx file:
vmx.buildType = stats
Boot the VM and run your benchmark.
Shut down the VM and send me the contents of the stats directory that will be created in the same folder as the VM.

from: https://communities.vmware.com/message/2408159#2408159

==== Hardening your vmx file for security ====

http://virtualfoundry.blogspot.com/2009/04/hardening-vmx-file.html

==== Spurious APIC interrupt on CPU#1, should never happen ====

These messages are the result of an optimization Workstation 11 uses for inter-processor interrupts between virtual CPUs. The interrupt vector used for this purpose is 0xff, which is the Linux spurious APIC interrupt vector. In some cases, an inter-processor interrupt may arrive on a physical processor after Workstation has relinquished the processor to the host OS. Linux will discard the interrupt and print this message.

Unless these messages occur with high frequency, they should be innocuous.

The following configuration option should disable the optimization and make the messages stop:
monitor_control.disable_hostedIPI = TRUE

You can add this setting to /etc/vmware/config, and it will take effect for all VMs the next time they are powered on

from: [https://communities.vmware.com/message/2456565#2456565 Spurious APIC interrupt on CPU#1, should never happen]

==== CPU Masking ====

Yes, it is possible to mask the CPUID values in a VM (except for user mode code when using binary translation). However, masking only changes what CPUID reports; it doesn't change the way the processor behaves. Thus, masking may cause unexpected guest behavior.

The general format for CPUID masking is:

cpuid.<leaf>.<register> = xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx

The right hand side is a binary representation of the desired value, most significant bit first. Aside from '0' and '1,' two other important symbols are 'h,' which means to pass through the bit from the host CPUID and '-,' which means not to override the normal handling for this bit.

Specifying a different CPU vendor is not recommended.

from [https://communities.vmware.com/thread/405727 thread masking] Mr JMattson

In any event, the first thing to do is to pretend to be an AMD CPU. These settings should accomplish that:

cpuid.0.ebx = "0110:1000:0111:0100:0111:0101:0100:0001"
cpuid.0.ecx = "0100:0100:0100:1101:0100:0001:0110:0011"
cpuid.0.edx = "0110:1001:0111:0100:0110:1110:0110:0101"

Then you want to claim the family, model, and stepping of an actual AMD CPU. This setting should do that (claiming to be an early 64-bit Opteron):

cpuid.1.eax="----:0000:0000:0000:----:1111:0100:0110"

Even with these settings, some guests may still be unhappy.

=== Workstation ===

==== USB debugging ====

from [https://communities.vmware.com/message/2473661#2473661 Conversion from Workstation 10 to 11 breaks USB connections]
usb.quirks.device0 = "0x04e8:0x685b skip-reset"

==== USB Passthrough on Linux Host ====
'Passthrough' mode was disabled on Linux host as it conflicted with shared mode provided via pcscd

from [https://communities.vmware.com/message/2462510#2462510 Gemalto Smart Card Reader only appears as "Shared" not "Passthrough"]

* 1) Go to the VM's installation directory. Typically C:\Users\<username>\Documents\Virtual Machines\
* 2) Open <virtual-machine-name>.vmx file
* 3) Append the following lines:
usb.generic.allowCCID = "TRUE"
usb.ccid.disable = "TRUE"
* 4) Kill the process corresponding to the PCSC daemon on the Linux host

Do a # ps -ef | grep -i pcsc on your Linux host
sudo kill -9 <pid of the process that corresponds to pcscd>

Notes:
* 1) The first line in step 3 enables the passthrough mode
* 2) The second line in step 3 disables shared mode
* 3) Since you are killing the pcscd on your host, you wont be able to use the smart card on the host. You can passthrough the smart card now and use it in the VM

==== Change thumbnail speed ====

From Workstation 14 including 15, the thumbnail views are not in real time any more and the default refresh interval value is 3000 ms.

You can add

pref.thumbnailRefreshIntervalMs = 1000

(or other values) in the preference file %appdata%/vmware/preferences.ini to change the refesh rate. But keep in mind that this way may cause high CPU usage.

If you really need the previous real time thumbnail, you can use

pref.closeInactiveMKSWindows = "false"

But this way may cause mouse/keyboard functions under multi tabs not working well.

Both these settings are not documented or tested, so I cannot guarantee they working normally.

Note that you should make changes to the preferences.ini file with VMware Workstation shut down.

from: https://communities.vmware.com/message/2807350#2807350

==== Linux Host - switch back from Vulkan to X11 ====
Workstation 16.2.0 and higher

Add to .vmx if changing for one VM, or ~/.vmware/config if you want to change this systemwide:

mks.enableX11Presentation=TRUE
mks.enableVulkanPresentation=FALSE

That will force us to draw the window using X11 instead of Vulkan, which is normally less performant, but might work better on some setups?

from: [https://communities.vmware.com/t5/VMware-Workstation-Pro/VMware-16-2-1-Display-3D-acceleration-not-working-Windows-10/m-p/2877574#M172414 VMware 16.2.1 Display 3D acceleration not working Windows 10]

Has a great explanation on the difference by banackm

Beware that if you have this issue -and your host has more than one GPU- that it also might be because the wrong GPU was selected for Vulkan.

==== Dark Mode ====

In Workstation 16.2 Dark Mode had disappeared by accident, it was discovered that adding the following setting to the preferences.ini file makes it re-appear.

wsFeatureDarkModeSupported = "TRUE"

from: [https://communities.vmware.com/t5/VMware-Workstation-Pro/Vmware-Workstation-16-2-dark-mode/m-p/2874723/highlight/true#M172025 forum user mrdow2000]

==== All USB devices are disabled ====

Check your .vmx file for the following line:

usb.restrictions.defaultAllow = "FALSE"

If it has this then remove that line and try again.

It seems that this line is automatically added for Workstation/Player 16.2.x when using "Easy Setup".

More details here: [https://communities.vmware.com/t5/VMware-Workstation-Player/All-USB-devices-are-greyed-out/m-p/2878067#M37999 All USB devices are greyed out]

=== Fusion ===
==== Applying a setting over all VMs ====

Instead of editing each .vmx file manually, you can also apply config options to all VMs, by creating/editing the user global config file that can be found at: ~/Library/Preferences/VMware\ Fusion/config

There's already a 'preferences' file in the same directory, but normally the config file has to be created.

If an individual .vmx file contains the same config options as the global file, the .vmx file will take precedence.

==== Hide the Full Screen application menu ====

It's unsupported, but try editing /Users/$USER/Library/Preferences/VMware Fusion/preferences and add the line:

fusion.showFullScreenTitleBar = "FALSE"

See also: http://communities.vmware.com/message/1348663#1348663

==== Delay drop down Full Screen application menu ====

Edit /Users/$USER/Library/Preferences/VMware Fusion/preferences and add the line:

fusion.fullScreenMenuDelay = "2"

The delay is in seconds and the default is 1.5 seconds, added since Fusion 4.1
A value of "0" removes the delay.

See also: http://communities.vmware.com/message/2273022

On VMware Workstation you would add the following lines to the preferences.ini file.

pref.fullscreen.showDelay = "5000"
to delay the showing of the toolbar 5000ms (5 seconds)
pref.fullscreen.hideDelay = "1000"
to hide the toolbar after 1000ms (1 second)

For Win7 the preferences.ini file is located under:
C:\Users\<username>\AppData\Roaming\VMware

==== debug menu ====

fusion.enableDebugMenu

(never tried)

==== Turn off full screen autofit to host ====

Here's another way to stop the guest from automagically being resized at each swipe:

* Open Finder, select the "Go" menu then select "Go To Folder..." and type in: ~/Library/Preferences/VMware Fusion/
* Open the preferences file in a text editor and add/append the following lines at the end of the file:

pref.autoFitGuestToWindow = "FALSE"
pref.autoFitFullScreen = "stretchGuestToHost"

Taken from: https://communities.vmware.com/message/2293562

==== Pass through host model ====

It's unsupported, but try editing /Users/$USER/Library/Preferences/VMware Fusion/preferences and add the line:

hw.model.reflectHost = "TRUE"

This will cause the VM to see the same model ID as the host. The default for this option is FALSE. Be aware that using this option may cause VM portability issues since the guest may now depend on this behavior and the type of the underlying Mac.

See also: http://communities.vmware.com/thread/336922

==== VM power options always display "Force" ====

If the Virtual Machine was not originally created in VMware Fusion then you will notice that the Fusion Virtual Machine menu has the word "Force" inserted before any power option.
For example copying a VM from a Windows systems to Mac it displays the "Force ..." commands by default. In other words, pressing the Option Key is backwards of what it is supposed to be. This is because the following options are missing from the Virtual Machine's .vmx configuration file.

powerType.powerOff = "soft"
powerType.powerOn = "soft"
powerType.suspend = "soft"
powerType.reset = "soft"

By default, VMware Fusion creates these options in the Virtual Machine's .vmx configuration file while VMware Player/Workstation does not. So, add the above options to the Virtual Machine's .vmx configuration file and the "Force ..." commands will then exhibit VMware Fusion normal behavior. Meaning in order to access the "Force ..." commands one will need to press the Option Key.

See also: http://communities.vmware.com/thread/402281

==== kernel debugging ====

You can attach a remote debugger such as gdb to your vm to do kernel debugging.

DebugStub knows nothing at all about the guest OS. Think of debugStub as an In-Circuit Debugger for the virtual CPU(s).

debugStub.listen.guest64 = "TRUE"
debugStub.listen.guest64.remote = "TRUE"
debugStub.hideBreakpoints=1
specify a custom port with:
debugStub.port.guest64 = "8865"
other options:
debugStub.listen.guest32 = "TRUE" # Enable listener for 32 bit guest
debugStub.listen.guest32.remote = "TRUE" # Allow remote connection
debugStub.port.guest32 = "32001" # Listen on specified port NNN

see also: [https://communities.vmware.com/thread/470936 Using debugStub to debug a guest linux kernel]

==== Additional logging ====
For troubleshooting boot issues etcetera you can increase the log level in vmware.log

monitor_control.log_vmsample = "TRUE"

[https://communities.vmware.com/thread/471833 Fusion 6.0.2 / OS X 10.9.2 Host / OS X 10.9 Guest VM running >100% CPU no matter what]

==== memory hole ====

At 3.2 GB there's a 1024kB memory hole.

You can use the pciHole.start option to adjust the start of the memory hole, measured in megabytes from address 0x00000000. The default is

pciHole.start = 3072

which corresponds to 0xC0000000.

from [https://communities.vmware.com/thread/478739 Memory hole at 3.2GB]

==== Disable Shared Folder event notification ====

isolation.tools.hgfs.notify.enable = "FALSE"

See also: http://kb.vmware.com/kb/2011360

==== Shared folder size check ====

The other workaround is to stop the VM, edit the VM's .vmx file and add the following setting:

tools.hgfs.volumeInfoType = "max"

Then start the VM again, and this time you will not need to disable the other shares which are on smaller sized volumes.

The default setting causes the shares to be aggregated to the smallest volume size that a share resides on when our file system is queried for size and free space.

The above setting overrides this to pick the largest volume size. The downside is that you can start a copy to a share on volume with a smaller amount of free space and it will only fail when it actually fails to write when the free space is exhausted.

If you know you are not going to run into that type of scenario yourself or you verify prior to starting the copy operation then you will be fine.

Note, the above can only be set to "min" or "max" and if not set at all, then "min" is the default.

from: [https://communities.vmware.com/message/2381223#2381223 Folder copy on Windows 7 vm fails for "not enough space", but there is.]

==== Disable location services ====

sensor.location = "disable"

to vmx.

[https://communities.vmware.com/message/2383410#2383410 how-to disable location services]

==== Disable automatic USB connect to guest feature ====

1. Suspend or shut down any running VMs and quit Fusion.

2. Ensure that the vmware-usbarbitrator process is no longer running.

3. Create/edit the host-global configuration file, with root privileges: (this example uses nano, but feel free to use any other editor)

sudo nano /Library/Preferences/VMware\ Fusion/config

4. Add the following line to disable the automatic claiming of USB devices:

usbarb.autoconnect.claimAll = "FALSE"

5. Save the file and quit the editor.

With this change, all USB devices should automatically connect to the host even when VMs are running. Note that it will completely disable the USB connection prompt, and will prevent devices from automatically connecting to VMs (even if the option is selected in settings). However it should still be possible to manually connect USB devices to a running VM (except possibly in cases where the reset command is not correctly issued via the hub).

from: [https://communities.vmware.com/message/2393343#2393343 2014 Preview still has USB 3 hub issue]

==== Open file with host OS application ====
When a file is located on a shared folder (VMware HGFS) then you can choose to be able to open this file with the host OS default application.
For example. Your png file can open in macOS Preview.

proxyApps.publishToGuest = "TRUE"

See also: [https://communities.vmware.com/t5/VMware-Workstation-Pro/Has-there-ever-been-a-solution-to-opening-a-host-application/m-p/2841711/highlight/true#M169663 Has there ever been a solution to opening a host application from a guest OS?]

==== Pass OS X host serial number ====

If you want an OS X guest to use the host's serial number, you'll need to add this option to the VM's configuration:

serialNumber.reflectHost = "TRUE"

==== Pass OS X host hardware model ====

To pass hardware model to the guest (not even sure this works, as it does not seem to do anything for me, but ... Fusion does not error on starting the VM )

hw.model.reflectHost = "TRUE"

==== Pass OS X host hardware model ID ====

If you want an OS X guest to use the host's hardware model ID (i.e. "MacPro5,1"), board ID (i.e. "Mac-12345678") and serial number all together:

smbios.reflectHost = "TRUE"

=== Any platform ===

==== Disable scoreboard files ====

In VMware Fusion 12.2 and Workstation 16.2 new files have been introduced for keeping some sort of statistics.

These are called scoreboard files.

You can disable that feature.

vmx.scoreboard.enabled = "FALSE"

See: [https://communities.vmware.com/t5/VMware-Workstation-Pro/VMware-Workstation-16-2-0-and-scoreboard-files-What-it-is/m-p/2881784/highlight/true#M172906 Suggestion by DaveP on VMware Workstation 16.2.0 and .scoreboard files. What is it?]

==== Slow down time in guest ====

You can't quite stop time, but you can make it go extremely slowly. Set the following in your system-wide configuration file (/etc/vmware/config on Linux; C:\ProgramData\VMware\VMware Workstation\config.ini on Windows):

host.cpukHz = 1000

This is probably not all that useful in practice, unless the guest OS has no reliance on any time sources.

from [https://communities.vmware.com/message/2431592#2431592 System time]

==== Set max number of snapshots ====

snapshot.maxSnapshots = 100

==== Enable DX11 or OpenGL Host Renderer ====

Courtesy @bluefirestorm at [https://communities.vmware.com/message/2812499#2812499 setting *.vmx]

mks.enableDX11Renderer

When 3D accelerated graphics is enabled in Workstation 12/14/15 the default value is "TRUE" (i.e. the line does not have to be present in the vmx file), VMware Workstation uses DX11 of the Windows host to deliver the DX10/OpenGL 3.3 core profile capability inside the VMs. For Linux hosts, the equivalent is mks.enableGLRenderer = "TRUE"

==== Enable D3D Renderer ====
Courtesy @bluefirestorm at [https://communities.vmware.com/message/2812499#2812499 setting *.vmx]

mks.enableD3DRenderer

Default is "FALSE" from Workstation 12.x and later. This is only useful in version 12.x if the host graphics card does not have DX11 capability and setting this to TRUE and enableDX11Renderer to FALSE let the VM have some limited 3D accelerated graphics capability. This looks like is already ineffective in version 14/15.

==== Select host Graphics card to use ====
Courtesy @bluefirestorm at [https://communities.vmware.com/message/2812499#2812499 setting *.vmx]

mks.dx11.vendorID

valid values are the vendor ID of the graphic card, 0x8086 for Intel, 0x10DE for Nvidia, 0x1002 for AMD.

If this line is not present, VMware Workstation will use the default graphic card of the Windows host system. This line is useful if the system has two graphic cards from two different vendors that are simultaneously active on the host machine (example: Intel integrated graphics in the CPU and a discrete graphics card from Nvidia or AMD).

==== ReflectHost ====
Courtesy @bluefirestorm at [https://communities.vmware.com/message/2812499#2812499 setting *.vmx]

SMBIOS.reflectHost

Default is "FALSE". If set to "TRUE" some of the DMI info will use the host values (example: manufacturer will change from VMware to the host value). You can see this difference by using msinfo32 in Windows VM or dmidecode in Linux VM. This is not so useful anymore to hide the fact that the VM is a VM.

==== vmx.buildType ====
Courtesy @bluefirestorm at [https://communities.vmware.com/message/2812499#2812499 setting *.vmx]

vmx.buildType

Valid values are "release" and "debug". The "debug" is the default for the beta versions (aka Tech Preview). When set to "debug", vmware-vmx-debug.exe will be used instead of vmware-vmx.exe and the vmware.log file will be larger.

=== External sites ===

There's only one .vmx site that has most .vmx options and that's Ulli's reference over at sanbarrow:

http://sanbarrow.com/vmx/vmx-advanced.html

DOS

2021-11-27T19:03:16Z

Wila:

When creating a virtual machine with MS DOS (or PC Dos) then you'll notice that there are a few issues.

The first major issue being that the VM will run one of your cores with a high CPU.
The reason being that MS DOS did not idle your CPU when it wasn't doing nothing, so instead of having a VM that uses no CPU when not doing anything you have that 1 core going nuts.

The classical way to resolve that is by installing DosIdle.

As it doesn't appear to be available much, here's a copy.

[https://wiki.vi-toolkit.com/images/f/f2/DOS-Drivers.zip Dos Drivers download]

Other interesting notes for DOS users of VMware virtual machines:

* [https://communities.vmware.com/t5/VMware-Workstation-Pro-Documents/Sound-Blaster-16-on-VMware-Workstation-15-5-and-VMware-Fusion-11/ta-p/2781947 SoundBlaster 16 support] which has vastly improved thanks to Darius.

You also might want to check out Zamba's page here:

* http://www.scampers.org/steve/vmware/
and Ken Kato's pages here:

* https://sites.google.com/site/chitchatvmback/

See also: [[Windows 3.1]]

Windows 3.1

2021-11-27T19:02:48Z

Wila:

Some links:

http://www.stankowic-development.net/?p=6674&lang=en

[https://github.com/NattyNarwhal/vmwmouse VMware Mouse driver for Windows 3.x]

See also [[DOS]]

Windows 3.1

2021-11-27T18:53:24Z

Wila: Created page with " http://www.scampers.org/steve/vmware/#31pack http://www.stankowic-development.net/?p=6674&lang=en https://sites.google.com/site/chitchatvmback/misc [https://github.com/Nat..."

http://www.scampers.org/steve/vmware/#31pack

http://www.stankowic-development.net/?p=6674&lang=en

https://sites.google.com/site/chitchatvmback/misc

[https://github.com/NattyNarwhal/vmwmouse VMware Mouse driver for Windows 3.x]

Vmx hacks

2021-11-17T12:07:24Z

Wila: Note about multiple GPU's when having issues with Vulkan

=== VMX hacks ===

Here's my internal list of the .vmx hacks that I collected over time.

Beware that editing a .vmx file manually and adding any of these options is unsupported.

If you end up breaking your VM by editing the .vmx ... then restore the backup! (If you had no backups before hacking on your config, you are doing something wrong)

Also note that some options might no longer be active as they might be for an earlier version of a VMware product.

==== Wait 5 seconds on booting ====
Wait 5 seconds on booting:
bios.bootDelay = "5000"
Time is in milliseconds, change it accordingly.
==== Open BIOS settings on next boot ====
Open BIOS settings on next boot:
bios.forceSetupOnce = "TRUE"
In VMware Server 2, this setting is also in the web management interface, choose "Configure VM", power tabdialog, near the bottom.

[http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1648 Automatically Connecting USB Devices at Virtual Machine Power On]
==== Disable all Power menu and keyboard shortcuts====
gui.restricted="true"
This disables all power menu and keyboard shortcuts. It also disables suspend button

==== Fix repeating keys ====

To reduce these effects, increase the time threshold necessary for auto-repeat in the remote console.

Power off the virtual machine.
Add a line, similar to this, at the end of your virtual machine's configuration (.vmx) file:

keyboard.typematicMinDelay = "2000000"

The delay is specified in micro-seconds, so the line in the example above increases the repeat time to 2 seconds. This should ensure that you never get auto-repeat unless you intend it.

[http://kb.vmware.com/kb/196 Repeated characters when typing in remote console]

==== Disables suspend option ====
suspend.disabled = "TRUE"
This disables the suspend option in a virtual machine.

==== Fix Caps Lock synchronisation issues ====
This tip fixes the caps lock sync issue in Fusion 2.0.x and Tech Preview. I found it to be invaluable, add this to your VM's configuration file (.vmx):

mks.keyboard.syncLEDs = "TRUE"
==== Run a VM without a suspend file====
isn't there an option to run a VM without a suspend file (which is a file named like abcdef01-abcd-abcd-abcd-abcdef012345.vmem)
you mean
mainmem.useNamedFile = "false"
only works in windows

==== Use FT in a VM under Workstation ====
To use FT in a nested VM, you will still have to supply the entirely unsupported option (for the inner VM):

replay.allowBTOnly = "TRUE"

[http://communities.vmware.com/message/1343622 VMTN Anyone had sucess setting up a ESX40 Lab on Workstation 7.0?]

==== Disable VIX ====

An interesting tidbit if you’re super security cautious you can disable VIX by adding

“Guest.Command.Enabled”=”False”

to either the VM or the host. Be aware that this WILL break upgrading of VMware tools, and Guest customization as they both use vix as the underlying technology!

==== Optimize performance linux VM ====

mainmem.useNamedFile is no longer longer used on Linux hosts that run VMplayer 3 or Workstation 7.

New parameters are :
mainmem.backing = "swap"
mainmem.backing = "named"
mainmem.backing = "unnamed"

see http://sanbarrow.com/vmx/vmx-advanced.html#mainmem

==== Optimize troubleshooting ====
Please power off your VM and add the following configuration option to your .vmx file:
vmx.buildType = stats
Boot the VM and run your benchmark.
Shut down the VM and send me the contents of the stats directory that will be created in the same folder as the VM.

from: https://communities.vmware.com/message/2408159#2408159

==== Hardening your vmx file for security ====

http://virtualfoundry.blogspot.com/2009/04/hardening-vmx-file.html

==== Spurious APIC interrupt on CPU#1, should never happen ====

These messages are the result of an optimization Workstation 11 uses for inter-processor interrupts between virtual CPUs. The interrupt vector used for this purpose is 0xff, which is the Linux spurious APIC interrupt vector. In some cases, an inter-processor interrupt may arrive on a physical processor after Workstation has relinquished the processor to the host OS. Linux will discard the interrupt and print this message.

Unless these messages occur with high frequency, they should be innocuous.

The following configuration option should disable the optimization and make the messages stop:
monitor_control.disable_hostedIPI = TRUE

You can add this setting to /etc/vmware/config, and it will take effect for all VMs the next time they are powered on

from: [https://communities.vmware.com/message/2456565#2456565 Spurious APIC interrupt on CPU#1, should never happen]

==== CPU Masking ====

Yes, it is possible to mask the CPUID values in a VM (except for user mode code when using binary translation). However, masking only changes what CPUID reports; it doesn't change the way the processor behaves. Thus, masking may cause unexpected guest behavior.

The general format for CPUID masking is:

cpuid.<leaf>.<register> = xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx

The right hand side is a binary representation of the desired value, most significant bit first. Aside from '0' and '1,' two other important symbols are 'h,' which means to pass through the bit from the host CPUID and '-,' which means not to override the normal handling for this bit.

Specifying a different CPU vendor is not recommended.

from [https://communities.vmware.com/thread/405727 thread masking] Mr JMattson

In any event, the first thing to do is to pretend to be an AMD CPU. These settings should accomplish that:

cpuid.0.ebx = "0110:1000:0111:0100:0111:0101:0100:0001"
cpuid.0.ecx = "0100:0100:0100:1101:0100:0001:0110:0011"
cpuid.0.edx = "0110:1001:0111:0100:0110:1110:0110:0101"

Then you want to claim the family, model, and stepping of an actual AMD CPU. This setting should do that (claiming to be an early 64-bit Opteron):

cpuid.1.eax="----:0000:0000:0000:----:1111:0100:0110"

Even with these settings, some guests may still be unhappy.

=== Workstation ===

==== USB debugging ====

from [https://communities.vmware.com/message/2473661#2473661 Conversion from Workstation 10 to 11 breaks USB connections]
usb.quirks.device0 = "0x04e8:0x685b skip-reset"

==== USB Passthrough on Linux Host ====
'Passthrough' mode was disabled on Linux host as it conflicted with shared mode provided via pcscd

from [https://communities.vmware.com/message/2462510#2462510 Gemalto Smart Card Reader only appears as "Shared" not "Passthrough"]

* 1) Go to the VM's installation directory. Typically C:\Users\<username>\Documents\Virtual Machines\
* 2) Open <virtual-machine-name>.vmx file
* 3) Append the following lines:
usb.generic.allowCCID = "TRUE"
usb.ccid.disable = "TRUE"
* 4) Kill the process corresponding to the PCSC daemon on the Linux host

Do a # ps -ef | grep -i pcsc on your Linux host
sudo kill -9 <pid of the process that corresponds to pcscd>

Notes:
* 1) The first line in step 3 enables the passthrough mode
* 2) The second line in step 3 disables shared mode
* 3) Since you are killing the pcscd on your host, you wont be able to use the smart card on the host. You can passthrough the smart card now and use it in the VM

==== Change thumbnail speed ====

From Workstation 14 including 15, the thumbnail views are not in real time any more and the default refresh interval value is 3000 ms.

You can add

pref.thumbnailRefreshIntervalMs = 1000

(or other values) in the preference file %appdata%/vmware/preferences.ini to change the refesh rate. But keep in mind that this way may cause high CPU usage.

If you really need the previous real time thumbnail, you can use

pref.closeInactiveMKSWindows = "false"

But this way may cause mouse/keyboard functions under multi tabs not working well.

Both these settings are not documented or tested, so I cannot guarantee they working normally.

Note that you should make changes to the preferences.ini file with VMware Workstation shut down.

from: https://communities.vmware.com/message/2807350#2807350

==== Linux Host - switch back from Vulkan to X11 ====
Workstation 16.2.0 and higher

Add to .vmx if changing for one VM, or ~/.vmware/config if you want to change this systemwide:

mks.enableX11Presentation=TRUE
mks.enableVulkanPresentation=FALSE

That will force us to draw the window using X11 instead of Vulkan, which is normally less performant, but might work better on some setups?

from: [https://communities.vmware.com/t5/VMware-Workstation-Pro/VMware-16-2-1-Display-3D-acceleration-not-working-Windows-10/m-p/2877574#M172414 VMware 16.2.1 Display 3D acceleration not working Windows 10]

Has a great explanation on the difference by banackm

Beware that if you have this issue -and your host has more than one GPU- that it also might be because the wrong GPU was selected for Vulkan.

==== Dark Mode ====

In Workstation 16.2 Dark Mode had disappeared by accident, it was discovered that adding the following setting to the preferences.ini file makes it re-appear.

wsFeatureDarkModeSupported = "TRUE"

from: [https://communities.vmware.com/t5/VMware-Workstation-Pro/Vmware-Workstation-16-2-dark-mode/m-p/2874723/highlight/true#M172025 forum user mrdow2000]

==== All USB devices are disabled ====

Check your .vmx file for the following line:

usb.restrictions.defaultAllow = "FALSE"

If it has this then remove that line and try again.

It seems that this line is automatically added for Workstation/Player 16.2.x when using "Easy Setup".

More details here: [https://communities.vmware.com/t5/VMware-Workstation-Player/All-USB-devices-are-greyed-out/m-p/2878067#M37999 All USB devices are greyed out]

=== Fusion ===
==== Applying a setting over all VMs ====

Instead of editing each .vmx file manually, you can also apply config options to all VMs, by creating/editing the user global config file that can be found at: ~/Library/Preferences/VMware\ Fusion/config

There's already a 'preferences' file in the same directory, but normally the config file has to be created.

If an individual .vmx file contains the same config options as the global file, the .vmx file will take precedence.

==== Hide the Full Screen application menu ====

It's unsupported, but try editing /Users/$USER/Library/Preferences/VMware Fusion/preferences and add the line:

fusion.showFullScreenTitleBar = "FALSE"

See also: http://communities.vmware.com/message/1348663#1348663

==== Delay drop down Full Screen application menu ====

Edit /Users/$USER/Library/Preferences/VMware Fusion/preferences and add the line:

fusion.fullScreenMenuDelay = "2"

The delay is in seconds and the default is 1.5 seconds, added since Fusion 4.1
A value of "0" removes the delay.

See also: http://communities.vmware.com/message/2273022

On VMware Workstation you would add the following lines to the preferences.ini file.

pref.fullscreen.showDelay = "5000"
to delay the showing of the toolbar 5000ms (5 seconds)
pref.fullscreen.hideDelay = "1000"
to hide the toolbar after 1000ms (1 second)

For Win7 the preferences.ini file is located under:
C:\Users\<username>\AppData\Roaming\VMware

==== debug menu ====

fusion.enableDebugMenu

(never tried)

==== Turn off full screen autofit to host ====

Here's another way to stop the guest from automagically being resized at each swipe:

* Open Finder, select the "Go" menu then select "Go To Folder..." and type in: ~/Library/Preferences/VMware Fusion/
* Open the preferences file in a text editor and add/append the following lines at the end of the file:

pref.autoFitGuestToWindow = "FALSE"
pref.autoFitFullScreen = "stretchGuestToHost"

Taken from: https://communities.vmware.com/message/2293562

==== Pass through host model ====

It's unsupported, but try editing /Users/$USER/Library/Preferences/VMware Fusion/preferences and add the line:

hw.model.reflectHost = "TRUE"

This will cause the VM to see the same model ID as the host. The default for this option is FALSE. Be aware that using this option may cause VM portability issues since the guest may now depend on this behavior and the type of the underlying Mac.

See also: http://communities.vmware.com/thread/336922

==== VM power options always display "Force" ====

If the Virtual Machine was not originally created in VMware Fusion then you will notice that the Fusion Virtual Machine menu has the word "Force" inserted before any power option.
For example copying a VM from a Windows systems to Mac it displays the "Force ..." commands by default. In other words, pressing the Option Key is backwards of what it is supposed to be. This is because the following options are missing from the Virtual Machine's .vmx configuration file.

powerType.powerOff = "soft"
powerType.powerOn = "soft"
powerType.suspend = "soft"
powerType.reset = "soft"

By default, VMware Fusion creates these options in the Virtual Machine's .vmx configuration file while VMware Player/Workstation does not. So, add the above options to the Virtual Machine's .vmx configuration file and the "Force ..." commands will then exhibit VMware Fusion normal behavior. Meaning in order to access the "Force ..." commands one will need to press the Option Key.

See also: http://communities.vmware.com/thread/402281

==== kernel debugging ====

You can attach a remote debugger such as gdb to your vm to do kernel debugging.

DebugStub knows nothing at all about the guest OS. Think of debugStub as an In-Circuit Debugger for the virtual CPU(s).

debugStub.listen.guest64 = "TRUE"
debugStub.listen.guest64.remote = "TRUE"
debugStub.hideBreakpoints=1
specify a custom port with:
debugStub.port.guest64 = "8865"
other options:
debugStub.listen.guest32 = "TRUE" # Enable listener for 32 bit guest
debugStub.listen.guest32.remote = "TRUE" # Allow remote connection
debugStub.port.guest32 = "32001" # Listen on specified port NNN

see also: [https://communities.vmware.com/thread/470936 Using debugStub to debug a guest linux kernel]

==== Additional logging ====
For troubleshooting boot issues etcetera you can increase the log level in vmware.log

monitor_control.log_vmsample = "TRUE"

[https://communities.vmware.com/thread/471833 Fusion 6.0.2 / OS X 10.9.2 Host / OS X 10.9 Guest VM running >100% CPU no matter what]

==== memory hole ====

At 3.2 GB there's a 1024kB memory hole.

You can use the pciHole.start option to adjust the start of the memory hole, measured in megabytes from address 0x00000000. The default is

pciHole.start = 3072

which corresponds to 0xC0000000.

from [https://communities.vmware.com/thread/478739 Memory hole at 3.2GB]

==== Disable Shared Folder event notification ====

isolation.tools.hgfs.notify.enable = "FALSE"

See also: http://kb.vmware.com/kb/2011360

==== Shared folder size check ====

The other workaround is to stop the VM, edit the VM's .vmx file and add the following setting:

tools.hgfs.volumeInfoType = "max"

Then start the VM again, and this time you will not need to disable the other shares which are on smaller sized volumes.

The default setting causes the shares to be aggregated to the smallest volume size that a share resides on when our file system is queried for size and free space.

The above setting overrides this to pick the largest volume size. The downside is that you can start a copy to a share on volume with a smaller amount of free space and it will only fail when it actually fails to write when the free space is exhausted.

If you know you are not going to run into that type of scenario yourself or you verify prior to starting the copy operation then you will be fine.

Note, the above can only be set to "min" or "max" and if not set at all, then "min" is the default.

from: [https://communities.vmware.com/message/2381223#2381223 Folder copy on Windows 7 vm fails for "not enough space", but there is.]

==== Disable location services ====

sensor.location = "disable"

to vmx.

[https://communities.vmware.com/message/2383410#2383410 how-to disable location services]

==== Disable automatic USB connect to guest feature ====

1. Suspend or shut down any running VMs and quit Fusion.

2. Ensure that the vmware-usbarbitrator process is no longer running.

3. Create/edit the host-global configuration file, with root privileges: (this example uses nano, but feel free to use any other editor)

sudo nano /Library/Preferences/VMware\ Fusion/config

4. Add the following line to disable the automatic claiming of USB devices:

usbarb.autoconnect.claimAll = "FALSE"

5. Save the file and quit the editor.

With this change, all USB devices should automatically connect to the host even when VMs are running. Note that it will completely disable the USB connection prompt, and will prevent devices from automatically connecting to VMs (even if the option is selected in settings). However it should still be possible to manually connect USB devices to a running VM (except possibly in cases where the reset command is not correctly issued via the hub).

from: [https://communities.vmware.com/message/2393343#2393343 2014 Preview still has USB 3 hub issue]

==== Open file with host OS application ====
When a file is located on a shared folder (VMware HGFS) then you can choose to be able to open this file with the host OS default application.
For example. Your png file can open in macOS Preview.

proxyApps.publishToGuest = "TRUE"

See also: [https://communities.vmware.com/t5/VMware-Workstation-Pro/Has-there-ever-been-a-solution-to-opening-a-host-application/m-p/2841711/highlight/true#M169663 Has there ever been a solution to opening a host application from a guest OS?]

==== Pass OS X host serial number ====

If you want an OS X guest to use the host's serial number, you'll need to add this option to the VM's configuration:

serialNumber.reflectHost = "TRUE"

==== Pass OS X host hardware model ====

To pass hardware model to the guest (not even sure this works, as it does not seem to do anything for me, but ... Fusion does not error on starting the VM )

hw.model.reflectHost = "TRUE"

==== Pass OS X host hardware model ID ====

If you want an OS X guest to use the host's hardware model ID (i.e. "MacPro5,1"), board ID (i.e. "Mac-12345678") and serial number all together:

smbios.reflectHost = "TRUE"

=== Any platform ===

==== Slow down time in guest ====

You can't quite stop time, but you can make it go extremely slowly. Set the following in your system-wide configuration file (/etc/vmware/config on Linux; C:\ProgramData\VMware\VMware Workstation\config.ini on Windows):

host.cpukHz = 1000

This is probably not all that useful in practice, unless the guest OS has no reliance on any time sources.

from [https://communities.vmware.com/message/2431592#2431592 System time]

==== Set max number of snapshots ====

snapshot.maxSnapshots = 100

==== Enable DX11 or OpenGL Host Renderer ====

Courtesy @bluefirestorm at [https://communities.vmware.com/message/2812499#2812499 setting *.vmx]

mks.enableDX11Renderer

When 3D accelerated graphics is enabled in Workstation 12/14/15 the default value is "TRUE" (i.e. the line does not have to be present in the vmx file), VMware Workstation uses DX11 of the Windows host to deliver the DX10/OpenGL 3.3 core profile capability inside the VMs. For Linux hosts, the equivalent is mks.enableGLRenderer = "TRUE"

==== Enable D3D Renderer ====
Courtesy @bluefirestorm at [https://communities.vmware.com/message/2812499#2812499 setting *.vmx]

mks.enableD3DRenderer

Default is "FALSE" from Workstation 12.x and later. This is only useful in version 12.x if the host graphics card does not have DX11 capability and setting this to TRUE and enableDX11Renderer to FALSE let the VM have some limited 3D accelerated graphics capability. This looks like is already ineffective in version 14/15.

==== Select host Graphics card to use ====
Courtesy @bluefirestorm at [https://communities.vmware.com/message/2812499#2812499 setting *.vmx]

mks.dx11.vendorID

valid values are the vendor ID of the graphic card, 0x8086 for Intel, 0x10DE for Nvidia, 0x1002 for AMD.

If this line is not present, VMware Workstation will use the default graphic card of the Windows host system. This line is useful if the system has two graphic cards from two different vendors that are simultaneously active on the host machine (example: Intel integrated graphics in the CPU and a discrete graphics card from Nvidia or AMD).

==== ReflectHost ====
Courtesy @bluefirestorm at [https://communities.vmware.com/message/2812499#2812499 setting *.vmx]

SMBIOS.reflectHost

Default is "FALSE". If set to "TRUE" some of the DMI info will use the host values (example: manufacturer will change from VMware to the host value). You can see this difference by using msinfo32 in Windows VM or dmidecode in Linux VM. This is not so useful anymore to hide the fact that the VM is a VM.

==== vmx.buildType ====
Courtesy @bluefirestorm at [https://communities.vmware.com/message/2812499#2812499 setting *.vmx]

vmx.buildType

Valid values are "release" and "debug". The "debug" is the default for the beta versions (aka Tech Preview). When set to "debug", vmware-vmx-debug.exe will be used instead of vmware-vmx.exe and the vmware.log file will be larger.

=== External sites ===

There's only one .vmx site that has most .vmx options and that's Ulli's reference over at sanbarrow:

http://sanbarrow.com/vmx/vmx-advanced.html

Vmx hacks

2021-11-17T12:05:09Z

Wila: Disable all USB devices

=== VMX hacks ===

Here's my internal list of the .vmx hacks that I collected over time.

Beware that editing a .vmx file manually and adding any of these options is unsupported.

If you end up breaking your VM by editing the .vmx ... then restore the backup! (If you had no backups before hacking on your config, you are doing something wrong)

Also note that some options might no longer be active as they might be for an earlier version of a VMware product.

==== Wait 5 seconds on booting ====
Wait 5 seconds on booting:
bios.bootDelay = "5000"
Time is in milliseconds, change it accordingly.
==== Open BIOS settings on next boot ====
Open BIOS settings on next boot:
bios.forceSetupOnce = "TRUE"
In VMware Server 2, this setting is also in the web management interface, choose "Configure VM", power tabdialog, near the bottom.

[http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1648 Automatically Connecting USB Devices at Virtual Machine Power On]
==== Disable all Power menu and keyboard shortcuts====
gui.restricted="true"
This disables all power menu and keyboard shortcuts. It also disables suspend button

==== Fix repeating keys ====

To reduce these effects, increase the time threshold necessary for auto-repeat in the remote console.

Power off the virtual machine.
Add a line, similar to this, at the end of your virtual machine's configuration (.vmx) file:

keyboard.typematicMinDelay = "2000000"

The delay is specified in micro-seconds, so the line in the example above increases the repeat time to 2 seconds. This should ensure that you never get auto-repeat unless you intend it.

[http://kb.vmware.com/kb/196 Repeated characters when typing in remote console]

==== Disables suspend option ====
suspend.disabled = "TRUE"
This disables the suspend option in a virtual machine.

==== Fix Caps Lock synchronisation issues ====
This tip fixes the caps lock sync issue in Fusion 2.0.x and Tech Preview. I found it to be invaluable, add this to your VM's configuration file (.vmx):

mks.keyboard.syncLEDs = "TRUE"
==== Run a VM without a suspend file====
isn't there an option to run a VM without a suspend file (which is a file named like abcdef01-abcd-abcd-abcd-abcdef012345.vmem)
you mean
mainmem.useNamedFile = "false"
only works in windows

==== Use FT in a VM under Workstation ====
To use FT in a nested VM, you will still have to supply the entirely unsupported option (for the inner VM):

replay.allowBTOnly = "TRUE"

[http://communities.vmware.com/message/1343622 VMTN Anyone had sucess setting up a ESX40 Lab on Workstation 7.0?]

==== Disable VIX ====

An interesting tidbit if you’re super security cautious you can disable VIX by adding

“Guest.Command.Enabled”=”False”

to either the VM or the host. Be aware that this WILL break upgrading of VMware tools, and Guest customization as they both use vix as the underlying technology!

==== Optimize performance linux VM ====

mainmem.useNamedFile is no longer longer used on Linux hosts that run VMplayer 3 or Workstation 7.

New parameters are :
mainmem.backing = "swap"
mainmem.backing = "named"
mainmem.backing = "unnamed"

see http://sanbarrow.com/vmx/vmx-advanced.html#mainmem

==== Optimize troubleshooting ====
Please power off your VM and add the following configuration option to your .vmx file:
vmx.buildType = stats
Boot the VM and run your benchmark.
Shut down the VM and send me the contents of the stats directory that will be created in the same folder as the VM.

from: https://communities.vmware.com/message/2408159#2408159

==== Hardening your vmx file for security ====

http://virtualfoundry.blogspot.com/2009/04/hardening-vmx-file.html

==== Spurious APIC interrupt on CPU#1, should never happen ====

These messages are the result of an optimization Workstation 11 uses for inter-processor interrupts between virtual CPUs. The interrupt vector used for this purpose is 0xff, which is the Linux spurious APIC interrupt vector. In some cases, an inter-processor interrupt may arrive on a physical processor after Workstation has relinquished the processor to the host OS. Linux will discard the interrupt and print this message.

Unless these messages occur with high frequency, they should be innocuous.

The following configuration option should disable the optimization and make the messages stop:
monitor_control.disable_hostedIPI = TRUE

You can add this setting to /etc/vmware/config, and it will take effect for all VMs the next time they are powered on

from: [https://communities.vmware.com/message/2456565#2456565 Spurious APIC interrupt on CPU#1, should never happen]

==== CPU Masking ====

Yes, it is possible to mask the CPUID values in a VM (except for user mode code when using binary translation). However, masking only changes what CPUID reports; it doesn't change the way the processor behaves. Thus, masking may cause unexpected guest behavior.

The general format for CPUID masking is:

cpuid.<leaf>.<register> = xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx

The right hand side is a binary representation of the desired value, most significant bit first. Aside from '0' and '1,' two other important symbols are 'h,' which means to pass through the bit from the host CPUID and '-,' which means not to override the normal handling for this bit.

Specifying a different CPU vendor is not recommended.

from [https://communities.vmware.com/thread/405727 thread masking] Mr JMattson

In any event, the first thing to do is to pretend to be an AMD CPU. These settings should accomplish that:

cpuid.0.ebx = "0110:1000:0111:0100:0111:0101:0100:0001"
cpuid.0.ecx = "0100:0100:0100:1101:0100:0001:0110:0011"
cpuid.0.edx = "0110:1001:0111:0100:0110:1110:0110:0101"

Then you want to claim the family, model, and stepping of an actual AMD CPU. This setting should do that (claiming to be an early 64-bit Opteron):

cpuid.1.eax="----:0000:0000:0000:----:1111:0100:0110"

Even with these settings, some guests may still be unhappy.

=== Workstation ===

==== USB debugging ====

from [https://communities.vmware.com/message/2473661#2473661 Conversion from Workstation 10 to 11 breaks USB connections]
usb.quirks.device0 = "0x04e8:0x685b skip-reset"

==== USB Passthrough on Linux Host ====
'Passthrough' mode was disabled on Linux host as it conflicted with shared mode provided via pcscd

from [https://communities.vmware.com/message/2462510#2462510 Gemalto Smart Card Reader only appears as "Shared" not "Passthrough"]

* 1) Go to the VM's installation directory. Typically C:\Users\<username>\Documents\Virtual Machines\
* 2) Open <virtual-machine-name>.vmx file
* 3) Append the following lines:
usb.generic.allowCCID = "TRUE"
usb.ccid.disable = "TRUE"
* 4) Kill the process corresponding to the PCSC daemon on the Linux host

Do a # ps -ef | grep -i pcsc on your Linux host
sudo kill -9 <pid of the process that corresponds to pcscd>

Notes:
* 1) The first line in step 3 enables the passthrough mode
* 2) The second line in step 3 disables shared mode
* 3) Since you are killing the pcscd on your host, you wont be able to use the smart card on the host. You can passthrough the smart card now and use it in the VM

==== Change thumbnail speed ====

From Workstation 14 including 15, the thumbnail views are not in real time any more and the default refresh interval value is 3000 ms.

You can add

pref.thumbnailRefreshIntervalMs = 1000

(or other values) in the preference file %appdata%/vmware/preferences.ini to change the refesh rate. But keep in mind that this way may cause high CPU usage.

If you really need the previous real time thumbnail, you can use

pref.closeInactiveMKSWindows = "false"

But this way may cause mouse/keyboard functions under multi tabs not working well.

Both these settings are not documented or tested, so I cannot guarantee they working normally.

Note that you should make changes to the preferences.ini file with VMware Workstation shut down.

from: https://communities.vmware.com/message/2807350#2807350

==== Linux Host - switch back from Vulkan to X11 ====
Workstation 16.2.0 and higher

Add to .vmx if changing for one VM, or ~/.vmware/config if you want to change this systemwide:

mks.enableX11Presentation=TRUE
mks.enableVulkanPresentation=FALSE

That will force us to draw the window using X11 instead of Vulkan, which is normally less performant, but might work better on some setups?

from: [https://communities.vmware.com/t5/VMware-Workstation-Pro/VMware-16-2-1-Display-3D-acceleration-not-working-Windows-10/m-p/2877574#M172414 VMware 16.2.1 Display 3D acceleration not working Windows 10]

Has a great explanation on the difference by banackm

==== Dark Mode ====

In Workstation 16.2 Dark Mode had disappeared by accident, it was discovered that adding the following setting to the preferences.ini file makes it re-appear.

wsFeatureDarkModeSupported = "TRUE"

from: [https://communities.vmware.com/t5/VMware-Workstation-Pro/Vmware-Workstation-16-2-dark-mode/m-p/2874723/highlight/true#M172025 forum user mrdow2000]

==== All USB devices are disabled ====

Check your .vmx file for the following line:

usb.restrictions.defaultAllow = "FALSE"

If it has this then remove that line and try again.

It seems that this line is automatically added for Workstation/Player 16.2.x when using "Easy Setup".

More details here: [https://communities.vmware.com/t5/VMware-Workstation-Player/All-USB-devices-are-greyed-out/m-p/2878067#M37999 All USB devices are greyed out]

=== Fusion ===
==== Applying a setting over all VMs ====

Instead of editing each .vmx file manually, you can also apply config options to all VMs, by creating/editing the user global config file that can be found at: ~/Library/Preferences/VMware\ Fusion/config

There's already a 'preferences' file in the same directory, but normally the config file has to be created.

If an individual .vmx file contains the same config options as the global file, the .vmx file will take precedence.

==== Hide the Full Screen application menu ====

It's unsupported, but try editing /Users/$USER/Library/Preferences/VMware Fusion/preferences and add the line:

fusion.showFullScreenTitleBar = "FALSE"

See also: http://communities.vmware.com/message/1348663#1348663

==== Delay drop down Full Screen application menu ====

Edit /Users/$USER/Library/Preferences/VMware Fusion/preferences and add the line:

fusion.fullScreenMenuDelay = "2"

The delay is in seconds and the default is 1.5 seconds, added since Fusion 4.1
A value of "0" removes the delay.

See also: http://communities.vmware.com/message/2273022

On VMware Workstation you would add the following lines to the preferences.ini file.

pref.fullscreen.showDelay = "5000"
to delay the showing of the toolbar 5000ms (5 seconds)
pref.fullscreen.hideDelay = "1000"
to hide the toolbar after 1000ms (1 second)

For Win7 the preferences.ini file is located under:
C:\Users\<username>\AppData\Roaming\VMware

==== debug menu ====

fusion.enableDebugMenu

(never tried)

==== Turn off full screen autofit to host ====

Here's another way to stop the guest from automagically being resized at each swipe:

* Open Finder, select the "Go" menu then select "Go To Folder..." and type in: ~/Library/Preferences/VMware Fusion/
* Open the preferences file in a text editor and add/append the following lines at the end of the file:

pref.autoFitGuestToWindow = "FALSE"
pref.autoFitFullScreen = "stretchGuestToHost"

Taken from: https://communities.vmware.com/message/2293562

==== Pass through host model ====

It's unsupported, but try editing /Users/$USER/Library/Preferences/VMware Fusion/preferences and add the line:

hw.model.reflectHost = "TRUE"

This will cause the VM to see the same model ID as the host. The default for this option is FALSE. Be aware that using this option may cause VM portability issues since the guest may now depend on this behavior and the type of the underlying Mac.

See also: http://communities.vmware.com/thread/336922

==== VM power options always display "Force" ====

If the Virtual Machine was not originally created in VMware Fusion then you will notice that the Fusion Virtual Machine menu has the word "Force" inserted before any power option.
For example copying a VM from a Windows systems to Mac it displays the "Force ..." commands by default. In other words, pressing the Option Key is backwards of what it is supposed to be. This is because the following options are missing from the Virtual Machine's .vmx configuration file.

powerType.powerOff = "soft"
powerType.powerOn = "soft"
powerType.suspend = "soft"
powerType.reset = "soft"

By default, VMware Fusion creates these options in the Virtual Machine's .vmx configuration file while VMware Player/Workstation does not. So, add the above options to the Virtual Machine's .vmx configuration file and the "Force ..." commands will then exhibit VMware Fusion normal behavior. Meaning in order to access the "Force ..." commands one will need to press the Option Key.

See also: http://communities.vmware.com/thread/402281

==== kernel debugging ====

You can attach a remote debugger such as gdb to your vm to do kernel debugging.

DebugStub knows nothing at all about the guest OS. Think of debugStub as an In-Circuit Debugger for the virtual CPU(s).

debugStub.listen.guest64 = "TRUE"
debugStub.listen.guest64.remote = "TRUE"
debugStub.hideBreakpoints=1
specify a custom port with:
debugStub.port.guest64 = "8865"
other options:
debugStub.listen.guest32 = "TRUE" # Enable listener for 32 bit guest
debugStub.listen.guest32.remote = "TRUE" # Allow remote connection
debugStub.port.guest32 = "32001" # Listen on specified port NNN

see also: [https://communities.vmware.com/thread/470936 Using debugStub to debug a guest linux kernel]

==== Additional logging ====
For troubleshooting boot issues etcetera you can increase the log level in vmware.log

monitor_control.log_vmsample = "TRUE"

[https://communities.vmware.com/thread/471833 Fusion 6.0.2 / OS X 10.9.2 Host / OS X 10.9 Guest VM running >100% CPU no matter what]

==== memory hole ====

At 3.2 GB there's a 1024kB memory hole.

You can use the pciHole.start option to adjust the start of the memory hole, measured in megabytes from address 0x00000000. The default is

pciHole.start = 3072

which corresponds to 0xC0000000.

from [https://communities.vmware.com/thread/478739 Memory hole at 3.2GB]

==== Disable Shared Folder event notification ====

isolation.tools.hgfs.notify.enable = "FALSE"

See also: http://kb.vmware.com/kb/2011360

==== Shared folder size check ====

The other workaround is to stop the VM, edit the VM's .vmx file and add the following setting:

tools.hgfs.volumeInfoType = "max"

Then start the VM again, and this time you will not need to disable the other shares which are on smaller sized volumes.

The default setting causes the shares to be aggregated to the smallest volume size that a share resides on when our file system is queried for size and free space.

The above setting overrides this to pick the largest volume size. The downside is that you can start a copy to a share on volume with a smaller amount of free space and it will only fail when it actually fails to write when the free space is exhausted.

If you know you are not going to run into that type of scenario yourself or you verify prior to starting the copy operation then you will be fine.

Note, the above can only be set to "min" or "max" and if not set at all, then "min" is the default.

from: [https://communities.vmware.com/message/2381223#2381223 Folder copy on Windows 7 vm fails for "not enough space", but there is.]

==== Disable location services ====

sensor.location = "disable"

to vmx.

[https://communities.vmware.com/message/2383410#2383410 how-to disable location services]

==== Disable automatic USB connect to guest feature ====

1. Suspend or shut down any running VMs and quit Fusion.

2. Ensure that the vmware-usbarbitrator process is no longer running.

3. Create/edit the host-global configuration file, with root privileges: (this example uses nano, but feel free to use any other editor)

sudo nano /Library/Preferences/VMware\ Fusion/config

4. Add the following line to disable the automatic claiming of USB devices:

usbarb.autoconnect.claimAll = "FALSE"

5. Save the file and quit the editor.

With this change, all USB devices should automatically connect to the host even when VMs are running. Note that it will completely disable the USB connection prompt, and will prevent devices from automatically connecting to VMs (even if the option is selected in settings). However it should still be possible to manually connect USB devices to a running VM (except possibly in cases where the reset command is not correctly issued via the hub).

from: [https://communities.vmware.com/message/2393343#2393343 2014 Preview still has USB 3 hub issue]

==== Open file with host OS application ====
When a file is located on a shared folder (VMware HGFS) then you can choose to be able to open this file with the host OS default application.
For example. Your png file can open in macOS Preview.

proxyApps.publishToGuest = "TRUE"

See also: [https://communities.vmware.com/t5/VMware-Workstation-Pro/Has-there-ever-been-a-solution-to-opening-a-host-application/m-p/2841711/highlight/true#M169663 Has there ever been a solution to opening a host application from a guest OS?]

==== Pass OS X host serial number ====

If you want an OS X guest to use the host's serial number, you'll need to add this option to the VM's configuration:

serialNumber.reflectHost = "TRUE"

==== Pass OS X host hardware model ====

To pass hardware model to the guest (not even sure this works, as it does not seem to do anything for me, but ... Fusion does not error on starting the VM )

hw.model.reflectHost = "TRUE"

==== Pass OS X host hardware model ID ====

If you want an OS X guest to use the host's hardware model ID (i.e. "MacPro5,1"), board ID (i.e. "Mac-12345678") and serial number all together:

smbios.reflectHost = "TRUE"

=== Any platform ===

==== Slow down time in guest ====

You can't quite stop time, but you can make it go extremely slowly. Set the following in your system-wide configuration file (/etc/vmware/config on Linux; C:\ProgramData\VMware\VMware Workstation\config.ini on Windows):

host.cpukHz = 1000

This is probably not all that useful in practice, unless the guest OS has no reliance on any time sources.

from [https://communities.vmware.com/message/2431592#2431592 System time]

==== Set max number of snapshots ====

snapshot.maxSnapshots = 100

==== Enable DX11 or OpenGL Host Renderer ====

Courtesy @bluefirestorm at [https://communities.vmware.com/message/2812499#2812499 setting *.vmx]

mks.enableDX11Renderer

When 3D accelerated graphics is enabled in Workstation 12/14/15 the default value is "TRUE" (i.e. the line does not have to be present in the vmx file), VMware Workstation uses DX11 of the Windows host to deliver the DX10/OpenGL 3.3 core profile capability inside the VMs. For Linux hosts, the equivalent is mks.enableGLRenderer = "TRUE"

==== Enable D3D Renderer ====
Courtesy @bluefirestorm at [https://communities.vmware.com/message/2812499#2812499 setting *.vmx]

mks.enableD3DRenderer

Default is "FALSE" from Workstation 12.x and later. This is only useful in version 12.x if the host graphics card does not have DX11 capability and setting this to TRUE and enableDX11Renderer to FALSE let the VM have some limited 3D accelerated graphics capability. This looks like is already ineffective in version 14/15.

==== Select host Graphics card to use ====
Courtesy @bluefirestorm at [https://communities.vmware.com/message/2812499#2812499 setting *.vmx]

mks.dx11.vendorID

valid values are the vendor ID of the graphic card, 0x8086 for Intel, 0x10DE for Nvidia, 0x1002 for AMD.

If this line is not present, VMware Workstation will use the default graphic card of the Windows host system. This line is useful if the system has two graphic cards from two different vendors that are simultaneously active on the host machine (example: Intel integrated graphics in the CPU and a discrete graphics card from Nvidia or AMD).

==== ReflectHost ====
Courtesy @bluefirestorm at [https://communities.vmware.com/message/2812499#2812499 setting *.vmx]

SMBIOS.reflectHost

Default is "FALSE". If set to "TRUE" some of the DMI info will use the host values (example: manufacturer will change from VMware to the host value). You can see this difference by using msinfo32 in Windows VM or dmidecode in Linux VM. This is not so useful anymore to hide the fact that the VM is a VM.

==== vmx.buildType ====
Courtesy @bluefirestorm at [https://communities.vmware.com/message/2812499#2812499 setting *.vmx]

vmx.buildType

Valid values are "release" and "debug". The "debug" is the default for the beta versions (aka Tech Preview). When set to "debug", vmware-vmx-debug.exe will be used instead of vmware-vmx.exe and the vmware.log file will be larger.

=== External sites ===

There's only one .vmx site that has most .vmx options and that's Ulli's reference over at sanbarrow:

http://sanbarrow.com/vmx/vmx-advanced.html

Vmx hacks

2021-11-12T10:24:20Z

Wila: /* Linux Host - switch back from Vulkan to X11 */

=== VMX hacks ===

Here's my internal list of the .vmx hacks that I collected over time.

Beware that editing a .vmx file manually and adding any of these options is unsupported.

If you end up breaking your VM by editing the .vmx ... then restore the backup! (If you had no backups before hacking on your config, you are doing something wrong)

Also note that some options might no longer be active as they might be for an earlier version of a VMware product.

==== Wait 5 seconds on booting ====
Wait 5 seconds on booting:
bios.bootDelay = "5000"
Time is in milliseconds, change it accordingly.
==== Open BIOS settings on next boot ====
Open BIOS settings on next boot:
bios.forceSetupOnce = "TRUE"
In VMware Server 2, this setting is also in the web management interface, choose "Configure VM", power tabdialog, near the bottom.

[http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1648 Automatically Connecting USB Devices at Virtual Machine Power On]
==== Disable all Power menu and keyboard shortcuts====
gui.restricted="true"
This disables all power menu and keyboard shortcuts. It also disables suspend button

==== Fix repeating keys ====

To reduce these effects, increase the time threshold necessary for auto-repeat in the remote console.

Power off the virtual machine.
Add a line, similar to this, at the end of your virtual machine's configuration (.vmx) file:

keyboard.typematicMinDelay = "2000000"

The delay is specified in micro-seconds, so the line in the example above increases the repeat time to 2 seconds. This should ensure that you never get auto-repeat unless you intend it.

[http://kb.vmware.com/kb/196 Repeated characters when typing in remote console]

==== Disables suspend option ====
suspend.disabled = "TRUE"
This disables the suspend option in a virtual machine.

==== Fix Caps Lock synchronisation issues ====
This tip fixes the caps lock sync issue in Fusion 2.0.x and Tech Preview. I found it to be invaluable, add this to your VM's configuration file (.vmx):

mks.keyboard.syncLEDs = "TRUE"
==== Run a VM without a suspend file====
isn't there an option to run a VM without a suspend file (which is a file named like abcdef01-abcd-abcd-abcd-abcdef012345.vmem)
you mean
mainmem.useNamedFile = "false"
only works in windows

==== Use FT in a VM under Workstation ====
To use FT in a nested VM, you will still have to supply the entirely unsupported option (for the inner VM):

replay.allowBTOnly = "TRUE"

[http://communities.vmware.com/message/1343622 VMTN Anyone had sucess setting up a ESX40 Lab on Workstation 7.0?]

==== Disable VIX ====

An interesting tidbit if you’re super security cautious you can disable VIX by adding

“Guest.Command.Enabled”=”False”

to either the VM or the host. Be aware that this WILL break upgrading of VMware tools, and Guest customization as they both use vix as the underlying technology!

==== Optimize performance linux VM ====

mainmem.useNamedFile is no longer longer used on Linux hosts that run VMplayer 3 or Workstation 7.

New parameters are :
mainmem.backing = "swap"
mainmem.backing = "named"
mainmem.backing = "unnamed"

see http://sanbarrow.com/vmx/vmx-advanced.html#mainmem

==== Optimize troubleshooting ====
Please power off your VM and add the following configuration option to your .vmx file:
vmx.buildType = stats
Boot the VM and run your benchmark.
Shut down the VM and send me the contents of the stats directory that will be created in the same folder as the VM.

from: https://communities.vmware.com/message/2408159#2408159

==== Hardening your vmx file for security ====

http://virtualfoundry.blogspot.com/2009/04/hardening-vmx-file.html

==== Spurious APIC interrupt on CPU#1, should never happen ====

These messages are the result of an optimization Workstation 11 uses for inter-processor interrupts between virtual CPUs. The interrupt vector used for this purpose is 0xff, which is the Linux spurious APIC interrupt vector. In some cases, an inter-processor interrupt may arrive on a physical processor after Workstation has relinquished the processor to the host OS. Linux will discard the interrupt and print this message.

Unless these messages occur with high frequency, they should be innocuous.

The following configuration option should disable the optimization and make the messages stop:
monitor_control.disable_hostedIPI = TRUE

You can add this setting to /etc/vmware/config, and it will take effect for all VMs the next time they are powered on

from: [https://communities.vmware.com/message/2456565#2456565 Spurious APIC interrupt on CPU#1, should never happen]

==== CPU Masking ====

Yes, it is possible to mask the CPUID values in a VM (except for user mode code when using binary translation). However, masking only changes what CPUID reports; it doesn't change the way the processor behaves. Thus, masking may cause unexpected guest behavior.

The general format for CPUID masking is:

cpuid.<leaf>.<register> = xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx

The right hand side is a binary representation of the desired value, most significant bit first. Aside from '0' and '1,' two other important symbols are 'h,' which means to pass through the bit from the host CPUID and '-,' which means not to override the normal handling for this bit.

Specifying a different CPU vendor is not recommended.

from [https://communities.vmware.com/thread/405727 thread masking] Mr JMattson

In any event, the first thing to do is to pretend to be an AMD CPU. These settings should accomplish that:

cpuid.0.ebx = "0110:1000:0111:0100:0111:0101:0100:0001"
cpuid.0.ecx = "0100:0100:0100:1101:0100:0001:0110:0011"
cpuid.0.edx = "0110:1001:0111:0100:0110:1110:0110:0101"

Then you want to claim the family, model, and stepping of an actual AMD CPU. This setting should do that (claiming to be an early 64-bit Opteron):

cpuid.1.eax="----:0000:0000:0000:----:1111:0100:0110"

Even with these settings, some guests may still be unhappy.

=== Workstation ===

==== USB debugging ====

from [https://communities.vmware.com/message/2473661#2473661 Conversion from Workstation 10 to 11 breaks USB connections]
usb.quirks.device0 = "0x04e8:0x685b skip-reset"

==== USB Passthrough on Linux Host ====
'Passthrough' mode was disabled on Linux host as it conflicted with shared mode provided via pcscd

from [https://communities.vmware.com/message/2462510#2462510 Gemalto Smart Card Reader only appears as "Shared" not "Passthrough"]

* 1) Go to the VM's installation directory. Typically C:\Users\<username>\Documents\Virtual Machines\
* 2) Open <virtual-machine-name>.vmx file
* 3) Append the following lines:
usb.generic.allowCCID = "TRUE"
usb.ccid.disable = "TRUE"
* 4) Kill the process corresponding to the PCSC daemon on the Linux host

Do a # ps -ef | grep -i pcsc on your Linux host
sudo kill -9 <pid of the process that corresponds to pcscd>

Notes:
* 1) The first line in step 3 enables the passthrough mode
* 2) The second line in step 3 disables shared mode
* 3) Since you are killing the pcscd on your host, you wont be able to use the smart card on the host. You can passthrough the smart card now and use it in the VM

==== Change thumbnail speed ====

From Workstation 14 including 15, the thumbnail views are not in real time any more and the default refresh interval value is 3000 ms.

You can add

pref.thumbnailRefreshIntervalMs = 1000

(or other values) in the preference file %appdata%/vmware/preferences.ini to change the refesh rate. But keep in mind that this way may cause high CPU usage.

If you really need the previous real time thumbnail, you can use

pref.closeInactiveMKSWindows = "false"

But this way may cause mouse/keyboard functions under multi tabs not working well.

Both these settings are not documented or tested, so I cannot guarantee they working normally.

Note that you should make changes to the preferences.ini file with VMware Workstation shut down.

from: https://communities.vmware.com/message/2807350#2807350

==== Linux Host - switch back from Vulkan to X11 ====
Workstation 16.2.0 and higher

Add to .vmx if changing for one VM, or ~/.vmware/config if you want to change this systemwide:

mks.enableX11Presentation=TRUE
mks.enableVulkanPresentation=FALSE

That will force us to draw the window using X11 instead of Vulkan, which is normally less performant, but might work better on some setups?

from: [https://communities.vmware.com/t5/VMware-Workstation-Pro/VMware-16-2-1-Display-3D-acceleration-not-working-Windows-10/m-p/2877574#M172414 VMware 16.2.1 Display 3D acceleration not working Windows 10]

Has a great explanation on the difference by banackm

=== Dark Mode ===

In Workstation 16.2 Dark Mode had disappeared by accident, it was discovered that adding the following setting to the preferences.ini file makes it re-appear.

wsFeatureDarkModeSupported = "TRUE"

from: [https://communities.vmware.com/t5/VMware-Workstation-Pro/Vmware-Workstation-16-2-dark-mode/m-p/2874723/highlight/true#M172025 forum user mrdow2000]

=== Fusion ===
==== Applying a setting over all VMs ====

Instead of editing each .vmx file manually, you can also apply config options to all VMs, by creating/editing the user global config file that can be found at: ~/Library/Preferences/VMware\ Fusion/config

There's already a 'preferences' file in the same directory, but normally the config file has to be created.

If an individual .vmx file contains the same config options as the global file, the .vmx file will take precedence.

==== Hide the Full Screen application menu ====

It's unsupported, but try editing /Users/$USER/Library/Preferences/VMware Fusion/preferences and add the line:

fusion.showFullScreenTitleBar = "FALSE"

See also: http://communities.vmware.com/message/1348663#1348663

==== Delay drop down Full Screen application menu ====

Edit /Users/$USER/Library/Preferences/VMware Fusion/preferences and add the line:

fusion.fullScreenMenuDelay = "2"

The delay is in seconds and the default is 1.5 seconds, added since Fusion 4.1
A value of "0" removes the delay.

See also: http://communities.vmware.com/message/2273022

On VMware Workstation you would add the following lines to the preferences.ini file.

pref.fullscreen.showDelay = "5000"
to delay the showing of the toolbar 5000ms (5 seconds)
pref.fullscreen.hideDelay = "1000"
to hide the toolbar after 1000ms (1 second)

For Win7 the preferences.ini file is located under:
C:\Users\<username>\AppData\Roaming\VMware

==== debug menu ====

fusion.enableDebugMenu

(never tried)

==== Turn off full screen autofit to host ====

Here's another way to stop the guest from automagically being resized at each swipe:

* Open Finder, select the "Go" menu then select "Go To Folder..." and type in: ~/Library/Preferences/VMware Fusion/
* Open the preferences file in a text editor and add/append the following lines at the end of the file:

pref.autoFitGuestToWindow = "FALSE"
pref.autoFitFullScreen = "stretchGuestToHost"

Taken from: https://communities.vmware.com/message/2293562

==== Pass through host model ====

It's unsupported, but try editing /Users/$USER/Library/Preferences/VMware Fusion/preferences and add the line:

hw.model.reflectHost = "TRUE"

This will cause the VM to see the same model ID as the host. The default for this option is FALSE. Be aware that using this option may cause VM portability issues since the guest may now depend on this behavior and the type of the underlying Mac.

See also: http://communities.vmware.com/thread/336922

==== VM power options always display "Force" ====

If the Virtual Machine was not originally created in VMware Fusion then you will notice that the Fusion Virtual Machine menu has the word "Force" inserted before any power option.
For example copying a VM from a Windows systems to Mac it displays the "Force ..." commands by default. In other words, pressing the Option Key is backwards of what it is supposed to be. This is because the following options are missing from the Virtual Machine's .vmx configuration file.

powerType.powerOff = "soft"
powerType.powerOn = "soft"
powerType.suspend = "soft"
powerType.reset = "soft"

By default, VMware Fusion creates these options in the Virtual Machine's .vmx configuration file while VMware Player/Workstation does not. So, add the above options to the Virtual Machine's .vmx configuration file and the "Force ..." commands will then exhibit VMware Fusion normal behavior. Meaning in order to access the "Force ..." commands one will need to press the Option Key.

See also: http://communities.vmware.com/thread/402281

==== kernel debugging ====

You can attach a remote debugger such as gdb to your vm to do kernel debugging.

DebugStub knows nothing at all about the guest OS. Think of debugStub as an In-Circuit Debugger for the virtual CPU(s).

debugStub.listen.guest64 = "TRUE"
debugStub.listen.guest64.remote = "TRUE"
debugStub.hideBreakpoints=1
specify a custom port with:
debugStub.port.guest64 = "8865"
other options:
debugStub.listen.guest32 = "TRUE" # Enable listener for 32 bit guest
debugStub.listen.guest32.remote = "TRUE" # Allow remote connection
debugStub.port.guest32 = "32001" # Listen on specified port NNN

see also: [https://communities.vmware.com/thread/470936 Using debugStub to debug a guest linux kernel]

==== Additional logging ====
For troubleshooting boot issues etcetera you can increase the log level in vmware.log

monitor_control.log_vmsample = "TRUE"

[https://communities.vmware.com/thread/471833 Fusion 6.0.2 / OS X 10.9.2 Host / OS X 10.9 Guest VM running >100% CPU no matter what]

==== memory hole ====

At 3.2 GB there's a 1024kB memory hole.

You can use the pciHole.start option to adjust the start of the memory hole, measured in megabytes from address 0x00000000. The default is

pciHole.start = 3072

which corresponds to 0xC0000000.

from [https://communities.vmware.com/thread/478739 Memory hole at 3.2GB]

==== Disable Shared Folder event notification ====

isolation.tools.hgfs.notify.enable = "FALSE"

See also: http://kb.vmware.com/kb/2011360

==== Shared folder size check ====

The other workaround is to stop the VM, edit the VM's .vmx file and add the following setting:

tools.hgfs.volumeInfoType = "max"

Then start the VM again, and this time you will not need to disable the other shares which are on smaller sized volumes.

The default setting causes the shares to be aggregated to the smallest volume size that a share resides on when our file system is queried for size and free space.

The above setting overrides this to pick the largest volume size. The downside is that you can start a copy to a share on volume with a smaller amount of free space and it will only fail when it actually fails to write when the free space is exhausted.

If you know you are not going to run into that type of scenario yourself or you verify prior to starting the copy operation then you will be fine.

Note, the above can only be set to "min" or "max" and if not set at all, then "min" is the default.

from: [https://communities.vmware.com/message/2381223#2381223 Folder copy on Windows 7 vm fails for "not enough space", but there is.]

==== Disable location services ====

sensor.location = "disable"

to vmx.

[https://communities.vmware.com/message/2383410#2383410 how-to disable location services]

==== Disable automatic USB connect to guest feature ====

1. Suspend or shut down any running VMs and quit Fusion.

2. Ensure that the vmware-usbarbitrator process is no longer running.

3. Create/edit the host-global configuration file, with root privileges: (this example uses nano, but feel free to use any other editor)

sudo nano /Library/Preferences/VMware\ Fusion/config

4. Add the following line to disable the automatic claiming of USB devices:

usbarb.autoconnect.claimAll = "FALSE"

5. Save the file and quit the editor.

With this change, all USB devices should automatically connect to the host even when VMs are running. Note that it will completely disable the USB connection prompt, and will prevent devices from automatically connecting to VMs (even if the option is selected in settings). However it should still be possible to manually connect USB devices to a running VM (except possibly in cases where the reset command is not correctly issued via the hub).

from: [https://communities.vmware.com/message/2393343#2393343 2014 Preview still has USB 3 hub issue]

==== Open file with host OS application ====
When a file is located on a shared folder (VMware HGFS) then you can choose to be able to open this file with the host OS default application.
For example. Your png file can open in macOS Preview.

proxyApps.publishToGuest = "TRUE"

See also: [https://communities.vmware.com/t5/VMware-Workstation-Pro/Has-there-ever-been-a-solution-to-opening-a-host-application/m-p/2841711/highlight/true#M169663 Has there ever been a solution to opening a host application from a guest OS?]

==== Pass OS X host serial number ====

If you want an OS X guest to use the host's serial number, you'll need to add this option to the VM's configuration:

serialNumber.reflectHost = "TRUE"

==== Pass OS X host hardware model ====

To pass hardware model to the guest (not even sure this works, as it does not seem to do anything for me, but ... Fusion does not error on starting the VM )

hw.model.reflectHost = "TRUE"

==== Pass OS X host hardware model ID ====

If you want an OS X guest to use the host's hardware model ID (i.e. "MacPro5,1"), board ID (i.e. "Mac-12345678") and serial number all together:

smbios.reflectHost = "TRUE"

=== Any platform ===

==== Slow down time in guest ====

You can't quite stop time, but you can make it go extremely slowly. Set the following in your system-wide configuration file (/etc/vmware/config on Linux; C:\ProgramData\VMware\VMware Workstation\config.ini on Windows):

host.cpukHz = 1000

This is probably not all that useful in practice, unless the guest OS has no reliance on any time sources.

from [https://communities.vmware.com/message/2431592#2431592 System time]

==== Set max number of snapshots ====

snapshot.maxSnapshots = 100

==== Enable DX11 or OpenGL Host Renderer ====

Courtesy @bluefirestorm at [https://communities.vmware.com/message/2812499#2812499 setting *.vmx]

mks.enableDX11Renderer

When 3D accelerated graphics is enabled in Workstation 12/14/15 the default value is "TRUE" (i.e. the line does not have to be present in the vmx file), VMware Workstation uses DX11 of the Windows host to deliver the DX10/OpenGL 3.3 core profile capability inside the VMs. For Linux hosts, the equivalent is mks.enableGLRenderer = "TRUE"

==== Enable D3D Renderer ====
Courtesy @bluefirestorm at [https://communities.vmware.com/message/2812499#2812499 setting *.vmx]

mks.enableD3DRenderer

Default is "FALSE" from Workstation 12.x and later. This is only useful in version 12.x if the host graphics card does not have DX11 capability and setting this to TRUE and enableDX11Renderer to FALSE let the VM have some limited 3D accelerated graphics capability. This looks like is already ineffective in version 14/15.

==== Select host Graphics card to use ====
Courtesy @bluefirestorm at [https://communities.vmware.com/message/2812499#2812499 setting *.vmx]

mks.dx11.vendorID

valid values are the vendor ID of the graphic card, 0x8086 for Intel, 0x10DE for Nvidia, 0x1002 for AMD.

If this line is not present, VMware Workstation will use the default graphic card of the Windows host system. This line is useful if the system has two graphic cards from two different vendors that are simultaneously active on the host machine (example: Intel integrated graphics in the CPU and a discrete graphics card from Nvidia or AMD).

==== ReflectHost ====
Courtesy @bluefirestorm at [https://communities.vmware.com/message/2812499#2812499 setting *.vmx]

SMBIOS.reflectHost

Default is "FALSE". If set to "TRUE" some of the DMI info will use the host values (example: manufacturer will change from VMware to the host value). You can see this difference by using msinfo32 in Windows VM or dmidecode in Linux VM. This is not so useful anymore to hide the fact that the VM is a VM.

==== vmx.buildType ====
Courtesy @bluefirestorm at [https://communities.vmware.com/message/2812499#2812499 setting *.vmx]

vmx.buildType

Valid values are "release" and "debug". The "debug" is the default for the beta versions (aka Tech Preview). When set to "debug", vmware-vmx-debug.exe will be used instead of vmware-vmx.exe and the vmware.log file will be larger.

=== External sites ===

There's only one .vmx site that has most .vmx options and that's Ulli's reference over at sanbarrow:

http://sanbarrow.com/vmx/vmx-advanced.html

Vmx hacks

2021-11-12T10:21:06Z

Wila: /* Change thumbnail speed */

=== VMX hacks ===

Here's my internal list of the .vmx hacks that I collected over time.

Beware that editing a .vmx file manually and adding any of these options is unsupported.

If you end up breaking your VM by editing the .vmx ... then restore the backup! (If you had no backups before hacking on your config, you are doing something wrong)

Also note that some options might no longer be active as they might be for an earlier version of a VMware product.

==== Wait 5 seconds on booting ====
Wait 5 seconds on booting:
bios.bootDelay = "5000"
Time is in milliseconds, change it accordingly.
==== Open BIOS settings on next boot ====
Open BIOS settings on next boot:
bios.forceSetupOnce = "TRUE"
In VMware Server 2, this setting is also in the web management interface, choose "Configure VM", power tabdialog, near the bottom.

[http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1648 Automatically Connecting USB Devices at Virtual Machine Power On]
==== Disable all Power menu and keyboard shortcuts====
gui.restricted="true"
This disables all power menu and keyboard shortcuts. It also disables suspend button

==== Fix repeating keys ====

To reduce these effects, increase the time threshold necessary for auto-repeat in the remote console.

Power off the virtual machine.
Add a line, similar to this, at the end of your virtual machine's configuration (.vmx) file:

keyboard.typematicMinDelay = "2000000"

The delay is specified in micro-seconds, so the line in the example above increases the repeat time to 2 seconds. This should ensure that you never get auto-repeat unless you intend it.

[http://kb.vmware.com/kb/196 Repeated characters when typing in remote console]

==== Disables suspend option ====
suspend.disabled = "TRUE"
This disables the suspend option in a virtual machine.

==== Fix Caps Lock synchronisation issues ====
This tip fixes the caps lock sync issue in Fusion 2.0.x and Tech Preview. I found it to be invaluable, add this to your VM's configuration file (.vmx):

mks.keyboard.syncLEDs = "TRUE"
==== Run a VM without a suspend file====
isn't there an option to run a VM without a suspend file (which is a file named like abcdef01-abcd-abcd-abcd-abcdef012345.vmem)
you mean
mainmem.useNamedFile = "false"
only works in windows

==== Use FT in a VM under Workstation ====
To use FT in a nested VM, you will still have to supply the entirely unsupported option (for the inner VM):

replay.allowBTOnly = "TRUE"

[http://communities.vmware.com/message/1343622 VMTN Anyone had sucess setting up a ESX40 Lab on Workstation 7.0?]

==== Disable VIX ====

An interesting tidbit if you’re super security cautious you can disable VIX by adding

“Guest.Command.Enabled”=”False”

to either the VM or the host. Be aware that this WILL break upgrading of VMware tools, and Guest customization as they both use vix as the underlying technology!

==== Optimize performance linux VM ====

mainmem.useNamedFile is no longer longer used on Linux hosts that run VMplayer 3 or Workstation 7.

New parameters are :
mainmem.backing = "swap"
mainmem.backing = "named"
mainmem.backing = "unnamed"

see http://sanbarrow.com/vmx/vmx-advanced.html#mainmem

==== Optimize troubleshooting ====
Please power off your VM and add the following configuration option to your .vmx file:
vmx.buildType = stats
Boot the VM and run your benchmark.
Shut down the VM and send me the contents of the stats directory that will be created in the same folder as the VM.

from: https://communities.vmware.com/message/2408159#2408159

==== Hardening your vmx file for security ====

http://virtualfoundry.blogspot.com/2009/04/hardening-vmx-file.html

==== Spurious APIC interrupt on CPU#1, should never happen ====

These messages are the result of an optimization Workstation 11 uses for inter-processor interrupts between virtual CPUs. The interrupt vector used for this purpose is 0xff, which is the Linux spurious APIC interrupt vector. In some cases, an inter-processor interrupt may arrive on a physical processor after Workstation has relinquished the processor to the host OS. Linux will discard the interrupt and print this message.

Unless these messages occur with high frequency, they should be innocuous.

The following configuration option should disable the optimization and make the messages stop:
monitor_control.disable_hostedIPI = TRUE

You can add this setting to /etc/vmware/config, and it will take effect for all VMs the next time they are powered on

from: [https://communities.vmware.com/message/2456565#2456565 Spurious APIC interrupt on CPU#1, should never happen]

==== CPU Masking ====

Yes, it is possible to mask the CPUID values in a VM (except for user mode code when using binary translation). However, masking only changes what CPUID reports; it doesn't change the way the processor behaves. Thus, masking may cause unexpected guest behavior.

The general format for CPUID masking is:

cpuid.<leaf>.<register> = xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx

The right hand side is a binary representation of the desired value, most significant bit first. Aside from '0' and '1,' two other important symbols are 'h,' which means to pass through the bit from the host CPUID and '-,' which means not to override the normal handling for this bit.

Specifying a different CPU vendor is not recommended.

from [https://communities.vmware.com/thread/405727 thread masking] Mr JMattson

In any event, the first thing to do is to pretend to be an AMD CPU. These settings should accomplish that:

cpuid.0.ebx = "0110:1000:0111:0100:0111:0101:0100:0001"
cpuid.0.ecx = "0100:0100:0100:1101:0100:0001:0110:0011"
cpuid.0.edx = "0110:1001:0111:0100:0110:1110:0110:0101"

Then you want to claim the family, model, and stepping of an actual AMD CPU. This setting should do that (claiming to be an early 64-bit Opteron):

cpuid.1.eax="----:0000:0000:0000:----:1111:0100:0110"

Even with these settings, some guests may still be unhappy.

=== Workstation ===

==== USB debugging ====

from [https://communities.vmware.com/message/2473661#2473661 Conversion from Workstation 10 to 11 breaks USB connections]
usb.quirks.device0 = "0x04e8:0x685b skip-reset"

==== USB Passthrough on Linux Host ====
'Passthrough' mode was disabled on Linux host as it conflicted with shared mode provided via pcscd

from [https://communities.vmware.com/message/2462510#2462510 Gemalto Smart Card Reader only appears as "Shared" not "Passthrough"]

* 1) Go to the VM's installation directory. Typically C:\Users\<username>\Documents\Virtual Machines\
* 2) Open <virtual-machine-name>.vmx file
* 3) Append the following lines:
usb.generic.allowCCID = "TRUE"
usb.ccid.disable = "TRUE"
* 4) Kill the process corresponding to the PCSC daemon on the Linux host

Do a # ps -ef | grep -i pcsc on your Linux host
sudo kill -9 <pid of the process that corresponds to pcscd>

Notes:
* 1) The first line in step 3 enables the passthrough mode
* 2) The second line in step 3 disables shared mode
* 3) Since you are killing the pcscd on your host, you wont be able to use the smart card on the host. You can passthrough the smart card now and use it in the VM

==== Change thumbnail speed ====

From Workstation 14 including 15, the thumbnail views are not in real time any more and the default refresh interval value is 3000 ms.

You can add

pref.thumbnailRefreshIntervalMs = 1000

(or other values) in the preference file %appdata%/vmware/preferences.ini to change the refesh rate. But keep in mind that this way may cause high CPU usage.

If you really need the previous real time thumbnail, you can use

pref.closeInactiveMKSWindows = "false"

But this way may cause mouse/keyboard functions under multi tabs not working well.

Both these settings are not documented or tested, so I cannot guarantee they working normally.

Note that you should make changes to the preferences.ini file with VMware Workstation shut down.

from: https://communities.vmware.com/message/2807350#2807350

==== Linux Host - switch back from Vulkan to X11 ====
Workstation 16.x and higher

Add to .vmx if changing for one VM, or ~/.vmware/config if you want to change this systemwide:

mks.enableX11Presentation=TRUE
mks.enableVulkanPresentation=FALSE

That will force us to draw the window using X11 instead of Vulkan, which is normally less performant, but might work better on some setups?

from: [https://communities.vmware.com/t5/VMware-Workstation-Pro/VMware-16-2-1-Display-3D-acceleration-not-working-Windows-10/m-p/2877574#M172414 VMware 16.2.1 Display 3D acceleration not working Windows 10]

Has a great explanation on the difference by banackm

=== Dark Mode ===

In Workstation 16.2 Dark Mode had disappeared by accident, it was discovered that adding the following setting to the preferences.ini file makes it re-appear.

wsFeatureDarkModeSupported = "TRUE"

from: [https://communities.vmware.com/t5/VMware-Workstation-Pro/Vmware-Workstation-16-2-dark-mode/m-p/2874723/highlight/true#M172025 forum user mrdow2000]

=== Fusion ===
==== Applying a setting over all VMs ====

Instead of editing each .vmx file manually, you can also apply config options to all VMs, by creating/editing the user global config file that can be found at: ~/Library/Preferences/VMware\ Fusion/config

There's already a 'preferences' file in the same directory, but normally the config file has to be created.

If an individual .vmx file contains the same config options as the global file, the .vmx file will take precedence.

==== Hide the Full Screen application menu ====

It's unsupported, but try editing /Users/$USER/Library/Preferences/VMware Fusion/preferences and add the line:

fusion.showFullScreenTitleBar = "FALSE"

See also: http://communities.vmware.com/message/1348663#1348663

==== Delay drop down Full Screen application menu ====

Edit /Users/$USER/Library/Preferences/VMware Fusion/preferences and add the line:

fusion.fullScreenMenuDelay = "2"

The delay is in seconds and the default is 1.5 seconds, added since Fusion 4.1
A value of "0" removes the delay.

See also: http://communities.vmware.com/message/2273022

On VMware Workstation you would add the following lines to the preferences.ini file.

pref.fullscreen.showDelay = "5000"
to delay the showing of the toolbar 5000ms (5 seconds)
pref.fullscreen.hideDelay = "1000"
to hide the toolbar after 1000ms (1 second)

For Win7 the preferences.ini file is located under:
C:\Users\<username>\AppData\Roaming\VMware

==== debug menu ====

fusion.enableDebugMenu

(never tried)

==== Turn off full screen autofit to host ====

Here's another way to stop the guest from automagically being resized at each swipe:

* Open Finder, select the "Go" menu then select "Go To Folder..." and type in: ~/Library/Preferences/VMware Fusion/
* Open the preferences file in a text editor and add/append the following lines at the end of the file:

pref.autoFitGuestToWindow = "FALSE"
pref.autoFitFullScreen = "stretchGuestToHost"

Taken from: https://communities.vmware.com/message/2293562

==== Pass through host model ====

It's unsupported, but try editing /Users/$USER/Library/Preferences/VMware Fusion/preferences and add the line:

hw.model.reflectHost = "TRUE"

This will cause the VM to see the same model ID as the host. The default for this option is FALSE. Be aware that using this option may cause VM portability issues since the guest may now depend on this behavior and the type of the underlying Mac.

See also: http://communities.vmware.com/thread/336922

==== VM power options always display "Force" ====

If the Virtual Machine was not originally created in VMware Fusion then you will notice that the Fusion Virtual Machine menu has the word "Force" inserted before any power option.
For example copying a VM from a Windows systems to Mac it displays the "Force ..." commands by default. In other words, pressing the Option Key is backwards of what it is supposed to be. This is because the following options are missing from the Virtual Machine's .vmx configuration file.

powerType.powerOff = "soft"
powerType.powerOn = "soft"
powerType.suspend = "soft"
powerType.reset = "soft"

By default, VMware Fusion creates these options in the Virtual Machine's .vmx configuration file while VMware Player/Workstation does not. So, add the above options to the Virtual Machine's .vmx configuration file and the "Force ..." commands will then exhibit VMware Fusion normal behavior. Meaning in order to access the "Force ..." commands one will need to press the Option Key.

See also: http://communities.vmware.com/thread/402281

==== kernel debugging ====

You can attach a remote debugger such as gdb to your vm to do kernel debugging.

DebugStub knows nothing at all about the guest OS. Think of debugStub as an In-Circuit Debugger for the virtual CPU(s).

debugStub.listen.guest64 = "TRUE"
debugStub.listen.guest64.remote = "TRUE"
debugStub.hideBreakpoints=1
specify a custom port with:
debugStub.port.guest64 = "8865"
other options:
debugStub.listen.guest32 = "TRUE" # Enable listener for 32 bit guest
debugStub.listen.guest32.remote = "TRUE" # Allow remote connection
debugStub.port.guest32 = "32001" # Listen on specified port NNN

see also: [https://communities.vmware.com/thread/470936 Using debugStub to debug a guest linux kernel]

==== Additional logging ====
For troubleshooting boot issues etcetera you can increase the log level in vmware.log

monitor_control.log_vmsample = "TRUE"

[https://communities.vmware.com/thread/471833 Fusion 6.0.2 / OS X 10.9.2 Host / OS X 10.9 Guest VM running >100% CPU no matter what]

==== memory hole ====

At 3.2 GB there's a 1024kB memory hole.

You can use the pciHole.start option to adjust the start of the memory hole, measured in megabytes from address 0x00000000. The default is

pciHole.start = 3072

which corresponds to 0xC0000000.

from [https://communities.vmware.com/thread/478739 Memory hole at 3.2GB]

==== Disable Shared Folder event notification ====

isolation.tools.hgfs.notify.enable = "FALSE"

See also: http://kb.vmware.com/kb/2011360

==== Shared folder size check ====

The other workaround is to stop the VM, edit the VM's .vmx file and add the following setting:

tools.hgfs.volumeInfoType = "max"

Then start the VM again, and this time you will not need to disable the other shares which are on smaller sized volumes.

The default setting causes the shares to be aggregated to the smallest volume size that a share resides on when our file system is queried for size and free space.

The above setting overrides this to pick the largest volume size. The downside is that you can start a copy to a share on volume with a smaller amount of free space and it will only fail when it actually fails to write when the free space is exhausted.

If you know you are not going to run into that type of scenario yourself or you verify prior to starting the copy operation then you will be fine.

Note, the above can only be set to "min" or "max" and if not set at all, then "min" is the default.

from: [https://communities.vmware.com/message/2381223#2381223 Folder copy on Windows 7 vm fails for "not enough space", but there is.]

==== Disable location services ====

sensor.location = "disable"

to vmx.

[https://communities.vmware.com/message/2383410#2383410 how-to disable location services]

==== Disable automatic USB connect to guest feature ====

1. Suspend or shut down any running VMs and quit Fusion.

2. Ensure that the vmware-usbarbitrator process is no longer running.

3. Create/edit the host-global configuration file, with root privileges: (this example uses nano, but feel free to use any other editor)

sudo nano /Library/Preferences/VMware\ Fusion/config

4. Add the following line to disable the automatic claiming of USB devices:

usbarb.autoconnect.claimAll = "FALSE"

5. Save the file and quit the editor.

With this change, all USB devices should automatically connect to the host even when VMs are running. Note that it will completely disable the USB connection prompt, and will prevent devices from automatically connecting to VMs (even if the option is selected in settings). However it should still be possible to manually connect USB devices to a running VM (except possibly in cases where the reset command is not correctly issued via the hub).

from: [https://communities.vmware.com/message/2393343#2393343 2014 Preview still has USB 3 hub issue]

==== Open file with host OS application ====
When a file is located on a shared folder (VMware HGFS) then you can choose to be able to open this file with the host OS default application.
For example. Your png file can open in macOS Preview.

proxyApps.publishToGuest = "TRUE"

See also: [https://communities.vmware.com/t5/VMware-Workstation-Pro/Has-there-ever-been-a-solution-to-opening-a-host-application/m-p/2841711/highlight/true#M169663 Has there ever been a solution to opening a host application from a guest OS?]

==== Pass OS X host serial number ====

If you want an OS X guest to use the host's serial number, you'll need to add this option to the VM's configuration:

serialNumber.reflectHost = "TRUE"

==== Pass OS X host hardware model ====

To pass hardware model to the guest (not even sure this works, as it does not seem to do anything for me, but ... Fusion does not error on starting the VM )

hw.model.reflectHost = "TRUE"

==== Pass OS X host hardware model ID ====

If you want an OS X guest to use the host's hardware model ID (i.e. "MacPro5,1"), board ID (i.e. "Mac-12345678") and serial number all together:

smbios.reflectHost = "TRUE"

=== Any platform ===

==== Slow down time in guest ====

You can't quite stop time, but you can make it go extremely slowly. Set the following in your system-wide configuration file (/etc/vmware/config on Linux; C:\ProgramData\VMware\VMware Workstation\config.ini on Windows):

host.cpukHz = 1000

This is probably not all that useful in practice, unless the guest OS has no reliance on any time sources.

from [https://communities.vmware.com/message/2431592#2431592 System time]

==== Set max number of snapshots ====

snapshot.maxSnapshots = 100

==== Enable DX11 or OpenGL Host Renderer ====

Courtesy @bluefirestorm at [https://communities.vmware.com/message/2812499#2812499 setting *.vmx]

mks.enableDX11Renderer

When 3D accelerated graphics is enabled in Workstation 12/14/15 the default value is "TRUE" (i.e. the line does not have to be present in the vmx file), VMware Workstation uses DX11 of the Windows host to deliver the DX10/OpenGL 3.3 core profile capability inside the VMs. For Linux hosts, the equivalent is mks.enableGLRenderer = "TRUE"

==== Enable D3D Renderer ====
Courtesy @bluefirestorm at [https://communities.vmware.com/message/2812499#2812499 setting *.vmx]

mks.enableD3DRenderer

Default is "FALSE" from Workstation 12.x and later. This is only useful in version 12.x if the host graphics card does not have DX11 capability and setting this to TRUE and enableDX11Renderer to FALSE let the VM have some limited 3D accelerated graphics capability. This looks like is already ineffective in version 14/15.

==== Select host Graphics card to use ====
Courtesy @bluefirestorm at [https://communities.vmware.com/message/2812499#2812499 setting *.vmx]

mks.dx11.vendorID

valid values are the vendor ID of the graphic card, 0x8086 for Intel, 0x10DE for Nvidia, 0x1002 for AMD.

If this line is not present, VMware Workstation will use the default graphic card of the Windows host system. This line is useful if the system has two graphic cards from two different vendors that are simultaneously active on the host machine (example: Intel integrated graphics in the CPU and a discrete graphics card from Nvidia or AMD).

==== ReflectHost ====
Courtesy @bluefirestorm at [https://communities.vmware.com/message/2812499#2812499 setting *.vmx]

SMBIOS.reflectHost

Default is "FALSE". If set to "TRUE" some of the DMI info will use the host values (example: manufacturer will change from VMware to the host value). You can see this difference by using msinfo32 in Windows VM or dmidecode in Linux VM. This is not so useful anymore to hide the fact that the VM is a VM.

==== vmx.buildType ====
Courtesy @bluefirestorm at [https://communities.vmware.com/message/2812499#2812499 setting *.vmx]

vmx.buildType

Valid values are "release" and "debug". The "debug" is the default for the beta versions (aka Tech Preview). When set to "debug", vmware-vmx-debug.exe will be used instead of vmware-vmx.exe and the vmware.log file will be larger.

=== External sites ===

There's only one .vmx site that has most .vmx options and that's Ulli's reference over at sanbarrow:

http://sanbarrow.com/vmx/vmx-advanced.html

Building Gallium3D

2021-11-02T09:55:58Z

Wila: Copy from my internal wiki on how-to build Gallium3D (hopelessly out of date now, but perhaps it helps)

==== basic research ====

setup Ubuntu Lucid (10.04) x64

sudo apt-get mesa-utils

glxinfo | grep -i render

sudo add-apt-repository ppa:xorg-edgers/drivers-only

Brian Paul at vmware

Gallium llvmpipe is what we need and a kernel driver called vmwgfx driver
===== vmwgfx =====
The vmwgfx kernel driver source can be found at: http://cgit.freedesktop.org/mesa/vmwgfx/commit/
direct download link sources:
http://cgit.freedesktop.org/mesa/vmwgfx/snapshot/vmwgfx-master.tar.gz

In order to built the kernel module you'll need to have the kernel headers installed.
No Configure step is needed.
Just run:
make
make install

The install doesn't appear to copy the kernel module into the kernel driver tree for whatever reason, so copy by hand:
cp vmwgfx.ko /lib/modules/2.6.33-020633-generic/kernel/drivers/gpu/drm/vmwgfx
(create the vmwgfx subfolder first)

Doesn't work either....

Restarting X server > Right Alt + Print Screen + k
instead of Ctrl + Alt + Backspace

===== Mesa =====
Gallium3D is part of the mesa drivers
The mesa drivers can be found at: http://cgit.freedesktop.org/mesa/mesa/commit/
and a direct download link for the source:

http://cgit.freedesktop.org/mesa/mesa/snapshot/mesa-master.tar.gz

http://www.khattam.info/2010/02/06/installing-kernel-2-6-33-to-lucid-lynx-ubuntu-10-04-without-compiling/

http://www.x.org/wiki/radeonBuildHowTo

# cd xf86-video-radeonhd/ # ./autogen.sh --prefix=/usr # make # make install

This should install the RadeonHD driver for you. Please note that it might be nontrivial to completely uninstall the driver now.

Also note that you can also drop off the --prefix=/usr part so the driver will be installed to /usr/local. You should at this point find out which path your X downloads its modules from. The next will prepend module search directory under /usr/local before the one which in many computers is the default X.org module path. Not that this can cause your X not to start if main module path is changed for some reason so don't forget this setting's existence. The second path needs to be the real X.org module path.
File: /etc/X11/xorg.conf
Section "Files"
ModulePath "/usr/local/lib/xorg/modules,/usr/lib/xorg/modules"
EndSection

==== mesa build requirements ====
sudo apt-get install build-essentials automake autoconf xserver-xorg-dev libdrm-dev x11proto-gl-dev libxfixes-dev x11proto-fixes-dev
mesa-common-dev libosmesa-dev
libxext-dev
libxdamage-dev
libxxf86vm-dev
expat libexpat1-dev
libxt-dev
libxmu-dev
libxi-dev
llvm-dev

./autogen.sh --enable-gallium-llvm --prefix=/opt/xorg
./autogen.sh --enable-gallium-llvm --with-driver=xlib --prefix=/opt/xorg
./autogen.sh --with-driver=osmesa --prefix=/opt/xorg

./autogen.sh --prefix=/opt/xorg

Now without gallium-llvm (this is the only one that compiles OK)
./autogen.sh --with-driver=xlib --prefix=/opt/xorg

==== External links ====

[http://www.phoronix.com/scan.php?page=article&item=gallium3d_llvmpipe&num=1 LLVMpipe: OpenGL With Gallium3D on Your CPU]

[http://www.phoronix.com/scan.php?page=news_item&px=ODA1OA Gallium3D's LLVMpipe Software Rasterizer Is Kicking]

[http://www.phoronix.com/scan.php?page=news_item&px=Nzc4Ng VMware Goes For Mainline Inclusion Of Its DRM]

[http://www.phoronix.com/scan.php?page=news_item&px=ODIxMw LLVMpipe Doesn't Yet Like The GNOME Shell]

http://vmware-svga.sourceforge.net/

Vmwgfx

2021-11-02T09:55:22Z

Wila: /* vmwgfx */

== vmwgfx ==

3D accelerated graphics in Linux

This driver is nowadays part of the linux kernel, see:

https://github.com/torvalds/linux/tree/master/drivers/gpu/drm/vmwgfx

Before it was at freedesktop:

https://gitlab.freedesktop.org/mesa/vmwgfx

older
https://cgit.freedesktop.org/mesa/vmwgfx

and doc with tips on how-to build your own:
https://docs.mesa3d.org/drivers/svga3d.html

In 2010 I wrote this on my internal wiki [[Building Gallium3D]] when I did build my own.

Vmwgfx

2021-11-02T09:54:59Z

Wila: /* vmwgfx */

Vmwgfx

2021-11-02T09:48:12Z

Wila: /* vmwgfx */

Vmwgfx

2021-11-02T09:32:25Z

Wila: Created page with "== vmwgfx == 3D accelerated graphics in Linux This driver is nowadays part of the linux kernel, see: https://github.com/torvalds/linux/tree/master/drivers/gpu/drm/vmwgfx B..."

Build guest vmware kernel modules

2021-11-02T09:30:23Z

Wila: /* available kernel modules */

====Pre built modules are sometimes not enough====
When you select "install VMware Tools" then your VMware product will try to install the available vmware modules.
If you run linux then sometimes the kernel will not match up with the prebuilt modules as are supplied with your vmware product.
You can unzip the vmware tools .tar.gz bundle from the attached virtual CDrom and run the perl script, but if you just supply defaults you might still miss out on some modules as it will fail silently.

eg running:
./vmware-install.pl --default
is great as long as you have provided the VM with the right prerequisites.
====The solution====
Present the linux vmware tools virtual cd-rom to the VM and mount as a CDRom.
mount /dev/sr0 /mnt/cdrom
Copy the files to your home folder
cd ~
cp /mnt/cdrom/VMwareTools-*.tar.gz .
unzip
tar xfz VMwareTools-*.tar.gz
go into sub folder to build the tools
cd vmware-tools-distrib/
check and run pre-requisites from next paragraph if needed and then run:
sudo ./vmware-install.pl
Press <enter> on any questions asked.

After you are done you can remove the vmware-tool-distrib folder as it is only needed before the install.

After installing VMware Tools you now have the possibility to run
vmware-config-tools.pl
to configure how vmware tools is supposed to work.

Please note that on linux kernels 3.3 and higher, the original vmxnet module is no longer recommended.
You are advised to use a newer virtual NIC such as vmxnet3 or e1000e.

====Preconditions for the script to work====

If you try to run the vmware-install.pl script and you need to build new kernel modules, then the script might give you the following error:
Before you can compile modules, you need to have the following installed...

make
gcc
kernel headers of the running kernel

You will have to get your kernel-headers and a compiler and build system before hand.
On Ubuntu or debian based systems execute this:
sudo apt-get install build-essential linux-headers-$(uname -r)
On fedora / Red Hat based systems:
su -c "yum install kernel-devel"
On SUSE / openSUSE use YaST to fetch the latest linux-kernel-headers

====Troubleshooting====

===== available kernel modules =====
After the manual compile, you can run the lsmod command to see what modules it was able to load:
$ lsmod | grep -i vm

The following kernel modules are currently available:
* vmhgfs - shared folders
* vmxnet3 - virtual network adapter
* vmmemctl - memory
* vmw_balloon - balloon memory driver
* vmw_pvscsi - paravirtual scsi
* [[vmwgfx]] - accelerated graphics
* vmblock - enable drag & drop between guest and host OS (desktop feature)
* vmsync -
* vgauth - Guest Authentication
* vmw_vmci - inter-VM and host interface
* vmw_vsock_vmci_transport -
* vsock - virtual sockets

Interesting tidbit, the reason that there's a "vmw_" prefix means it is VMware only and if there's no prefix, like vsock, then it is because it is a hypervisor-independent interface. See [https://communities.vmware.com/thread/497086 (1)] for details

There's also a number of additional commands/scripts to enable other features
* /usr/bin/vmware-toolbox-cmd - shrink, upgrade, statistics, version, timesync, run scripts on power operations, power operations, control devices
* /usr/bin/vmware-user - advanced X features, guest resolution fit, drag and drop, file and text copy & paste. Running this will start the vmtoolsd daemon in /usr/lib/vmware-tools/sbin64
* /usr/lib/vmware-tools/sbin64/vmware-checkvm - prints VMware software version
* /usr/lib/vmware-tools/sbin64/vmware-modconfig-console - module helper for acquiring status, kernel headers version, is a link to /usr/lib/vmware-tools/bin64/appLoader option --install-all will actually build all of your modules as well.
* vmware-tools-thinprint - printing integration with the host using a virtual printing daemon

===== unable to start services for VMware Tools =====

Creating a new initrd boot image for the kernel.

NOTE: both /etc/vmware-tools/GuestProxyData/server/key.pem and
/etc/vmware-tools/GuestProxyData/server/cert.pem already exist.
They are not generated again. To regenerate them by force,
use the "vmware-guestproxycerttool -g -f" command.

initctl: Job failed to start
Unable to start services for VMware Tools

Execution aborted.

If you get the above error then you can probably do as is sugggested above. I simply nuked the folder /etc/vmware-tools/GuestProxyData (rm -rf ) and completely reran the installer, after that it worked.

===== vgauth what? =====

Nowadays VMware Tools asks if you want to enable the CAF agent (Common Agent Framework agent).

If you are like me then you are probably wondering what this is.

At the forums there's an answer ( https://communities.vmware.com/message/2604183#2604183 by VMware employee ykzang)

I'm quoting that here for ease of reading.

''Multiple VMware management solutions (e.g. vCM, Hyperic, Log Insight) require installation of in-guest agents.The Common Agent Framework attempts to provide a common framework to unify and simplify the management of various types of agents, and these agents would be referred to as Common Agent.''

''Those VMware solutions are working on distinct administrative domains from the guest. VGAuth provides a way to authorize those solutions users' behaviors(install agent for example) within guest.''

====Alternative solution====
Many Linux distributions now come with a package called [[open-vm-tools]] and while that does give you a good bases, there are still things missing.
Most notable is the host guest file system integration that is provided by the vmhgfs kernel module.

[[Category: CLI]] [[Category: Bash]]

Vmx hacks

2021-10-29T09:07:16Z

Wila: Add Dark Mode setting

=== VMX hacks ===

Here's my internal list of the .vmx hacks that I collected over time.

Beware that editing a .vmx file manually and adding any of these options is unsupported.

If you end up breaking your VM by editing the .vmx ... then restore the backup! (If you had no backups before hacking on your config, you are doing something wrong)

Also note that some options might no longer be active as they might be for an earlier version of a VMware product.

==== Wait 5 seconds on booting ====
Wait 5 seconds on booting:
bios.bootDelay = "5000"
Time is in milliseconds, change it accordingly.
==== Open BIOS settings on next boot ====
Open BIOS settings on next boot:
bios.forceSetupOnce = "TRUE"
In VMware Server 2, this setting is also in the web management interface, choose "Configure VM", power tabdialog, near the bottom.

[http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1648 Automatically Connecting USB Devices at Virtual Machine Power On]
==== Disable all Power menu and keyboard shortcuts====
gui.restricted="true"
This disables all power menu and keyboard shortcuts. It also disables suspend button

==== Fix repeating keys ====

To reduce these effects, increase the time threshold necessary for auto-repeat in the remote console.

Power off the virtual machine.
Add a line, similar to this, at the end of your virtual machine's configuration (.vmx) file:

keyboard.typematicMinDelay = "2000000"

The delay is specified in micro-seconds, so the line in the example above increases the repeat time to 2 seconds. This should ensure that you never get auto-repeat unless you intend it.

[http://kb.vmware.com/kb/196 Repeated characters when typing in remote console]

==== Disables suspend option ====
suspend.disabled = "TRUE"
This disables the suspend option in a virtual machine.

==== Fix Caps Lock synchronisation issues ====
This tip fixes the caps lock sync issue in Fusion 2.0.x and Tech Preview. I found it to be invaluable, add this to your VM's configuration file (.vmx):

mks.keyboard.syncLEDs = "TRUE"
==== Run a VM without a suspend file====
isn't there an option to run a VM without a suspend file (which is a file named like abcdef01-abcd-abcd-abcd-abcdef012345.vmem)
you mean
mainmem.useNamedFile = "false"
only works in windows

==== Use FT in a VM under Workstation ====
To use FT in a nested VM, you will still have to supply the entirely unsupported option (for the inner VM):

replay.allowBTOnly = "TRUE"

[http://communities.vmware.com/message/1343622 VMTN Anyone had sucess setting up a ESX40 Lab on Workstation 7.0?]

==== Disable VIX ====

An interesting tidbit if you’re super security cautious you can disable VIX by adding

“Guest.Command.Enabled”=”False”

to either the VM or the host. Be aware that this WILL break upgrading of VMware tools, and Guest customization as they both use vix as the underlying technology!

==== Optimize performance linux VM ====

mainmem.useNamedFile is no longer longer used on Linux hosts that run VMplayer 3 or Workstation 7.

New parameters are :
mainmem.backing = "swap"
mainmem.backing = "named"
mainmem.backing = "unnamed"

see http://sanbarrow.com/vmx/vmx-advanced.html#mainmem

==== Optimize troubleshooting ====
Please power off your VM and add the following configuration option to your .vmx file:
vmx.buildType = stats
Boot the VM and run your benchmark.
Shut down the VM and send me the contents of the stats directory that will be created in the same folder as the VM.

from: https://communities.vmware.com/message/2408159#2408159

==== Hardening your vmx file for security ====

http://virtualfoundry.blogspot.com/2009/04/hardening-vmx-file.html

==== Spurious APIC interrupt on CPU#1, should never happen ====

These messages are the result of an optimization Workstation 11 uses for inter-processor interrupts between virtual CPUs. The interrupt vector used for this purpose is 0xff, which is the Linux spurious APIC interrupt vector. In some cases, an inter-processor interrupt may arrive on a physical processor after Workstation has relinquished the processor to the host OS. Linux will discard the interrupt and print this message.

Unless these messages occur with high frequency, they should be innocuous.

The following configuration option should disable the optimization and make the messages stop:
monitor_control.disable_hostedIPI = TRUE

You can add this setting to /etc/vmware/config, and it will take effect for all VMs the next time they are powered on

from: [https://communities.vmware.com/message/2456565#2456565 Spurious APIC interrupt on CPU#1, should never happen]

==== CPU Masking ====

Yes, it is possible to mask the CPUID values in a VM (except for user mode code when using binary translation). However, masking only changes what CPUID reports; it doesn't change the way the processor behaves. Thus, masking may cause unexpected guest behavior.

The general format for CPUID masking is:

cpuid.<leaf>.<register> = xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx

The right hand side is a binary representation of the desired value, most significant bit first. Aside from '0' and '1,' two other important symbols are 'h,' which means to pass through the bit from the host CPUID and '-,' which means not to override the normal handling for this bit.

Specifying a different CPU vendor is not recommended.

from [https://communities.vmware.com/thread/405727 thread masking] Mr JMattson

In any event, the first thing to do is to pretend to be an AMD CPU. These settings should accomplish that:

cpuid.0.ebx = "0110:1000:0111:0100:0111:0101:0100:0001"
cpuid.0.ecx = "0100:0100:0100:1101:0100:0001:0110:0011"
cpuid.0.edx = "0110:1001:0111:0100:0110:1110:0110:0101"

Then you want to claim the family, model, and stepping of an actual AMD CPU. This setting should do that (claiming to be an early 64-bit Opteron):

cpuid.1.eax="----:0000:0000:0000:----:1111:0100:0110"

Even with these settings, some guests may still be unhappy.

=== Workstation ===

==== USB debugging ====

from [https://communities.vmware.com/message/2473661#2473661 Conversion from Workstation 10 to 11 breaks USB connections]
usb.quirks.device0 = "0x04e8:0x685b skip-reset"

==== USB Passthrough on Linux Host ====
'Passthrough' mode was disabled on Linux host as it conflicted with shared mode provided via pcscd

from [https://communities.vmware.com/message/2462510#2462510 Gemalto Smart Card Reader only appears as "Shared" not "Passthrough"]

* 1) Go to the VM's installation directory. Typically C:\Users\<username>\Documents\Virtual Machines\
* 2) Open <virtual-machine-name>.vmx file
* 3) Append the following lines:
usb.generic.allowCCID = "TRUE"
usb.ccid.disable = "TRUE"
* 4) Kill the process corresponding to the PCSC daemon on the Linux host

Do a # ps -ef | grep -i pcsc on your Linux host
sudo kill -9 <pid of the process that corresponds to pcscd>

Notes:
* 1) The first line in step 3 enables the passthrough mode
* 2) The second line in step 3 disables shared mode
* 3) Since you are killing the pcscd on your host, you wont be able to use the smart card on the host. You can passthrough the smart card now and use it in the VM

==== Change thumbnail speed ====

From Workstation 14 including 15, the thumbnail views are not in real time any more and the default refresh interval value is 3000 ms.

You can add

pref.thumbnailRefreshIntervalMs = 1000

(or other values) in the preference file %appdata%/vmware/preferences.ini to change the refesh rate. But keep in mind that this way may cause high CPU usage.

If you really need the previous real time thumbnail, you can use

pref.closeInactiveMKSWindows = "false"

But this way may cause mouse/keyboard functions under multi tabs not working well.

Both these settings are not documented or tested, so I cannot guarantee they working normally.

Note that you should make changes to the preferences.ini file with VMware Workstation shut down.

from: https://communities.vmware.com/message/2807350#2807350

=== Dark Mode ===

In Workstation 16.2 Dark Mode had disappeared by accident, it was discovered that adding the following setting to the preferences.ini file makes it re-appear.

wsFeatureDarkModeSupported = "TRUE"

from: [https://communities.vmware.com/t5/VMware-Workstation-Pro/Vmware-Workstation-16-2-dark-mode/m-p/2874723/highlight/true#M172025 forum user mrdow2000]

=== Fusion ===
==== Applying a setting over all VMs ====

Instead of editing each .vmx file manually, you can also apply config options to all VMs, by creating/editing the user global config file that can be found at: ~/Library/Preferences/VMware\ Fusion/config

There's already a 'preferences' file in the same directory, but normally the config file has to be created.

If an individual .vmx file contains the same config options as the global file, the .vmx file will take precedence.

==== Hide the Full Screen application menu ====

It's unsupported, but try editing /Users/$USER/Library/Preferences/VMware Fusion/preferences and add the line:

fusion.showFullScreenTitleBar = "FALSE"

See also: http://communities.vmware.com/message/1348663#1348663

==== Delay drop down Full Screen application menu ====

Edit /Users/$USER/Library/Preferences/VMware Fusion/preferences and add the line:

fusion.fullScreenMenuDelay = "2"

The delay is in seconds and the default is 1.5 seconds, added since Fusion 4.1
A value of "0" removes the delay.

See also: http://communities.vmware.com/message/2273022

On VMware Workstation you would add the following lines to the preferences.ini file.

pref.fullscreen.showDelay = "5000"
to delay the showing of the toolbar 5000ms (5 seconds)
pref.fullscreen.hideDelay = "1000"
to hide the toolbar after 1000ms (1 second)

For Win7 the preferences.ini file is located under:
C:\Users\<username>\AppData\Roaming\VMware

==== debug menu ====

fusion.enableDebugMenu

(never tried)

==== Turn off full screen autofit to host ====

Here's another way to stop the guest from automagically being resized at each swipe:

* Open Finder, select the "Go" menu then select "Go To Folder..." and type in: ~/Library/Preferences/VMware Fusion/
* Open the preferences file in a text editor and add/append the following lines at the end of the file:

pref.autoFitGuestToWindow = "FALSE"
pref.autoFitFullScreen = "stretchGuestToHost"

Taken from: https://communities.vmware.com/message/2293562

==== Pass through host model ====

It's unsupported, but try editing /Users/$USER/Library/Preferences/VMware Fusion/preferences and add the line:

hw.model.reflectHost = "TRUE"

This will cause the VM to see the same model ID as the host. The default for this option is FALSE. Be aware that using this option may cause VM portability issues since the guest may now depend on this behavior and the type of the underlying Mac.

See also: http://communities.vmware.com/thread/336922

==== VM power options always display "Force" ====

If the Virtual Machine was not originally created in VMware Fusion then you will notice that the Fusion Virtual Machine menu has the word "Force" inserted before any power option.
For example copying a VM from a Windows systems to Mac it displays the "Force ..." commands by default. In other words, pressing the Option Key is backwards of what it is supposed to be. This is because the following options are missing from the Virtual Machine's .vmx configuration file.

powerType.powerOff = "soft"
powerType.powerOn = "soft"
powerType.suspend = "soft"
powerType.reset = "soft"

By default, VMware Fusion creates these options in the Virtual Machine's .vmx configuration file while VMware Player/Workstation does not. So, add the above options to the Virtual Machine's .vmx configuration file and the "Force ..." commands will then exhibit VMware Fusion normal behavior. Meaning in order to access the "Force ..." commands one will need to press the Option Key.

See also: http://communities.vmware.com/thread/402281

==== kernel debugging ====

You can attach a remote debugger such as gdb to your vm to do kernel debugging.

DebugStub knows nothing at all about the guest OS. Think of debugStub as an In-Circuit Debugger for the virtual CPU(s).

debugStub.listen.guest64 = "TRUE"
debugStub.listen.guest64.remote = "TRUE"
debugStub.hideBreakpoints=1
specify a custom port with:
debugStub.port.guest64 = "8865"
other options:
debugStub.listen.guest32 = "TRUE" # Enable listener for 32 bit guest
debugStub.listen.guest32.remote = "TRUE" # Allow remote connection
debugStub.port.guest32 = "32001" # Listen on specified port NNN

see also: [https://communities.vmware.com/thread/470936 Using debugStub to debug a guest linux kernel]

==== Additional logging ====
For troubleshooting boot issues etcetera you can increase the log level in vmware.log

monitor_control.log_vmsample = "TRUE"

[https://communities.vmware.com/thread/471833 Fusion 6.0.2 / OS X 10.9.2 Host / OS X 10.9 Guest VM running >100% CPU no matter what]

==== memory hole ====

At 3.2 GB there's a 1024kB memory hole.

You can use the pciHole.start option to adjust the start of the memory hole, measured in megabytes from address 0x00000000. The default is

pciHole.start = 3072

which corresponds to 0xC0000000.

from [https://communities.vmware.com/thread/478739 Memory hole at 3.2GB]

==== Disable Shared Folder event notification ====

isolation.tools.hgfs.notify.enable = "FALSE"

See also: http://kb.vmware.com/kb/2011360

==== Shared folder size check ====

The other workaround is to stop the VM, edit the VM's .vmx file and add the following setting:

tools.hgfs.volumeInfoType = "max"

Then start the VM again, and this time you will not need to disable the other shares which are on smaller sized volumes.

The default setting causes the shares to be aggregated to the smallest volume size that a share resides on when our file system is queried for size and free space.

The above setting overrides this to pick the largest volume size. The downside is that you can start a copy to a share on volume with a smaller amount of free space and it will only fail when it actually fails to write when the free space is exhausted.

If you know you are not going to run into that type of scenario yourself or you verify prior to starting the copy operation then you will be fine.

Note, the above can only be set to "min" or "max" and if not set at all, then "min" is the default.

from: [https://communities.vmware.com/message/2381223#2381223 Folder copy on Windows 7 vm fails for "not enough space", but there is.]

==== Disable location services ====

sensor.location = "disable"

to vmx.

[https://communities.vmware.com/message/2383410#2383410 how-to disable location services]

==== Disable automatic USB connect to guest feature ====

1. Suspend or shut down any running VMs and quit Fusion.

2. Ensure that the vmware-usbarbitrator process is no longer running.

3. Create/edit the host-global configuration file, with root privileges: (this example uses nano, but feel free to use any other editor)

sudo nano /Library/Preferences/VMware\ Fusion/config

4. Add the following line to disable the automatic claiming of USB devices:

usbarb.autoconnect.claimAll = "FALSE"

5. Save the file and quit the editor.

With this change, all USB devices should automatically connect to the host even when VMs are running. Note that it will completely disable the USB connection prompt, and will prevent devices from automatically connecting to VMs (even if the option is selected in settings). However it should still be possible to manually connect USB devices to a running VM (except possibly in cases where the reset command is not correctly issued via the hub).

from: [https://communities.vmware.com/message/2393343#2393343 2014 Preview still has USB 3 hub issue]

==== Open file with host OS application ====
When a file is located on a shared folder (VMware HGFS) then you can choose to be able to open this file with the host OS default application.
For example. Your png file can open in macOS Preview.

proxyApps.publishToGuest = "TRUE"

See also: [https://communities.vmware.com/t5/VMware-Workstation-Pro/Has-there-ever-been-a-solution-to-opening-a-host-application/m-p/2841711/highlight/true#M169663 Has there ever been a solution to opening a host application from a guest OS?]

==== Pass OS X host serial number ====

If you want an OS X guest to use the host's serial number, you'll need to add this option to the VM's configuration:

serialNumber.reflectHost = "TRUE"

==== Pass OS X host hardware model ====

To pass hardware model to the guest (not even sure this works, as it does not seem to do anything for me, but ... Fusion does not error on starting the VM )

hw.model.reflectHost = "TRUE"

==== Pass OS X host hardware model ID ====

If you want an OS X guest to use the host's hardware model ID (i.e. "MacPro5,1"), board ID (i.e. "Mac-12345678") and serial number all together:

smbios.reflectHost = "TRUE"

=== Any platform ===

==== Slow down time in guest ====

You can't quite stop time, but you can make it go extremely slowly. Set the following in your system-wide configuration file (/etc/vmware/config on Linux; C:\ProgramData\VMware\VMware Workstation\config.ini on Windows):

host.cpukHz = 1000

This is probably not all that useful in practice, unless the guest OS has no reliance on any time sources.

from [https://communities.vmware.com/message/2431592#2431592 System time]

==== Set max number of snapshots ====

snapshot.maxSnapshots = 100

==== Enable DX11 or OpenGL Host Renderer ====

Courtesy @bluefirestorm at [https://communities.vmware.com/message/2812499#2812499 setting *.vmx]

mks.enableDX11Renderer

When 3D accelerated graphics is enabled in Workstation 12/14/15 the default value is "TRUE" (i.e. the line does not have to be present in the vmx file), VMware Workstation uses DX11 of the Windows host to deliver the DX10/OpenGL 3.3 core profile capability inside the VMs. For Linux hosts, the equivalent is mks.enableGLRenderer = "TRUE"

==== Enable D3D Renderer ====
Courtesy @bluefirestorm at [https://communities.vmware.com/message/2812499#2812499 setting *.vmx]

mks.enableD3DRenderer

Default is "FALSE" from Workstation 12.x and later. This is only useful in version 12.x if the host graphics card does not have DX11 capability and setting this to TRUE and enableDX11Renderer to FALSE let the VM have some limited 3D accelerated graphics capability. This looks like is already ineffective in version 14/15.

==== Select host Graphics card to use ====
Courtesy @bluefirestorm at [https://communities.vmware.com/message/2812499#2812499 setting *.vmx]

mks.dx11.vendorID

valid values are the vendor ID of the graphic card, 0x8086 for Intel, 0x10DE for Nvidia, 0x1002 for AMD.

If this line is not present, VMware Workstation will use the default graphic card of the Windows host system. This line is useful if the system has two graphic cards from two different vendors that are simultaneously active on the host machine (example: Intel integrated graphics in the CPU and a discrete graphics card from Nvidia or AMD).

==== ReflectHost ====
Courtesy @bluefirestorm at [https://communities.vmware.com/message/2812499#2812499 setting *.vmx]

SMBIOS.reflectHost

Default is "FALSE". If set to "TRUE" some of the DMI info will use the host values (example: manufacturer will change from VMware to the host value). You can see this difference by using msinfo32 in Windows VM or dmidecode in Linux VM. This is not so useful anymore to hide the fact that the VM is a VM.

==== vmx.buildType ====
Courtesy @bluefirestorm at [https://communities.vmware.com/message/2812499#2812499 setting *.vmx]

vmx.buildType

Valid values are "release" and "debug". The "debug" is the default for the beta versions (aka Tech Preview). When set to "debug", vmware-vmx-debug.exe will be used instead of vmware-vmx.exe and the vmware.log file will be larger.

=== External sites ===

There's only one .vmx site that has most .vmx options and that's Ulli's reference over at sanbarrow:

http://sanbarrow.com/vmx/vmx-advanced.html

Shrink guest on hosted platform

2021-10-12T23:15:55Z

Wila: /* Zero out using fstrim */

== Important ==
Note that the technique described below to zero out the unused space on the guest OS will in fact make your guest virtual disk grow to the maximum size first. For each byte that is changed to zero the virtual disk will need to claim a byte. This means that while you can use the technique to reclaim disk space after the unused space is zero'd out, it is important to have enough space before you start.

If you don't have that kind of free disk space then you can skip the zero-ing out part. You can still reclaim space, but it will be less optimal.
Alternatively you can use the "Partially zero out" trick described below.

=== How much free space do you need before shrinking? ===
Also please note that you need more free space in order to be able to run the shrinking process.
The shrinking process consists of making a copy of your virtual disk while omitting the zero'd out blocks.
So how much extra space you need depends on how you configured the virtual disk for your Virtual Machine.
If your Virtual Disk is a single file, then your free space requirement can grow up-to the full size of that virtual disk.

If OTOH you are using the split disk scheme where a virtual disk is sliced into multiple files the maximum free space you need is the maximum size a slice can be. Nowadays there's not a fixed slice size, it depends on how big your virtual disk actually is.

The split disk scheme since VMware Workstation 11 (VMware Fusion 7), older version of Workstation/Fusion use a 2GB split disk scheme.

Capacity Extent size
================================
<=128GB 4GB (increased from 2GB)
>128GB && <2TB Capacity / 32 (so maximum of 32 extents)
>=2TB 2TB

For extra safety I recommend to make sure you have an additional 2GB of free space on top of those requirements as mentioned above.

As side note, this also explains why it is generally recommended at the forum by the regulars to use a split disk scheme over single disk files.
This same problem also exists when you want to commit snapshots.

=== Using the clean up option in the menu ===

When you use the "Clean Up Disks" option in the menu in VMware Workstation 12 or later, then you do not require extra disk space for reclaiming space (see also: [https://docs.vmware.com/en/VMware-Workstation-Pro/14.0/com.vmware.ws.using.doc/GUID-421A1073-BF16-4BC7-AA76-46B954CA438D.html Clean Up a Virtual Hard Disk on Windows Hosts] )

Currently this only works for Windows guests where the filesystem is NTFS.

== Zero out unused space in a Linux VM ==

Before we try to shrink the virtual disk files, we should try to remove any unneeded files from the virtual machine to free space.
More free space means more disk space that can get reclaimed.

One of the areas in a VM that can take up a lot of disk space is the repository cache. So I personally tend to clean the cache in the VM before reclaiming disk space at the host.

Clean up your repositories:

For example, on Debian-based VMs, you can run the following command (in the VM)

apt-get clean all

to clear out the local repository of retrieved package files.

On red hat based VMs that would be:

yum clean

The next step is important:

Shut down any services that depend on having enough available disk space to run.

The reason for this is that we are going to write out zero's to the file system until the file system is full and we do not want any application - for example a database system like mySQL or postgreSQL - to run out of disk space while we are zeroing out the file system. If mySQL would try to write when your disk is full you risk a corrupted database. So this step is important!

Next run (also from within the VM):

cat /dev/zero > zero.fill;sync;sleep 1;sync;rm -f zero.fill

to fill the unused space with zeros and then remove the "zero.fill" that has all the zero's.

As this command writes to the disk until it runs out of disk space, you will get an error "No space left on the device". This is expected.

Note that you have multiple partitions that you have to repeat the above command to zero out for each partition.
Adjust "zero.fill" to the relevant mountpoint, for example if you have a separate partition for home it would become:

cat /dev/zero > /home/zero.fill;sync;sleep 1;sync;rm -f /home/zero.fill

=== Zero out a part of your virtual disk ===

If your virtual machine cannot be taken down and you do not want to shut down services that might end up corrupting files because of the "No space left on the device" problem then an idea that might work is to zero out a part of your partition.

This for example creates a 100MB size file filled with zero's

# dd if=/dev/zero of=zero.fill bs=1024 count=102400
102400+0 records in
102400+0 records out
104857600 bytes (105 MB) copied, 0.3839 s, 273 MB/s

So if you want to zero out 10GB instead, add two more zero's to the count parameter, eg: count=10240000

If you want to fill up in steps, just change the output file name from "zero.fill" into "zero.fill2" etcetera..

Then run the "sync; sleep 1; sync" from above and remove the zero.fill files.

If your VM is running on VMware vSphere and you have a NFS LUN with enough free space then one way to reclaim your space is to Storage vMotion the VM to NFS storage and back. Once done the zero'd out data has been reclaimed. No need to shut down the VM.

If this is not for you, then do read on.

=== Zero out using fstrim ===

These days there's an alternative way for zero-ing out the parts of the disk that are not used using [https://www.man7.org/linux/man-pages/man8/fstrim.8.html fstrim].

The great thing about this is that it only zero's out the parts of the disk that are not zero and as such the disk does not inflate to its full size.

* [https://forums.freebsd.org/threads/ssd-trim-maintenance.56951/post-328912 Detail comment from Theodore Ts'o on using fstrim]

* [https://github.com/vmware/open-vm-tools/issues/457 Avoid disk expansion while shrinking (github issue tracker)]

== Zero out unused space on a Windows VM ==

To do the same with a windows VM, you can use Microsoft's tool [http://technet.microsoft.com/en-us/sysinternals/bb897443.aspx sdelete].

Run it as
sdelete -z c:

To clean out the free space on disk c:

Careful!

As of sdelete v1.6 -c and -z have changed meanings, many instructions say -c zeros free space, this is no longer the case, it zeros the space then fills with random data in accordance with DOD spec: DOD 5220.22-M, random data will prevent the reclaim logic from working.

The trigger to zero space with 0x00 has changed to -z!

== Zeroing an encrypted disk ==

If you use disk encryption in the guest OS then zero'ing out the disk won't help.

The reason is that a good disk encryption scheme will write out random data to the disk when you write out zero's.

In other words, if you have enabled full disk encryption in the guest then you can not shrink the disk anymore as there is no space to reclaim.

== Shrink the disk ==

Then power down the VM and open a terminal on the Linux host.

Navigate to the directory where the .vmdk files are located, e.g.:

cd /var/lib/vmware/Virtual\ Machines/Ubuntu\ Desktop/

You can shrink the .vmdk file as follows:

vmware-vdiskmanager -k Ubuntu\ Desktop.vmdk

On Windows the command also uses the -k option, so I leave that for you as an exercise.

Note that vmware-vdiskmanager is probably not in your search path, so you might have to prepend the vmware-vdiskmanager command with the actual path with the command is located.

If you need to use "sudo" in order to be able to run the above then beware that the ownership of the .vmdk files might get changed to root.

You will have to change the ownership back to your own user, eg:
sudo chown username: *.vmdk
If you don't change the ownership back you might see errors like:
"Unable to open file .../Virtual Disk.vmdk: Insufficient permission to access file".

== Shrink using vmware tools ==

Nowadays you can also shrink the guest by using the shrink feature as offered via vmware tools.

So for clarity all of the following commands are run from within the guest to shrink the disk while the guest is running.

On linux in order to use this run:
sudo vmware-toolbox-cmd disk shrink /

Where "/" is the mount point of the partition that you want to shrink.

On Windows in order to use this run (as administrator):

C:\Program Files\VMware\VMware Tools>VMwareToolboxCmd.exe disk shrink <location>

where <location> is the drive you want to shrink

For example:
C:\Program Files\VMware\VMware Tools>VMwareToolboxCmd.exe disk shrink c:\
Please disregard any warnings about disk space for the duration of shrink process.
Progress: 62 [=======> ]
The progress you see here is VMware Tools blanking out the unused space.

At 99% it will popup the "Shrinking Disk" progress dialog at the host that takes care of the actual shrinking process.

If you are logged in via remote desktop then do expect to loose the connection for a bit while the actual shrinking is taking place.

On OS X / macOS the command to use is:

sudo /Library/Application\ Support/VMware\ Tools/vmware-tools-cli disk shrink /

== Shrink macOS VM with APFS ==

[https://communities.vmware.com/thread/581576 Solved: Shrink an APFS virtual disk]

== External links ==

* [https://docs.vmware.com/en/VMware-Workstation-Pro/16.0/com.vmware.ws.using.doc/GUID-421A1073-BF16-4BC7-AA76-46B954CA438D.html Clean Up a Virtual Hard Disk on Windows Hosts - Workstation 16 Pro documentation]

* [https://docs.vmware.com/en/VMware-Workstation-Pro/16.0/com.vmware.ws.using.doc/GUID-3F94C7B5-19A5-4E91-9709-B17FAA93FF75.html Configuring and Maintaining Virtual Hard Disks - Workstation 16 Pro documentation]

* [https://docs.vmware.com/en/VMware-Fusion/12/com.vmware.fusion.using.doc/GUID-6BB29187-F47F-41D1-AD92-1754036DACD9.html#GUID-6BB29187-F47F-41D1-AD92-1754036DACD9 Clean up a Virtual Machine - VMware Fusion 12 documentation]

Shrink guest on hosted platform

2021-10-12T22:23:06Z

Wila: /* Zero out using fstrim */

== Important ==
Note that the technique described below to zero out the unused space on the guest OS will in fact make your guest virtual disk grow to the maximum size first. For each byte that is changed to zero the virtual disk will need to claim a byte. This means that while you can use the technique to reclaim disk space after the unused space is zero'd out, it is important to have enough space before you start.

If you don't have that kind of free disk space then you can skip the zero-ing out part. You can still reclaim space, but it will be less optimal.
Alternatively you can use the "Partially zero out" trick described below.

=== How much free space do you need before shrinking? ===
Also please note that you need more free space in order to be able to run the shrinking process.
The shrinking process consists of making a copy of your virtual disk while omitting the zero'd out blocks.
So how much extra space you need depends on how you configured the virtual disk for your Virtual Machine.
If your Virtual Disk is a single file, then your free space requirement can grow up-to the full size of that virtual disk.

If OTOH you are using the split disk scheme where a virtual disk is sliced into multiple files the maximum free space you need is the maximum size a slice can be. Nowadays there's not a fixed slice size, it depends on how big your virtual disk actually is.

The split disk scheme since VMware Workstation 11 (VMware Fusion 7), older version of Workstation/Fusion use a 2GB split disk scheme.

Capacity Extent size
================================
<=128GB 4GB (increased from 2GB)
>128GB && <2TB Capacity / 32 (so maximum of 32 extents)
>=2TB 2TB

For extra safety I recommend to make sure you have an additional 2GB of free space on top of those requirements as mentioned above.

As side note, this also explains why it is generally recommended at the forum by the regulars to use a split disk scheme over single disk files.
This same problem also exists when you want to commit snapshots.

=== Using the clean up option in the menu ===

When you use the "Clean Up Disks" option in the menu in VMware Workstation 12 or later, then you do not require extra disk space for reclaiming space (see also: [https://docs.vmware.com/en/VMware-Workstation-Pro/14.0/com.vmware.ws.using.doc/GUID-421A1073-BF16-4BC7-AA76-46B954CA438D.html Clean Up a Virtual Hard Disk on Windows Hosts] )

Currently this only works for Windows guests where the filesystem is NTFS.

== Zero out unused space in a Linux VM ==

Before we try to shrink the virtual disk files, we should try to remove any unneeded files from the virtual machine to free space.
More free space means more disk space that can get reclaimed.

One of the areas in a VM that can take up a lot of disk space is the repository cache. So I personally tend to clean the cache in the VM before reclaiming disk space at the host.

Clean up your repositories:

For example, on Debian-based VMs, you can run the following command (in the VM)

apt-get clean all

to clear out the local repository of retrieved package files.

On red hat based VMs that would be:

yum clean

The next step is important:

Shut down any services that depend on having enough available disk space to run.

The reason for this is that we are going to write out zero's to the file system until the file system is full and we do not want any application - for example a database system like mySQL or postgreSQL - to run out of disk space while we are zeroing out the file system. If mySQL would try to write when your disk is full you risk a corrupted database. So this step is important!

Next run (also from within the VM):

cat /dev/zero > zero.fill;sync;sleep 1;sync;rm -f zero.fill

to fill the unused space with zeros and then remove the "zero.fill" that has all the zero's.

As this command writes to the disk until it runs out of disk space, you will get an error "No space left on the device". This is expected.

Note that you have multiple partitions that you have to repeat the above command to zero out for each partition.
Adjust "zero.fill" to the relevant mountpoint, for example if you have a separate partition for home it would become:

cat /dev/zero > /home/zero.fill;sync;sleep 1;sync;rm -f /home/zero.fill

=== Zero out a part of your virtual disk ===

If your virtual machine cannot be taken down and you do not want to shut down services that might end up corrupting files because of the "No space left on the device" problem then an idea that might work is to zero out a part of your partition.

This for example creates a 100MB size file filled with zero's

# dd if=/dev/zero of=zero.fill bs=1024 count=102400
102400+0 records in
102400+0 records out
104857600 bytes (105 MB) copied, 0.3839 s, 273 MB/s

So if you want to zero out 10GB instead, add two more zero's to the count parameter, eg: count=10240000

If you want to fill up in steps, just change the output file name from "zero.fill" into "zero.fill2" etcetera..

Then run the "sync; sleep 1; sync" from above and remove the zero.fill files.

If your VM is running on VMware vSphere and you have a NFS LUN with enough free space then one way to reclaim your space is to Storage vMotion the VM to NFS storage and back. Once done the zero'd out data has been reclaimed. No need to shut down the VM.

If this is not for you, then do read on.

=== Zero out using fstrim ===

These days there's an alternative way for zero-ing out the parts of the disk that are not used using [https://www.man7.org/linux/man-pages/man8/fstrim.8.html fstrim].

The great thing about this is that it only zero's out the parts of the disk that are not zero and as such the disk does not inflate to its full size.

[https://forums.freebsd.org/threads/ssd-trim-maintenance.56951/post-328912 Detail comment from Theodore Ts'o on using fstrim]

== Zero out unused space on a Windows VM ==

To do the same with a windows VM, you can use Microsoft's tool [http://technet.microsoft.com/en-us/sysinternals/bb897443.aspx sdelete].

Run it as
sdelete -z c:

To clean out the free space on disk c:

Careful!

As of sdelete v1.6 -c and -z have changed meanings, many instructions say -c zeros free space, this is no longer the case, it zeros the space then fills with random data in accordance with DOD spec: DOD 5220.22-M, random data will prevent the reclaim logic from working.

The trigger to zero space with 0x00 has changed to -z!

== Zeroing an encrypted disk ==

If you use disk encryption in the guest OS then zero'ing out the disk won't help.

The reason is that a good disk encryption scheme will write out random data to the disk when you write out zero's.

In other words, if you have enabled full disk encryption in the guest then you can not shrink the disk anymore as there is no space to reclaim.

== Shrink the disk ==

Then power down the VM and open a terminal on the Linux host.

Navigate to the directory where the .vmdk files are located, e.g.:

cd /var/lib/vmware/Virtual\ Machines/Ubuntu\ Desktop/

You can shrink the .vmdk file as follows:

vmware-vdiskmanager -k Ubuntu\ Desktop.vmdk

On Windows the command also uses the -k option, so I leave that for you as an exercise.

Note that vmware-vdiskmanager is probably not in your search path, so you might have to prepend the vmware-vdiskmanager command with the actual path with the command is located.

If you need to use "sudo" in order to be able to run the above then beware that the ownership of the .vmdk files might get changed to root.

You will have to change the ownership back to your own user, eg:
sudo chown username: *.vmdk
If you don't change the ownership back you might see errors like:
"Unable to open file .../Virtual Disk.vmdk: Insufficient permission to access file".

== Shrink using vmware tools ==

Nowadays you can also shrink the guest by using the shrink feature as offered via vmware tools.

So for clarity all of the following commands are run from within the guest to shrink the disk while the guest is running.

On linux in order to use this run:
sudo vmware-toolbox-cmd disk shrink /

Where "/" is the mount point of the partition that you want to shrink.

On Windows in order to use this run (as administrator):

C:\Program Files\VMware\VMware Tools>VMwareToolboxCmd.exe disk shrink <location>

where <location> is the drive you want to shrink

For example:
C:\Program Files\VMware\VMware Tools>VMwareToolboxCmd.exe disk shrink c:\
Please disregard any warnings about disk space for the duration of shrink process.
Progress: 62 [=======> ]
The progress you see here is VMware Tools blanking out the unused space.

At 99% it will popup the "Shrinking Disk" progress dialog at the host that takes care of the actual shrinking process.

If you are logged in via remote desktop then do expect to loose the connection for a bit while the actual shrinking is taking place.

On OS X / macOS the command to use is:

sudo /Library/Application\ Support/VMware\ Tools/vmware-tools-cli disk shrink /

== Shrink macOS VM with APFS ==

[https://communities.vmware.com/thread/581576 Solved: Shrink an APFS virtual disk]

== External links ==

* [https://docs.vmware.com/en/VMware-Workstation-Pro/16.0/com.vmware.ws.using.doc/GUID-421A1073-BF16-4BC7-AA76-46B954CA438D.html Clean Up a Virtual Hard Disk on Windows Hosts - Workstation 16 Pro documentation]

* [https://docs.vmware.com/en/VMware-Workstation-Pro/16.0/com.vmware.ws.using.doc/GUID-3F94C7B5-19A5-4E91-9709-B17FAA93FF75.html Configuring and Maintaining Virtual Hard Disks - Workstation 16 Pro documentation]

* [https://docs.vmware.com/en/VMware-Fusion/12/com.vmware.fusion.using.doc/GUID-6BB29187-F47F-41D1-AD92-1754036DACD9.html#GUID-6BB29187-F47F-41D1-AD92-1754036DACD9 Clean up a Virtual Machine - VMware Fusion 12 documentation]

Shrink guest on hosted platform

2021-10-12T22:14:49Z

Wila: /* Zero out using fstrim */

== Important ==
Note that the technique described below to zero out the unused space on the guest OS will in fact make your guest virtual disk grow to the maximum size first. For each byte that is changed to zero the virtual disk will need to claim a byte. This means that while you can use the technique to reclaim disk space after the unused space is zero'd out, it is important to have enough space before you start.

If you don't have that kind of free disk space then you can skip the zero-ing out part. You can still reclaim space, but it will be less optimal.
Alternatively you can use the "Partially zero out" trick described below.

=== How much free space do you need before shrinking? ===
Also please note that you need more free space in order to be able to run the shrinking process.
The shrinking process consists of making a copy of your virtual disk while omitting the zero'd out blocks.
So how much extra space you need depends on how you configured the virtual disk for your Virtual Machine.
If your Virtual Disk is a single file, then your free space requirement can grow up-to the full size of that virtual disk.

If OTOH you are using the split disk scheme where a virtual disk is sliced into multiple files the maximum free space you need is the maximum size a slice can be. Nowadays there's not a fixed slice size, it depends on how big your virtual disk actually is.

The split disk scheme since VMware Workstation 11 (VMware Fusion 7), older version of Workstation/Fusion use a 2GB split disk scheme.

Capacity Extent size
================================
<=128GB 4GB (increased from 2GB)
>128GB && <2TB Capacity / 32 (so maximum of 32 extents)
>=2TB 2TB

For extra safety I recommend to make sure you have an additional 2GB of free space on top of those requirements as mentioned above.

As side note, this also explains why it is generally recommended at the forum by the regulars to use a split disk scheme over single disk files.
This same problem also exists when you want to commit snapshots.

=== Using the clean up option in the menu ===

When you use the "Clean Up Disks" option in the menu in VMware Workstation 12 or later, then you do not require extra disk space for reclaiming space (see also: [https://docs.vmware.com/en/VMware-Workstation-Pro/14.0/com.vmware.ws.using.doc/GUID-421A1073-BF16-4BC7-AA76-46B954CA438D.html Clean Up a Virtual Hard Disk on Windows Hosts] )

Currently this only works for Windows guests where the filesystem is NTFS.

== Zero out unused space in a Linux VM ==

Before we try to shrink the virtual disk files, we should try to remove any unneeded files from the virtual machine to free space.
More free space means more disk space that can get reclaimed.

One of the areas in a VM that can take up a lot of disk space is the repository cache. So I personally tend to clean the cache in the VM before reclaiming disk space at the host.

Clean up your repositories:

For example, on Debian-based VMs, you can run the following command (in the VM)

apt-get clean all

to clear out the local repository of retrieved package files.

On red hat based VMs that would be:

yum clean

The next step is important:

Shut down any services that depend on having enough available disk space to run.

The reason for this is that we are going to write out zero's to the file system until the file system is full and we do not want any application - for example a database system like mySQL or postgreSQL - to run out of disk space while we are zeroing out the file system. If mySQL would try to write when your disk is full you risk a corrupted database. So this step is important!

Next run (also from within the VM):

cat /dev/zero > zero.fill;sync;sleep 1;sync;rm -f zero.fill

to fill the unused space with zeros and then remove the "zero.fill" that has all the zero's.

As this command writes to the disk until it runs out of disk space, you will get an error "No space left on the device". This is expected.

Note that you have multiple partitions that you have to repeat the above command to zero out for each partition.
Adjust "zero.fill" to the relevant mountpoint, for example if you have a separate partition for home it would become:

cat /dev/zero > /home/zero.fill;sync;sleep 1;sync;rm -f /home/zero.fill

=== Zero out a part of your virtual disk ===

If your virtual machine cannot be taken down and you do not want to shut down services that might end up corrupting files because of the "No space left on the device" problem then an idea that might work is to zero out a part of your partition.

This for example creates a 100MB size file filled with zero's

# dd if=/dev/zero of=zero.fill bs=1024 count=102400
102400+0 records in
102400+0 records out
104857600 bytes (105 MB) copied, 0.3839 s, 273 MB/s

So if you want to zero out 10GB instead, add two more zero's to the count parameter, eg: count=10240000

If you want to fill up in steps, just change the output file name from "zero.fill" into "zero.fill2" etcetera..

Then run the "sync; sleep 1; sync" from above and remove the zero.fill files.

If your VM is running on VMware vSphere and you have a NFS LUN with enough free space then one way to reclaim your space is to Storage vMotion the VM to NFS storage and back. Once done the zero'd out data has been reclaimed. No need to shut down the VM.

If this is not for you, then do read on.

=== Zero out using fstrim ===

These days there's an alternative way for zero-ing out the parts of the disk that are not used using [https://www.man7.org/linux/man-pages/man8/fstrim.8.html fstrim].

The great thing about this is that it only zero's out the parts of the disk that are not zero and as such the disk does not inflate to its full size.

== Zero out unused space on a Windows VM ==

To do the same with a windows VM, you can use Microsoft's tool [http://technet.microsoft.com/en-us/sysinternals/bb897443.aspx sdelete].

Run it as
sdelete -z c:

To clean out the free space on disk c:

Careful!

As of sdelete v1.6 -c and -z have changed meanings, many instructions say -c zeros free space, this is no longer the case, it zeros the space then fills with random data in accordance with DOD spec: DOD 5220.22-M, random data will prevent the reclaim logic from working.

The trigger to zero space with 0x00 has changed to -z!

== Zeroing an encrypted disk ==

If you use disk encryption in the guest OS then zero'ing out the disk won't help.

The reason is that a good disk encryption scheme will write out random data to the disk when you write out zero's.

In other words, if you have enabled full disk encryption in the guest then you can not shrink the disk anymore as there is no space to reclaim.

== Shrink the disk ==

Then power down the VM and open a terminal on the Linux host.

Navigate to the directory where the .vmdk files are located, e.g.:

cd /var/lib/vmware/Virtual\ Machines/Ubuntu\ Desktop/

You can shrink the .vmdk file as follows:

vmware-vdiskmanager -k Ubuntu\ Desktop.vmdk

On Windows the command also uses the -k option, so I leave that for you as an exercise.

Note that vmware-vdiskmanager is probably not in your search path, so you might have to prepend the vmware-vdiskmanager command with the actual path with the command is located.

If you need to use "sudo" in order to be able to run the above then beware that the ownership of the .vmdk files might get changed to root.

You will have to change the ownership back to your own user, eg:
sudo chown username: *.vmdk
If you don't change the ownership back you might see errors like:
"Unable to open file .../Virtual Disk.vmdk: Insufficient permission to access file".

== Shrink using vmware tools ==

Nowadays you can also shrink the guest by using the shrink feature as offered via vmware tools.

So for clarity all of the following commands are run from within the guest to shrink the disk while the guest is running.

On linux in order to use this run:
sudo vmware-toolbox-cmd disk shrink /

Where "/" is the mount point of the partition that you want to shrink.

On Windows in order to use this run (as administrator):

C:\Program Files\VMware\VMware Tools>VMwareToolboxCmd.exe disk shrink <location>

where <location> is the drive you want to shrink

For example:
C:\Program Files\VMware\VMware Tools>VMwareToolboxCmd.exe disk shrink c:\
Please disregard any warnings about disk space for the duration of shrink process.
Progress: 62 [=======> ]
The progress you see here is VMware Tools blanking out the unused space.

At 99% it will popup the "Shrinking Disk" progress dialog at the host that takes care of the actual shrinking process.

If you are logged in via remote desktop then do expect to loose the connection for a bit while the actual shrinking is taking place.

On OS X / macOS the command to use is:

sudo /Library/Application\ Support/VMware\ Tools/vmware-tools-cli disk shrink /

== Shrink macOS VM with APFS ==

[https://communities.vmware.com/thread/581576 Solved: Shrink an APFS virtual disk]

== External links ==

* [https://docs.vmware.com/en/VMware-Workstation-Pro/16.0/com.vmware.ws.using.doc/GUID-421A1073-BF16-4BC7-AA76-46B954CA438D.html Clean Up a Virtual Hard Disk on Windows Hosts - Workstation 16 Pro documentation]

* [https://docs.vmware.com/en/VMware-Workstation-Pro/16.0/com.vmware.ws.using.doc/GUID-3F94C7B5-19A5-4E91-9709-B17FAA93FF75.html Configuring and Maintaining Virtual Hard Disks - Workstation 16 Pro documentation]

* [https://docs.vmware.com/en/VMware-Fusion/12/com.vmware.fusion.using.doc/GUID-6BB29187-F47F-41D1-AD92-1754036DACD9.html#GUID-6BB29187-F47F-41D1-AD92-1754036DACD9 Clean up a Virtual Machine - VMware Fusion 12 documentation]

Shrink guest on hosted platform

2021-10-12T22:12:58Z

Wila: /* Zero out a part of your virtual disk */

== Important ==
Note that the technique described below to zero out the unused space on the guest OS will in fact make your guest virtual disk grow to the maximum size first. For each byte that is changed to zero the virtual disk will need to claim a byte. This means that while you can use the technique to reclaim disk space after the unused space is zero'd out, it is important to have enough space before you start.

If you don't have that kind of free disk space then you can skip the zero-ing out part. You can still reclaim space, but it will be less optimal.
Alternatively you can use the "Partially zero out" trick described below.

=== How much free space do you need before shrinking? ===
Also please note that you need more free space in order to be able to run the shrinking process.
The shrinking process consists of making a copy of your virtual disk while omitting the zero'd out blocks.
So how much extra space you need depends on how you configured the virtual disk for your Virtual Machine.
If your Virtual Disk is a single file, then your free space requirement can grow up-to the full size of that virtual disk.

If OTOH you are using the split disk scheme where a virtual disk is sliced into multiple files the maximum free space you need is the maximum size a slice can be. Nowadays there's not a fixed slice size, it depends on how big your virtual disk actually is.

The split disk scheme since VMware Workstation 11 (VMware Fusion 7), older version of Workstation/Fusion use a 2GB split disk scheme.

Capacity Extent size
================================
<=128GB 4GB (increased from 2GB)
>128GB && <2TB Capacity / 32 (so maximum of 32 extents)
>=2TB 2TB

For extra safety I recommend to make sure you have an additional 2GB of free space on top of those requirements as mentioned above.

As side note, this also explains why it is generally recommended at the forum by the regulars to use a split disk scheme over single disk files.
This same problem also exists when you want to commit snapshots.

=== Using the clean up option in the menu ===

When you use the "Clean Up Disks" option in the menu in VMware Workstation 12 or later, then you do not require extra disk space for reclaiming space (see also: [https://docs.vmware.com/en/VMware-Workstation-Pro/14.0/com.vmware.ws.using.doc/GUID-421A1073-BF16-4BC7-AA76-46B954CA438D.html Clean Up a Virtual Hard Disk on Windows Hosts] )

Currently this only works for Windows guests where the filesystem is NTFS.

== Zero out unused space in a Linux VM ==

Before we try to shrink the virtual disk files, we should try to remove any unneeded files from the virtual machine to free space.
More free space means more disk space that can get reclaimed.

One of the areas in a VM that can take up a lot of disk space is the repository cache. So I personally tend to clean the cache in the VM before reclaiming disk space at the host.

Clean up your repositories:

For example, on Debian-based VMs, you can run the following command (in the VM)

apt-get clean all

to clear out the local repository of retrieved package files.

On red hat based VMs that would be:

yum clean

The next step is important:

Shut down any services that depend on having enough available disk space to run.

The reason for this is that we are going to write out zero's to the file system until the file system is full and we do not want any application - for example a database system like mySQL or postgreSQL - to run out of disk space while we are zeroing out the file system. If mySQL would try to write when your disk is full you risk a corrupted database. So this step is important!

Next run (also from within the VM):

cat /dev/zero > zero.fill;sync;sleep 1;sync;rm -f zero.fill

to fill the unused space with zeros and then remove the "zero.fill" that has all the zero's.

As this command writes to the disk until it runs out of disk space, you will get an error "No space left on the device". This is expected.

Note that you have multiple partitions that you have to repeat the above command to zero out for each partition.
Adjust "zero.fill" to the relevant mountpoint, for example if you have a separate partition for home it would become:

cat /dev/zero > /home/zero.fill;sync;sleep 1;sync;rm -f /home/zero.fill

=== Zero out a part of your virtual disk ===

If your virtual machine cannot be taken down and you do not want to shut down services that might end up corrupting files because of the "No space left on the device" problem then an idea that might work is to zero out a part of your partition.

This for example creates a 100MB size file filled with zero's

# dd if=/dev/zero of=zero.fill bs=1024 count=102400
102400+0 records in
102400+0 records out
104857600 bytes (105 MB) copied, 0.3839 s, 273 MB/s

So if you want to zero out 10GB instead, add two more zero's to the count parameter, eg: count=10240000

If you want to fill up in steps, just change the output file name from "zero.fill" into "zero.fill2" etcetera..

Then run the "sync; sleep 1; sync" from above and remove the zero.fill files.

If your VM is running on VMware vSphere and you have a NFS LUN with enough free space then one way to reclaim your space is to Storage vMotion the VM to NFS storage and back. Once done the zero'd out data has been reclaimed. No need to shut down the VM.

If this is not for you, then do read on.

=== Zero out using fstrim ===

These days there's an alternative way for zero-ing out the parts of the disk that are not used using fstrim.

The great thing about this is that it only zero's out the parts of the disk that are not zero and as such the disk does not inflate to its full size.

== Zero out unused space on a Windows VM ==

To do the same with a windows VM, you can use Microsoft's tool [http://technet.microsoft.com/en-us/sysinternals/bb897443.aspx sdelete].

Run it as
sdelete -z c:

To clean out the free space on disk c:

Careful!

As of sdelete v1.6 -c and -z have changed meanings, many instructions say -c zeros free space, this is no longer the case, it zeros the space then fills with random data in accordance with DOD spec: DOD 5220.22-M, random data will prevent the reclaim logic from working.

The trigger to zero space with 0x00 has changed to -z!

== Zeroing an encrypted disk ==

If you use disk encryption in the guest OS then zero'ing out the disk won't help.

The reason is that a good disk encryption scheme will write out random data to the disk when you write out zero's.

In other words, if you have enabled full disk encryption in the guest then you can not shrink the disk anymore as there is no space to reclaim.

== Shrink the disk ==

Then power down the VM and open a terminal on the Linux host.

Navigate to the directory where the .vmdk files are located, e.g.:

cd /var/lib/vmware/Virtual\ Machines/Ubuntu\ Desktop/

You can shrink the .vmdk file as follows:

vmware-vdiskmanager -k Ubuntu\ Desktop.vmdk

On Windows the command also uses the -k option, so I leave that for you as an exercise.

Note that vmware-vdiskmanager is probably not in your search path, so you might have to prepend the vmware-vdiskmanager command with the actual path with the command is located.

If you need to use "sudo" in order to be able to run the above then beware that the ownership of the .vmdk files might get changed to root.

You will have to change the ownership back to your own user, eg:
sudo chown username: *.vmdk
If you don't change the ownership back you might see errors like:
"Unable to open file .../Virtual Disk.vmdk: Insufficient permission to access file".

== Shrink using vmware tools ==

Nowadays you can also shrink the guest by using the shrink feature as offered via vmware tools.

So for clarity all of the following commands are run from within the guest to shrink the disk while the guest is running.

On linux in order to use this run:
sudo vmware-toolbox-cmd disk shrink /

Where "/" is the mount point of the partition that you want to shrink.

On Windows in order to use this run (as administrator):

C:\Program Files\VMware\VMware Tools>VMwareToolboxCmd.exe disk shrink <location>

where <location> is the drive you want to shrink

For example:
C:\Program Files\VMware\VMware Tools>VMwareToolboxCmd.exe disk shrink c:\
Please disregard any warnings about disk space for the duration of shrink process.
Progress: 62 [=======> ]
The progress you see here is VMware Tools blanking out the unused space.

At 99% it will popup the "Shrinking Disk" progress dialog at the host that takes care of the actual shrinking process.

If you are logged in via remote desktop then do expect to loose the connection for a bit while the actual shrinking is taking place.

On OS X / macOS the command to use is:

sudo /Library/Application\ Support/VMware\ Tools/vmware-tools-cli disk shrink /

== Shrink macOS VM with APFS ==

[https://communities.vmware.com/thread/581576 Solved: Shrink an APFS virtual disk]

== External links ==

* [https://docs.vmware.com/en/VMware-Workstation-Pro/16.0/com.vmware.ws.using.doc/GUID-421A1073-BF16-4BC7-AA76-46B954CA438D.html Clean Up a Virtual Hard Disk on Windows Hosts - Workstation 16 Pro documentation]

* [https://docs.vmware.com/en/VMware-Workstation-Pro/16.0/com.vmware.ws.using.doc/GUID-3F94C7B5-19A5-4E91-9709-B17FAA93FF75.html Configuring and Maintaining Virtual Hard Disks - Workstation 16 Pro documentation]

* [https://docs.vmware.com/en/VMware-Fusion/12/com.vmware.fusion.using.doc/GUID-6BB29187-F47F-41D1-AD92-1754036DACD9.html#GUID-6BB29187-F47F-41D1-AD92-1754036DACD9 Clean up a Virtual Machine - VMware Fusion 12 documentation]

Open-vm-tools

2021-10-11T22:56:38Z

Wila: /* old links */

==== Open Virtual Machine Tools ====

The Open Virtual Machine Tools (open-vm-tools) are the open source implementation of VMware Tools.

Almost all of the current Linux distributions carry this version of VMware Tools in their repositories.
This is also the preferred version of VMware Tools over what might be bundled with VMware's products.

You will also find this on other open source operating systems such as FreeBSD.

The Open Virtual Machine Tools project aims to provide a suite of open source virtualization utilities and drivers to improve the functionality and user experience of virtualization. The project currently runs in guest operating systems under VMware hypervisors.

Project page: https://github.com/vmware/open-vm-tools

=== Install on Debian / Ubuntu ===

On a server:
sudo apt-get install open-vm-tools

On a desktop:
sudo apt-get install open-vm-tools open-vm-tools-desktop

=== Install on CentOS / RedHat ===

On a server:
sudo dnf install open-vm-tools

On a desktop:
sudo dnf install open-vm-tools open-vm-tools-desktop

Installing X11 driver:
sudo dnf install xorg-x11-drv-vmware

=== old links ===
* [http://sourceforge.net/projects/open-vm-tools/ sourceforge open-vm-tools project page]

* [http://open-vm-tools.sourceforge.net/ homepage]

[[Category: VMware OSS]]

Open-vm-tools

2021-10-11T22:56:16Z

Wila: /* old links */

==== Open Virtual Machine Tools ====

The Open Virtual Machine Tools (open-vm-tools) are the open source implementation of VMware Tools.

Almost all of the current Linux distributions carry this version of VMware Tools in their repositories.
This is also the preferred version of VMware Tools over what might be bundled with VMware's products.

You will also find this on other open source operating systems such as FreeBSD.

The Open Virtual Machine Tools project aims to provide a suite of open source virtualization utilities and drivers to improve the functionality and user experience of virtualization. The project currently runs in guest operating systems under VMware hypervisors.

Project page: https://github.com/vmware/open-vm-tools

=== Install on Debian / Ubuntu ===

On a server:
sudo apt-get install open-vm-tools

On a desktop:
sudo apt-get install open-vm-tools open-vm-tools-desktop

=== Install on CentOS / RedHat ===

On a server:
sudo dnf install open-vm-tools

On a desktop:
sudo dnf install open-vm-tools open-vm-tools-desktop

Installing X11 driver:
sudo dnf install xorg-x11-drv-vmware

==== old links ====
* [http://sourceforge.net/projects/open-vm-tools/ sourceforge open-vm-tools project page]

* [http://open-vm-tools.sourceforge.net/ homepage]

[[Category: VMware OSS]]

Open-vm-tools

2021-10-11T22:55:47Z

Wila:

==== Open Virtual Machine Tools ====

The Open Virtual Machine Tools (open-vm-tools) are the open source implementation of VMware Tools.

Almost all of the current Linux distributions carry this version of VMware Tools in their repositories.
This is also the preferred version of VMware Tools over what might be bundled with VMware's products.

You will also find this on other open source operating systems such as FreeBSD.

The Open Virtual Machine Tools project aims to provide a suite of open source virtualization utilities and drivers to improve the functionality and user experience of virtualization. The project currently runs in guest operating systems under VMware hypervisors.

Project page: https://github.com/vmware/open-vm-tools

=== Install on Debian / Ubuntu ===

On a server:
sudo apt-get install open-vm-tools

On a desktop:
sudo apt-get install open-vm-tools open-vm-tools-desktop

=== Install on CentOS / RedHat ===

On a server:
sudo dnf install open-vm-tools

On a desktop:
sudo dnf install open-vm-tools open-vm-tools-desktop

Installing X11 driver:
sudo dnf install xorg-x11-drv-vmware

===== old links =====
* [http://sourceforge.net/projects/open-vm-tools/ sourceforge open-vm-tools project page]

* [http://open-vm-tools.sourceforge.net/ homepage]

[[Category: VMware OSS]]

Open-vm-tools

2021-10-11T22:46:52Z

Wila: /* Open Virtual Machine Tools */

==== Open Virtual Machine Tools ====

The Open Virtual Machine Tools (open-vm-tools) are the open source implementation of VMware Tools.

Almost all of the current Linux distributions carry this version of VMware Tools in their repositories.
This is also the preferred version of VMware Tools over what might be bundled with VMware's products.

You will also find this on other open source operating systems such as FreeBSD.

The Open Virtual Machine Tools project aims to provide a suite of open source virtualization utilities and drivers to improve the functionality and user experience of virtualization. The project currently runs in guest operating systems under VMware hypervisors.

Project page: https://github.com/vmware/open-vm-tools

=== Install on Debian / Ubuntu ===

On a server:
sudo apt-get install open-vm-tools

On a desktop:
sudo apt-get install open-vm-tools open-vm-tools-desktop

===== old links =====
* [http://sourceforge.net/projects/open-vm-tools/ sourceforge open-vm-tools project page]

* [http://open-vm-tools.sourceforge.net/ homepage]

[[Category: VMware OSS]]

Vmx hacks

2021-10-07T16:23:25Z

Wila: typo

=== VMX hacks ===

Here's my internal list of the .vmx hacks that I collected over time.

Beware that editing a .vmx file manually and adding any of these options is unsupported.

If you end up breaking your VM by editing the .vmx ... then restore the backup! (If you had no backups before hacking on your config, you are doing something wrong)

Also note that some options might no longer be active as they might be for an earlier version of a VMware product.

==== Wait 5 seconds on booting ====
Wait 5 seconds on booting:
bios.bootDelay = "5000"
Time is in milliseconds, change it accordingly.
==== Open BIOS settings on next boot ====
Open BIOS settings on next boot:
bios.forceSetupOnce = "TRUE"
In VMware Server 2, this setting is also in the web management interface, choose "Configure VM", power tabdialog, near the bottom.

[http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1648 Automatically Connecting USB Devices at Virtual Machine Power On]
==== Disable all Power menu and keyboard shortcuts====
gui.restricted="true"
This disables all power menu and keyboard shortcuts. It also disables suspend button

==== Fix repeating keys ====

To reduce these effects, increase the time threshold necessary for auto-repeat in the remote console.

Power off the virtual machine.
Add a line, similar to this, at the end of your virtual machine's configuration (.vmx) file:

keyboard.typematicMinDelay = "2000000"

The delay is specified in micro-seconds, so the line in the example above increases the repeat time to 2 seconds. This should ensure that you never get auto-repeat unless you intend it.

[http://kb.vmware.com/kb/196 Repeated characters when typing in remote console]

==== Disables suspend option ====
suspend.disabled = "TRUE"
This disables the suspend option in a virtual machine.

==== Fix Caps Lock synchronisation issues ====
This tip fixes the caps lock sync issue in Fusion 2.0.x and Tech Preview. I found it to be invaluable, add this to your VM's configuration file (.vmx):

mks.keyboard.syncLEDs = "TRUE"
==== Run a VM without a suspend file====
isn't there an option to run a VM without a suspend file (which is a file named like abcdef01-abcd-abcd-abcd-abcdef012345.vmem)
you mean
mainmem.useNamedFile = "false"
only works in windows

==== Use FT in a VM under Workstation ====
To use FT in a nested VM, you will still have to supply the entirely unsupported option (for the inner VM):

replay.allowBTOnly = "TRUE"

[http://communities.vmware.com/message/1343622 VMTN Anyone had sucess setting up a ESX40 Lab on Workstation 7.0?]

==== Disable VIX ====

An interesting tidbit if you’re super security cautious you can disable VIX by adding

“Guest.Command.Enabled”=”False”

to either the VM or the host. Be aware that this WILL break upgrading of VMware tools, and Guest customization as they both use vix as the underlying technology!

==== Optimize performance linux VM ====

mainmem.useNamedFile is no longer longer used on Linux hosts that run VMplayer 3 or Workstation 7.

New parameters are :
mainmem.backing = "swap"
mainmem.backing = "named"
mainmem.backing = "unnamed"

see http://sanbarrow.com/vmx/vmx-advanced.html#mainmem

==== Optimize troubleshooting ====
Please power off your VM and add the following configuration option to your .vmx file:
vmx.buildType = stats
Boot the VM and run your benchmark.
Shut down the VM and send me the contents of the stats directory that will be created in the same folder as the VM.

from: https://communities.vmware.com/message/2408159#2408159

==== Hardening your vmx file for security ====

http://virtualfoundry.blogspot.com/2009/04/hardening-vmx-file.html

==== Spurious APIC interrupt on CPU#1, should never happen ====

These messages are the result of an optimization Workstation 11 uses for inter-processor interrupts between virtual CPUs. The interrupt vector used for this purpose is 0xff, which is the Linux spurious APIC interrupt vector. In some cases, an inter-processor interrupt may arrive on a physical processor after Workstation has relinquished the processor to the host OS. Linux will discard the interrupt and print this message.

Unless these messages occur with high frequency, they should be innocuous.

The following configuration option should disable the optimization and make the messages stop:
monitor_control.disable_hostedIPI = TRUE

You can add this setting to /etc/vmware/config, and it will take effect for all VMs the next time they are powered on

from: [https://communities.vmware.com/message/2456565#2456565 Spurious APIC interrupt on CPU#1, should never happen]

==== CPU Masking ====

Yes, it is possible to mask the CPUID values in a VM (except for user mode code when using binary translation). However, masking only changes what CPUID reports; it doesn't change the way the processor behaves. Thus, masking may cause unexpected guest behavior.

The general format for CPUID masking is:

cpuid.<leaf>.<register> = xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx

The right hand side is a binary representation of the desired value, most significant bit first. Aside from '0' and '1,' two other important symbols are 'h,' which means to pass through the bit from the host CPUID and '-,' which means not to override the normal handling for this bit.

Specifying a different CPU vendor is not recommended.

from [https://communities.vmware.com/thread/405727 thread masking] Mr JMattson

In any event, the first thing to do is to pretend to be an AMD CPU. These settings should accomplish that:

cpuid.0.ebx = "0110:1000:0111:0100:0111:0101:0100:0001"
cpuid.0.ecx = "0100:0100:0100:1101:0100:0001:0110:0011"
cpuid.0.edx = "0110:1001:0111:0100:0110:1110:0110:0101"

Then you want to claim the family, model, and stepping of an actual AMD CPU. This setting should do that (claiming to be an early 64-bit Opteron):

cpuid.1.eax="----:0000:0000:0000:----:1111:0100:0110"

Even with these settings, some guests may still be unhappy.

=== Workstation ===

==== USB debugging ====

from [https://communities.vmware.com/message/2473661#2473661 Conversion from Workstation 10 to 11 breaks USB connections]
usb.quirks.device0 = "0x04e8:0x685b skip-reset"

==== USB Passthrough on Linux Host ====
'Passthrough' mode was disabled on Linux host as it conflicted with shared mode provided via pcscd

from [https://communities.vmware.com/message/2462510#2462510 Gemalto Smart Card Reader only appears as "Shared" not "Passthrough"]

* 1) Go to the VM's installation directory. Typically C:\Users\<username>\Documents\Virtual Machines\
* 2) Open <virtual-machine-name>.vmx file
* 3) Append the following lines:
usb.generic.allowCCID = "TRUE"
usb.ccid.disable = "TRUE"
* 4) Kill the process corresponding to the PCSC daemon on the Linux host

Do a # ps -ef | grep -i pcsc on your Linux host
sudo kill -9 <pid of the process that corresponds to pcscd>

Notes:
* 1) The first line in step 3 enables the passthrough mode
* 2) The second line in step 3 disables shared mode
* 3) Since you are killing the pcscd on your host, you wont be able to use the smart card on the host. You can passthrough the smart card now and use it in the VM

==== Change thumbnail speed ====

From Workstation 14 including 15, the thumbnail views are not in real time any more and the default refresh interval value is 3000 ms.

You can add

pref.thumbnailRefreshIntervalMs = 1000

(or other values) in the preference file %appdata%/vmware/preferences.ini to change the refesh rate. But keep in mind that this way may cause high CPU usage.

If you really need the previous real time thumbnail, you can use

pref.closeInactiveMKSWindows = "false"

But this way may cause mouse/keyboard functions under multi tabs not working well.

Both these settings are not documented or tested, so I cannot guarantee they working normally.

Note that you should make changes to the preferences.ini file with VMware Workstation shut down.

from: https://communities.vmware.com/message/2807350#2807350

=== Fusion ===
==== Applying a setting over all VMs ====

Instead of editing each .vmx file manually, you can also apply config options to all VMs, by creating/editing the user global config file that can be found at: ~/Library/Preferences/VMware\ Fusion/config

There's already a 'preferences' file in the same directory, but normally the config file has to be created.

If an individual .vmx file contains the same config options as the global file, the .vmx file will take precedence.

==== Hide the Full Screen application menu ====

It's unsupported, but try editing /Users/$USER/Library/Preferences/VMware Fusion/preferences and add the line:

fusion.showFullScreenTitleBar = "FALSE"

See also: http://communities.vmware.com/message/1348663#1348663

==== Delay drop down Full Screen application menu ====

Edit /Users/$USER/Library/Preferences/VMware Fusion/preferences and add the line:

fusion.fullScreenMenuDelay = "2"

The delay is in seconds and the default is 1.5 seconds, added since Fusion 4.1
A value of "0" removes the delay.

See also: http://communities.vmware.com/message/2273022

On VMware Workstation you would add the following lines to the preferences.ini file.

pref.fullscreen.showDelay = "5000"
to delay the showing of the toolbar 5000ms (5 seconds)
pref.fullscreen.hideDelay = "1000"
to hide the toolbar after 1000ms (1 second)

For Win7 the preferences.ini file is located under:
C:\Users\<username>\AppData\Roaming\VMware

==== debug menu ====

fusion.enableDebugMenu

(never tried)

==== Turn off full screen autofit to host ====

Here's another way to stop the guest from automagically being resized at each swipe:

* Open Finder, select the "Go" menu then select "Go To Folder..." and type in: ~/Library/Preferences/VMware Fusion/
* Open the preferences file in a text editor and add/append the following lines at the end of the file:

pref.autoFitGuestToWindow = "FALSE"
pref.autoFitFullScreen = "stretchGuestToHost"

Taken from: https://communities.vmware.com/message/2293562

==== Pass through host model ====

It's unsupported, but try editing /Users/$USER/Library/Preferences/VMware Fusion/preferences and add the line:

hw.model.reflectHost = "TRUE"

This will cause the VM to see the same model ID as the host. The default for this option is FALSE. Be aware that using this option may cause VM portability issues since the guest may now depend on this behavior and the type of the underlying Mac.

See also: http://communities.vmware.com/thread/336922

==== VM power options always display "Force" ====

If the Virtual Machine was not originally created in VMware Fusion then you will notice that the Fusion Virtual Machine menu has the word "Force" inserted before any power option.
For example copying a VM from a Windows systems to Mac it displays the "Force ..." commands by default. In other words, pressing the Option Key is backwards of what it is supposed to be. This is because the following options are missing from the Virtual Machine's .vmx configuration file.

powerType.powerOff = "soft"
powerType.powerOn = "soft"
powerType.suspend = "soft"
powerType.reset = "soft"

By default, VMware Fusion creates these options in the Virtual Machine's .vmx configuration file while VMware Player/Workstation does not. So, add the above options to the Virtual Machine's .vmx configuration file and the "Force ..." commands will then exhibit VMware Fusion normal behavior. Meaning in order to access the "Force ..." commands one will need to press the Option Key.

See also: http://communities.vmware.com/thread/402281

==== kernel debugging ====

You can attach a remote debugger such as gdb to your vm to do kernel debugging.

DebugStub knows nothing at all about the guest OS. Think of debugStub as an In-Circuit Debugger for the virtual CPU(s).

debugStub.listen.guest64 = "TRUE"
debugStub.listen.guest64.remote = "TRUE"
debugStub.hideBreakpoints=1
specify a custom port with:
debugStub.port.guest64 = "8865"
other options:
debugStub.listen.guest32 = "TRUE" # Enable listener for 32 bit guest
debugStub.listen.guest32.remote = "TRUE" # Allow remote connection
debugStub.port.guest32 = "32001" # Listen on specified port NNN

see also: [https://communities.vmware.com/thread/470936 Using debugStub to debug a guest linux kernel]

==== Additional logging ====
For troubleshooting boot issues etcetera you can increase the log level in vmware.log

monitor_control.log_vmsample = "TRUE"

[https://communities.vmware.com/thread/471833 Fusion 6.0.2 / OS X 10.9.2 Host / OS X 10.9 Guest VM running >100% CPU no matter what]

==== memory hole ====

At 3.2 GB there's a 1024kB memory hole.

You can use the pciHole.start option to adjust the start of the memory hole, measured in megabytes from address 0x00000000. The default is

pciHole.start = 3072

which corresponds to 0xC0000000.

from [https://communities.vmware.com/thread/478739 Memory hole at 3.2GB]

==== Disable Shared Folder event notification ====

isolation.tools.hgfs.notify.enable = "FALSE"

See also: http://kb.vmware.com/kb/2011360

==== Shared folder size check ====

The other workaround is to stop the VM, edit the VM's .vmx file and add the following setting:

tools.hgfs.volumeInfoType = "max"

Then start the VM again, and this time you will not need to disable the other shares which are on smaller sized volumes.

The default setting causes the shares to be aggregated to the smallest volume size that a share resides on when our file system is queried for size and free space.

The above setting overrides this to pick the largest volume size. The downside is that you can start a copy to a share on volume with a smaller amount of free space and it will only fail when it actually fails to write when the free space is exhausted.

If you know you are not going to run into that type of scenario yourself or you verify prior to starting the copy operation then you will be fine.

Note, the above can only be set to "min" or "max" and if not set at all, then "min" is the default.

from: [https://communities.vmware.com/message/2381223#2381223 Folder copy on Windows 7 vm fails for "not enough space", but there is.]

==== Disable location services ====

sensor.location = "disable"

to vmx.

[https://communities.vmware.com/message/2383410#2383410 how-to disable location services]

==== Disable automatic USB connect to guest feature ====

1. Suspend or shut down any running VMs and quit Fusion.

2. Ensure that the vmware-usbarbitrator process is no longer running.

3. Create/edit the host-global configuration file, with root privileges: (this example uses nano, but feel free to use any other editor)

sudo nano /Library/Preferences/VMware\ Fusion/config

4. Add the following line to disable the automatic claiming of USB devices:

usbarb.autoconnect.claimAll = "FALSE"

5. Save the file and quit the editor.

With this change, all USB devices should automatically connect to the host even when VMs are running. Note that it will completely disable the USB connection prompt, and will prevent devices from automatically connecting to VMs (even if the option is selected in settings). However it should still be possible to manually connect USB devices to a running VM (except possibly in cases where the reset command is not correctly issued via the hub).

from: [https://communities.vmware.com/message/2393343#2393343 2014 Preview still has USB 3 hub issue]

==== Open file with host OS application ====
When a file is located on a shared folder (VMware HGFS) then you can choose to be able to open this file with the host OS default application.
For example. Your png file can open in macOS Preview.

proxyApps.publishToGuest = "TRUE"

See also: [https://communities.vmware.com/t5/VMware-Workstation-Pro/Has-there-ever-been-a-solution-to-opening-a-host-application/m-p/2841711/highlight/true#M169663 Has there ever been a solution to opening a host application from a guest OS?]

==== Pass OS X host serial number ====

If you want an OS X guest to use the host's serial number, you'll need to add this option to the VM's configuration:

serialNumber.reflectHost = "TRUE"

==== Pass OS X host hardware model ====

To pass hardware model to the guest (not even sure this works, as it does not seem to do anything for me, but ... Fusion does not error on starting the VM )

hw.model.reflectHost = "TRUE"

==== Pass OS X host hardware model ID ====

If you want an OS X guest to use the host's hardware model ID (i.e. "MacPro5,1"), board ID (i.e. "Mac-12345678") and serial number all together:

smbios.reflectHost = "TRUE"

=== Any platform ===

==== Slow down time in guest ====

You can't quite stop time, but you can make it go extremely slowly. Set the following in your system-wide configuration file (/etc/vmware/config on Linux; C:\ProgramData\VMware\VMware Workstation\config.ini on Windows):

host.cpukHz = 1000

This is probably not all that useful in practice, unless the guest OS has no reliance on any time sources.

from [https://communities.vmware.com/message/2431592#2431592 System time]

==== Set max number of snapshots ====

snapshot.maxSnapshots = 100

==== Enable DX11 or OpenGL Host Renderer ====

Courtesy @bluefirestorm at [https://communities.vmware.com/message/2812499#2812499 setting *.vmx]

mks.enableDX11Renderer

When 3D accelerated graphics is enabled in Workstation 12/14/15 the default value is "TRUE" (i.e. the line does not have to be present in the vmx file), VMware Workstation uses DX11 of the Windows host to deliver the DX10/OpenGL 3.3 core profile capability inside the VMs. For Linux hosts, the equivalent is mks.enableGLRenderer = "TRUE"

==== Enable D3D Renderer ====
Courtesy @bluefirestorm at [https://communities.vmware.com/message/2812499#2812499 setting *.vmx]

mks.enableD3DRenderer

Default is "FALSE" from Workstation 12.x and later. This is only useful in version 12.x if the host graphics card does not have DX11 capability and setting this to TRUE and enableDX11Renderer to FALSE let the VM have some limited 3D accelerated graphics capability. This looks like is already ineffective in version 14/15.

==== Select host Graphics card to use ====
Courtesy @bluefirestorm at [https://communities.vmware.com/message/2812499#2812499 setting *.vmx]

mks.dx11.vendorID

valid values are the vendor ID of the graphic card, 0x8086 for Intel, 0x10DE for Nvidia, 0x1002 for AMD.

If this line is not present, VMware Workstation will use the default graphic card of the Windows host system. This line is useful if the system has two graphic cards from two different vendors that are simultaneously active on the host machine (example: Intel integrated graphics in the CPU and a discrete graphics card from Nvidia or AMD).

==== ReflectHost ====
Courtesy @bluefirestorm at [https://communities.vmware.com/message/2812499#2812499 setting *.vmx]

SMBIOS.reflectHost

Default is "FALSE". If set to "TRUE" some of the DMI info will use the host values (example: manufacturer will change from VMware to the host value). You can see this difference by using msinfo32 in Windows VM or dmidecode in Linux VM. This is not so useful anymore to hide the fact that the VM is a VM.

==== vmx.buildType ====
Courtesy @bluefirestorm at [https://communities.vmware.com/message/2812499#2812499 setting *.vmx]

vmx.buildType

Valid values are "release" and "debug". The "debug" is the default for the beta versions (aka Tech Preview). When set to "debug", vmware-vmx-debug.exe will be used instead of vmware-vmx.exe and the vmware.log file will be larger.

=== External sites ===

There's only one .vmx site that has most .vmx options and that's Ulli's reference over at sanbarrow:

http://sanbarrow.com/vmx/vmx-advanced.html

Shrink guest on hosted platform

2021-08-09T13:35:49Z

Wila: Added an example of the shrinking process in progress and listing the RDP side effect that I am seeing here.

== Important ==
Note that the technique described below to zero out the unused space on the guest OS will in fact make your guest virtual disk grow to the maximum size first. For each byte that is changed to zero the virtual disk will need to claim a byte. This means that while you can use the technique to reclaim disk space after the unused space is zero'd out, it is important to have enough space before you start.

If you don't have that kind of free disk space then you can skip the zero-ing out part. You can still reclaim space, but it will be less optimal.
Alternatively you can use the "Partially zero out" trick described below.

=== How much free space do you need before shrinking? ===
Also please note that you need more free space in order to be able to run the shrinking process.
The shrinking process consists of making a copy of your virtual disk while omitting the zero'd out blocks.
So how much extra space you need depends on how you configured the virtual disk for your Virtual Machine.
If your Virtual Disk is a single file, then your free space requirement can grow up-to the full size of that virtual disk.

If OTOH you are using the split disk scheme where a virtual disk is sliced into multiple files the maximum free space you need is the maximum size a slice can be. Nowadays there's not a fixed slice size, it depends on how big your virtual disk actually is.

The split disk scheme since VMware Workstation 11 (VMware Fusion 7), older version of Workstation/Fusion use a 2GB split disk scheme.

Capacity Extent size
================================
<=128GB 4GB (increased from 2GB)
>128GB && <2TB Capacity / 32 (so maximum of 32 extents)
>=2TB 2TB

For extra safety I recommend to make sure you have an additional 2GB of free space on top of those requirements as mentioned above.

As side note, this also explains why it is generally recommended at the forum by the regulars to use a split disk scheme over single disk files.
This same problem also exists when you want to commit snapshots.

=== Using the clean up option in the menu ===

When you use the "Clean Up Disks" option in the menu in VMware Workstation 12 or later, then you do not require extra disk space for reclaiming space (see also: [https://docs.vmware.com/en/VMware-Workstation-Pro/14.0/com.vmware.ws.using.doc/GUID-421A1073-BF16-4BC7-AA76-46B954CA438D.html Clean Up a Virtual Hard Disk on Windows Hosts] )

Currently this only works for Windows guests where the filesystem is NTFS.

== Zero out unused space in a Linux VM ==

Before we try to shrink the virtual disk files, we should try to remove any unneeded files from the virtual machine to free space.
More free space means more disk space that can get reclaimed.

One of the areas in a VM that can take up a lot of disk space is the repository cache. So I personally tend to clean the cache in the VM before reclaiming disk space at the host.

Clean up your repositories:

For example, on Debian-based VMs, you can run the following command (in the VM)

apt-get clean all

to clear out the local repository of retrieved package files.

On red hat based VMs that would be:

yum clean

The next step is important:

Shut down any services that depend on having enough available disk space to run.

The reason for this is that we are going to write out zero's to the file system until the file system is full and we do not want any application - for example a database system like mySQL or postgreSQL - to run out of disk space while we are zeroing out the file system. If mySQL would try to write when your disk is full you risk a corrupted database. So this step is important!

Next run (also from within the VM):

cat /dev/zero > zero.fill;sync;sleep 1;sync;rm -f zero.fill

to fill the unused space with zeros and then remove the "zero.fill" that has all the zero's.

As this command writes to the disk until it runs out of disk space, you will get an error "No space left on the device". This is expected.

Note that you have multiple partitions that you have to repeat the above command to zero out for each partition.
Adjust "zero.fill" to the relevant mountpoint, for example if you have a separate partition for home it would become:

cat /dev/zero > /home/zero.fill;sync;sleep 1;sync;rm -f /home/zero.fill

=== Zero out a part of your virtual disk ===

If your virtual machine cannot be taken down and you do not want to shut down services that might end up corrupting files because of the "No space left on the device" problem then an idea that might work is to zero out a part of your partition.

This for example creates a 100MB size file filled with zero's

# dd if=/dev/zero of=zero.fill bs=1024 count=102400
102400+0 records in
102400+0 records out
104857600 bytes (105 MB) copied, 0.3839 s, 273 MB/s

So if you want to zero out 10GB instead, add two more zero's to the count parameter, eg: count=10240000

If you want to fill up in steps, just change the output file name from "zero.fill" into "zero.fill2" etcetera..

Then run the "sync; sleep 1; sync" from above and remove the zero.fill files.

If your VM is running on VMware vSphere and you have a NFS LUN with enough free space then one way to reclaim your space is to Storage vMotion the VM to NFS storage and back. Once done the zero'd out data has been reclaimed. No need to shut down the VM.

If this is not for you, then do read on.

== Zero out unused space on a Windows VM ==

To do the same with a windows VM, you can use Microsoft's tool [http://technet.microsoft.com/en-us/sysinternals/bb897443.aspx sdelete].

Run it as
sdelete -z c:

To clean out the free space on disk c:

Careful!

As of sdelete v1.6 -c and -z have changed meanings, many instructions say -c zeros free space, this is no longer the case, it zeros the space then fills with random data in accordance with DOD spec: DOD 5220.22-M, random data will prevent the reclaim logic from working.

The trigger to zero space with 0x00 has changed to -z!

== Zeroing an encrypted disk ==

If you use disk encryption in the guest OS then zero'ing out the disk won't help.

The reason is that a good disk encryption scheme will write out random data to the disk when you write out zero's.

In other words, if you have enabled full disk encryption in the guest then you can not shrink the disk anymore as there is no space to reclaim.

== Shrink the disk ==

Then power down the VM and open a terminal on the Linux host.

Navigate to the directory where the .vmdk files are located, e.g.:

cd /var/lib/vmware/Virtual\ Machines/Ubuntu\ Desktop/

You can shrink the .vmdk file as follows:

vmware-vdiskmanager -k Ubuntu\ Desktop.vmdk

On Windows the command also uses the -k option, so I leave that for you as an exercise.

Note that vmware-vdiskmanager is probably not in your search path, so you might have to prepend the vmware-vdiskmanager command with the actual path with the command is located.

If you need to use "sudo" in order to be able to run the above then beware that the ownership of the .vmdk files might get changed to root.

You will have to change the ownership back to your own user, eg:
sudo chown username: *.vmdk
If you don't change the ownership back you might see errors like:
"Unable to open file .../Virtual Disk.vmdk: Insufficient permission to access file".

== Shrink using vmware tools ==

Nowadays you can also shrink the guest by using the shrink feature as offered via vmware tools.

So for clarity all of the following commands are run from within the guest to shrink the disk while the guest is running.

On linux in order to use this run:
sudo vmware-toolbox-cmd disk shrink /

Where "/" is the mount point of the partition that you want to shrink.

On Windows in order to use this run (as administrator):

C:\Program Files\VMware\VMware Tools>VMwareToolboxCmd.exe disk shrink <location>

where <location> is the drive you want to shrink

For example:
C:\Program Files\VMware\VMware Tools>VMwareToolboxCmd.exe disk shrink c:\
Please disregard any warnings about disk space for the duration of shrink process.
Progress: 62 [=======> ]
The progress you see here is VMware Tools blanking out the unused space.

At 99% it will popup the "Shrinking Disk" progress dialog at the host that takes care of the actual shrinking process.

If you are logged in via remote desktop then do expect to loose the connection for a bit while the actual shrinking is taking place.

On OS X / macOS the command to use is:

sudo /Library/Application\ Support/VMware\ Tools/vmware-tools-cli disk shrink /

== Shrink macOS VM with APFS ==

[https://communities.vmware.com/thread/581576 Solved: Shrink an APFS virtual disk]

== External links ==

* [https://docs.vmware.com/en/VMware-Workstation-Pro/16.0/com.vmware.ws.using.doc/GUID-421A1073-BF16-4BC7-AA76-46B954CA438D.html Clean Up a Virtual Hard Disk on Windows Hosts - Workstation 16 Pro documentation]

* [https://docs.vmware.com/en/VMware-Workstation-Pro/16.0/com.vmware.ws.using.doc/GUID-3F94C7B5-19A5-4E91-9709-B17FAA93FF75.html Configuring and Maintaining Virtual Hard Disks - Workstation 16 Pro documentation]

* [https://docs.vmware.com/en/VMware-Fusion/12/com.vmware.fusion.using.doc/GUID-6BB29187-F47F-41D1-AD92-1754036DACD9.html#GUID-6BB29187-F47F-41D1-AD92-1754036DACD9 Clean up a Virtual Machine - VMware Fusion 12 documentation]

Resources

2021-06-07T14:10:08Z

Wila: /* VMware Developer targeted sites */

==== VMware Developer targeted sites ====

* [http://blogs.vmware.com/PowerCLI/ VMware PowerCLI blog]

* [https://blogs.vmware.com/code/ VMware Developer center blog] (old link is [http://blogs.vmware.com/developer here])

* [https://code.vmware.com VMware {code}] and [https://twitter.com/vmwarecode @vmwarecode twitter feed]

* [https://communities.vmware.com/t5/VMware-code/ct-p/4500-home VMware {code} forum]

* [https://communities.vmware.com/t5/Sample-Exchange-Discussions/bd-p/4502 VMware {code} sample exchange discussions] VMware Community Sample Code

* [http://libraries.io/search?page=1&q=vmware Libraries.io VMware pages]

==== Sites with code ====
Places to visit for information, scripts, code snippets and tools (usually) with source code.

* [http://powerscripting.net/ Powershell powerscripting.net]

* [https://sites.google.com/site/chitchatvmback/ Ken Kato VMware's Back]

* [http://sanbarrow.com sanbarrow site]

* [https://williamlam.com/ William Lam's blog] (formerly known as virtuallyghetto.com)

* [http://www.astroarch.com/ Edward Haletky's site]

* [http://www.vm-help.com/index.html Dave Mishchenko's ESX host help site] ( you need it )

* [http://www.vmwarescripting.com/ VMwarescripting.com forum]

==== Must read Blogs about Powershell and the vSphere API ====

* [http://www.virtu-al.net Virtu-Al blog]

* [http://lucd.info Luc D's notes]

* [http://www.peetersonline.nl/index.php/powershell/some-advice-on-creating-powershell-scripts/ peetersonline powershell scripts]

* [http://ict-freak.nl/ ICT-Freak.nl]

* [http://www.van-lieshout.com Arnim van Lieshout]

* [http://jonathanmedd.net/ Jonathan Medd's blog]

* [http://www.ntpro.nl/blog/categories/10-VMware-PowerShell NTPRO Powershell]

==== Interesting Blogs ====

* [http://www.yellow-bricks.com/ Duncan Epping's Yellow Bricks]

* [http://www.planetvm.net/ Tom Howarth's Planet VM]

[[Category: website]]

Resources

2021-06-07T14:08:03Z

Wila: /* VMware Developer targeted sites */

==== VMware Developer targeted sites ====

* [http://blogs.vmware.com/PowerCLI/ VMware PowerCLI blog]

* [https://blogs.vmware.com/code/ VMware Developer center blog] (old link is [http://blogs.vmware.com/developer here])

* [https://code.vmware.com VMware {code}] and [https://twitter.com/vmwarecode @vmwarecode twitter feed]

* [https://communities.vmware.com/t5/VMware-code/ct-p/4500-home VMware {code} forum]

* [http://communities.vmware.com/community/developer/codecentral VMware code central] VMware Community Sample Code

* [http://libraries.io/search?page=1&q=vmware Libraries.io VMware pages]

==== Sites with code ====
Places to visit for information, scripts, code snippets and tools (usually) with source code.

* [http://powerscripting.net/ Powershell powerscripting.net]

* [https://sites.google.com/site/chitchatvmback/ Ken Kato VMware's Back]

* [http://sanbarrow.com sanbarrow site]

* [https://williamlam.com/ William Lam's blog] (formerly known as virtuallyghetto.com)

* [http://www.astroarch.com/ Edward Haletky's site]

* [http://www.vm-help.com/index.html Dave Mishchenko's ESX host help site] ( you need it )

* [http://www.vmwarescripting.com/ VMwarescripting.com forum]

==== Must read Blogs about Powershell and the vSphere API ====

* [http://www.virtu-al.net Virtu-Al blog]

* [http://lucd.info Luc D's notes]

* [http://www.peetersonline.nl/index.php/powershell/some-advice-on-creating-powershell-scripts/ peetersonline powershell scripts]

* [http://ict-freak.nl/ ICT-Freak.nl]

* [http://www.van-lieshout.com Arnim van Lieshout]

* [http://jonathanmedd.net/ Jonathan Medd's blog]

* [http://www.ntpro.nl/blog/categories/10-VMware-PowerShell NTPRO Powershell]

==== Interesting Blogs ====

* [http://www.yellow-bricks.com/ Duncan Epping's Yellow Bricks]

* [http://www.planetvm.net/ Tom Howarth's Planet VM]

[[Category: website]]

Resources

2021-06-07T14:05:30Z

Wila: Fixing link

==== VMware Developer targeted sites ====

* [http://blogs.vmware.com/PowerCLI/ VMware PowerCLI blog]

* [https://blogs.vmware.com/code/ VMware Developer center blog] (old link is [http://blogs.vmware.com/developer here])

* [https://code.vmware.com VMware {code}] and [https://twitter.com/vmwarecode @vmwarecode twitter feed]

* [http://communities.vmware.com/community/developer/codecentral VMware code central] VMware Community Sample Code

* [http://libraries.io/search?page=1&q=vmware Libraries.io VMware pages]

==== Sites with code ====
Places to visit for information, scripts, code snippets and tools (usually) with source code.

* [http://powerscripting.net/ Powershell powerscripting.net]

* [https://sites.google.com/site/chitchatvmback/ Ken Kato VMware's Back]

* [http://sanbarrow.com sanbarrow site]

* [https://williamlam.com/ William Lam's blog] (formerly known as virtuallyghetto.com)

* [http://www.astroarch.com/ Edward Haletky's site]

* [http://www.vm-help.com/index.html Dave Mishchenko's ESX host help site] ( you need it )

* [http://www.vmwarescripting.com/ VMwarescripting.com forum]

==== Must read Blogs about Powershell and the vSphere API ====

* [http://www.virtu-al.net Virtu-Al blog]

* [http://lucd.info Luc D's notes]

* [http://www.peetersonline.nl/index.php/powershell/some-advice-on-creating-powershell-scripts/ peetersonline powershell scripts]

* [http://ict-freak.nl/ ICT-Freak.nl]

* [http://www.van-lieshout.com Arnim van Lieshout]

* [http://jonathanmedd.net/ Jonathan Medd's blog]

* [http://www.ntpro.nl/blog/categories/10-VMware-PowerShell NTPRO Powershell]

==== Interesting Blogs ====

* [http://www.yellow-bricks.com/ Duncan Epping's Yellow Bricks]

* [http://www.planetvm.net/ Tom Howarth's Planet VM]

[[Category: website]]

Pyvmware

2021-06-07T14:01:45Z

Wila: Fixing link

A python module that makes use of the vmware client sdk to control vmware instances.

NOTE: Currently beta with limited implemented methods. Enough to start, stop, and revert a VM.

https://code.google.com/archive/p/pyvmware/

[[Category:SDK]] [[Category:python]]

Protecting ESX VMFS Stores with Automation

2021-06-07T13:57:46Z

Wila: Fixing link

author: Mike La Spina

==== Description ====

Some time ago Mike shared some interesting information about VMFS volumes that he found using direct analysis in his blog named [http://blog.laspina.ca/ubiquitous/understanding-vmfs-volumes Understanding VMFS volumes].

This spawned some discussions on the VMware Community forums and it became apparent that an automated backup of the critical VMFS info could be useful in the event of an undesirable security event that impacts our system availability.

By creating a simple backup script process we can provide the ability to recover much more quickly from such events. In this howto guide we will enable this process with a cron job using the existing /etc/cron.daily/ job location directory.

We simply need to copy an automation script to this location and it will run daily. Or if your change rate is less frequent maybe the /etc/cron.weekly location is more suitable. ...

==== Location ====

[http://blog.laspina.ca/ubiquitous/understanding-vmfs-volumes Ubiquitous: Protecting ESX VMFS Stores with Automation]

See also:
[http://blog.laspina.ca/ubiquitous/additional-vmfs-backup-automation-script-features Ubiquitous: Additional VMFS Backup Automation script features]

[[Category: Bash]] [[Category: Forensics]]

Protecting ESX VMFS Stores with Automation

2021-06-07T13:56:27Z

Wila: Fixing link

author: Mike La Spina

==== Description ====

Some time ago Mike shared some interesting information about VMFS volumes that he found using direct analysis in his blog named [http://blog.laspina.ca/ubiquitous/understanding-vmfs-volumes Understanding VMFS volumes].

This spawned some discussions on the VMware Community forums and it became apparent that an automated backup of the critical VMFS info could be useful in the event of an undesirable security event that impacts our system availability.

By creating a simple backup script process we can provide the ability to recover much more quickly from such events. In this howto guide we will enable this process with a cron job using the existing /etc/cron.daily/ job location directory.

We simply need to copy an automation script to this location and it will run daily. Or if your change rate is less frequent maybe the /etc/cron.weekly location is more suitable. ...

==== Location ====

[http://blog.laspina.ca/roller/Ubiquitous/entry/understanding_vmfs_volumes Ubiquitous: Protecting ESX VMFS Stores with Automation]

See also:
[http://blog.laspina.ca/roller/Ubiquitous/entry/additional_vmfs_backup_automation_script Ubiquitous: Additional VMFS Backup Automation script features]

[[Category: Bash]] [[Category: Forensics]]

Vitoolkit: Status

2021-06-05T23:42:58Z

Wila: Moved from /wiki folder to wiki subdomain earlier this week

==== Status site ====

December 5, 2008: Initial setup

December 13, 2008: Full system backup, and added this page :)

Januari 1, 2009: Full system backup.

==== Things to do ====

Here's a list of things still to do, there's no time line as I don't want to put myself (or others) under stress.
This site is completely depending on free time of its contributors so only work on it if you want to.

* <s> Add daily backup to another machine</s> weekly is fine
* <s>Add proper category pages. Partly done </s>
* <s>Add "what's new" to the main page</s> use [[Special:RecentChanges|Recent changes]] link at top of page instead.
* <s>Add # of articles/pages to the main page</s>

* <s>Fix css for code snippets, it doesn't look like the current font is monospaced</s>
* <s>Fix theme template / settings so that we can edit per paragraph as well</s>
* Fix the silly html metatag redirection and use a proper 301 redirect
* <s>Redirect all alternative domain names to this site (like the .net and .org one, but especially the vitoolkit.com one)</s>
* <s>Do email notifications work? (I think not)</s>

* <s>Find a better way to present what's available on the site, improve ways to restructure the data. </s> The support for category tree at the main page now gives a much easier way to navigate the site. But it never hurts to find better ways as this doesn't scale too well (look at the vimsh category for example)
* Improve main page
* Add example code
* <s>Add a theme for mobile phones, so it is easier to read the content</s> Disabled the plugin as it was hopelessly out of date, I think the current theme is rather OK on mobile, but no phone to test now.

==== Things to make our mind up about ====

* Does the site need a forum? <- No, you can use the talk page if you have a comment or contact me directly. Maybe in a later incarnation.
* Does the site need an instant messager type of control ? <- No, use twitter @wilva for contacting me or use email wila under the site's domain name.
* Do we need a version code control system (my personal fav is [http://subversion.tigris.org/ subversion]) ? <- No, we don't host much code on the site right now. Pretty much all of the code snippets are located elsewhere and copying those over to this site makes no sense as it will only complicate things.
* Do we need project tracking a la [http://trac.edgewall.org/ Trac] ? My impression is that at this stage it´s a bit over the top.
* <s> Would it be better to change our url to https://wiki.vi-toolkit.com ? Probably ;) </s>

[[Category: website]]

PowerCLI: Change Virtual Machines Guest OS Names

2021-06-05T16:11:05Z

Wila: Adding the code itself (just in case)

=== PowerCLI: Change Virtual Machines Guest OS Names ===
author: Rawlinson
==== Description ====
The script displayed here queries the VM name at the host level and will use that to set the name of the operating system within the guest OS. The example code here is used for windows guests.

==== Code ====

$VMs = Get-VM | Where {$_.PowerState -eq "PoweredOn"}

Foreach ($VM in $VMS){
$VCName = $VM.Name
$WinName = $VM.Guest.Hostname
If ($WinName -ne $VCName) {
Write-Host "$VCName is currently $WinName... renaming"
$renamecomputer = "wmic path win32_computersystem where ""Name='%computername%'"" CALL rename name='$VCName'"
Invoke-VMScript -VM $VM -GuestUser "Administrator" -GuestPassword "vmware" -ScriptType Bat -ScriptText $renamecomputer
restart-vmguest -VM $VM -Confirm:$false
}
}

==== Usage ====

Save as a script and run it.

==== Location ====

* [http://web.archive.org/web/20160616222335/http://www.punchingclouds.com/2013/06/06/powercli-change-virtual-machines-guest-os-names/ http://www.punchingclouds.com/2013/06/06/powercli-change-virtual-machines-guest-os-names/]

[[Category: PowerCLI]] [[Category: VM Management]]

PowerCLI: Change Virtual Machines Guest OS Names

2021-06-05T16:09:19Z

Wila: Updated link to point to a copy at web.archive.org as the site is no longer there.

Vmx hacks

2021-04-21T14:48:13Z

Wila: /* Open file with host OS application */

=== VMX hacks ===

Here's my internal list of the .vmx hacks that I collected over time.

Beware that editing a .vmx file manually and adding any of these options is unsupported.

If you end up breaking your VM by editing the .vmx ... then restore the backup! (If you had no backups before hacking on your config, you are doing something wrong)

Also note that some options might no longer be active as they might be for an earlier version of a VMware product.

==== Wait 5 seconds on booting ====
Wait 5 seconds on booting:
bios.bootDelay = "5000"
Time is in milliseconds, change it accordingly.
==== Open BIOS settings on next boot ====
Open BIOS settings on next boot:
bios.forceSetupOnce = "TRUE"
In VMware Server 2, this setting is also in the web management interface, choose "Configure VM", power tabdialog, near the bottom.

[http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1648 Automatically Connecting USB Devices at Virtual Machine Power On]
==== Disable all Power menu and keyboard shortcuts====
gui.restricted="true"
This disables all power menu and keyboard shortcuts. It also disables suspend button

==== Fix repeating keys ====

To reduce these effects, increase the time threshold necessary for auto-repeat in the remote console.

Power off the virtual machine.
Add a line, similar to this, at the end of your virtual machine's configuration (.vmx) file:

keyboard.typematicMinDelay = "2000000"

The delay is specified in micro-seconds, so the line in the example above increases the repeat time to 2 seconds. This should ensure that you never get auto-repeat unless you intend it.

[http://kb.vmware.com/kb/196 Repeated characters when typing in remote console]

==== Disables suspend option ====
suspend.disabled = "TRUE"
This disables the suspend option in a virtual machine.

==== Fix Caps Lock synchronisation issues ====
This tip fixes the caps lock sync issue in Fusion 2.0.x and Tech Preview. I found it to be invaluable, add this to your VM's configuration file (.vmx):

mks.keyboard.syncLEDs = "TRUE"
==== Run a VM without a suspend file====
isn't there an option to run a VM without a suspend file (which is a file named like abcdef01-abcd-abcd-abcd-abcdef012345.vmem)
you mean
mainmem.useNamedFile = "false"
only works in windows

==== Use FT in a VM under Workstation ====
To use FT in a nested VM, you will still have to supply the entirely unsupported option (for the inner VM):

replay.allowBTOnly = "TRUE"

[http://communities.vmware.com/message/1343622 VMTN Anyone had sucess setting up a ESX40 Lab on Workstation 7.0?]

==== Disable VIX ====

An interesting tidbit if you’re super security cautious you can disable VIX by adding

“Guest.Command.Enabled”=”False”

to either the VM or the host. Be aware that this WILL break upgrading of VMware tools, and Guest customization as they both use vix as the underlying technology!

==== Optimize performance linux VM ====

mainmem.useNamedFile is no longer longer used on Linux hosts that run VMplayer 3 or Workstation 7.

New parameters are :
mainmem.backing = "swap"
mainmem.backing = "named"
mainmem.backing = "unnamed"

see http://sanbarrow.com/vmx/vmx-advanced.html#mainmem

==== Optimize troubleshooting ====
Please power off your VM and add the following configuration option to your .vmx file:
vmx.buildType = stats
Boot the VM and run your benchmark.
Shut down the VM and send me the contents of the stats directory that will be created in the same folder as the VM.

from: https://communities.vmware.com/message/2408159#2408159

==== Hardening your vmx file for security ====

http://virtualfoundry.blogspot.com/2009/04/hardening-vmx-file.html

==== Spurious APIC interrupt on CPU#1, should never happen ====

These messages are the result of an optimization Workstation 11 uses for inter-processor interrupts between virtual CPUs. The interrupt vector used for this purpose is 0xff, which is the Linux spurious APIC interrupt vector. In some cases, an inter-processor interrupt may arrive on a physical processor after Workstation has relinquished the processor to the host OS. Linux will discard the interrupt and print this message.

Unless these messages occur with high frequency, they should be innocuous.

The following configuration option should disable the optimization and make the messages stop:
monitor_control.disable_hostedIPI = TRUE

You can add this setting to /etc/vmware/config, and it will take effect for all VMs the next time they are powered on

from: [https://communities.vmware.com/message/2456565#2456565 Spurious APIC interrupt on CPU#1, should never happen]

==== CPU Masking ====

Yes, it is possible to mask the CPUID values in a VM (except for user mode code when using binary translation). However, masking only changes what CPUID reports; it doesn't change the way the processor behaves. Thus, masking may cause unexpected guest behavior.

The general format for CPUID masking is:

cpuid.<leaf>.<register> = xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx

The right hand side is a binary representation of the desired value, most significant bit first. Aside from '0' and '1,' two other important symbols are 'h,' which means to pass through the bit from the host CPUID and '-,' which means not to override the normal handling for this bit.

Specifying a different CPU vendor is not recommended.

from [https://communities.vmware.com/thread/405727 thread masking] Mr JMattson

In any event, the first thing to do is to pretend to be an AMD CPU. These settings should accomplish that:

cpuid.0.ebx = "0110:1000:0111:0100:0111:0101:0100:0001"
cpuid.0.ecx = "0100:0100:0100:1101:0100:0001:0110:0011"
cpuid.0.edx = "0110:1001:0111:0100:0110:1110:0110:0101"

Then you want to claim the family, model, and stepping of an actual AMD CPU. This setting should do that (claiming to be an early 64-bit Opteron):

cpuid.1.eax="----:0000:0000:0000:----:1111:0100:0110"

Even with these settings, some guests may still be unhappy.

=== Workstation ===

==== USB debugging ====

from [https://communities.vmware.com/message/2473661#2473661 Conversion from Workstation 10 to 11 breaks USB connections]
usb.quirks.device0 = "0x04e8:0x685b skip-reset"

==== USB Passthrough on Linux Host ====
'Passthrough' mode was disabled on Linux host as it conflicted with shared mode provided via pcscd

from [https://communities.vmware.com/message/2462510#2462510 Gemalto Smart Card Reader only appears as "Shared" not "Passthrough"]

* 1) Go to the VM's installation directory. Typically C:\Users\<username>\Documents\Virtual Machines\
* 2) Open <virtual-machine-name>.vmx file
* 3) Append the following lines:
usb.generic.allowCCID = "TRUE"
usb.ccid.disable = "TRUE"
* 4) Kill the process corresponding to the PCSC daemon on the Linux host

Do a # ps -ef | grep -i pcsc on your Linux host
sudo kill -9 <pid of the process that corresponds to pcscd>

Notes:
* 1) The first line in step 3 enables the passthrough mode
* 2) The second line in step 3 disables shared mode
* 3) Since you are killing the pcscd on your host, you wont be able to use the smart card on the host. You can passthrough the smart card now and use it in the VM

==== Change thumbnail speed ====

From Workstation 14 including 15, the thumbnail views are not in real time any more and the default refresh interval value is 3000 ms.

You can add

pref.thumbnailRefreshIntervalMs = 1000

(or other values) in the preference file %appdata%/vmware/preferences.ini to change the refesh rate. But keep in mind that this way may cause high CPU usage.

If you really need the previous real time thumbnail, you can use

pref.closeInactiveMKSWindows = "false"

But this way may cause mouse/keyboard functions under multi tabs not working well.

Both these settings are not documented or tested, so I cannot guarantee they working normally.

Note that you should make changes to the preferences.ini file with VMware Workstation shut down.

from: https://communities.vmware.com/message/2807350#2807350

=== Fusion ===
==== Applying a setting over all VMs ====

Instead of editing each .vmx file manually, you can also apply config options to all VMs, by creating/editing the user global config file that can be found at: ~/Library/Preferences/VMware\ Fusion/config

There's already a 'preferences' file in the same directory, but normally the config file has to be created.

If an individual .vmx file contains the same config options as the global file, the .vmx file will take precedence.

==== Hide the Full Screen application menu ====

It's unsupported, but try editing /Users/$USER/Library/Preferences/VMware Fusion/preferences and add the line:

fusion.showFullScreenTitleBar = "FALSE"

See also: http://communities.vmware.com/message/1348663#1348663

==== Delay drop down Full Screen application menu ====

Edit /Users/$USER/Library/Preferences/VMware Fusion/preferences and add the line:

fusion.fullScreenMenuDelay = "2"

The delay is in seconds and the default is 1.5 seconds, added since Fusion 4.1
A value of "0" removes the delay.

See also: http://communities.vmware.com/message/2273022

On VMware Workstation you would add the following lines to the preferences.ini file.

pref.fullscreen.showDelay = "5000"
to delay the showing of the toolbar 5000ms (5 seconds)
pref.fullscreen.hideDelay = "1000"
to hide the toolbar after 1000ms (1 second)

For Win7 the preferences.ini file is located under:
C:\Users\<username>\AppData\Roaming\VMware

==== debug menu ====

fusion.enableDebugMenu

(never tried)

==== Turn off full screen autofit to host ====

Here's another way to stop the guest from automagically being resized at each swipe:

* Open Finder, select the "Go" menu then select "Go To Folder..." and type in: ~/Library/Preferences/VMware Fusion/
* Open the preferences file in a text editor and add/append the following lines at the end of the file:

pref.autoFitGuestToWindow = "FALSE"
pref.autoFitFullScreen = "stretchGuestToHost"

Taken from: https://communities.vmware.com/message/2293562

==== Pass through host model ====

It's unsupported, but try editing /Users/$USER/Library/Preferences/VMware Fusion/preferences and add the line:

hw.model.reflectHost = "TRUE"

This will cause the VM to see the same model ID as the host. The default for this option is FALSE. Be aware that using this option may cause VM portability issues since the guest may now depend on this behavior and the type of the underlying Mac.

See also: http://communities.vmware.com/thread/336922

==== VM power options always display "Force" ====

If the Virtual Machine was not originally created in VMware Fusion then you will notice that the Fusion Virtual Machine menu has the word "Force" inserted before any power option.
For example copying a VM from a Windows systems to Mac it displays the "Force ..." commands by default. In other words, pressing the Option Key is backwards of what it is supposed to be. This is because the following options are missing from the Virtual Machine's .vmx configuration file.

powerType.powerOff = "soft"
powerType.powerOn = "soft"
powerType.suspend = "soft"
powerType.reset = "soft"

By default, VMware Fusion creates these options in the Virtual Machine's .vmx configuration file while VMware Player/Workstation does not. So, add the above options to the Virtual Machine's .vmx configuration file and the "Force ..." commands will then exhibit VMware Fusion normal behavior. Meaning in order to access the "Force ..." commands one will need to press the Option Key.

See also: http://communities.vmware.com/thread/402281

==== kernel debugging ====

You can attach a remote debugger such as gdb to your vm to do kernel debugging.

DebugStub knows nothing at all about the guest OS. Think of debugStub as an In-Circuit Debugger for the virtual CPU(s).

debugStub.listen.guest64 = "TRUE"
debugStub.listen.guest64.remote = "TRUE"
debugStub.hideBreakpoints=1
specify a custom port with:
debugStub.port.guest64 = "8865"
other options:
debugStub.listen.guest32 = "TRUE" # Enable listener for 32 bit guest
debugStub.listen.guest32.remote = "TRUE" # Allow remote connection
debugStub.port.guest32 = "32001" # Listen on specified port NNN

see also: [https://communities.vmware.com/thread/470936 Using debugStub to debug a guest linux kernel]

==== Additional logging ====
For troubleshooting boot issues etcetera you can increase the log level in vmware.log

monitor_control.log_vmsample = "TRUE"

[https://communities.vmware.com/thread/471833 Fusion 6.0.2 / OS X 10.9.2 Host / OS X 10.9 Guest VM running >100% CPU no matter what]

==== memory hole ====

At 3.2 GB there's a 1024kB memory hole.

You can use the pciHole.start option to adjust the start of the memory hole, measured in megabytes from address 0x00000000. The default is

pciHole.start = 3072

which corresponds to 0xC0000000.

from [https://communities.vmware.com/thread/478739 Memory hole at 3.2GB]

==== Disable Shared Folder event notification ====

isolation.tools.hgfs.notify.enable = "FALSE"

See also: http://kb.vmware.com/kb/2011360

==== Shared folder size check ====

The other workaround is to stop the VM, edit the VM's .vmx file and add the following setting:

tools.hgfs.volumeInfoType = "max"

Then start the VM again, and this time you will not need to disable the other shares which are on smaller sized volumes.

The default setting causes the shares to be aggregated to the smallest volume size that a share resides on when our file system is queried for size and free space.

The above setting overrides this to pick the largest volume size. The downside is that you can start a copy to a share on volume with a smaller amount of free space and it will only fail when it actually fails to write when the free space is exhausted.

If you know you are not going to run into that type of scenario yourself or you verify prior to starting the copy operation then you will be fine.

Note, the above can only be set to "min" or "max" and if not set at all, then "min" is the default.

from: [https://communities.vmware.com/message/2381223#2381223 Folder copy on Windows 7 vm fails for "not enough space", but there is.]

==== Disable location services ====

sensor.location = "disable"

to vmx.

[https://communities.vmware.com/message/2383410#2383410 how-to disable location services]

==== Disable automatic USB connect to guest feature ====

1. Suspend or shut down any running VMs and quit Fusion.

2. Ensure that the vmware-usbarbitrator process is no longer running.

3. Create/edit the host-global configuration file, with root privileges: (this example uses nano, but feel free to use any other editor)

sudo nano /Library/Preferences/VMware\ Fusion/config

4. Add the following line to disable the automatic claiming of USB devices:

usbarb.autoconnect.claimAll = "FALSE"

5. Save the file and quit the editor.

With this change, all USB devices should automatically connect to the host even when VMs are running. Note that it will completely disable the USB connection prompt, and will prevent devices from automatically connecting to VMs (even if the option is selected in settings). However it should still be possible to manually connect USB devices to a running VM (except possibly in cases where the reset command is not correctly issued via the hub).

from: [https://communities.vmware.com/message/2393343#2393343 2014 Preview still has USB 3 hub issue]

==== Open file with host OS application ====
When a file is located on a shared folder (VMware HGFS) then you can choose to be able to open this file with the host OS default application.
For example. Your png file can open in macOS Preview.

proxyApps.publishToGuest = "TRUE"

See also: [https://communities.vmware.com/t5/VMware-Workstation-Pro/Has-there-ever-been-a-solution-to-opening-a-host-application/m-p/2841711/highlight/true#M169663 Has there ever been a solution to opening a host application from a guest OS?]

==== Pass OS X host serial number ====

If you want an OS X guest to use the host's serial number, you'll need to add this option to the VM's configuration:

serialNumber.reflectHost = "TRUE"

==== Pass OS X host hardware model ====

To pass hardware model to the guest (not even sure this works, as it does not seem to do anything for me, but ... Fusion does not error on starting the VM )

hw.model.reflectHost = "TRUE"

==== Pass OS X host hardware model ID ====

If you want an OS X guest to use the host's hardware model ID (i.e. "MacPro5,1"), board ID (i.e. "Mac-12345678") and serial number all together:

smbios.reflectHost = "TRUE"

=== Any platform ===

==== Slow down time in guest ====

You can't quite stop time, but you can make it go extremely slowly. Set the following in your system-wide configuration file (/etc/vmware/config on Linux; C:\ProgramData\VMware\VMware Workstation\config.ini on Windows):

host.cpukHz = 1000

This is probably not all that useful in practice, unless the guest OS has no reliance on any time sources.

from [https://communities.vmware.com/message/2431592#2431592 System time]

==== Set max number of snapshots ====

snapshot.maxSnapshots = 100

==== Enable DX11 or OpenGL Host Renderer ====

Courtesy @bluefirestorm at [https://communities.vmware.com/message/2812499#2812499 setting *.vmx]

mks.enableDX11Renderer

When 3D accelerated graphics is enabled in Workstation 12/14/15 the default value is "TRUE" (i.e. the line does not have to be present in the vmx file), VMware Workstation uses DX11 of the Windows host to deliver the DX10/OpenGL 3.3 core profile capability inside the VMs. For Linux hosts, the equivalent is mks.enableGLRenderer = "TRUE"

==== Enable D3D Renderer ====
Courtesy @bluefirestorm at [https://communities.vmware.com/message/2812499#2812499 setting *.vmx]

mks.enableD3DRenderer

Default is "FALSE" from Workstation 12.x and later. This is only useful in version 12.x if the host graphics card does not have DX11 capability and setting this to TRUE and enableDX11Renderer to FALSE let the VM have some limited 3D accelerated graphics capability. This looks like is already ineffective in version 14/15.

==== Select host Graphics card to use ====
Courtesy @bluefirestorm at [https://communities.vmware.com/message/2812499#2812499 setting *.vmx]

mks.dx11.vendorID

valid values are the vendor ID of the graphic card, 0x8086 for Intel, 0x10DE for Nvidia, 0x1002 for AMD.

If this line is not present, VMware Workstation will use the default graphic card of the Windows host system. This line is useful if the system has two graphic cards from two different vendors that are simultaneously active on the host machine (example: Intel integrated graphics in the CPU and a discrete graphics card from Nvidia or AMD).

==== ReflecHost ====
Courtesy @bluefirestorm at [https://communities.vmware.com/message/2812499#2812499 setting *.vmx]

SMBIOS.reflectHost

Default is "FALSE". If set to "TRUE" some of the DMI info will use the host values (example: manufacturer will change from VMware to the host value). You can see this difference by using msinfo32 in Windows VM or dmidecode in Linux VM. This is not so useful anymore to hide the fact that the VM is a VM.

==== vmx.buildType ====
Courtesy @bluefirestorm at [https://communities.vmware.com/message/2812499#2812499 setting *.vmx]

vmx.buildType

Valid values are "release" and "debug". The "debug" is the default for the beta versions (aka Tech Preview). When set to "debug", vmware-vmx-debug.exe will be used instead of vmware-vmx.exe and the vmware.log file will be larger.

=== External sites ===

There's only one .vmx site that has most .vmx options and that's Ulli's reference over at sanbarrow:

http://sanbarrow.com/vmx/vmx-advanced.html

Vmx hacks

2021-04-21T14:47:10Z

Wila: /* Pass OS X host serial number */

=== VMX hacks ===

Here's my internal list of the .vmx hacks that I collected over time.

Beware that editing a .vmx file manually and adding any of these options is unsupported.

If you end up breaking your VM by editing the .vmx ... then restore the backup! (If you had no backups before hacking on your config, you are doing something wrong)

Also note that some options might no longer be active as they might be for an earlier version of a VMware product.

==== Wait 5 seconds on booting ====
Wait 5 seconds on booting:
bios.bootDelay = "5000"
Time is in milliseconds, change it accordingly.
==== Open BIOS settings on next boot ====
Open BIOS settings on next boot:
bios.forceSetupOnce = "TRUE"
In VMware Server 2, this setting is also in the web management interface, choose "Configure VM", power tabdialog, near the bottom.

[http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1648 Automatically Connecting USB Devices at Virtual Machine Power On]
==== Disable all Power menu and keyboard shortcuts====
gui.restricted="true"
This disables all power menu and keyboard shortcuts. It also disables suspend button

==== Fix repeating keys ====

To reduce these effects, increase the time threshold necessary for auto-repeat in the remote console.

Power off the virtual machine.
Add a line, similar to this, at the end of your virtual machine's configuration (.vmx) file:

keyboard.typematicMinDelay = "2000000"

The delay is specified in micro-seconds, so the line in the example above increases the repeat time to 2 seconds. This should ensure that you never get auto-repeat unless you intend it.

[http://kb.vmware.com/kb/196 Repeated characters when typing in remote console]

==== Disables suspend option ====
suspend.disabled = "TRUE"
This disables the suspend option in a virtual machine.

==== Fix Caps Lock synchronisation issues ====
This tip fixes the caps lock sync issue in Fusion 2.0.x and Tech Preview. I found it to be invaluable, add this to your VM's configuration file (.vmx):

mks.keyboard.syncLEDs = "TRUE"
==== Run a VM without a suspend file====
isn't there an option to run a VM without a suspend file (which is a file named like abcdef01-abcd-abcd-abcd-abcdef012345.vmem)
you mean
mainmem.useNamedFile = "false"
only works in windows

==== Use FT in a VM under Workstation ====
To use FT in a nested VM, you will still have to supply the entirely unsupported option (for the inner VM):

replay.allowBTOnly = "TRUE"

[http://communities.vmware.com/message/1343622 VMTN Anyone had sucess setting up a ESX40 Lab on Workstation 7.0?]

==== Disable VIX ====

An interesting tidbit if you’re super security cautious you can disable VIX by adding

“Guest.Command.Enabled”=”False”

to either the VM or the host. Be aware that this WILL break upgrading of VMware tools, and Guest customization as they both use vix as the underlying technology!

==== Optimize performance linux VM ====

mainmem.useNamedFile is no longer longer used on Linux hosts that run VMplayer 3 or Workstation 7.

New parameters are :
mainmem.backing = "swap"
mainmem.backing = "named"
mainmem.backing = "unnamed"

see http://sanbarrow.com/vmx/vmx-advanced.html#mainmem

==== Optimize troubleshooting ====
Please power off your VM and add the following configuration option to your .vmx file:
vmx.buildType = stats
Boot the VM and run your benchmark.
Shut down the VM and send me the contents of the stats directory that will be created in the same folder as the VM.

from: https://communities.vmware.com/message/2408159#2408159

==== Hardening your vmx file for security ====

http://virtualfoundry.blogspot.com/2009/04/hardening-vmx-file.html

==== Spurious APIC interrupt on CPU#1, should never happen ====

These messages are the result of an optimization Workstation 11 uses for inter-processor interrupts between virtual CPUs. The interrupt vector used for this purpose is 0xff, which is the Linux spurious APIC interrupt vector. In some cases, an inter-processor interrupt may arrive on a physical processor after Workstation has relinquished the processor to the host OS. Linux will discard the interrupt and print this message.

Unless these messages occur with high frequency, they should be innocuous.

The following configuration option should disable the optimization and make the messages stop:
monitor_control.disable_hostedIPI = TRUE

You can add this setting to /etc/vmware/config, and it will take effect for all VMs the next time they are powered on

from: [https://communities.vmware.com/message/2456565#2456565 Spurious APIC interrupt on CPU#1, should never happen]

==== CPU Masking ====

Yes, it is possible to mask the CPUID values in a VM (except for user mode code when using binary translation). However, masking only changes what CPUID reports; it doesn't change the way the processor behaves. Thus, masking may cause unexpected guest behavior.

The general format for CPUID masking is:

cpuid.<leaf>.<register> = xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx

The right hand side is a binary representation of the desired value, most significant bit first. Aside from '0' and '1,' two other important symbols are 'h,' which means to pass through the bit from the host CPUID and '-,' which means not to override the normal handling for this bit.

Specifying a different CPU vendor is not recommended.

from [https://communities.vmware.com/thread/405727 thread masking] Mr JMattson

In any event, the first thing to do is to pretend to be an AMD CPU. These settings should accomplish that:

cpuid.0.ebx = "0110:1000:0111:0100:0111:0101:0100:0001"
cpuid.0.ecx = "0100:0100:0100:1101:0100:0001:0110:0011"
cpuid.0.edx = "0110:1001:0111:0100:0110:1110:0110:0101"

Then you want to claim the family, model, and stepping of an actual AMD CPU. This setting should do that (claiming to be an early 64-bit Opteron):

cpuid.1.eax="----:0000:0000:0000:----:1111:0100:0110"

Even with these settings, some guests may still be unhappy.

=== Workstation ===

==== USB debugging ====

from [https://communities.vmware.com/message/2473661#2473661 Conversion from Workstation 10 to 11 breaks USB connections]
usb.quirks.device0 = "0x04e8:0x685b skip-reset"

==== USB Passthrough on Linux Host ====
'Passthrough' mode was disabled on Linux host as it conflicted with shared mode provided via pcscd

from [https://communities.vmware.com/message/2462510#2462510 Gemalto Smart Card Reader only appears as "Shared" not "Passthrough"]

* 1) Go to the VM's installation directory. Typically C:\Users\<username>\Documents\Virtual Machines\
* 2) Open <virtual-machine-name>.vmx file
* 3) Append the following lines:
usb.generic.allowCCID = "TRUE"
usb.ccid.disable = "TRUE"
* 4) Kill the process corresponding to the PCSC daemon on the Linux host

Do a # ps -ef | grep -i pcsc on your Linux host
sudo kill -9 <pid of the process that corresponds to pcscd>

Notes:
* 1) The first line in step 3 enables the passthrough mode
* 2) The second line in step 3 disables shared mode
* 3) Since you are killing the pcscd on your host, you wont be able to use the smart card on the host. You can passthrough the smart card now and use it in the VM

==== Change thumbnail speed ====

From Workstation 14 including 15, the thumbnail views are not in real time any more and the default refresh interval value is 3000 ms.

You can add

pref.thumbnailRefreshIntervalMs = 1000

(or other values) in the preference file %appdata%/vmware/preferences.ini to change the refesh rate. But keep in mind that this way may cause high CPU usage.

If you really need the previous real time thumbnail, you can use

pref.closeInactiveMKSWindows = "false"

But this way may cause mouse/keyboard functions under multi tabs not working well.

Both these settings are not documented or tested, so I cannot guarantee they working normally.

Note that you should make changes to the preferences.ini file with VMware Workstation shut down.

from: https://communities.vmware.com/message/2807350#2807350

=== Fusion ===
==== Applying a setting over all VMs ====

Instead of editing each .vmx file manually, you can also apply config options to all VMs, by creating/editing the user global config file that can be found at: ~/Library/Preferences/VMware\ Fusion/config

There's already a 'preferences' file in the same directory, but normally the config file has to be created.

If an individual .vmx file contains the same config options as the global file, the .vmx file will take precedence.

==== Hide the Full Screen application menu ====

It's unsupported, but try editing /Users/$USER/Library/Preferences/VMware Fusion/preferences and add the line:

fusion.showFullScreenTitleBar = "FALSE"

See also: http://communities.vmware.com/message/1348663#1348663

==== Delay drop down Full Screen application menu ====

Edit /Users/$USER/Library/Preferences/VMware Fusion/preferences and add the line:

fusion.fullScreenMenuDelay = "2"

The delay is in seconds and the default is 1.5 seconds, added since Fusion 4.1
A value of "0" removes the delay.

See also: http://communities.vmware.com/message/2273022

On VMware Workstation you would add the following lines to the preferences.ini file.

pref.fullscreen.showDelay = "5000"
to delay the showing of the toolbar 5000ms (5 seconds)
pref.fullscreen.hideDelay = "1000"
to hide the toolbar after 1000ms (1 second)

For Win7 the preferences.ini file is located under:
C:\Users\<username>\AppData\Roaming\VMware

==== debug menu ====

fusion.enableDebugMenu

(never tried)

==== Turn off full screen autofit to host ====

Here's another way to stop the guest from automagically being resized at each swipe:

* Open Finder, select the "Go" menu then select "Go To Folder..." and type in: ~/Library/Preferences/VMware Fusion/
* Open the preferences file in a text editor and add/append the following lines at the end of the file:

pref.autoFitGuestToWindow = "FALSE"
pref.autoFitFullScreen = "stretchGuestToHost"

Taken from: https://communities.vmware.com/message/2293562

==== Pass through host model ====

It's unsupported, but try editing /Users/$USER/Library/Preferences/VMware Fusion/preferences and add the line:

hw.model.reflectHost = "TRUE"

This will cause the VM to see the same model ID as the host. The default for this option is FALSE. Be aware that using this option may cause VM portability issues since the guest may now depend on this behavior and the type of the underlying Mac.

See also: http://communities.vmware.com/thread/336922

==== VM power options always display "Force" ====

If the Virtual Machine was not originally created in VMware Fusion then you will notice that the Fusion Virtual Machine menu has the word "Force" inserted before any power option.
For example copying a VM from a Windows systems to Mac it displays the "Force ..." commands by default. In other words, pressing the Option Key is backwards of what it is supposed to be. This is because the following options are missing from the Virtual Machine's .vmx configuration file.

powerType.powerOff = "soft"
powerType.powerOn = "soft"
powerType.suspend = "soft"
powerType.reset = "soft"

By default, VMware Fusion creates these options in the Virtual Machine's .vmx configuration file while VMware Player/Workstation does not. So, add the above options to the Virtual Machine's .vmx configuration file and the "Force ..." commands will then exhibit VMware Fusion normal behavior. Meaning in order to access the "Force ..." commands one will need to press the Option Key.

See also: http://communities.vmware.com/thread/402281

==== kernel debugging ====

You can attach a remote debugger such as gdb to your vm to do kernel debugging.

DebugStub knows nothing at all about the guest OS. Think of debugStub as an In-Circuit Debugger for the virtual CPU(s).

debugStub.listen.guest64 = "TRUE"
debugStub.listen.guest64.remote = "TRUE"
debugStub.hideBreakpoints=1
specify a custom port with:
debugStub.port.guest64 = "8865"
other options:
debugStub.listen.guest32 = "TRUE" # Enable listener for 32 bit guest
debugStub.listen.guest32.remote = "TRUE" # Allow remote connection
debugStub.port.guest32 = "32001" # Listen on specified port NNN

see also: [https://communities.vmware.com/thread/470936 Using debugStub to debug a guest linux kernel]

==== Additional logging ====
For troubleshooting boot issues etcetera you can increase the log level in vmware.log

monitor_control.log_vmsample = "TRUE"

[https://communities.vmware.com/thread/471833 Fusion 6.0.2 / OS X 10.9.2 Host / OS X 10.9 Guest VM running >100% CPU no matter what]

==== memory hole ====

At 3.2 GB there's a 1024kB memory hole.

You can use the pciHole.start option to adjust the start of the memory hole, measured in megabytes from address 0x00000000. The default is

pciHole.start = 3072

which corresponds to 0xC0000000.

from [https://communities.vmware.com/thread/478739 Memory hole at 3.2GB]

==== Disable Shared Folder event notification ====

isolation.tools.hgfs.notify.enable = "FALSE"

See also: http://kb.vmware.com/kb/2011360

==== Shared folder size check ====

The other workaround is to stop the VM, edit the VM's .vmx file and add the following setting:

tools.hgfs.volumeInfoType = "max"

Then start the VM again, and this time you will not need to disable the other shares which are on smaller sized volumes.

The default setting causes the shares to be aggregated to the smallest volume size that a share resides on when our file system is queried for size and free space.

The above setting overrides this to pick the largest volume size. The downside is that you can start a copy to a share on volume with a smaller amount of free space and it will only fail when it actually fails to write when the free space is exhausted.

If you know you are not going to run into that type of scenario yourself or you verify prior to starting the copy operation then you will be fine.

Note, the above can only be set to "min" or "max" and if not set at all, then "min" is the default.

from: [https://communities.vmware.com/message/2381223#2381223 Folder copy on Windows 7 vm fails for "not enough space", but there is.]

==== Disable location services ====

sensor.location = "disable"

to vmx.

[https://communities.vmware.com/message/2383410#2383410 how-to disable location services]

==== Disable automatic USB connect to guest feature ====

1. Suspend or shut down any running VMs and quit Fusion.

2. Ensure that the vmware-usbarbitrator process is no longer running.

3. Create/edit the host-global configuration file, with root privileges: (this example uses nano, but feel free to use any other editor)

sudo nano /Library/Preferences/VMware\ Fusion/config

4. Add the following line to disable the automatic claiming of USB devices:

usbarb.autoconnect.claimAll = "FALSE"

5. Save the file and quit the editor.

With this change, all USB devices should automatically connect to the host even when VMs are running. Note that it will completely disable the USB connection prompt, and will prevent devices from automatically connecting to VMs (even if the option is selected in settings). However it should still be possible to manually connect USB devices to a running VM (except possibly in cases where the reset command is not correctly issued via the hub).

from: [https://communities.vmware.com/message/2393343#2393343 2014 Preview still has USB 3 hub issue]

==== Open file with host OS application ====
When a file is located on a shared folder (VMware HGFS) then you can choose to be able to open this file with the host OS default application.
For example. Your png file can open in macOS Preview.

proxyApps.publishToGuest = "TRUE"

See also: [https://communities.vmware.com/t5/VMware-Workstation-Pro/Has-there-ever-been-a-solution-to-opening-a-host-application/m-p/2841051 Has there ever been a solution to opening a host application from a guest OS?]

==== Pass OS X host serial number ====

If you want an OS X guest to use the host's serial number, you'll need to add this option to the VM's configuration:

serialNumber.reflectHost = "TRUE"

==== Pass OS X host hardware model ====

To pass hardware model to the guest (not even sure this works, as it does not seem to do anything for me, but ... Fusion does not error on starting the VM )

hw.model.reflectHost = "TRUE"

==== Pass OS X host hardware model ID ====

If you want an OS X guest to use the host's hardware model ID (i.e. "MacPro5,1"), board ID (i.e. "Mac-12345678") and serial number all together:

smbios.reflectHost = "TRUE"

=== Any platform ===

==== Slow down time in guest ====

You can't quite stop time, but you can make it go extremely slowly. Set the following in your system-wide configuration file (/etc/vmware/config on Linux; C:\ProgramData\VMware\VMware Workstation\config.ini on Windows):

host.cpukHz = 1000

This is probably not all that useful in practice, unless the guest OS has no reliance on any time sources.

from [https://communities.vmware.com/message/2431592#2431592 System time]

==== Set max number of snapshots ====

snapshot.maxSnapshots = 100

==== Enable DX11 or OpenGL Host Renderer ====

Courtesy @bluefirestorm at [https://communities.vmware.com/message/2812499#2812499 setting *.vmx]

mks.enableDX11Renderer

When 3D accelerated graphics is enabled in Workstation 12/14/15 the default value is "TRUE" (i.e. the line does not have to be present in the vmx file), VMware Workstation uses DX11 of the Windows host to deliver the DX10/OpenGL 3.3 core profile capability inside the VMs. For Linux hosts, the equivalent is mks.enableGLRenderer = "TRUE"

==== Enable D3D Renderer ====
Courtesy @bluefirestorm at [https://communities.vmware.com/message/2812499#2812499 setting *.vmx]

mks.enableD3DRenderer

Default is "FALSE" from Workstation 12.x and later. This is only useful in version 12.x if the host graphics card does not have DX11 capability and setting this to TRUE and enableDX11Renderer to FALSE let the VM have some limited 3D accelerated graphics capability. This looks like is already ineffective in version 14/15.

==== Select host Graphics card to use ====
Courtesy @bluefirestorm at [https://communities.vmware.com/message/2812499#2812499 setting *.vmx]

mks.dx11.vendorID

valid values are the vendor ID of the graphic card, 0x8086 for Intel, 0x10DE for Nvidia, 0x1002 for AMD.

If this line is not present, VMware Workstation will use the default graphic card of the Windows host system. This line is useful if the system has two graphic cards from two different vendors that are simultaneously active on the host machine (example: Intel integrated graphics in the CPU and a discrete graphics card from Nvidia or AMD).

==== ReflecHost ====
Courtesy @bluefirestorm at [https://communities.vmware.com/message/2812499#2812499 setting *.vmx]

SMBIOS.reflectHost

Default is "FALSE". If set to "TRUE" some of the DMI info will use the host values (example: manufacturer will change from VMware to the host value). You can see this difference by using msinfo32 in Windows VM or dmidecode in Linux VM. This is not so useful anymore to hide the fact that the VM is a VM.

==== vmx.buildType ====
Courtesy @bluefirestorm at [https://communities.vmware.com/message/2812499#2812499 setting *.vmx]

vmx.buildType

Valid values are "release" and "debug". The "debug" is the default for the beta versions (aka Tech Preview). When set to "debug", vmware-vmx-debug.exe will be used instead of vmware-vmx.exe and the vmware.log file will be larger.

=== External sites ===

There's only one .vmx site that has most .vmx options and that's Ulli's reference over at sanbarrow:

http://sanbarrow.com/vmx/vmx-advanced.html

Shrink guest on hosted platform

2021-04-15T22:39:01Z

Wila: and for Fusion

== Important ==
Note that the technique described below to zero out the unused space on the guest OS will in fact make your guest virtual disk grow to the maximum size first. For each byte that is changed to zero the virtual disk will need to claim a byte. This means that while you can use the technique to reclaim disk space after the unused space is zero'd out, it is important to have enough space before you start.

If you don't have that kind of free disk space then you can skip the zero-ing out part. You can still reclaim space, but it will be less optimal.
Alternatively you can use the "Partially zero out" trick described below.

=== How much free space do you need before shrinking? ===
Also please note that you need more free space in order to be able to run the shrinking process.
The shrinking process consists of making a copy of your virtual disk while omitting the zero'd out blocks.
So how much extra space you need depends on how you configured the virtual disk for your Virtual Machine.
If your Virtual Disk is a single file, then your free space requirement can grow up-to the full size of that virtual disk.

If OTOH you are using the split disk scheme where a virtual disk is sliced into multiple files the maximum free space you need is the maximum size a slice can be. Nowadays there's not a fixed slice size, it depends on how big your virtual disk actually is.

The split disk scheme since VMware Workstation 11 (VMware Fusion 7), older version of Workstation/Fusion use a 2GB split disk scheme.

Capacity Extent size
================================
<=128GB 4GB (increased from 2GB)
>128GB && <2TB Capacity / 32 (so maximum of 32 extents)
>=2TB 2TB

For extra safety I recommend to make sure you have an additional 2GB of free space on top of those requirements as mentioned above.

As side note, this also explains why it is generally recommended at the forum by the regulars to use a split disk scheme over single disk files.
This same problem also exists when you want to commit snapshots.

=== Using the clean up option in the menu ===

When you use the "Clean Up Disks" option in the menu in VMware Workstation 12 or later, then you do not require extra disk space for reclaiming space (see also: [https://docs.vmware.com/en/VMware-Workstation-Pro/14.0/com.vmware.ws.using.doc/GUID-421A1073-BF16-4BC7-AA76-46B954CA438D.html Clean Up a Virtual Hard Disk on Windows Hosts] )

Currently this only works for Windows guests where the filesystem is NTFS.

== Zero out unused space in a Linux VM ==

Before we try to shrink the virtual disk files, we should try to remove any unneeded files from the virtual machine to free space.
More free space means more disk space that can get reclaimed.

One of the areas in a VM that can take up a lot of disk space is the repository cache. So I personally tend to clean the cache in the VM before reclaiming disk space at the host.

Clean up your repositories:

For example, on Debian-based VMs, you can run the following command (in the VM)

apt-get clean all

to clear out the local repository of retrieved package files.

On red hat based VMs that would be:

yum clean

The next step is important:

Shut down any services that depend on having enough available disk space to run.

The reason for this is that we are going to write out zero's to the file system until the file system is full and we do not want any application - for example a database system like mySQL or postgreSQL - to run out of disk space while we are zeroing out the file system. If mySQL would try to write when your disk is full you risk a corrupted database. So this step is important!

Next run (also from within the VM):

cat /dev/zero > zero.fill;sync;sleep 1;sync;rm -f zero.fill

to fill the unused space with zeros and then remove the "zero.fill" that has all the zero's.

As this command writes to the disk until it runs out of disk space, you will get an error "No space left on the device". This is expected.

Note that you have multiple partitions that you have to repeat the above command to zero out for each partition.
Adjust "zero.fill" to the relevant mountpoint, for example if you have a separate partition for home it would become:

cat /dev/zero > /home/zero.fill;sync;sleep 1;sync;rm -f /home/zero.fill

=== Zero out a part of your virtual disk ===

If your virtual machine cannot be taken down and you do not want to shut down services that might end up corrupting files because of the "No space left on the device" problem then an idea that might work is to zero out a part of your partition.

This for example creates a 100MB size file filled with zero's

# dd if=/dev/zero of=zero.fill bs=1024 count=102400
102400+0 records in
102400+0 records out
104857600 bytes (105 MB) copied, 0.3839 s, 273 MB/s

So if you want to zero out 10GB instead, add two more zero's to the count parameter, eg: count=10240000

If you want to fill up in steps, just change the output file name from "zero.fill" into "zero.fill2" etcetera..

Then run the "sync; sleep 1; sync" from above and remove the zero.fill files.

If your VM is running on VMware vSphere and you have a NFS LUN with enough free space then one way to reclaim your space is to Storage vMotion the VM to NFS storage and back. Once done the zero'd out data has been reclaimed. No need to shut down the VM.

If this is not for you, then do read on.

== Zero out unused space on a Windows VM ==

To do the same with a windows VM, you can use Microsoft's tool [http://technet.microsoft.com/en-us/sysinternals/bb897443.aspx sdelete].

Run it as
sdelete -z c:

To clean out the free space on disk c:

Careful!

As of sdelete v1.6 -c and -z have changed meanings, many instructions say -c zeros free space, this is no longer the case, it zeros the space then fills with random data in accordance with DOD spec: DOD 5220.22-M, random data will prevent the reclaim logic from working.

The trigger to zero space with 0x00 has changed to -z!

== Zeroing an encrypted disk ==

If you use disk encryption in the guest OS then zero'ing out the disk won't help.

The reason is that a good disk encryption scheme will write out random data to the disk when you write out zero's.

In other words, if you have enabled full disk encryption in the guest then you can not shrink the disk anymore as there is no space to reclaim.

== Shrink the disk ==

Then power down the VM and open a terminal on the Linux host.

Navigate to the directory where the .vmdk files are located, e.g.:

cd /var/lib/vmware/Virtual\ Machines/Ubuntu\ Desktop/

You can shrink the .vmdk file as follows:

vmware-vdiskmanager -k Ubuntu\ Desktop.vmdk

On Windows the command also uses the -k option, so I leave that for you as an exercise.

Note that vmware-vdiskmanager is probably not in your search path, so you might have to prepend the vmware-vdiskmanager command with the actual path with the command is located.

If you need to use "sudo" in order to be able to run the above then beware that the ownership of the .vmdk files might get changed to root.

You will have to change the ownership back to your own user, eg:
sudo chown username: *.vmdk
If you don't change the ownership back you might see errors like:
"Unable to open file .../Virtual Disk.vmdk: Insufficient permission to access file".

== Shrink using vmware tools ==

Nowadays you can also shrink the guest by using the shrink feature as offered via vmware tools.

So for clarity all of the following commands are run from within the guest to shrink the disk while the guest is running.

On linux in order to use this run:
sudo vmware-toolbox-cmd disk shrink /

Where "/" is the mount point of the partition that you want to shrink.

On Windows in order to use this run:

C:\Program Files\VMware\VMware Tools>VMwareToolboxCmd.exe disk shrink <location>

where <location> is the drive you want to shrink

On OS X / macOS the command to use is:

sudo /Library/Application\ Support/VMware\ Tools/vmware-tools-cli disk shrink /

== Shrink macOS VM with APFS ==

[https://communities.vmware.com/thread/581576 Solved: Shrink an APFS virtual disk]

== External links ==

* [https://docs.vmware.com/en/VMware-Workstation-Pro/16.0/com.vmware.ws.using.doc/GUID-421A1073-BF16-4BC7-AA76-46B954CA438D.html Clean Up a Virtual Hard Disk on Windows Hosts - Workstation 16 Pro documentation]

* [https://docs.vmware.com/en/VMware-Workstation-Pro/16.0/com.vmware.ws.using.doc/GUID-3F94C7B5-19A5-4E91-9709-B17FAA93FF75.html Configuring and Maintaining Virtual Hard Disks - Workstation 16 Pro documentation]

* [https://docs.vmware.com/en/VMware-Fusion/12/com.vmware.fusion.using.doc/GUID-6BB29187-F47F-41D1-AD92-1754036DACD9.html#GUID-6BB29187-F47F-41D1-AD92-1754036DACD9 Clean up a Virtual Machine - VMware Fusion 12 documentation]

Shrink guest on hosted platform

2021-04-15T22:30:48Z

Wila: adding links to the official doc of VMware Workstation

== Important ==
Note that the technique described below to zero out the unused space on the guest OS will in fact make your guest virtual disk grow to the maximum size first. For each byte that is changed to zero the virtual disk will need to claim a byte. This means that while you can use the technique to reclaim disk space after the unused space is zero'd out, it is important to have enough space before you start.

If you don't have that kind of free disk space then you can skip the zero-ing out part. You can still reclaim space, but it will be less optimal.
Alternatively you can use the "Partially zero out" trick described below.

=== How much free space do you need before shrinking? ===
Also please note that you need more free space in order to be able to run the shrinking process.
The shrinking process consists of making a copy of your virtual disk while omitting the zero'd out blocks.
So how much extra space you need depends on how you configured the virtual disk for your Virtual Machine.
If your Virtual Disk is a single file, then your free space requirement can grow up-to the full size of that virtual disk.

If OTOH you are using the split disk scheme where a virtual disk is sliced into multiple files the maximum free space you need is the maximum size a slice can be. Nowadays there's not a fixed slice size, it depends on how big your virtual disk actually is.

The split disk scheme since VMware Workstation 11 (VMware Fusion 7), older version of Workstation/Fusion use a 2GB split disk scheme.

Capacity Extent size
================================
<=128GB 4GB (increased from 2GB)
>128GB && <2TB Capacity / 32 (so maximum of 32 extents)
>=2TB 2TB

For extra safety I recommend to make sure you have an additional 2GB of free space on top of those requirements as mentioned above.

As side note, this also explains why it is generally recommended at the forum by the regulars to use a split disk scheme over single disk files.
This same problem also exists when you want to commit snapshots.

=== Using the clean up option in the menu ===

When you use the "Clean Up Disks" option in the menu in VMware Workstation 12 or later, then you do not require extra disk space for reclaiming space (see also: [https://docs.vmware.com/en/VMware-Workstation-Pro/14.0/com.vmware.ws.using.doc/GUID-421A1073-BF16-4BC7-AA76-46B954CA438D.html Clean Up a Virtual Hard Disk on Windows Hosts] )

Currently this only works for Windows guests where the filesystem is NTFS.

== Zero out unused space in a Linux VM ==

Before we try to shrink the virtual disk files, we should try to remove any unneeded files from the virtual machine to free space.
More free space means more disk space that can get reclaimed.

One of the areas in a VM that can take up a lot of disk space is the repository cache. So I personally tend to clean the cache in the VM before reclaiming disk space at the host.

Clean up your repositories:

For example, on Debian-based VMs, you can run the following command (in the VM)

apt-get clean all

to clear out the local repository of retrieved package files.

On red hat based VMs that would be:

yum clean

The next step is important:

Shut down any services that depend on having enough available disk space to run.

The reason for this is that we are going to write out zero's to the file system until the file system is full and we do not want any application - for example a database system like mySQL or postgreSQL - to run out of disk space while we are zeroing out the file system. If mySQL would try to write when your disk is full you risk a corrupted database. So this step is important!

Next run (also from within the VM):

cat /dev/zero > zero.fill;sync;sleep 1;sync;rm -f zero.fill

to fill the unused space with zeros and then remove the "zero.fill" that has all the zero's.

As this command writes to the disk until it runs out of disk space, you will get an error "No space left on the device". This is expected.

Note that you have multiple partitions that you have to repeat the above command to zero out for each partition.
Adjust "zero.fill" to the relevant mountpoint, for example if you have a separate partition for home it would become:

cat /dev/zero > /home/zero.fill;sync;sleep 1;sync;rm -f /home/zero.fill

=== Zero out a part of your virtual disk ===

If your virtual machine cannot be taken down and you do not want to shut down services that might end up corrupting files because of the "No space left on the device" problem then an idea that might work is to zero out a part of your partition.

This for example creates a 100MB size file filled with zero's

# dd if=/dev/zero of=zero.fill bs=1024 count=102400
102400+0 records in
102400+0 records out
104857600 bytes (105 MB) copied, 0.3839 s, 273 MB/s

So if you want to zero out 10GB instead, add two more zero's to the count parameter, eg: count=10240000

If you want to fill up in steps, just change the output file name from "zero.fill" into "zero.fill2" etcetera..

Then run the "sync; sleep 1; sync" from above and remove the zero.fill files.

If your VM is running on VMware vSphere and you have a NFS LUN with enough free space then one way to reclaim your space is to Storage vMotion the VM to NFS storage and back. Once done the zero'd out data has been reclaimed. No need to shut down the VM.

If this is not for you, then do read on.

== Zero out unused space on a Windows VM ==

To do the same with a windows VM, you can use Microsoft's tool [http://technet.microsoft.com/en-us/sysinternals/bb897443.aspx sdelete].

Run it as
sdelete -z c:

To clean out the free space on disk c:

Careful!

As of sdelete v1.6 -c and -z have changed meanings, many instructions say -c zeros free space, this is no longer the case, it zeros the space then fills with random data in accordance with DOD spec: DOD 5220.22-M, random data will prevent the reclaim logic from working.

The trigger to zero space with 0x00 has changed to -z!

== Zeroing an encrypted disk ==

If you use disk encryption in the guest OS then zero'ing out the disk won't help.

The reason is that a good disk encryption scheme will write out random data to the disk when you write out zero's.

In other words, if you have enabled full disk encryption in the guest then you can not shrink the disk anymore as there is no space to reclaim.

== Shrink the disk ==

Then power down the VM and open a terminal on the Linux host.

Navigate to the directory where the .vmdk files are located, e.g.:

cd /var/lib/vmware/Virtual\ Machines/Ubuntu\ Desktop/

You can shrink the .vmdk file as follows:

vmware-vdiskmanager -k Ubuntu\ Desktop.vmdk

On Windows the command also uses the -k option, so I leave that for you as an exercise.

Note that vmware-vdiskmanager is probably not in your search path, so you might have to prepend the vmware-vdiskmanager command with the actual path with the command is located.

If you need to use "sudo" in order to be able to run the above then beware that the ownership of the .vmdk files might get changed to root.

You will have to change the ownership back to your own user, eg:
sudo chown username: *.vmdk
If you don't change the ownership back you might see errors like:
"Unable to open file .../Virtual Disk.vmdk: Insufficient permission to access file".

== Shrink using vmware tools ==

Nowadays you can also shrink the guest by using the shrink feature as offered via vmware tools.

So for clarity all of the following commands are run from within the guest to shrink the disk while the guest is running.

On linux in order to use this run:
sudo vmware-toolbox-cmd disk shrink /

Where "/" is the mount point of the partition that you want to shrink.

On Windows in order to use this run:

C:\Program Files\VMware\VMware Tools>VMwareToolboxCmd.exe disk shrink <location>

where <location> is the drive you want to shrink

On OS X / macOS the command to use is:

sudo /Library/Application\ Support/VMware\ Tools/vmware-tools-cli disk shrink /

== Shrink macOS VM with APFS ==

[https://communities.vmware.com/thread/581576 Solved: Shrink an APFS virtual disk]

== External links ==

* [https://docs.vmware.com/en/VMware-Workstation-Pro/16.0/com.vmware.ws.using.doc/GUID-421A1073-BF16-4BC7-AA76-46B954CA438D.html Clean Up a Virtual Hard Disk on Windows Hosts - Workstation 16 Pro documentation]

* [https://docs.vmware.com/en/VMware-Workstation-Pro/16.0/com.vmware.ws.using.doc/GUID-3F94C7B5-19A5-4E91-9709-B17FAA93FF75.html Configuring and Maintaining Virtual Hard Disks - Workstation 16 Pro documentation]

Shrink guest on hosted platform

2021-04-15T22:24:45Z

Wila: Note about zero'ing out an encrypted disk

DOS

2021-02-13T17:39:45Z

Wila: Added a few relevant links