Skip to main content

VMware to Proxmox VE Migration with Druva Global Deduplication

Organizations migrating from VMware to Proxmox VE often need to know whether Druva's global deduplication works across different hypervisor platforms.

The answer: cross-hypervisor global deduplication works when you use a block-preserving migration method. This document covers the validation framework, results, and requirements.

Validation framework and outcome

To test deduplication across platforms, the following setup was used:

  • Environment: A target virtual machine was initially provisioned, configured, and protected within a native VMware environment. This same workload was subsequently migrated and protected within a Proxmox VE target environment.

  • Critical infrastructure setup: Both the source VMware and target Proxmox workloads were explicitly configured to route backups to the same AWS (or Azure) storage destination in Druva. This ensures that incoming data blocks from both hypervisors are compared against the same logical cloud storage pool.

The outcome of this validation is summarized in the following table.

Backup Event

Source Hypervisor/Platform

Result

Backup 1 - Initial backup of the VMWare VM

VMware

Full Data Ingestion. Since this is the initial backup, the cloud storage target is empty of this data. Therefore, no existing blocks are available for comparison. The system stores all of the data blocks, causing the cloud storage consumption to be equal to the full size of the source data.

Backup 2 - Initial backup of the Proxmox VM after migration

Proxmox VE

Druva’s deduplication savings. Despite backing up the same data again from a different platform, Druva backs up only the minimal unique blocks, achieving storage savings.

Critical Requirement: Cross-platform deduplication depends on using a block-preserving migration method. In this validation, the VMware VM was migrated to Proxmox using a QEMU-based disk import functionality ensuring data blocks remained unaltered. Detailed steps on this migration are given at a later section.

Validating alternative migration methodologies

Organizations may use various approaches to transition from VMware to Proxmox VE. To determine whether your chosen method preserves deduplication, leverage the following validation test:

The Checksum verification method

Perform the following:

  1. Migrate a single test VM using your preferred method.

  2. Run a cryptographic checksum (e.g., SHA-256) on the virtual disks pre-migration (on VMware) and post-migration (on Proxmox VE).

  3. The Rule: If the pre- and post-migration checksums match exactly, the underlying block structure is preserved and Druva's global deduplication will work seamlessly across the platforms.

Using this verification method the native Proxmox Migration Wizard (import wizard) has also been confirmed to preserve block integrity and yield cross-platform deduplication savings.

QEMU-based disk Import: Migrating a VM from VMware to Proxmox VE

In the following steps, run the commands from the Proxmox node shell.

  1. Copy disks to Proxmox node as follows:

    1. Connect to the VMware ESXI host using ssh. Use the disk path as /vmfs/volumes/<DATASORE_NAME>/<VM_NAME>

    2. Copy the following disk files to the Proxmox node (location: /var/lib/vz):

      1. <VM_DISK_NAME>.vmdk

      2. <VM_DISK_NAME>-flat.vmdk
        ​

        📝 Note

        ​Before copying disk files, power off the VM in VMware ESXi.

  2. Create a VM (no disks).
    ​qm create <NODE-ID> --name test_dedupe --memory 8196 --cores 8 --net0 virtio,bridge=vmbr0

  3. Check the storage name:
    ​pvesm status

    The above command will provide the available storage names on the Proxmox node. You can select the node storage, such as local-lvm or zfs storage.

  4. Import the disks:

    1. Disks will be attached as unused disks to the VM.

      1. qm importdisk <NODE-ID> /var/lib/vz/<VM_DISK_1>.vmdk local-lvm
        where, local-lvm is the Proxmox storage name

      2. qm importdisk <NODE-ID> /var/lib/vz/<VM_DISK_2>.vmdk local-lvm

      This converts VMDK to the raw disk image type and creates a thin volume inside the lvm-thin storage type. The VM is created with the naming convention vm-<VM-ID>-disk-0.

  5. Attach the imported disks.

    1. After import, disks are added but not attached to the VM. Use the following command to attach the disks.

      qm set <VM_ID> --scsi0 local-lvm:vm-<VM_ID>-disk-0

    2. Define the virtual bus for better performance. In this example, it sets the SCSI controller type of the VM to VirtIO SCSI.

      qm set <VM_ID> --scsihw virtio-scsi-pci

  6. Set the boot disk

    qm set <VM_ID> --boot order=scsi0

Related Articles
Did this answer your question?