All posts by Wil van Antwerpen

Wil van Antwerpen
October 23, 2021

What you should know about VMware’s experimental vTPM

Updates:
2021/12/15, added near the end,
2022/01/24, “” “” “” “”
2022/01/27, “” “” “” “”

VMware recently released Workstation 16.2 and Fusion 12.2. One of the exciting new features is an experimental vTPM implementation that doesn’t need encryption to help with Windows 11 virtual machines. This however is not the complete story and in my opinion you need to know more details before using this experimental feature.
In the rest of this document I will use the word “Workstation”, but if you’re using Fusion, read that as “Fusion”, otherwise this article gets really hard to read.

The background

Microsoft Windows 11 now requires a TPM device. You have been able to use a TPM device in your virtual machines since Workstation 14 (Fusion 10). In the past however, you would have to encrypt your entire Virtual Machine using VMware’s encryption logic before you can add the TPM device. With the new experimental vTPM feature the virtual disk is no longer encrypted, thereby preventing additional performance loss. But that is only a part of the story.

The potential issue

While the virtual disk itself no longer gets encrypted, a lot of the other files -including disk descriptor files- are still encrypted. Worse even, the password used to encrypt these files is unknown to you. This can become a pretty big problem later on.

OK.. so far the overview, let’s step back and look at how this works and then describe this all in more details.

How to use the new experimental vTPM feature?

After upgrading to Workstation 16.2 (Fusion 12.2), shut down Workstation and add the following line to the vmx file of your virtual machine.

managedvm.autoAddVTPM = "software"

Then go back to VMware Workstation and open the virtual machine.
At that moment, a vTPM has been added to your VM and in addition the following new lines are also added to your .vmx file (with different details). 

managedVM.ID = "52 e3 71 9f d0 ef 55 6e-7e f0 4e 05 51 d3 98 52"
encryption.encryptedKey = "AQAAANCMnd8BFdERjHoAwE/Cl+sBAAAAZKX7IXyss0.......CKw=="
encryption.keySafe = "vmware:key/list/(pair/(phrase/OrVWhvfQTLY%3d/pass2key%3dPBKDF2%2dHMAC%2dSHA%2d1%3acipher%3dAES%2d256%3arounds%3d10000%3asalt%3dUTYIUjqT6VPerQQfAvKY7Q%253d%253d,HMAC%2dSHA%2d1,yXJ3PmVy......3d))"
encryption.data = "4pKXS5ChzVg5gngF.......+OT2WswlLjgGzfajENWM5g=="

The rest of the .vmx file stays untouched.
So far, so good and if this was all that happened, then I would have been very happy with the vTPM implementation. This however is far from all that has happened to your VM.

The following files are now also encrypted:

the .vmsd file (which holds your snapshot meta data)
the .nvram file (your bios/efi data)
all your .vmsn/.vmss files (snapshot/suspend file state data)
all the vmem files (memory backing files)

and the worst one:
all the vmdk descriptor files. Your main vmdk descriptor files _and_ all the descriptor files of the vmdk snapshot files, including the snapshots taken before the vtpm was added.

Here’s an example of a .vmdk file before:

# Disk DescriptorFile
version=1
encoding="UTF-8"
CID=290130a2
parentCID=ffffffff
createType="twoGbMaxExtentSparse"

# Extent description
RW 8304640 SPARSE "Virtual Disk-s001.vmdk"
RW 8304640 SPARSE "Virtual Disk-s002.vmdk"
RW 8304640 SPARSE "Virtual Disk-s003.vmdk"
RW 8304640 SPARSE "Virtual Disk-s004.vmdk"
RW 8304640 SPARSE "Virtual Disk-s005.vmdk"
RW 8304640 SPARSE "Virtual Disk-s006.vmdk"
RW 8304640 SPARSE "Virtual Disk-s007.vmdk"
RW 8304640 SPARSE "Virtual Disk-s008.vmdk"
RW 2768896 SPARSE "Virtual Disk-s009.vmdk"

# The Disk Data Base 
#DDB

