If you enter a room and want to get someone’s attention, you might call out their name so they know you want to talk to them (and not, say, the person standing next to them). Computers have various unique identifiers that serve a similar purpose, and if these identifiers conflict, they might not be able to communicate with each other. A common identifier is the MAC (short for Media Access Control) address. Every network adapter has one of these. VMware virtual machines have another identifier called the UUID – this isn’t important to the guest, but is how Fusion (or other VMware products) keeps track of virtual machines.
Whenever you move or copy a virtual machine, Fusion needs to know which happened — if you’ve moved the virtual machine, the UUID and MAC address(es) remain the same. In the people-in-a-room analogy, you just walked over to a different spot. If you’ve copied the virtual machine, Fusion assigns a new UUID and MAC address(es) — in the people-in-a-room analogy, your twin sibling just walked in and needs a different name so people don’t confuse the two of you. Maintaining the same unique identifier is less disruptive for the virtual machine, while creating a new identifier is required if you’re going to use an original and a copy at the same time.
So far so good, but to make things more complicated, there are potentially other unique identifiers associated with each computer that Fusion doesn’t know about and so can’t change. If your guest has one of these, you’ll need to update it if you copy the virtual machine or else things may not work. One example is Windows, which has a Security Identifier, or SID. Even if two computers have independent MAC address, if the SID is the same, one won’t be able to access the network. You may need to use a tool like NewSID to update the SID of a copied Windows virtual machine. Another example is older versions of Ubuntu, which stored the MAC address in /etc/iftab; networking didn’t work if the MAC address changed and this file wasn’t updated.
