vCSA Network Error After Copy

I had been running my home lab's vCSA under Workstation while I played around with vShield 5 on my small, two server, ESXi cluster.  Mainly because I needed the resources free for all the vShield appliances and also because I didn't want to take the chance of isolating my vCenter while I was testing vShield out.

Anyway, when I got done with vShield and cleaned up the environment I decided to go ahead and move the vCSA back to the vSphere cluster.  I did this using a capability of Workstation 8 that allows you to upload a copy of a Workstation VM to a remote ESXi host.  All fun and games until I powered on my vCSA. 

Ruh-Roh Raggy! NO NETWORKING DETECTED!?  IP address is 0.0.0.0?!

What I didn't realize is that the MAC address would change as a result of the copy.  I should have known - you know that little message that pops up when you manually copy or move VM files around and then power on said guests?

Well, what's happening is vSphere trying to prevent you from shooting yourself in the foot by having duplicate MAC addresses on your network.

In the case of my uploaded vCSA, I got no such message.  The MAC address of the vNIC was changed.  As a result, the vCSA registered the new MAC address as a new ethernet interface - eth1.  The problem is, vCSA expects to use eth0.

To fix this, I had two choices - I'll explain both, but start with the one I did first which is much easier but less "clean" and I'll tell you why I think so in my summary.

Fix "A" involves recording the MAC address associated with eth0 and then selecting manual addressing that to the vNIC of your vCSA.  Note the VM has to be powered off to make this change (the image below shows a powered on VM, thus the selection is unavailable but you get the point).

The VM will now boot up and the OS of the vCSA will be happy to see eth0 again and you're in business.  Oh, by the way I knew what MAC address I needed by looking at the properties of the vNIC on the source VM.

For fix "B" you'll need to login to the vCSA OS (which is SLES 11 for those interested) from the VM console and delete the /etc/udev/rules.d/70-persistent-net.rules file.

Now, this sounds pretty drastic but the file is actually auto generated by the Linux kernel device manager (udev).  What's happened to my vCSA upon changing vNIC MAC addresses is that the udev added another entry to the rules file as eth1.  As you can see from the output of the rules file below, eth0 is still there with the old MAC address.

So, I'll make a copy of the rules file (because I'm anal that way) and then delete it...

cp /etc/udev/rules.d/70-persistent-net.rules /etc/udev/rules.d/70-persistent-net.rule.backup
 
rm /etc/udev/rules.d/70-persistent-net.rules

Restart the guest OS and I'm back in business.

As I mentioned, fix "B" is the better way to go in my opinion.  Simply because you don't want to run the risk of having two nodes on your network with the same layer 2 address.  Plus, I just don't like manually setting things like MAC addresses unless there's a really good reason.

This fix would actually apply to any SLES virtual appliance that you may happen to copy.  Frankly, this is probably a rare problem but you never know - if it happened to me, it could happen to someone else!