VMotion downtime question

[cmsJustin]

We currently have one ESX server with a VirtualCenter VM and 2 other VMs running. When I take a snapshot of a machine (not the VirtualCenter VM), the machine is unavailable from a ping. Services also lose connectivity. If I snapshot the SQL server, the VirtualCenter service stops and then eventually restarts when the DB comes back up. If I snapshot the VirtualCenter server, the VirtualCenter client loses its connection. Same thing if I snapshot our SCE (kinda like SMS) server, the SCE client loses it's connection.

This is not a problem, but from my understanding a VMotion takes a snapshot of the VMs memory and then restores it on a second ESX server. We are getting a second ESX server and an iSCSI SAN very soon, and I wanted to know from people's experience if a VMotion has the same service disruption. I know that a snapshot is doing a little more than a VMotion, such as snapshotting the disk, so maybe it should be more unresponsive during a snapshot then a VMotion.

Also we are planning to have a 1 gigabit non-blocking VLAN for VMotion alone with a redundant path. Is this enough? Or will 2 gigabit reduce downtime? Any info is appreciated while I suggest to management to spend hundred's of thousands of dollars on our new infrastructure

[stvkpln · Accepted solution]

Nope, vmotions are not the same as a snapshot! What a vmotion essentially does is utilizes the shared storage, and only transfers the contents of memory over to the new host, seamlessly starting the VM on the new host while stopping it on the old host.. A snapshot is basically a clean method to add a redo log to the VM so that you can revert to a point in time..

What you can expect to see with a vmotion is approximately 1ms of ping loss while the transition occurs. We utilize it on a daily basis. In fact, my original demo of vmotion involved initiating a remote desktop session to a VM and browsing the web while I vmotioned it... There was no less of connectivity to the RDP session and the big wigs nodded approvingly

[psharpley]

1 Gb is 'required' but it's the latency that is important. Your usual dedicated gig connection is fine. As just stated, there is no downtime to improve with 2 x Gb connections but resilience is a good thing to design for.

[Jae_Ellers]

Good description. There are a couple of memory synchronization cycles. The memory is locked for the final scan and sync for obvious reasons. Once the sync is complete the control is handed to the target machine.

As distorted said, ping losses are usually very small, but I've seen more than 1 ms. Most applications may experience a slight pause.

My favorite demo is to remotely connect to our admin Citrix server and run the VI client from there. I start a ping -t to the server, another from the local workstation to the server, and start the vmotion while browsing the web. This way I'm controlling the vmotion from inside the machine that gets vmotioned. This is usually impressive, especially since there are 10-15 admins using this server for various tasks at any given time.

Most of the time we have to check the ping output to see when the cutover happened as it's usually imperceptible.

Also VMotion and it's allied features (DRS) are VMware's enterprise critical feature set. Without VMotion working flawlessly for thousands of customers VMware would be out of work instead of the lastest Wall St. sweetheart. VMware has been doing hot migration for years now. I know M$ hasn't been able to keep it on their feature list. I don't know who else has it running now, but VMware has the history and proven record.

[cmsJustin]

Thanks for all your comments, I really do appreciate your time.