Have you ever stumbled upon a cloned Linux system, in my case CentOS 6.5, where eth0 does not exist and eth1 isn’t started automatically?
When VMware clones a VM it gives its network card a new MAC address, ensuring that you don’t end up with several VMs with the same MAC. If your distro uses udev and it discoveres the new NIC, it gives it a different UUID, thus creating eth1 in the process, since it can’t match the MAC addresses and UUIDs of the NICs. This might break all sorts of scripts or configs.
Here is how to fix it:
First we need to remove the discovered and assigned UUIDs from udev:
rm -f /etc/udev/rules.d/70-persistent-net.rules
Secondly we need to edit the networking script for eth0:
Here you should change the old MAC address to the new one the VM got after cloning.
Thats it. eth0 should work as it used to on the parent VM.
today I am not writing because of a certain problem or thing I stumbled upon. The “news” I want to share is somewhat “old” (26 August 2013), too: VMware announced vSphere 5.5 and ESXi 5.5!
Why am I posting this? Besides some cool new features in Hardware Version 10 or on the VDP side and Hypervisor side, a mayor change that will affect how we use vCenter in our Company is: Full Mac OS X Client integration (including the plugin for vCenter WebClient).
So, we’ve all been there: A user is using his Mac with a local account. At some point IT needs to manage all Computers and Passwords, and thus this Mac together with it’s user needs to be ActiveDirectory managed. But of course: No setting, no file, nothing should change, because the user is king (and maybe the company’s boss that hates being upset, and even a changed background or shortcut-location upsets him….). Here’s how to do it:
Create a new local user with admin rights.
Logout of existing User and into the new admin user.
Delete the user you want to migrate. When the system asks, don’t delete or archive the user folder, just leave it where it is.
In a terminal issue the following command “sudo mv /Users/oldusername /Users/newusername” where newusername is the shortname of the AD User. This is critical!
If not already happened bind the Mac to the AD.
Use “chown” in terminal to change the owner of the users directory to the new domain user. Use the shortname, no need to write the FQDN of the AD.
Use “directory utility” to change the settings and check the box to create a “mobile account at login”, and check the second box, too.
Now logout, maybe reboot. (Sometimes it is needed, sometimes not, depending on how quickly the Mac gets the new AD binding.
Login using the new users shortname. It should ask for a mobile profile, create one!
You might need to update the keychain password.
Thats it: Enjoy your migrated user folder and settings. You shouldn’t notice any difference besides a new password ;-)
One note: The new user is a standard user without administrative rights. If you need to give him/her or the Administrator-Group admin rights, you can to this in the “Directory Utility” as well. Single users won’t work, use groups like this: DOMAINNAME\groupname .
After a while of backing up VMs via vSphere Data Protection (VDP) the backup jobs for four VMs failed. The message said they needed consolidation.
After the consolidation everything started to work for 3 VMs, but not for the fourth. Now I was getting the following error:
Execution error: E10056: Restore failed due to existing snapshot. Job Id: <job-id> (Full Client Path:)
The GUI said nothing about needed consolidation, no snapshots where created, either, and if you look into the VMs config you see that the hdd points to a vmdk, not to a 00001.vmdk snapshot file. So, everything seemed to be in order, right?
The solution therein: Old 000001.vmdk-files lying around unused, nowhere referenced or anything. Simply deleting them will help (but an additional move to another location is recommended just to be on the save side).
So with this everything is up and running again! Thanks vmware!
So it seems that when you install vSphere Data Protection and want to use a distinct user that is not Administrator or root, you need to give that user (in this installation it was called datarecovery from the old version) rights on vCenter Level on its own. Just putting that user into a Active Directory Group will not suffice, as registration to vCenter will then give an error as result.