Using ESXi 5.1 (build 1021289) in my lab(no vCenter server). Havdatastore is local. Have a VM Vyatta in root of datastore with 2 NICs - eth0 and eth1. When moving VM via datastore browser to the folder on the same datastore - VM network config is broken and Vyatta reporting NICs as eth2 and eth3. (respective router config is missing as NICs are different). When moving back to the root of datastore NICs re-appear as eth0 and eth1 and the config on Vyatta is restored. I'm hitting known issue due to my ignorence or this is something new?
Interesting! IMO this shouldn't happen, except you select "I copied it" when asked whether you moved or copied the VM.
Please provide (attach) the VM's vmware.log files, the one from the root folder and the one from the other - non-working - folder.
Thanks for the attention to my problem. I definitely select MOVED IT (it is already a reflex). Will be able to provide the logs next week only as will be out of city.
Have a nice weekend
Hi everyone here,
I feel like a total noob now. I posted this message as initially I met this issue when I added another local storage and was moving VMs there - both Vyatta VMs + 1 VM with Debian had broken NICs. So I've reinstalled them. Then last Thursday I was on webex showing my friend some config when I noticed that newly installed Vyatta is in root directory so decided to move it to a subfolder. After moving and starting it NICs were renamed in the fashion I've described earlier. I told him that had this issue before. Then just for fun I moved VM back to the root of datastore and the NICs re-appeared. We both agreed that this is a bug so I started a thread here knowing that I know how to replicate the issue. BUT I CANNOT NOW. Feel so lame. Still trying to replicate it. As soon as manage to do this - will post here. Sorry guys for bothering. Feel like my clients sometimes)))
Check that the Virtual MAC Id's remain the same regardless of move or copy - thats the crucial element that causes Debian (and hence vyatta) to decide that there are new NICS in the box and therefore create new device end points. In fact if you get your virtual nics the wrong way round (which I've done more that once) if you flip the MAC addresses at the hypervisor layer it all sorts its self out
Hope that helps