Difference between revisions of "Troubleshooting (Virtual Machine)"

Jump to navigation Jump to search
Added "Can't Connect VM's NIC"
m (moved Virtual Machine Trubleshooting to Troubleshooting (Virtual Machine ): Name doesn't work well on Virtual Machine category page)
(Added "Can't Connect VM's NIC")
 
(5 intermediate revisions by the same user not shown)
Line 6: Line 6:
'''Error connecting: Cannot connect to host...''' or '''Can't connect to MKS...'''
'''Error connecting: Cannot connect to host...''' or '''Can't connect to MKS...'''
* This is caused by a TCP connection failure to the ESX server the VM is hosted on. Using telnet or a port test utility, confirm you can connect on both TCP 902 and 443 from your machine to the ESX server.
* This is caused by a TCP connection failure to the ESX server the VM is hosted on. Using telnet or a port test utility, confirm you can connect on both TCP 902 and 443 from your machine to the ESX server.
* If the problem is affecting a single ESX that previously worked, [[ESX#VMware_Management_Agent_Restart|restart the management services]] on that ESX
* If the problem is affecting a single ESX that previously worked, [[Procedures_(ESX)#VMware_Management_Agent_Restart|restart the management services]] on that ESX


== Can't Deploy VM ==
== Can't Deploy VM ==
Line 186: Line 186:
#* EG <code> scsi0:0.fileName = "MyVM-flat.vmdk" </code>  &larr;&larr;&larr;&larr;&larr;&larr; Base disk file ''(no snapshot running)''
#* EG <code> scsi0:0.fileName = "MyVM-flat.vmdk" </code>  &larr;&larr;&larr;&larr;&larr;&larr; Base disk file ''(no snapshot running)''
# If there's no snapshots running, but snapshot files exist then the files can be deleted (if you're sure!)
# If there's no snapshots running, but snapshot files exist then the files can be deleted (if you're sure!)
=== Revert to Snapshot Causes Trust Relationship Failure ===
When reverting a VM that is a member of a Windows domain to a snapshot you can get the following errors at boot up, or when trying to logon
* '''The trust relationship between this workstation and the primary domain failed'''
* '''Windows cannot connect to the domain, either because the domain controller is down or otherwise unavailable, or because your computer account was not found. Please try again later. If this message continues to appear, contact your system administrator for assistance.'''
The problem is caused by the VM's computer account, which is used by the domain client/snapshotted machine to access the domain controller, having an invalid password.  Domain member servers periodically change the password they use to connect to the domain with (by default every 30 days).  So if a VM is snapshotted, then following that updates its computer account password; on a revert to snapshot it will revert to the old invalid password and be unable to login to the domain.
* '''To resolve:'''
*# The machine needs to be taken off the domain, and put back on (you'll need a domain account with rights to do this)
*#* See [[Windows_2008#Re-Add_Server_to_Domain|Re-Add Server to Domain]] for further info
* '''To prevent:''' - see note below
** Disable machine account password changes
**# On the domain member machine update the registry
**# <code> HKLM\SYSTEM\CurrentControlSet\Services\NetLogon\Parameters\DisablePasswordChange </code> to <code>1</code>
** Reduce machine account password change frequency
**# On the domain member machine update the registry
**# <code> HKLM\SYSTEM\CurrentControlSet\Services\NetLogon\Parameters\MaximumPasswordAge </code> to a higher value (in days), eg <code>60</code>
{| class="vwiki-note"
|-
! The prevention options reduce domain security !
|-
| They should only be actioned if you understand the risks and are not breaching any security policies that may in force at your organisation.
If its not a regular occurrence, its probably best to just live the problem, and resolve when required.  Snapshots should not be allowed to run for many days in normal operation, which means that the problem should not occur frequently in a well run environment.
|}
Further reading...
* http://blogs.msdn.com/b/mikekol/archive/2009/03/18/does-restoring-a-snapshot-break-domain-connectivity-here-s-why.aspx
* http://www.petri.co.il/working-with-domain-member-virtual-machines-and-snapshots.htm


== Can't Customise ==
== Can't Customise ==
Line 193: Line 224:
** The virtual hardware has changed (especially disk type) since the original machine was created
** The virtual hardware has changed (especially disk type) since the original machine was created
** Sysprep can't customise the machine because it doesn't have administrator rights, this can occur where a DC's users have been offloaded to [[Acronyms#L|LDS]]
** Sysprep can't customise the machine because it doesn't have administrator rights, this can occur where a DC's users have been offloaded to [[Acronyms#L|LDS]]
== Can't Connect VM's NIC ==
When powering up a VM its network card becomes disconnected.  If you tick the ''Connected'' checkbox, the task completes without error, but the checkbox is unchecked again.
This can happen when exporting a VM from Lab Manager, or can be caused by config errors with vShield Zones (and there are probably triggers as well).  You may notice either of the following in the VM's <code>vmware.log</code> file
* <code>vcpu-0| [msg.ethernet.e1000.openFailed] Failed to connect ethernet0.</code>
* <code>vcpu-0| [msg.ethernet.openFailed] Failed to initialize ethernet0.</code>
Filter config has been left on the VM's NIC, which is causing problems when trying to connect the vNIC to its portgroup.
In order to resolve either...
* Replace the virtual NIC in the VM's config (remove the NIC, then readd it)
* Manually remove the offending config lines from the VMX file
*# Power off the VM, and identify where its VMX config file is, and what ESX its on
*# Remove the VM from the vCenter inventory
*# SSH to the ESX, and edit the VM's VMX config file
*# Remove any lines that reference a filter on the affected NIC, for example...
*#* <code>ethernet0.filter1.param0 = "0x2000029" </code>
*#* <code>ethernet0.filter1.param1 = "3" </code>
*#* <code>ethernet0.filter1.name = "vsla-fence" </code>
*# Register the VM
*# Verify the NIC's connected network, and reconnected the NIC
*# Power the VM back up
For more info see [http://kb.vmware.com/kb/1028151 VMware KB 1028151]


== VMTools Automatic Cursor Release Not Working ==
== VMTools Automatic Cursor Release Not Working ==
Line 229: Line 285:
[[Category:Virtual Machine]]
[[Category:Virtual Machine]]
[[Category:Troubleshooting]]
[[Category:Troubleshooting]]
[[Category:Troubleshooting VMware]]

Navigation menu