SvHCI - Importing VMs From VMware

The StorMagic SvHCI VMware Virtual Machine import utility consists of an engine within the SvHCI node that is triggered to import a VMware virtual machine from a client device via a Python script.

The intent of this model is the ability to potentially trigger VM imports via a centralized automated script, with the VM import running within a remote LAN network.

The SvHCI node may be triggered to import the virtual machines, talking either to vCenter or directly to an ESXi host over any VMkernel adapter. For example, SvHCI can communicate directly with ESXi over a faster network link, such as a direct attach cable between the nodes.

The workflow for a warm import is:

1. Trigger the SvHCI node to start the import of a virtual machine from vCenter or an ESXi node.
2. This triggers a non-quiesced snapshot of the virtual machine in VMware, named StorMagicWarmImport, so as not to impact the production VM. Any existing snapshots must be merged back in before a warm import is possible.

3. The data is streamed out of VMware across to SvHCI.
4. The snapshot is consolidated, completing one iteration against the VM.
5. The VM goes through repeated iterations until the system administrator is ready to cut over.
6. At cutover, the virtual machine is powered down, either in the guest operating system, which is preferred when VMware Tools has already been removed, or through VMware Tools. This quiesces the final virtual machine I/O.
7. The virtual machine is recreated in SvHCI with matching virtual machine hardware settings, including MAC addresses.
8. The original virtual machine remains untouched in VMware following shutdown. Should the system administrator wish to back out, the virtual machine can be powered back on in VMware, noting that the import would need to be attempted again later.

To ensure Windows VMs import correctly, ensure they are booting and running on SvHCI-supported virtual hardware.

The virtual machine must use a VMware Paravirtual SCSI controller within VMware prior to import.

If the VM is still using LSI Logic SAS, this can be modified using the steps below.

This example uses a guest VM base system installed from the VMware defaults for a Windows Server 2016 template:

• UEFI
• LSI Logic SAS
• E1000E

1. Install VMware Tools, if not already present, to install the VMXNET3 and PVSCSI drivers.
2. Shut down the virtual machine.
3. Add a new SCSI controller.

Set the new controller to VMware Paravirtual (PVSCSI), typically as SCSI controller 1.

4. Boot the virtual machine to ensure the drivers for the PVSCSI controller are loaded into the Windows operating system.

The controller will display in Device Manager.

5. Power down the virtual machine.
6. Transition SCSI controller 0 from LSI Logic SAS to VMware Paravirtual.
7. Remove SCSI controller 1.

8. Boot the virtual machine in VMware. It should boot normally. Reboot once more to verify.

9. Power down the virtual machine.

The virtual machine is now ready to run on SvHCI and may be:

1. Imported using the StorMagic VM import utility detailed below.
2. Exported to OVF.
3. Copied by downloading the VMDK using the datastore browser and uploading it into SvHCI.

Download and install Python on the operating system of choice. The example below demonstrates installation on Windows 11.

From a Windows Terminal session, type python to install Python through the Microsoft Store.

Type:

py install default

Validate that the vm_import.py file will run by executing it with the -h switch.

SvHCI can import VMs from VMware as a cold import, with the virtual machine shut down. However, with large VMs or a large amount of data to copy, this can result in extended copy times and application downtime.

SvHCI 2.4.0 or higher introduces warm import. This enables the guest VM to remain live while data is copied using change block tracking and VM snapshots.

This ensures that most of the data is copied while the VM is still running in production in VMware. A desired cutover period can then be selected to shut down the VM and bring it back online in SvHCI.

PS C:\svhci-vm-import\warm> python.exe .\vm_import.py -h
usage: vm_import.py [-h] [--defaults DEFAULTS] [--hostname HOSTNAME] [--password PASSWORD]
                    [--vsphere-hostname VSPHERE_HOSTNAME] [--vsphere-username VSPHERE_USERNAME]
                    [--vsphere-password VSPHERE_PASSWORD] [--vm-name VM_NAME] [--pool POOL]
                    [--remote-pool REMOTE_POOL] [--warm] [--threshold THRESHOLD] [--power]

SvHCI VM import from vSphere ESXi/VCSA

