I got VMware fusion for my mac so that I could play a game on steam (civilization 6). When I try to start it nothing happens, no error messages or anything. It just tries to start the game for half a second, but nothing happens. While I was downloading the game my windows 7 was not recognized as a valid copy, but I have fixed that now. What could be the problem?

> Regarding your statement - "It does not matter if the path used for parenFileNameHint is a relative one or an absolut one"
You missunderstood - for the WS-application it makes no difference wether the path is absolute or relative as long as it is valid.
During troubleshooting it is best to expect both variants and understand the consequences of each option.
While using linked clones it of course makes a big difference.
For the question did you copy or move - check the vmx-parameters uuid.bios and uuid.location
http://sanbarrow.com/vmx/vmx-advanced.html#uuid

ESXi 5.5

The end goal is to have a successful upgrade with no snapshots remaining.

Initially there is a Windows VM with no snapshots.

Scenario 1:

I’ll take a snapshot and perform the upgrade on that snapshot.  The upgrade fails.

I’ll simply delete the snapshot and be back at the original VM with no changes.  Correct?

Scenario 2:

I’ll take a snapshot and perform the upgrade on that snapshot.  The upgrade succeeds.

Do I delete the snapshot and perform the upgrade again on the original VM or is there some way to move the changes from the upgrade back to the original VM?

Thanks for any guidance.

Excellent - let us know what the outcome is

Oh, but as I described, for the WS application it CAN make a huge difference.  True, as long as the path is valid, the machine WILL boot.  But if you study my scenario carefully you'll see that when I booted the COPY, it was using the virtual disks from the original location since the path in the .vmx was absolute and somehow didn't get updated when I booted the COPIED VM.

I updated about 8 machines, most I'm sure I said "copied", I might have said "moved" on a couple by mistake.  Copied updates the bios and maybe the location whereas move only updates the location.  Not sure why that location change was not sufficient for WS to update the .vmx and strip the absolute path.  Unless, my theory of the VM having been on the exact same physical media before, only in a different folder, had something to do with it.  Though you'd think moving to a different folder would qualify as a "move".  Speaking of that, I did have one machine with an absolute path which refuse to boot if I moved it to another folder on the same disk.  So I copied it to another disk, booted it, copied it back to the folder on the other disk I wanted it in, booted, all OK.  Just needed VM to do it's magic by updating the location CID and strip the path then I can put it anywhere.  My stripping the path alone was not sufficient.

In my case, no linked clones.

Would like to send out a report on a weekly basis showing all new VM creations/deletions over the course of that week.

Possible?

Hello,

I'm new and have similar questions; I have been reading a bunch today, and it is my understanding that a "snapshot" isn't intended to be a full backup.  It is more so for restoring software corruption.  IE, you take a snapshot, then go and install an exchange service pack, or windows updates; if things go wrong, then you can revert to the snapshot.
By default the snap shot is automatically stored on the same Data Store as the Virtual Machine. (this is usually preferred, because it is the quickest)  The most common complaint is if the data store is low on space.   If that is the scenario, then the snapshot location needs to be moved to other local or network based storage: Creating snapshots in a different location than default virtual machine directory for VMware ESXi and VMware ESX (100292…

In regards to a full backup, copying the entire VM's folder contents to another Data Store located on another drive / disk set, should do the trick. The VM has to be powered off and not suspended:  Best practices when backing up a VMware Workstation virtual machine (2006202) | VMware KB

I have a Raid5 set with hot spare as my main storage Data store;  In the event of 2 disks failing at the same time, it's my understanding that I can replace the disks, rebuild the Raid5 set and re-create the "main_Storage"  data store;   after that it's copying the folder / contents of the VM back to the main data store;   *NOTE*  this is also assuming that you do NOT have ESXI / host installed on the raid 5 set.   I install Esxi to a 4GB USB memory stick;  after all VM's are created; I make at least 2 clones of the USB stick.  (one get's taped to the case in the server room and the other goes offsite;  anytime that changes to a VM are made (both spare USB sticks need to be re-cloned) .

http://prntscr.com/cxa7up

In this screen shot I have a 2012 server with 1 TB of allocated space,  The backup drive is only 3.6, which means I can only have 3 backups of this VM off of the Main_Storage at any given time. 

Hi,

None of workarounds worked for me to save settings of bridged VMnets. After 4 hours finally I found this way that seems do the trick:

Add below lines to registry for every VMnet that you want to stay in bridge mode and restart the host: (sample is for VMnet0 and VMnet1)

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Part 1

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VMware, Inc.\VMnetLib]

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VMware, Inc.\VMnetLib\VMnetBridge]

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VMware, Inc.\VMnetLib\VMnetBridge\Adapters]

