For the last week we have been troubleshooting a customer's Red Hat Virtual Machine running on ESXi. We've been using Veeam to try to create a replica off-site and have been having getting it to work on a decent schedule and recently we noticed that there were issues with orphaned snapshots while looking at the datastore. You can see several snapshots in the same folder and it's causing issues with replication and backup, so we decided the cleanest way was to v2v the machine to another datastore so that we had a clean single-vmdk setup to work with, this is where our trouble started.
We first started off with a v2v using vmware converter and connecting to the powered on machine as we were having issues doing an offline v2v. This copied fine but when I tried to set a static MAC using this article http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=507 the new VM wouldn't take the address, it simply obtained a new MAC, received a dhcp lease and then would only boot up to a blank red screen, never the login screen.
So the next step was to do an offline v2v, once we finally got it working. Same thing, followed the kb to the letter and still it wouldn't take the MAC. I then tried it again and upon completion I compared both old and new VMX file, copying every identifier and variable possible, then unregistered both VMs, uploaded the new VMX file and booted, only to see the same results.
Finally I did the same as above but I copied the disk using DD to a second attached vmdk and then attached this to the new VM, and still no luck.
After downloading the modified VMX file after the first boot and comparing it to the original I created I found that the bios uuid had changed from the one I typed in manually, so I'm assuming this may be the snagging point, but I have no idea.
I've never had this issue before on a P2V and I'm just wondering if someone could shed some light on this, maybe it's to do with RHEL licencing?
This may or may not resolve your problem:
Most ethernet cards -- including the virtual ones provided by VMware -- have a software programmable MAC address. You can take advantage of this by inserting something into your startup sequence to set the MAC address of the card early in the boot process.
You would run a command like this:
This is obviously not The Right Way to solve this, but it may provide enough of a workaround to get you moving forward.
I used to have similar issues. I'd usually scratch my head wondering why settings didn't take and it was almost always because the VM had to be unregistered and not just started/stopped. I know you said you did that, but give the following a try (in order):