Does any of the virtual machines that you try to demotion contain a raw device mapping. If yes, the dmotion will not work. In that case you need to decouple the raw device mapping then dmotion your virtual machine and recouple your raw device mapping.
Hi Bart, no RDM's in use. This is a single 8GB vmdk file.
Do you not get a clue as to why the migration timed out in the events for the server? I guess it might be DNS related rather than connectivity. Can you resolve long and short names on both servers?
Presume VMotion is OK? and it's probs the vmdk relocate that's the issue?
Does your old ESX 2.5.4 box have access to the NEW VMFS3 volume?
wonkert, I do have successful name resolution with both long and short names. I only have two servers right now in this farm. One at 2.5.4 and the other at 3.0.1. so I havent been able to try vmotion from one server at 2.5.4 and the other at 2.5.4. DMotion will not work, however an offline migration will work (VM turned off from one datastore to the 3.0.1 datstore on the other server. So right now the issue is with live dmotion, not an offline migration from the 2.5x to 3.x server.
Hope this helps. And yes, both servers see each other's datastore volume...the 3.0.1 server sees the 2.5.4 volume as read only.
to be honest, whenever I've tried it it worked fine so hard to debug
I'm assuming the VM meets the criteria in terms of persistent disks, etc.?
Im also assuming whne you say long and short name resolution is OK, that this is for the console connections. For the VMotion IP addresses on each ESX host, are they in the same subnet with a network path between them? I believe the VMotion network isn't checked for connectivity before attempting a migration - so this would maybe timeout.
I guess another difference between a hot and cold migration is the guest needs to have a redo added and then the VMDK copied to the new VMFS3. Are there no messages on either ESX host in /var/log (or VC) that might help?
I fall else fails, use VMware Converter 3.
I am on a project at the moment and it was harder to get approval to change the source environment than it was to get approval to power them down and cold migrate with Convertor.
it works a treat and takes care of the virtual hardware upgrade and vmtools upgrade.
Do you have find a solution yet dougjef ?
I got the same message when trying to transfer a VM from a 2.5.4 machine to a 3.0.1, both hosts can see the VMFS LUNs.
It turns out one of the servers VMotion NICS were not pingable. Ooops! Replaced a cable and its working fine now! Apparently cold migrations use the console NIC and dmotion migrations use the vmotion NIC. In any case issue is solved!
Thanks for the tips.
How did you check if the VMotion NICs where pingable, those are placed in a separated VLan, which isn't available from the outside.
I guess it depends on how you setup vmotion on your network. Our vmotion nics on all servers are pingable (via a different vlan).