"Test"=dword:00000000

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VMware, Inc.\VMnetLib\VMnetConfig]

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VMware, Inc.\VMnetLib\VMnetConfig\vmnet0]

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VMware, Inc.\VMnetLib\VMnetConfig\vmnet1]

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Part 2

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VMware, Inc.\VMnetLibSaved]

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VMware, Inc.\VMnetLibSaved\VMnetBridge]

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VMware, Inc.\VMnetLibSaved\VMnetBridge\Adapters]

"Test"=dword:00000000

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VMware, Inc.\VMnetLibSaved\VMnetConfig]

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VMware, Inc.\VMnetLibSaved\VMnetConfig\vmnet0]

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VMware, Inc.\VMnetLibSaved\VMnetConfig\vmnet1]

G!v3M35

Hi,

None of workarounds worked for me to save settings of bridged VMnets. After 4 hours finally I found this way that seems do the trick:

Add below lines to registry for every VMnet that you want to stay in bridge mode and restart the host: (sample is for VMnet0 and VMnet1)

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Part 1

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VMware, Inc.\VMnetLib]

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VMware, Inc.\VMnetLib\VMnetBridge]

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VMware, Inc.\VMnetLib\VMnetBridge\Adapters]

"Test"=dword:00000000

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VMware, Inc.\VMnetLib\VMnetConfig]

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VMware, Inc.\VMnetLib\VMnetConfig\vmnet0]

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VMware, Inc.\VMnetLib\VMnetConfig\vmnet1]

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Part 2

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VMware, Inc.\VMnetLibSaved]

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VMware, Inc.\VMnetLibSaved\VMnetBridge]

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VMware, Inc.\VMnetLibSaved\VMnetBridge\Adapters]

"Test"=dword:00000000

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VMware, Inc.\VMnetLibSaved\VMnetConfig]

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VMware, Inc.\VMnetLibSaved\VMnetConfig\vmnet0]

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VMware, Inc.\VMnetLibSaved\VMnetConfig\vmnet1]

G!v3M35

Hi,

None of workarounds worked for me to save settings of bridged VMnets. After 4 hours finally I found this way that seems do the trick:

Add below lines to registry for every VMnet that you want to stay in bridge mode and restart the host: (sample is for VMnet0 and VMnet1)

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Part 1

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VMware, Inc.\VMnetLib]

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VMware, Inc.\VMnetLib\VMnetBridge]

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VMware, Inc.\VMnetLib\VMnetBridge\Adapters]

"Test"=dword:00000000

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VMware, Inc.\VMnetLib\VMnetConfig]

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VMware, Inc.\VMnetLib\VMnetConfig\vmnet0]

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VMware, Inc.\VMnetLib\VMnetConfig\vmnet1]

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Part 2

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VMware, Inc.\VMnetLibSaved]

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VMware, Inc.\VMnetLibSaved\VMnetBridge]

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VMware, Inc.\VMnetLibSaved\VMnetBridge\Adapters]

"Test"=dword:00000000

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VMware, Inc.\VMnetLibSaved\VMnetConfig]

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VMware, Inc.\VMnetLibSaved\VMnetConfig\vmnet0]

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VMware, Inc.\VMnetLibSaved\VMnetConfig\vmnet1]

G!v3M35

Hi,

None of workarounds worked for me to save settings of bridged VMnets. After 4 hours finally I found this way that seems do the trick:

Add below lines to registry for every VMnet that you want to stay in bridge mode and restart the host: (sample is for VMnet0 and VMnet1)

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Part 1

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VMware, Inc.\VMnetLib]

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VMware, Inc.\VMnetLib\VMnetBridge]

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VMware, Inc.\VMnetLib\VMnetBridge\Adapters]

"Test"=dword:00000000

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VMware, Inc.\VMnetLib\VMnetConfig]

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VMware, Inc.\VMnetLib\VMnetConfig\vmnet0]

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VMware, Inc.\VMnetLib\VMnetConfig\vmnet1]

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Part 2

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VMware, Inc.\VMnetLibSaved]

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VMware, Inc.\VMnetLibSaved\VMnetBridge]

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VMware, Inc.\VMnetLibSaved\VMnetBridge\Adapters]

"Test"=dword:00000000

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VMware, Inc.\VMnetLibSaved\VMnetConfig]

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VMware, Inc.\VMnetLibSaved\VMnetConfig\vmnet0]

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VMware, Inc.\VMnetLibSaved\VMnetConfig\vmnet1]

G!v3M35

Hi,

None of workarounds worked for me to save settings of bridged VMnets. After 4 hours finally I found this way that seems do the trick:

Add below lines to registry for every VMnet that you want to stay in bridge mode and restart the host: (sample is for VMnet0 and VMnet1)

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Part 1

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VMware, Inc.\VMnetLib]

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VMware, Inc.\VMnetLib\VMnetBridge]

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VMware, Inc.\VMnetLib\VMnetBridge\Adapters]

