Is it correct that when a new version of Vmware Workstation arrives - the whole former installation must be removed and the new one installed after? I updated today to version 7.1.4, which seems like a very minor update, but I had to uninstall everything, reinstall the new package and doing two reboots (on Windows 7.)
Is this expected? Is it always like this?
> Is this expected? Is it always like this?
yes - WS installs several kernel drivers - most important one vmx86.sys - and so there is no way around it
> I never 'upgrade' instead I'll log into the vMWare site and download a new full install.
This is still the recommended way - not by VMware of course - but by everyone else who knows what an update may result in ...
In my view - yes!
I base that view on the way that a vm hypervisor works at a very low level. It isn't something just tacked onto your Windows install. In fact due to bitter experiences in the past I take it a few steps further. I never 'upgrade' instead I'll log into the vMWare site and download a new full install. Then while logged on as a sole Admin user, I'll fully remove VMWare (except any licenses), reboot, log back in as Admin and do a fresh install. Rebooting again into the Admin account.
Now I'll admit I don't know if this belt&braces approach is really required, but at least it always works.
> Is this expected? Is it always like this?
yes - WS installs several kernel drivers - most important one vmx86.sys - and so there is no way around it
> I never 'upgrade' instead I'll log into the vMWare site and download a new full install.
This is still the recommended way - not by VMware of course - but by everyone else who knows what an update may result in ...
Thanks a lot for both your answers. Then it is expected, but still a bit unfamiliar, but I guess the kernel level driver explains it.
As for the manual uninstall, there is no risk at loosing the license key when not doing the "vmware way" of updating?
it should ask if you want to keep the license
I always keep a backup of the registry key
HKEY_LOCAL_MACHINE\SOFTWARE\VMware, Inc.\VMware Workstation\License.ws.7.0.e1.200904
key is different for 64 bit hosts !
export with regedit and doubleclick after setup to re-import the license
That is good to know, and also to have the ability to get the license exported to somewhere else if something goes wrong.
And by the way, if doing manual un-install, don't you lose the folder structure and known VMs in the inventory?
that key has the serial-number in plain text - lookup the "Serial" in the key I mentioned
> And by the way, if doing manual un-install, don't you lose the folder structure and known VMs in the inventory?
folder structure ? - nope - VMware uninstall does not touch any directory where you stored your VMs
known VMs in the inventory ? - nope - those VMs are listed in a file named preferences.ini - look up the path to that file in any vmware.log
see the example ...
Oct 22 23:35:10.948: vmx| DICT --- USER PREFERENCES F:\Users\moon\AppData\Roaming\VMware\preferences.ini
the uninstall will not delete this file
this way of uninstall - new install will not keep your bridged network-assignments - but never mind - the normal way will mess that up as well
so however you do it - take notes like
vmnet0 is bridged to my Intel-nic
vmnet2 is bridged to the WLAN
vmnet3 is bridged to the broadcom
I always disable automatic bridging first thinmg after any version change
Ulli Hankeln wrote:
> And by the way, if doing manual un-install, don't you lose the folder structure and known VMs in the inventory?
folder structure ? - nope - VMware uninstall does not touch any directory where you stored your VMs
With folder structure I mean this: (not the host file system folders)
Are these folder preserved between uninstall and new installs?
ah ok - see screenshot
the directory is listed like this
vmlist12.config = "folder12"
vmlist12.Type = "2"
vmlist12.DisplayName = "aunt-dorothies-favorite-sausage"
vmlist12.ParentID = "0"
vmlist12.ItemID = "12"
vmlist12.SeqID = "-1"
vmlist12.Expanded = "false"
in favorites.vmls.
Favorites.vmls is stored next to the preferences.ini
vmlist12.config = "folder12"
vmlist12.Type = "2"
vmlist12.DisplayName = "aunt-dorothies-favorite-sausage"
vmlist12.ParentID = "0"
vmlist12.ItemID = "12"
vmlist12.SeqID = "-1"
vmlist12.Expanded = "false"in favorites.vmls.
Favorites.vmls is stored next to the preferences.ini
Thanks, I found my version of this file. I wonder if the vmlist.X is the reason for the somewhat strange sorting order (just in order of creation, not names or something.)