2

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?

user9517
  • 114,104
  • 20
  • 206
  • 289
Alex Berry
  • 2,307
  • 13
  • 23
  • a longshot, but what if you try setting ethernetX.checkMACAddress = “false” ? did vmware ask you when you've started the vm if you've copied it or moved? – Jure1873 Jun 23 '11 at 17:14
  • Thanks Jure, I'll be sure to check this when I get a chance for downtime, please set this as an answer and if it works I'll award you the bounty! – Alex Berry Jun 24 '11 at 09:55
  • According to my colleague we've already tried this and it hasn't worked. The manin issue is this is an oracle box and so the licencing is a nightmare, which is why we need to keep the MAC address. – Alex Berry Jun 24 '11 at 10:09

2 Answers2

1

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:

ifconfig eth0 hw ether c0:ff:ee:fa:ca:de

This is obviously not The Right Way to solve this, but it may provide enough of a workaround to get you moving forward.

larsks
  • 41,276
  • 13
  • 117
  • 170
  • I think we have tried this and still no joy. I'm going to check with my colleague and provide more detail in the question on Monday. – Alex Berry Jun 25 '11 at 01:02
1

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):

  1. Stop (not pause) the new VM
  2. Unregister the new VM
  3. Set the following (in .vmx file):

    ethernet0.addressType="static"

    ethernet0.address = YO:UR:MA:CA:DD:RS

  4. Re-register the VM and boot it.
Charles Hooper
  • 1,500
  • 9
  • 8