VMware Cloud Community
mrmmcglone
Contributor
Contributor
Jump to solution

Guest OS affected after vMotion

After successfully migrating a VM (Change Host) the Guest OS is slow to respond to the point where the VM has to be reset and services get stopped on the guest OS.  Restarting the Guest OS does not resolve the issue - only resetting the VM.  And it does not completely resolve the issue.  The application has performed poorly ever since the VM was migrated after the VMware Tools upgrade.  It was this Tools upgrade to VMware Tools for Windows Version 9.4.10, build-2092844 that started these performance issues.  Of course we uninstalled re-installed, removed the VM from Inventory from vCenter and added it back. vMotion'd the VM back to its original host after the host had been restarted (for memory purposes). 

This VM is running Windows Server 2008R2,  It has 32 GB of RAM and is in a "High" Resource Pool in vCenter. In Windows, virtual memory is configured to use 3 different virtual disks for totaling about 36 GB. NOTE: These are SAP database servers and I have 30 other VMs with the same/similar configuration that work without issue. 

In the cluster DRS settings I have set the VM to Manual so a vMotion does not inititate. But this does leave the VM and its host vulnerable. 

Any ideas?

Matt

0 Kudos
1 Solution

Accepted Solutions
mrmmcglone
Contributor
Contributor
Jump to solution

So when our vCenter environment was migrated from 4.1 to 5.5 a number of settings did not migrate. One that slipped past us for quite a long time was the VM memory resource allocation.  By default this is set too Unlimited.  But that check box was not checked - on all of our VMs. I don't understand how we did not notice this before now but after changing this to Unlimited we were able to migrate (vMotion) without issue.

View solution in original post

0 Kudos
3 Replies
jrmunday
Commander
Commander
Jump to solution

Hi Matt,

Does the issue go away if you roll back to the previous version of VM Tools, before the issue started? Are all the other systems that work Ok running the same version of VM tools as this problematic one?

This might be a long shot, but does the issue persist if you reserve all memory for this VM? Perhaps there is something relevant logged in the virtual machine log file (vmware.log)?

Perhaps you can try uninstall the vmware tools using the /c parameter (for example, setup64 /c) ... this will force a clean up, removing all registry entries etc ... (requires a reboot) then do a clean install of the current version.

Also, are you sure application owners / developers have not made any changes at the same time the issue started?

Cheers,

Jon

vExpert 2014 - 2022 | VCP6-DCV | http://www.jonmunday.net | @JonMunday77
0 Kudos
mrmmcglone
Contributor
Contributor
Jump to solution

I have not rolled back to the previous version of VMware Tools as I dont know which version it is. I have reinstalled it though.

All of the other VMs with the same version of Tools is working ok.

The VM is 32 GB in size so reserving memory was not something I could really do with an outage. But I can try that.  The vmware.log for the VM did show an error and lead me to this KB.  http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&externalId=2000026&sl...

I performed the Resolution on the host during a short maintenance window and it did not resolve the issue, 

I did not use the /C switch when I re-installed.  I could try that to during the next maintenance window. 

The application is SAP and the owner sits right across from me. I have reviewed the servers' logs and I did not see anything that alarmed. No changes were down but I cannot rule it out. But the fact this happened a day after VMware Tools was installed and it was the first time a vMotion was done is a bit of a coincidence.

Thanks

0 Kudos
mrmmcglone
Contributor
Contributor
Jump to solution

So when our vCenter environment was migrated from 4.1 to 5.5 a number of settings did not migrate. One that slipped past us for quite a long time was the VM memory resource allocation.  By default this is set too Unlimited.  But that check box was not checked - on all of our VMs. I don't understand how we did not notice this before now but after changing this to Unlimited we were able to migrate (vMotion) without issue.

0 Kudos