Some instances that trigger this behavior include snapshots, restarting vmtools and, in our case, vMotioning a VM. What you may not know is that, independently of the option being disabled, there are instances where a VM will still synchronize its clock to that on the ESXi host. You are probably familiar with the Synchronize guest time with host VMware Tools option. Not a good thing if you’re migrating something like an AD domain controller which acts a PDC for the whole domain. This means that if the time on ESXi is off, so will be that on your VM. When a VM is migrated to a host with an out-of-sync clock, the VM’s guest OS clock will adjust accordingly. Time drift per se does not influence vMotion, however, there’s a slight issue. The -I parameter is used to tell vmkping which VMkernel should be used to test network connectivity.Īdditionally, I’ve used the nc (netcat) command to ensure that the source host can connect to the vMotion network port (8000) on the destination host.įigure 8 – Confirming a user initiated media disconnectĮnsure that the clocks on your ESXi hosts are kept in sync by specifying a common NTP source. As per the next example, I am verifying that host 192.168.16.69 is reachable from all the VMkernels adapters on the ESXi host where I’m running the command from.
In my environment, I’ve set all my hosts to use vmk0 for vMotion. Vmkping uses a VMkernel’s TCP/IP stack to send ICMP traffic to a destination host as opposed to using the host’s physical interface TCP/IP stack which is something a normal ping utility would do. There are a couple of ESXi shell commands that help you do this. When testing network connectivity between hosts, you will want to test from a VMkernel perspective more so if your hosts are running multiple VMkernel adapters. VMkernel network connectivity can be another problem area resulting in timeouts or outright failed migrations. Figure 4 – Ensuring the migrate.enabled advanced setting is set to 1ģ – Run network diagnostics at the VMkernel level
0 kommentar(er)
