Hi all,
Had an incident yesterday with vMotion that I am less than impressed about.
Have two ESX4.1 boxes, managed by vCenter. The VM's are running off local datastores.
I migrated a Virtual Machine's local datastore (one of our Application Servers) to shared storage, so we could
transition it from there to the other ESX box.
During the transfer to shared storage, the 'Relocate virtual machine' job failed with 'A general system error
occurred: Source detected that destination failed to resume'.
This is fine, it is a very busy VM and I can accept that the copy 'clagged out' with all the disk changes that would
have been happening, especially while the VM's datastore is being replicated on a separate host.
However calls started pouring in, our printing solution stopped working. After troubleshooting we found that a small
database (2GB) had it's compression attribute modified (still on the source datastore), which caused the service to fail,
database refused to start and my stress levels to skyrocket.
Few questions:
a) Why would vMotion write to the Source VM? This is literally BEYOND me.
My basic understanding is that a 'snapshot' is taken of the disks, sent to the destination - then all changes that
have occurred in the meantime get applied to the destination disk. If it fails, destination disk gets wiped - everything
is fine, as vCenter has not instructed the VM to start using the destination disk.
Is it normal for vMotion to enable the compressed attribute on copy?
b) I ran a vMotion a few days beforehand (as a trial) on a less important VM, this worked fine - then I discover that RealVNC
didn't make it across - not a trace, no service, no program files folder entry, no event logs (even past entries).
It's almost as if the server has been reconstructed sysprep style, not a byte for byte copy.
Being an open environment (we have techs in another city with access to our servers), we cannot rule out that it was
uninstalled by them - but has this been reported by anyone else?
james