VMware VM – ‘I moved it’ vs ‘I copied it’
If you’ve worked with VMware products before, you may have (at at some point likely will), encounter a pop-up similar to this one.
What is it asking? What prompted this question? Why does VMware want the default to be, ‘I copied it’? The short answer is that VMware ‘thinks’ that it is possible that this VM was cloned from a pre-existing VM (i.e. ‘I copied it’). If that is the case, VMware needs to change the unique identifiers within the cloned machine, so that potential hardware & software conflicts are avoided. Choosing ‘I copied it’, therefore, is preferred over ‘I moved it’, which prevents VMware from making any changes to the VM.
To understand the changes that are taking place, we’ll have to dig a little deeper into how the VMware hypervising software builds and maintains VMs.
Understanding VMware and UUIDs
When VMware creates a VM, it creates (at least one) UUID (Universally Unique Identifiers) on startup. This value is generated using the host machine’s BIOS, and the directory location of the VM itself. The value is then recorded within the VM’s VMware Virtual Machine Configuration file (*.vmx) file as “uuid.location”, and “uuid.bios”. Each time the VM is powered on, this value is once again calculated and compared to the one stored in the (*.vmx) file in order to determine if the directory location, or the host machine, has changed. If VMware determines the VM has moved, then you get the “Did you move it or copy it?’ pop-up.
The term UUID is often used interchangeably with GUID (Globally Unique Identifier). This identification is a 128-bit object that is non-resolvable (as opposed to, say, a FQDN), does not require registry (therefore it can be generated and used spontaneously), and unique across space and time. Many systems, from Windows software architecture, to the cellular device in your pocket, all depend on UUIDs for functionality. If you have the time, they’re defined quite well in a brief (32 page) RFC 4122: A Universally Unique IDentifier (UUID) URN Namespace.
So how can they be both globally unique and not require registry? It’s because the numbers are so large, that they don’t (necessarily) require registry. In addition to being massively large, they are used in confined systems. For example, the UUID assigned to a VMware machine is only competing against UUIDs generated by other VMware products. VMware does not need to consider UUIDs generated for a cellular handset. These two systems will never encroach on one another.
So how many UUIDs are there? Well, 2^128 is roughly 3.4 × 10^38 (beyond comprehension). However, Wikipedia does a good job at putting it into perspective: Wikipedia article on UUIDs:
“…the annual risk of a given person being hit by a meteorite is estimated to be one chance in 17 billion, which means the probability is about 0.00000000006 (6 × 10−11), equivalent to the odds of creating a few tens of trillions of UUIDs in a year and having one duplicate.”
Why is tracking the UUID and location of the VM so important?
Duplicate MAC addresses could result in big MAC problems (above).
The VM’s UUID is used by the VMware software to generate static values used by your VM, including the network MAC address. Before we go any further, it should be noted that proper packet routing depends an unique MAC address to be present on each network interface. A duplicate MAC address might result in big MAC problems. You should also be aware, that occasionally software licenses are tied to static identifiers, such as the MAC. The Avaya Aura product, for example, has its licensing tied to the MAC found on the host machine (which can be VMware VM). VMware would prefer to avoid creating VMs with duplicate MACs, but also would prefer not to rewrite the MAC if at all possible.
Below, I’ll examine what changes take place in the (*.vmx) file when you choose, ‘I moved it’ versus ‘I copied it’.
What changes when you click ‘I moved it’
Not much needs to change when you move the VM, other than recording the new directory location (“uuid.location”).
Below are two copies a VMware (*.vmx) files. The (*.vmx) file on the left is the ‘original’ machine (i.e. an unmoved & original VM). The (*.vmx) file on the right is from the same VMware machine after being moved, powered on once, selecting ‘I moved it’, then shutdown.
As you can see, the only difference between these files is a new “uuid.location” value. The “uuid.bios” has not changed, and the MAC address for the network adapter remains unchanged.
Click to enlarge:
The ‘original’ (*.vmx) file is on the left, and the ‘moved’ (*.vmx) is on the right. The differences between the (*.vmx) files is that the new (*.vmx) has a new value calculated for “uuid.location”.
What changes when you click ‘I copied it’
Several static identifiers must be changed when you copy the VM to avoid potential conflicts with the original machine.
Below are two copies a VMware (*.vmx) files. The (*.vmx) file on the left is the ‘original’ machine (i.e. an unmoved & original VM). The (*.vmx) file on the right is from the same VMware machine after being copied, powered on once, selecting ‘I copied it’, then shutdown.
The difference between these files is a new “uuid.location” & “uuid.bios” value (they’re both new and identical). VMware has also created a new value for “ethernet0.generatedAddress” (the MAC for the network adapter).
Click to enlarge:
The ‘original’ (*.vmx) file is on the left, and the ‘copied’ (*.vmx) is on the right. The differences between the (*.vmx) files is that the new (*.vmx) has a new and matching value calculated for “uuid.location” & “uuid.bios”. A new value has also been created an applied to “ethernet0.generatedAddress”.
Choose wisely
So there you have it. If you’re unsure, you can always choose “I copied it” and will always avoid hardware conflicts, however, you may create software licensing conflicts within the VM itself. Alternatively, if you choose “I moved it” you’ll always avoid software licensing conflicts within the VM, but may create hardware conflicts. Be sure to always choose wisely!
Materials used
VMware Workstation Version: 9.0.3
Host Machine OS: Windows 7
VM OS: Linux Mint 17 64-bit edition
VM Devices: Memory 1 GB, Processors 1, Hardisk 20 GB, Network Adapter (x1) (NAT)
Special thanks to Matthew Lawson for the MAC Attack photo!