vMotion requires that you have shared storage between the ESX servers (a SAN, in other words), and that you have a fast network set up for vMotion. It also requires that the ESX hosts have the same CPUs (or that you've done some CPU feature masking so that the CPUs appear the same to the VMs).
Essentially it pre-copies the entire contents of memory to the destination ESX host, then starts intercepting all of the CPU activity, eventually pausing the VM on the origin ESX host, copying the last bits of memory and CPU state over to the destination ESX host and starting it back up. I think it also forces some arp announcements so that your switching infrastructure picks up the move.
The end result is that the migration can take a minute or two, but the VM itself only pauses for a fraction of a second and never knows that it was moved from one physical host to another. The OS never sees anything.
We use it on our ESX cluster all the time. We've even turned on the features that automatically VMotion VMs in order to balance load between ESX hosts.