options:
  -h, --help            show this help message and exit
  --defaults DEFAULTS   Path to defaults file (key=value per line)
  --hostname HOSTNAME   SvHCI hostname
  --password PASSWORD   Password for authentication
  --vsphere-hostname VSPHERE_HOSTNAME
                        vSphere ESXi/VCSA address
  --vsphere-username VSPHERE_USERNAME
                        Username for vSphere authentication
  --vsphere-password VSPHERE_PASSWORD
                        Password for vSphere authentication
  --vm-name VM_NAME     Name of the virtual machine
  --pool POOL           Name of the SvHCI storage pool
  --remote-pool REMOTE_POOL
                        Name of the remote SvHCI storage pool (adds VM protection)
  --warm                Perform a warm import
  --threshold THRESHOLD
                        Upper limit of remaining data to trigger cutover (warm only)
  --power               Power on VM after successful import

In the example below, the Python trigger machine cannot route to the VMware node on VMkernel address 192.168.1.2. However, the SvHCI node can reach it over a back-end direct-attached network.

This enables:

• The import to occur within the local network while the Python trigger machine may be remote, preventing the VM data from copying over the WAN.
• Physical separation of import traffic onto a different physical NIC so it does not impact front-end production VM traffic.
• Potential use of a faster direct attach cable NIC instead of a slower switched network.

c:\VM-Import> python .\vm_import.py --hostname="10.10.130.3" --password="St0rMag1c!" --vsphere-hostname="192.168.1.2" --vsphere-username="root" --vsphere-password="St0rMag1c!" --vm-name="WindowsVM" --pool="pool" --warm --power

There is no limit to the number of concurrent imports.

import subprocess

vm_names = ["GuestVM01", "GuestVM02", "GuestVM03", "GuestVM04", "GuestVM05", "GuestVM06", "GuestVM07", "GuestVM08", "GuestVM09", "GuestVM10", "GuestVM11"]

base_cmd = [
    "python",
    r"C:\Users\Administrator\Downloads\vm_import.py",
    '--hostname=10.10.130.3',
    '--password=St0rMag1c!',
    '--vsphere-hostname=172.16.1.1',
    '--vsphere-username=root',
    '--vsphere-password=St0rMag1c!',
    '--pool=SvHCI01Pool',
    '--remote-pool=SvHCI02Pool',
    '--warm',
    '--power',
]

for vm in vm_names:
    cmd = base_cmd + [f'--vm-name={vm}']
    subprocess.run(cmd, check=True)

When an import is triggered, the task below is displayed in the Virtual Machines view in SvHCI.

Under Storage, the disk being imported can be observed, including the import percentage.

With the disk selected, select Statistics and enable the throughput toggle to view the incoming write speed.

With the host selected in vCenter, navigate to Monitor > Advanced > Chart Options > Network to view the network copy throughput.

Once most of the data has been copied, change block tracking is used and snapshots are triggered on the VM.

Iterations can also be observed on the import task.

When ready to cut over the VM, shut it down in VMware. The VM will then power on in SvHCI and the task will complete.

Import timings can also be determined from the SvHCI node events.

Copy speed is affected by many factors, including network bandwidth, contention, storage read speed, and storage write speed.

As an example, StorMagic has observed a customer importing a 500 GB VM containing four disks over 10 Gb networking in approximately four hours and fourteen minutes.

Streaming multiple VMs concurrently may also improve the overall import rate.

The VMkernel adapter must be configured to use the Default TCP/IP Stack, as shown below.

StorMagic has observed that Windows Server 2025 disks other than C: on disk 0, such as disk 1 and disk 2, may appear offline when the VM is automatically powered on in SvHCI.

This can significantly affect workloads such as SQL Server if those applications expect the disks to be online when the operating system starts.

This behavior is caused by the SAN policy within Windows. The policy may differ depending on the Windows operating system and edition, as shown below.

Before importing the VM, run the following commands through DiskPart to ensure that disks come online automatically during the first boot after import:

DISKPART> list disk
DISKPART> san
DISKPART> san policy = onlineall
DISKPART> san

When importing a Windows VM that contains a spanned disk, the disks must be manually brought online in Windows Disk Management after the import completes.

• StorMagic Product Documentation 
• SvHCI 2.1 VM Import Documentation 
• SvHCI 2.4 VM Import Utility Documentation