During my work experience, I have exported and imported virtual machines (VMs) on VMware ESXi hosts. This project documents the procedures and considerations I followed when importing VMs, including compatibility between ESXi versions, unique identifiers, network interface MAC addresses, and virtual hardware configuration.
Compatibility requirements for importing VMs between ESXi hosts.
Avoid conflicts caused by duplicate identifiers when importing VMs.
Import VMs using the ESXi web interface.
Configure the required virtual hardware and network interfaces after importing VMs.
Ensure imported VMs can run reliably on the target ESXi host.
VMware ESXi
VMware OVF Tool
OVF and OVA virtual machine formats
Windows sysprep
MikroTik RouterOS
Linux
Consistency
VMs exported from ESXi or vCenter can generally be imported into ESXi, as long as the formats and configurations are compatible. This helps save time and reduce potential issues. However, VMs exported using OVF Tool may sometimes be exported with the “—compress” option to reduce the exported file size. Although this makes it easier to transfer the files over the network, the resulting compressed format may not be supported by the ESXi web interface for importing.
Moreover, older versions of ESXi may not support VMs exported from newer versions due to differences in virtual hardware versions and supported features. To avoid this issue, I always chose the newest ESXi version supported by the organization's other ESXi hosts that might need to import and run the VM in case of a failure, serving as backup hosts.
Unique Identifiers
VMs exported from an ESXi host can be imported back into the same host, but some conditions must be considered to avoid conflicts caused by duplicate identifiers. The requirements vary depending on the guest operating system and VM configuration. Below, I explain how I considered these differences when importing VMs.
Windows VMs
Windows uses unique identifiers, including security identifiers (SIDs), for system and security management. Therefore, a Windows VM exported without running sysprep should not be deployed as a separate instance without considering potential identifier conflicts, especially when the original VM already exists on the same network.
To address this issue, after a fresh Windows installation on an ESXi host and before deploying services or joining a domain, I followed the steps below to generalize the Windows installation and prepare it to generate new machine-specific information.
To do this, I entered sysprep in the Run dialog and launched sysprep.exe. Then, I selected the Generalize option and set the shutdown option to Shutdown.
Then I exported the Windows VMs deployed on the host.
As a result, I considered this procedure to reduce the risk of identifier conflicts.
MikroTik RouterOS
MikroTik RouterOS VMs can generally be exported and imported without the same identifier-related concerns as Windows VMs. However, when running multiple instances on the same network, I checked for duplicate MAC addresses on their virtual network interfaces.
After powering on the VM, I reset the MAC address of the virtual interface connected to the vSwitch. To do this, after importing the RouterOS VM and signing in through the console, I ran the following command:
/interface ethernet reset-mac-address ether1
Linux OS
Linux hosts various services, including databases and core network services. I found that there was no single, simple procedure for safely handling duplicate system identifiers across all Linux distributions and services.
Therefore, when multiple independent instances of a Linux VM were required on the same ESXi host, I preferred to install the operating system and required services from scratch. Although this approach was time-consuming, it reduced the risk of conflicts caused by duplicated identifiers and configurations, helping ensure reliable operation of the VMs.
To import a VM into an ESXi host, I opened the Create a new virtual machine wizard and selected "Deploy a virtual machine from an OVF or OVA file."
I then entered a short, descriptive, and unique name for the VM and selected the required OVF or OVA files from my local computer.
Next, I selected the datastore where the VM files would be stored.
Finally, I configured the available disk provisioning options and selected whether the VM should be powered on automatically when the host starts, depending on the requirements of the environment.
After importing the VM, I reviewed its virtual hardware configuration and added the required components, mainly virtual hard disks and network interface cards (NICs). I did this by right-clicking the VM and selecting Edit Settings.
Once the required hardware and settings were configured, the imported VM was ready to be powered on and used.