"Test"=dword:00000000

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VMware, Inc.\VMnetLib\VMnetConfig]

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VMware, Inc.\VMnetLib\VMnetConfig\vmnet0]

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VMware, Inc.\VMnetLib\VMnetConfig\vmnet1]

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Part 2

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VMware, Inc.\VMnetLibSaved]

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VMware, Inc.\VMnetLibSaved\VMnetBridge]

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VMware, Inc.\VMnetLibSaved\VMnetBridge\Adapters]

"Test"=dword:00000000

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VMware, Inc.\VMnetLibSaved\VMnetConfig]

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VMware, Inc.\VMnetLibSaved\VMnetConfig\vmnet0]

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VMware, Inc.\VMnetLibSaved\VMnetConfig\vmnet1]

G!v3M35

Hi,

These type of issues are almost always due to a broken VMware Tools install.

Do not try a repair install from within the Guest OS as it likely will not fix this, unfortunately the "Reinstall VMware Tools" from the drop down menu also falls in that same category.

You really need the guest OS to reboot inbetween uninstall and install to make sure that all the files from VMware Tools are in the correct locations and of the correct version.

In short follow these steps:

• Uninstall VMware Tools
• Reboot guest OS
• Install VMware Tools
• Reboot guest OS.

A bit of a longer description is: 

• In the guest Windows operating system, go to Control Panel -> Programs & Features -> Select VMware Tools -> Uninstall

Follow the steps from the installer to completely uninstall VMware Tools

• Reboot the guest OS.
• Then from the Virtual Machine menu select "Install VMware Tools"

If no installer appears, go to the DVD-rom within windows and click "setup" (for 32 bits windows) or "setup64" (for 64 bits windows)

Once you see an installer, click "Next" until Finish, keep the defaults.

• Reboot the guest when done installing (it will ask by itself to reboot)

--

Wil

Having some issues with the Location dropdown on IaaS blueprints in vRA7.

Setup: I have several Compute Resources defined, each with an different associated Location.  Additionally, I have IaaS reservations, associated with each of these Compute Resources, defined under a Reservation Policy.  That Reservation Policy is associated with an IaaS blueprint.  Pretty standard setup, however, at this time, I am only enabling a reservation on one of my Compute Resources.  The rest of the reservations associated with other Compute Resources are disabled.

Issue:  When I request an IaaS Item from the Catalog, the Location dropdown shows all of the Compute Resources as options.  Naturally, if somebody submits the request against a location with no enabled reservation, the build fails.

The behavior in vRA6 automatically presented valid locations in the Location dropdown.  Valid meaning, only those locations that have enabled reservations.  Seems this behavior has changed in vRA7 which now shows all locations defined whether the reservations are enabled or not.  Is anyone else seeing this issue?  Is there some additional configuration to make vRA7 behave more like vRA6?

Thanks for help.

Hi Du,

Can you give more background on the Toolkit for activating office 2010? I'm aware of the KMS or MAK or retail licenses but have no idea about this toolkit for activation.

When a snapshot is taken the VM's original base disk files are frozen and a set of new snapshot delta files are created. All changes that occur on the VM are written to these delta files, leaving the base disks consistent with the point in time the snapshot was created. The same process occurs if multiple snapshots are taken; the files the VM is running on are frozen and a new set is created to contain new changes.

If you want to move the machine back to the point in time the snapshot was taken you would open Snapshot Manager, select the relevant snapshot and select "Revert To". The VM will now begin running from the original disk files (previously frozen) and you will be back at the point in time when the snapshot was capture.

Deleting a snapshot causes VMware to consolidate, or merge, the changed data in the delta files with the source disks, leaving you with only the original set of files for the VM.

So:

For Scenario1 you would not want to delete the snapshot, you would want to use the steps I described above to revert to the snapshot you took before installing the upgrade. This takes your VM back to a point in time before the upgrade so you can try it again or leave the VM running in its previous functional (but not upgraded) state. If you just deleted the snapshot you would be left with your broken VM/application with no snapshot to roll back to.

In Scenario2 yes, you would simply delete the snapshot. This would merge the changed blocks in the delta files with the original disks and you are left with a clean, successfully upgraded VM with no snaps.

If you right click on the Controller, you will see the option "Force Remove". Did you try that?

I need some assistance with gathering VM locations and Migrations on a certain date for all VM's in the Datacenter for a customer. I've attempted to get the following scripts by LucD to work but no luck. I have also tried the following but that is not a valid command for PowerCLI 6.3 unfortunately.

Get-MotionHistory-Entity (Get-VMVM*) -Days1|Export-CsvF:\motion-report1.csv-NoTypeINformation-UseCulture

LucD notesEvents - Part 8 - vMotion history - LucD notes

LucD notesGet the vMotion/svMotion history - LucD notes

Is all the relevant hardware officially supported?

I tried updating my bios but the system wont boot properly into vmware now

I got no sound from my CentOS 6 guest with a Windows 10 host running VMware Workstation Pro 12.

I'd appreciate any help.