Sometime i saw due to vMotion only 1 ping packet is dropped and sometimes 5-6 and sometime no packet is dropped what is reason of packet dropping that quiesec the vm but why it is like this kind of different behavior. Is this depends on bandwidth available for vMotion?
When vmotion occurs there is a quiescing of the VM so the VM is not going to respond to a ping during this perios - so if there is added latency due to network bandwidth or the load being experienced by the ESXi host you will see some dropped packets - but the nature of IP traffic the packets will be requeued and resent -
Quiesec is happened always then why in some cases no packet is dropped
And please tell me the impact of these dropped ping packets on those applications for whom a slight latency can initiate the failover like Oracle RAC cluster what is the recommendation for those vm's?
The quiescing typically is very short and a packet will not get dropped but in the rare instances where there are network bandwidth issues (this is why best practice is to have vmotion on its own isolated network), excessive loads on the ESXi hosts or latensy issues with the pysical network -
Since an IP network is a contention based there network you will always have some dropped packets and the dropped packets that can occur during vmotion are going to be minimal and shoulr not affect those types of applications -
Don't ping and you won't see any packets dropped! 😉
Is there a lot of vMotion happening and causing problems?
Turn down the aggressiveness of the DRS rules.
Add more resources so there is less DRS-induced vMotion
Can you tune RAC to be not so sensitive?
When I watch (which is seldom, these days) I usually only see one missed ping, which is typically a moment before vCenter reports Complete.
Ranjna Aggarwal wrote:
Yeah i Know due to quiesec the ping is dropped but why sometime no ping drop even at the time of quiesec
There are many things that should happen during the last phase of vMotion:
The final changed pages in memory will be transferred with the VM "paused".
The new ESXi shall take over the VMDK file on the shared storage
The new ESXi host shall send a faked broadcast frame "from" the VM, to get the physical switches to learn the new location
All of this is typically very fast and under 0.5 seconds. Ping -t typically sends each second and depending on the exact timing you might not lose a single ping.
In addition to the quiescing, remember that the VM is connected to another physical switch port. This means that the VM's MAC address has to be unregistered from the source switch port and registered to the destination switch port. Depending on the switch and configuration (e.g. spanning-tree) this might also cause a short network "outage".
André Pett wrote:
Depending on the switch and configuration (e.g. spanning-tree) this might also cause a short network "outage".
Even with spanning-tree enabled on the ESXi switch ports a vMotion event should in my opinion not be able to cause spanning-tree to react. Spanning-tree works only with special frames ("BPDUs") and calculates the map of the switched network, but does not really care of ordinary MAC address changes.
Ranjna Aggarwal wrote:
but why sometime no packet is dropped?
It could be that with some luck the "time slot" (around 1 second) between the two pings makes it possible to complete the final steps within this "slot".
What is interesting is to have a RDP session into the VM and "ride along the vMotion" through the terminal session, while at the same time doing a ping going out from the VM. Typically you do not see a ping loss from inside the VM.