ddb.adapterType = "lsilogic"
ddb.geometry.cylinders = "4307"
ddb.geometry.heads = "255"
ddb.geometry.sectors = "63"
ddb.longContentID = "1136bc3f7e515f8ea97d7a12290130a2"
ddb.toolsInstallType = "1"
ddb.toolsVersion = "11301"
ddb.uuid = "60 00 C2 95 84 d5 b7 74-36 7e 25 b7 34 a0 f2 40"
ddb.virtualHWVersion = "11"

and how the vmdk descriptor file looks like afterwards:

[18]lsilogic[binary data]vmware:key/list/(pair/(null/%3cVMWARE%2dEMPTYSTRING%3e,HMAC%2dSHA%2d1,%2b%2biOIPLnCp1AY2vI5IaOML7SxbI1%2fI….[lots of binary data]


Why might this be a problem?

Normally with any new experimental flag for a virtual machine you can go back to normal by removing the flag again.
As the autoVTPM flag has effectively altered your VM, just removing the flag again is not enough to completely go back.
You might be able to boot, but all the parts that had been encrypted, are still encrypted…. and you have no password.
Well it’s there, in the .vmx, but encrypted.

So what can you remove without damaging your VM?

Remove the line:

managedvm.autoAddVTPM = “software”


managedVM.ID = “52 e3 71 9f d0 ef 55 6e-7e f0 4e 05 51 d3 98 52”

encryption.encryptedKey = “AQAAANCMnd8BFdERjHoAwE/

encryption.data = “4pKXS5ChzVg5gngF…….+OT2WswlLjgGzfajENWM5g==”

encryption.keySafe = “vmware:key/list/(pair/(phrase/OrVWhvfQTLY%3d/…

Effects:

Removing that should not break your VM unless you used a feature depending on a TPM such as bitlocker. Windows 11 will ask you to setup the login PIN again.

Does not break your VM either

VM no longer boots (Enter Password => “This virtual machine is encrypted…”), can’t edit settings in Workstation either

Error: Could not open vmx, internal error

VM no longer boots (The disk ‘yadayada.vmdk’ is encrypted and a required key was not found. Cannot decrypt disk because key or password is incorrect

So this means that if you overwrite your .vmx file with a earlier copy of your VM that you can no longer open or edit that VM as the lines above are all missing.
In order to go back to the same state before you should restore the other files and optionally remove files that are automatically recreated when missing (such as .nvram, .vmsd, .vmxf)

Additional Side effects

Several automation API’s no longer work.

For example: Both starting your VM and take or commit snapshots, no longer work as expected. Those operations now require you to enter a password (which was never given).

You can still take a snapshot when a VM does not run.
However when the VM is running you get an error if you try:

C:\>"C:\Program Files (x86)\VMware\VMware Workstation"\vmrun -T ws snapshot "C:\VMs\Windows\Windows.vmx" "testsnapshot2"
Error: Authentication for encrypted virtual machine failed

or start a VM

C:\>"C:\Program Files (x86)\VMware\VMware Workstation"\vmrun -T ws start "C:\VMs\Windows\Windows.vmx"
Error: The operation is not supported

If you want to start your VM by trying to use vmware -x or vmware -X then that no longer works. It does start VMware Workstation and selects your VM, but it does not run the VM.

There’s a free disk space check when you add the new experimental vtpm feature. As a result you need to have free disk space for the full size of your virtual disk before you can apply the feature. Without sufficient free disk space, the vtpm is added partially and your VM might already be broken.

virtual machine in an inconsistent state

If you want to copy your VM to another host and run it there then you are out of luck (see edit below). The VM only runs on your existing host and trying to open it on another host now results in the following screen:

Restore VM on a different host
Restoring a VM from another machine

You can’t decrypt the vmdk descriptor files as you don’t have the password. The remove encryption dialog demands a non empty password (not that the password is actually empty, I tried that)

Edit 2021/12/15


Note that the inability to copy the VM to another hosts is only a limitation with the experimental vTPM feature. If your VM is fully encrypted you can copy it to a another host, see also this post by VMTN user DVE2000 “How easy is it to move a TPM2 Win11 VM to another host?“

Hopefully this will not be a limitation once this is no longer an experimental feature. VMware is aware about this.

Edit 2022/01/24

Note that the experimental vTPM feature does not work on VMware Workstation running on Linux hosts. For now this only works on Windows hosts (and on macOS when running VMware Fusion)

See also this forum thread: TPM and Secure Boot errors on Windows 11 preview vm

Edit 2022/01/27

Linked clone can be used to partially encrypt disk

The following is a trick posted by reddit user dmartin-ames in thread Lessons upgrading Windows 10 guest to Windows 11

If you encrypt a VM based that is based on a linked clone then your base image can be unencrypted. The VM then only has a small encrypted delta disk. This was tested with a fully encrypted VM, but is probably interesting to know for here as well.

Edit 2022/07/06

The following reddit thread describes how-to remove the vTPM when your virtual disk is a single filek disk which has the metadata embedded: Move a Windows 11 VM (with TPM) to a new computer

Recommended steps to take before using the new experimental vTPM feature

  • Commit all your snapshots
  • Make sure that your virtual disk is using disk slices and not the – all in one file (monolithic)- virtual disk format. By using disk slices the descriptor files are separate files and easy to restore.
  • Make a copy of the following files in your VM: the .vmx file and all of your vmdk descriptor files. Optionally also make a copy of the .nvram and .vmsd files. Then if you want to go back to original state you can replace these files with the old copies. As long as you haven’t changed your VM configuration, not used bitlocker in the VM or other features that depend on that vTPM then you can roll back that way.
  • Make sure you have plenty of free disk space before trying this experimental feature.

Does this mean that you shouldn’t use this feature?

No, that’s not my message. I still think it is a great feature. It is however good to be aware about the changes it makes to your VM.
Experimental features are labeled like that for a reason. Sometimes the risk is just a crash, sometimes the risk is a bit bigger.
You should have made good backups of your important data already and -if not- then this hopefully reminds you to fix that 😉

1 Comment on What you should know about VMware’s experimental vTPM Inblog VMware Fusion VMware Workstation
VMware Fusion 12 Metal Support
Wil van Antwerpen
October 1, 2020

VMware Fusion 12.0 macOS guest Metal Renderer Support

Ok.. I’m so ecstatic.. a quick blog post must be written…

The Product manager of VMware Fusion, Michael Roy, had a classic “One More Thing” item in his VMworld presentation. The presentation was “What’s New with VMware Workstation and VMware Fusion”.

While running a Big Sur macOS guest, he showed “Metal Support” working without a hitch… Now we have been told for years that we cannot get 3D Acceleration in a macOS guest. Seeing this on the list of “things to come” was already pretty great. Something to look forward to.
During that same presentation he also showed the .vmx settings in order to get that working. Once the feature lands…

Who wants to wait?

So of course, immediately after the presentation I had to try. No matter that it is only supposed to be working in a future version of VMware Fusion 12.0.
After adding the .vmx settings from the presentation I got a “Invalid configuration” error (or something along those lines).
OK, sad panda.

But … silly me did not look at the vmware.log file. Today I was poking Michael a bit on twitter and asking about how well Metal works on Big Sur beta 9 and that it is “so hard to wait” and he tells me “but you can try it yourself already”… ?

OMG.. that’s when I realized that I had missed a detail..

It’s all in the details

Also my host wasn’t running Big Sur yet (I had only run it in a VM)
… so… next hour or so I was frantically busy installing Big Sur Beta 9 on my 2014 Mac Mini and YES… IT DOES WORK and it is SOOOO SMOOTH

This is the best thing since sliced bread.


THANK YOU VMware Fusion team!

In summary

This is not an officially released feature, treat it what it is: Experimental

Required: minimum of macOS Big Sur as host OS
Required: minimum VMware Fusion 12.0
Guest OS support: minimum of macOS Big Sur as guest OS (earlier macOS versions are missing the GPU paravirtual kernel extension for this – AppleParavirtGPU.kext. Unless apple steps in here and releases that for earlier macOS versions, it likely isn’t coming to earlier guest OS’s)

You have to add the following lines to the .vmx file of your VM in order to test this:
svga.present="FALSE"
appleGPU0.present="TRUE"
appleGPU0.screen0.width = "1680"
appleGPU0.screen0.height = "1050"

To be honest I don’t even have the lines with width and height, but that’s how you can define that for now.
It will only get better from here on once it is officially supported.

Update 2020/11/13: Another tip from Michael Roy (thanks Mike) is to update your VMware Tools to 11.2

Update 2021/06/13: Beware that you cannot edit the .vmx file of an encrypted VM! If you want to test this on an encrypted VM you will have to remove the encrypted before trying to change the .vmx file. If you don’t’ do that, you will likely break your VM.

Now that you are here. Please check out our product “Vimalin“. It has been designed for making your life easier to get good backups of your VMs. We support VM’s running in VMware Fusion, VMware Workstation and VMware Player.

More info at our main page

Leave a comment Inblog
Boot menu
Wil van Antwerpen
March 1, 2020

Install Android x86 in VMware Fusion

Thanks to the Android x86 project you can run Android as a VM in VMware Fusion. Getting this to work requires a few additional steps that are not exactly obvious. So I figured to write this post.

For this post I used the latest release Android 9.0 r1 which you can download from OSDN with this direct link android-x86_64-9.0-r1.iso

Install Android 9.0 as a VM

In VMware Fusion, from the menu select File -> New.
You will get the following screen:

Select Installation method

Drag your downloaded .iso file onto the designated area and press the Continue button.

Select your .iso file
The create a new virtual machine wizard

As you can see I had installed android earlier. The “New VM” wizard comes with the .iso file you dragged onto it selected and it detected it as “FreeBSD 10 or earlier”. That guest OS type isn’t exactly correct, but it doesn’t matter for getting this to work. Select “Continue”.

Select BIOS
Select “Legacy BIOS”, not UEFI

For the firmware option, it is recommended to stick to the “Legacy BIOS”. Click Continue again.

Finish Wizard mode
Finish Wizard

Customize Virtual Hardware

Here we click on “Customize Settings” and not “Finish” as the defaults need to be tweaked for the VM to run better. When you click “Customize Settings you first get an opportunity to rename your VM to something better.

Customize Change Name
Give the VM a proper name

I figured to call the VM “Android x86_64”, but name it anything you like. Then press Save.

Virtual Machine Settings
Adjust the default VM settings

Here we can change the default VM settings.
Click on “Processors & Memory”

Processors and memory
Change default vCPU’s and RAM

The default was 1 vCPU and 256MB of RAM. That’s really not sufficient, change to 2 vCPU’s and 2GB of RAM. More can be added later if it isn’t enough for your usage. No need to change any of the advanced options.

Click on “Show All” after making the changes.

That brings you back to the settings. Click on the “Display” icon to change the settings there.

Display Settings
Enable 3D and assign more video RAM

Enable 3D and change the shared graphics memory to 1024 MB.

Android Installation Walk through

Click back on “Show All” and close the “Settings” dialog. You can now boot your VM. It should come up with the following screen.

Boot menu
Select “installation” in the boot menu

Select “installation” from the boot menu here as we are going to create it into a VM.

Create Partition
Create a new partition

Partitioning the virtual disk

We are going to create a new “All in one” partition, type “C” to select the “Create/Modify partitions” option. With the arrow keys you can navigate on the options. Press the “Return” key with the “OK” button highlighted like here.

Create GPT or MBR
Create MBR

We are not going to use GPT, but MBR instead. So select “No” like the default and press “Return” once more.

Create New Partition
Create a new partition

Use the “Right Arrow” key to select “New” and press Return.

Create Primary Partition
Create a Primary Partition

The partition wizard wants to know if you want to create a Primary or a Logical Partition. Choose the default (Primary) and press return.
After that it asks how big that partition should be. It will default to the whole disk. Which is correct.

size: 21467.98

Press Return again.

Make bootable
Make partition bootable

We need to make the partition bootable in order to be able to start up. So with “Bootable” selected as above press “return”. The “Boot” flag should show up, just as in the screenshot above.
Arrow right a few times to go to “Write”
Press “return”

Write New partition
Write partition to disk

You are asked if you are sure as it is a potentially data destroying operation. This is a new virtual machine, so yes we are sure. Type “yes” -without typing the parentheses- and press return. As you can see in the above screenshot, the letter “s” fell off the screen. Don’t worry about that.

Select partition
Select new partition

Once we have a partition, we can select it.
Select “OK” and return once more.

Create file system
Create ext4 file system

Our partition needs a file system, select ext4 and continue.

Confirm write ext4
Write out ext4 file system

Yep, format as ext4, Select Yes and continue.

Install a boot loader

Install Grub
Install boot loader

Choose to install the GRUB boot loader.
Select Yes and continue.

Copy the installation files to the VM

Install system as read/write
keep system read only

We do not need system read-write so keep it read only. Select “No” and continue. The installer will copy all the files to your virtual disk and once that completes, the following screen appears.

Android is installed
Android installed

Fix the problems

You can try the “Run Android-x86”, but it won’t work. You’ll get a blinking cursor, so you might just save yourself the trouble of having to press reset in the toolbar and go straight for a “Reboot”.

Grub boot menu options
Grub boot menu options

Android is now installed on your virtual disk. However trying the first options gives you a black screen and all the other “Debug” options give you a screen with text scrolling by that all stops at “USB video class driver”

Boot into LVDS
Booting into debug

Not exactly great.
But it can be fixed.

Adjust boot options

So reset the VM, get back to the “Grub options” screen from above.
Select “debug mode” and press the letter “e”, the on line “kernel” press “e” again to edit.

edit grub kernel line
Edit grub kernel line

At the end of the line add “vga=834 nomodeset xforcevesa” like above. Press return to get back in the previous screen and press “b” to boot with the new changed kernel parameters.

boot into debug
Booted into debug

Let it boot. Android might appear to hang at the end, but if you press “return” then you will get a prompt.

edit grub menu.lst
remount read-write, edit grub menu.lst

Remount the disk as read/write

At the prompt do the following

Now remount the partition so you can make changes:
mount -o remount,rw /mnt
Then edit the default menu file for grub in vi:
vi /mnt/grub/menu.lst

Edit in vi
Edit boot option in vi

Use the cursor keys to navigate to the first line that has “kernel” at the front. Press “Shift+a” to move the cursor behind “/android-9.0-r1” then press space and add:
vga=834 nomodeset xforcevesa
at the end of the line.
Save your changes in vi by pressing the Escape key, the type the letters :wq
which should save your changes to the menu.lst file if all went well.
Reboot the system:
cd /
reboot -f
and the system should reboot into the graphical Android environment.

Android welcome
Android welcome screen

Success

That’s it.
From here it is a matter of following normal Android steps except for the network settings.
For networking select “Virtual WiFi” and it should work OK.

android 9
Android 9 in a VM

All the steps above have been reported to work equally well in Workstation Professional 15.5.1

The following links have helped a lot while I had the initial issues getting this to work:
https://www.itsmdaily.com/install-android-on-vmware-fusion-osx/
and this one (in particular the steps from stack exchange user ajira:
https://android.stackexchange.com/questions/144535/android-x86-marshmallow-not-booting-on-virtualbox-and-vmware-workstation#155950

Now that you are here. Please check out our product “Vimalin“. It has been designed for making your life easier to get good backups of your VMs. We support VM’s running in VMware Fusion, VMware Workstation and VMware Player.

More info at our main page

Leave a comment Inandroid blog
Wil van Antwerpen
January 18, 2020

Windows 7 to Windows 10 upgrade

Now might be the right time to update to Windows 10 if you have a virtual machine running Windows 7. You don’t really want to keep on running with a VM that is no longer receiving Windows Updates.

Upgrading from Windows 7 (or 8) is as simple as downloading and running the installer from https://www.microsoft.com/software-download/windows10 This is still free, even today in Januari 2020.

This week at the VMware Forums there was a few people who had problems upgrading to Windows 10. The error is as follows:

“This device isn’t compatible in Windows 10. Contact the manufacturer for more info.

LSI Adapter, Ultra320 SCSI 2000 series, w/1020/1030″

You would see a similar error if you happen to use a Buslogic scsi adapter. Neither of those adapters have drivers for Windows 10 and as such the update gets stuck in a continuous loop.

Luckily though we are running a VM and changing hardware is therefor relatively easy and comes at a minimum cost (it is free!) But, you can’t just change the adapter as then you will end up with problems booting. There is however an easy way around that issue.

So cancel the upgrade and follow these steps. The screenshots below are for Windows 8, but it will also work for Windows 7. This article is written for VMware Fusion, but the same trick also works for VMware Workstation Professional and VMware Workstation Player.

Prerequisites:

  • Make sure your Windows is activated,
  • that the virtual hardware is up-to-date and
  • that VMware Tools is installed and the most recent version.

Step 1: Shut down your VM and make a backup

You can make a backup by closing VMware Fusion (or VMware Workstation) and make a copy of the complete VM to an external disk.

Step 2: Add the LSI SCSI SAS controller to the VM.

With the VM shut down and the VM window closed, go to Virtual Machine Library in VMware Fusion. Then select the VM, use right click (Ctrl+click) and hold down the option key. In the context menu, the option “Show in Finder” will change into “Open Config File in Editor”

Edit Configuration vmx file in TextEdit
Hold down the option key to edit the config file

In TextEdit, make sure you do not have smart quotes enabled. (File menu -> Preferences, the checkbox should not be ticked)

Smart quotes disabled in TextEdit

With all that out of the way, now look for the following bit of text in your vmx file. Please be aware that the lines do not have to be in this order, they can be anywhere in the .vmx file.

If you have a buslogic scsi adapter you will have this snippet:

scsi0.present = "TRUE"

scsi0.virtualDev = "buslogic"

buslogic.noDriver = "FALSE"

If you have a parallel LSI scsi adapter, then you will have this snippet:

scsi0.present = "TRUE"

scsi0.virtualDev = "lsilogic"

We need to be able to use the LSI Logic SAS scsi driver. We cannot change that here now as Windows will not be able to boot. So instead we are going to let Windows load the new driver for us.

Add the following line to your .vmx file.

scsi1.present = "TRUE"

scsi1.virtualDev = "lsisas1068"

Note that instead of scsi0 it now says scsi1. This is important!

We are adding a new LSI SAS adapter in addition of the scsi adapter we already had.

Now save the file and exit TextEdit.

Step 3: Load the drivers for the new scsi controller.

Boot your VM. If you followed the directions carefully, then the VM should still boot without any issues. Log in and verify that we have indeed loaded a new SCSI adapter. (Start menu -> right click -> Device Manager)

Storage conttrollers now has an LSI SAS Adapter listed
LSI SAS Adapter

That was the tricky part.

Step 4: Remove the old scsi adapter and switch over to use the new one

Now shut down your VM again and go back to editing the .vmx file. (use our earlier steps).

Locate the lines for the old parallel LSI Logic or buslogic adapter and remove those lines. This will remove the adapter that is incompatible with Windows 10.

Then change the lines we added from scsi adapter 1 to scsi adapter 0.

Eg. change from:

scsi1.present = "TRUE"

scsi1.virtualDev = "lsisas1068"

into:

scsi0.present = "TRUE"

scsi0.virtualDev = "lsisas1068"

… and that’s it.

You should now be able to boot your VM with a new LSI SAS controller.

A scsi controller that is compatible with Windows 10.

Beware that changing the scsi controller might trigger the Windows Activation logic. Adding a controller and swapping them appears to be less of an issue. So if you trip up the activation Gods then that is my suggestion to try next.

Another problem you might bump into is:

“VMware SVGA 3D is not compatible with Windows 10.”

Normally that is just a warning with a button next to it that you can use to tell the installer to ignore this warning. After ignoring that you should be able to proceed. If there’s no “ignore this button” then have a look at the following KB article: https://kb.vmware.com/s/article/2126929

After you completed your upgrade to Windows 10 do not forget to change the guest OS type in VMware Fusion / Workstation from “Windows 7” to “Windows 10” and then re-install VMware Tools.

Now that you are here. Please check out our product “Vimalin“. It has been designed for making your life easier to get good backups of your VMs. We support VM’s running in VMware Fusion, VMware Workstation and VMware Player.

More info at our main page

1 Comment on Windows 7 to Windows 10 upgrade Inblog
Wil van Antwerpen
October 17, 2018

Backup your VMware Fusion VMs, even when they are still running

Making a backup can be problematic

Taking care of the data and time you invested in a virtual machine (VM) is one of the problems. In other words make sure to have good backups. For Time Machine, VMware recommends you to exclude virtual machines as you can’t make good backups with it (see [1] and [2]). The problem is similar with normal backup products on Windows.

You cannot normally make a backup of a machine that is still running. The reason is that the copy of the virtual disk would likely end up being corrupted. This is because there is a high chance that the disk is changed while you are copying the virtual disk file(s). File systems do not like that.

Some alternative solutions

A suggestion is to move your data out of the VM and save it at your host while accessing it via shared folders. This by itself breaks the encapsulation of a VM – have everything in one package. On top of that, shared folders aren’t very performant. Not an ideal solution either.

Of course you can make a manual copy of the VM when it has been shut down, but that means having to set aside time to do so. Now you also have to make sure to not forget doing so on a regular time.

Wouldn’t it be neat if you could make easy backups of your VMs in an automatic way and not having to worry if you left them running or not?

Enter Vimalin

The above got me thinking and work on a product called “Vimalin”.

With Vimalin you can schedule backups of your virtual machines. Vimalin uses VMware automation to detect if the virtual machine is running or not. If the VM is running at a time when the backup is scheduled then Vimalin knows about that. In that scenario it uses VMware snapshot technology to be able to make a consistent virtual disk copy. In that case it also copies the machine state and memory contents from your VM.

As a result when restoring the VM, you end up with a restored machine that looks exactly like it was suspended at the time of the backup. It does this all by using VMware automation and does not require you to install an agent in the VM. Both VMware Fusion as well as VMware Workstation Professional are supported.

You can read more about how to use Vimalin (including screen shots) in the online documentation

or you can download the latest version from our download page and test drive it for yourself.

There is a 60 day trial period. After 60 days it changes into the free version which still allows you to make backups or restore them, but it disables the scheduling and email notifications feature.

Leave a comment Inshow case
Wil van Antwerpen
October 4, 2018

Free Vimalin 2.6 license for vExperts

Congratulations with your 2021 VMware vExpert award!

We do appreciate your efforts and contributions to the VMware community and therefor like to give you a free NFR license to Vimalin 2.6.

Whether you use VMware Fusion, VMware Workstation or VMware Player. Vimalin can help you with automatic backups of your virtual machines.

With Vimalin you can run the backups of your VMs automatically without worrying that you forgot to make that manual copy. You don’t even have to stop your VM as it happily makes a backup while the VM is running.

More details can be found at the main site.

Please fill in your details below


    Please use the same email address as for your vExpert communications.

    This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

    and after verification of your details we will send a free license to your email ASAP.

    1 Comment on Free Vimalin 2.6 license for vExperts InNFR
    Wil van Antwerpen
    January 7, 2018

    Import backup targets

    One of the main new features of our latest release (version 1.0.298 see download page) is the ability to import backups.

    Normally Vimalin keeps track of all your backups in a database and based on the data in there it will show you an overview of all the backups you currently have. Those backups can be on different disks and/or network locations.

    That works great. But what now if you happen to do a fresh install of macOS and you don’t have that old database available? Then Vimalin would not be able to locate those previously made backups. Until now.

    Another scenario is if you have multiple machines that you backup via Vimalin. Normally you only see your own backups. Vimalin stores the backups per host, and the database is stored locally so normally you do not see backups from other hosts.

    If you want to put back a backup from another host then there was no easy way to do that. This new feature also makes this much easier.

    So how does it work?

    If you add a backup Disk Target then Vimalin will now verify if it has been used by Vimalin before and if it has it displays the following popup:

    If you select “Yes” then it will scan the contents of the Disk target and report back what if found.

    You can then verify what backup have been found in the backup archive screen:

    As you can see in our example it found 2 backups of 2 VMs. The first one is a backup that was made onDemand earlier today while the other one is a backup of Win98 made yesterday.

    Note that it will only add backups not already in your database and that it will verify if all the files that make up the database are available. You can even remove the target and add it back to sync with the disk target.

    Leave a comment Infeatures