Summary: We get the question all the time if the K2 supports V-Motion. We know that any supported Guest OS supports V-motion, but how do the actual applications/services, like the K2, in the VM elegantly handle the timeout (from the KBE perspective) during that V-Motion?
Solution:
You might guess that a VK2000 (and any other Guest OS) is unaware and unconcerned if its ESX host changes. VM's IPs and ethernet MAC addresses do not change due to a V-Motion event, so the Layer 3 TCP connection between K2 and target machine(s) is unchanged. Because TCP is connection oriented, any quick changes on the network between the two will be handled via TCP connection logic— acknowledgments, windowing, etc.
What does change happens at Layer 2, on the virtual and physical switches. Each switch keeps track of all the ethernet MAC addresses of all devices passing traffic through it. When a VM changes hosts via V-Motion, the VM takes its ethernet adapter and MAC with it. The VM's ethernet interface now appears active on a different physical port than it was before the V-Motion occurred. Switches need to learn that a VM is now reachable via a different physical interface. Switches would eventually update their CAM tables after some timeouts, but VMware expedites this by sending a RARP out on the network the instant the VM is running on its new host. This forces switches to learn immediately how to find that ethernet MAC address. The TCP connection reestablishes almost immediately.
In our QA Lab, most of our K2s and target machines are virtual and in a vSphere cluster. V-Motion automatically moves these around regularly without any negative effects.
See this link and go to page 4.
Comments