# Nutanix Move senza VDDK: DirectPath, le novità della 6.x e la configurazione multihomed

- Link: https://www.silviobalduzzi.com/2026/11/nutanix-move-directpath-senza-vddk-multihomed/
- Published: 2026-11-03T18:44:15+01:00
- Author: balduz84

_Fino a poche settimane fa ogni migrazione da VMware con Nutanix Move cominciava
allo stesso modo: scaricare il VDDK dal portale Broadcom e caricarlo nell’appliance.
Da fine agosto quel download non è più disponibile, e Nutanix ha risposto con Move
6.3.3 e un nuovo metodo di migrazione, DirectPath. Vediamo come funziona, cosa richiede,
cosa ha portato il resto della famiglia 6.x e, già che ci siamo, come configurare
Move quando ha più di una scheda di rete._

## Il problema: il VDDK non si scarica più

Il Virtual Disk Development Kit (VDDK) è la libreria VMware con cui i prodotti di
terze parti leggono i dischi delle VM su ESXi. Move l’ha usata per anni per copiare
i dischi delle VM sorgenti, ma il VDDK non fa parte di Move: dalla versione 5.3.0
bisogna scaricarlo dal portale Broadcom e caricarlo nell’appliance prima di aggiungere
un ambiente ESXi come sorgente, scegliendo la versione giusta in base alla release
di ESXi (7.0.3.1 oppure 8.0.3.2 con le versioni più recenti di Move).

Alla fine di agosto 2026 Broadcom ha rimosso le pagine pubbliche di download del
VDDK. A chi ha aperto un ticket è stato risposto che il kit non è più disponibile
per l’uso generale e che resta riservato ai partner tecnologici, per i prodotti 
di backup e recovery. Il tema non riguarda solo Nutanix: anche Red Hat MTV, Azure
Migrate e diversi strumenti di migrazione verso KVM si appoggiano al VDDK.

Per chi sta pianificando l’uscita da VMware è un ostacolo concreto: senza VDDK, 
fino alla 6.3 Move non è in grado di copiare i dischi da ESXi.

## DirectPath: come funziona

Move 6.3.3, con note di rilascio del 13 ottobre 2026, introduce **DirectPath**: 
un metodo che trasferisce i dati dei dischi delle VM direttamente da ESXi ad AHV,
senza VDDK. Nutanix la presenta come una release speciale, già in GA, pensata per
le migrazioni da ESXi ad AHV e da ESXi a ESXi su AOS.

Secondo il blog tecnico di Nutanix, il meccanismo è questo:

 1. Move crea uno snapshot del disco della VM sorgente.
 2. Il disco dello snapshot viene collegato all’appliance Move come dispositivo a blocchi
    locale.
 3. Move legge i dati a livello di blocco, indipendentemente dal file system del sistema
    operativo guest, e li copia sul cluster di destinazione insieme alla configurazione
    della VM.
 4. A copia terminata, Move scollega il disco dello snapshot dall’appliance.

Chi viene dal mondo del backup su vSphere riconoscerà uno schema simile alla modalità
hot-add dei proxy: un’appliance che vive nello stesso ambiente e legge i dischi 
dagli snapshot. Il flusso di lavoro di Move resta quello di sempre: si aggiunge 
vCenter o l’host ESXi come sorgente, si crea il piano di migrazione, si sincronizza
e si esegue il cutover. Sparisce solo il passaggio del VDDK: niente download, niente
upload, nessuna versione da far combaciare con ESXi.

## Requisiti e vincoli da conoscere

Il rovescio della medaglia è che l’appliance deve poter raggiungere direttamente
i dischi. Da qui alcuni vincoli da conoscere prima di partire:

 * **Move gira nell’ambiente vSphere di origine.** L’appliance va distribuita come
   VM su ESXi, e il datastore che contiene i dischi delle VM da migrare deve essere
   accessibile dall’host su cui gira Move. Con più cluster o datastore non condivisi
   bisogna ragionare su dove posizionare l’appliance, o su quante appliance distribuire.
 * **Solo nuove installazioni.** La 6.3.3 non si installa come aggiornamento di 
   una versione precedente, e non è supportato nemmeno l’aggiornamento dalla 6.3.3
   a una versione successiva. Al momento l’appliance si scarica solo per ESXi: non
   c’è un’immagine per AHV.
 * **Niente ESXi con licenza gratuita.** Gli host con licenza free non sono supportati.
 * **Due privilegi vCenter da verificare.** L’account usato da Move deve avere _Provisioning›
   Allow virtual machine download_ e _Cryptographic Operations › Direct Access_.
   Se il ruolo dedicato a Move è stato creato per una versione precedente, controllatelo.
 * **Reti riservate.** Move usa internamente `172.17.0.0/16` e `172.18.0.0/16`: 
   se fanno parte del vostro piano di indirizzamento, va tenuto in conto.

### Compatibilità

| Componente | Versioni supportate da Move 6.3.3 | 
| Nutanix AOS | 6.10, 7.0, 7.3, 7.5, 7.6 | 
| Prism Central | pc.2024.3, pc.7.3, pc.7.5, pc.7.6 | 
| VMware ESXi | 6.5, 6.7, 7.0 (Update 1–3), 8.0 (Update 1 e 3) | 
| VMware vCenter | 6.7, 7.0 (Update 1–3), 8.0, 8.0 Update 3, 9.0 | 
| Nutanix VirtIO | 1.2.5 |

### Problemi noti

 * **Datastore con lo stesso nome.** Se due cluster dello stesso datacenter hanno
   datastore con lo stesso nome ma contenuti diversi, la migrazione con DirectPath
   può fallire. La soluzione è usare nomi univoci.
 * **Cutover e risorse del cluster.** Se la VM di destinazione richiede più risorse
   di quelle disponibili sul cluster, il cutover fallisce e ridimensionarla può 
   non bastare: prima di riprovare, cancellate da Prism la VM di destinazione già
   creata.
 * **CentOS 8.4 e 8.5 con Secure Boot.** Queste VM potrebbero non avviarsi su AHV:
   si può disabilitare Secure Boot oppure reimpostarne le chiavi dal boot manager.

Un dato che manca ancora è il confronto di prestazioni con il VDDK: Nutanix non 
l’ha pubblicato, quindi i tempi vanno misurati sul campo.

## Le altre novità della famiglia 6.x

DirectPath è la novità che fa notizia, ma le release 6.x hanno portato altro di 
interessante.

### Move 6.0 (settembre 2025)

 * Aggiornamento in place dalla 5.6.0; dalle 5.4.x e 5.5.x si passa invece con una
   migrazione verso la nuova appliance.
 * Migrazione delle policy di sicurezza di VMware NSX verso Flow Network Security.
 * La dashboard View Metrics, con lo stato e le prestazioni dell’appliance in tempo
   reale.

### Move 6.3 (luglio 2026)

 * Migrazione diretta nei Projects 2.0 di Prism Central, insieme alle security policy.
 * Migrazione zero-copy da ESXi ad AHV con storage esterno supportato, e nuovi array:
   Dell PowerStore e Pure Storage FlashArray.
 * Le VM Windows conservano le impostazioni WINS e, anche sui sistemi non in inglese,
   quelle IPv6.
 * Un piano di migrazione arriva in fondo anche se una singola VM ha un problema
   durante il cutover.
 * Gestione da Prism Central 7.6, migrazione dei dati verso Federated Files Server,
   destinazione Nutanix GC2 su AWS GovCloud e integrazione con CyberArk per le credenziali,
   in technical preview.

Una nota pratica: la 6.3 si aggiorna in place solo dalle 6.0.x, 6.1.x e 6.2.0, mentre
la 6.3.3, come abbiamo visto, è sempre una nuova installazione.

## Move in un ambiente multihomed

### Quando serve

In molte infrastrutture la rete di gestione di vSphere e quella dei CVM Nutanix 
sono separate, e il firewall tra le due non lascia passare il traffico NFS. La soluzione
naturale è dare all’appliance Move due schede di rete: una verso vCenter e gli host
ESXi, una verso i CVM del cluster di destinazione. Con DirectPath lo scenario diventa
ancora più frequente, perché l’appliance deve stare nell’ambiente vSphere ma scrivere
sullo storage Nutanix.

Nutanix però è chiara: Move non supporta gli ambienti multihomed. Esiste un workaround,
documentato nella guida di Move 6.0, che sostituisce con due operazioni manuali 
ciò che Move normalmente prepara da sola: autorizzare l’IP di Move sul container
di destinazione tramite la whitelist del file system, e montare il container sull’appliance
nel percorso che Move usa per scriverci.

### Cosa preparare

 * la seconda scheda di rete della VM Move, già aggiunta e configurata secondo la
   guida della vostra versione;
 * l’indirizzo IP con cui Move raggiunge i CVM, in genere quello della seconda scheda,
   e la relativa subnet mask;
 * l’indirizzo IP del CVM;
 * nome e UUID del container di destinazione;
 * l’accesso a Prism Element e la password dell’utente admin di Move.

### La procedura passo per passo

**1. Create il piano di migrazione.** Accedete all’interfaccia di Move, create un
nuovo piano di migrazione scegliendo il container di destinazione e salvatelo, senza
avviarlo.

**2. Annotate l’UUID del container.** Se non lo avete a portata di mano, lo trovate
da un CVM, nel campo `Uuid` dell’output:

    ```wp-block-code
    ncli ctr ls name=<tgt_contr_name>
    ```

**3. Autorizzate Move sul container.** In Prism Element scegliete _Storage_ dal 
menu in alto e passate alla vista _Storage Container_. Selezionate il container,
cliccate _Update_, aprite _Advanced Settings_ e scorrete fino al campo _Filesystem
Whitelists_. Inserite l’IP di Move con la subnet mask, nel formato `<ip-address>/
<netmask>`, e salvate. Se usate più appliance Move, separate gli indirizzi con una
virgola. Per autorizzare solo l’appliance, e non tutta la sua rete, uso la maschera`
255.255.255.255`:

    ```wp-block-code
    192.168.20.50/255.255.255.255
    ```

**4. Entrate nell’appliance come root.** La documentazione indica di collegarsi 
via SSH come root: in pratica si entra con l’utente `admin` e si passa alla shell
di root con `rs`, che chiede di nuovo la password di admin.

    ```wp-block-code
    ssh admin@<move_ip>
    rs
    ```

**5. Create la directory di mount.** Rispetto alla documentazione aggiungo `-p`,
così viene creata anche la cartella del CVM se non esiste ancora.

    ```wp-block-code
    mkdir -p /opt/xtract-vm/datamover/CVM_<cvm_ip>/<tgt_storage_container_uuid>
    ```

**6. Montate il container di destinazione** e verificate che il mount sia attivo:

    ```wp-block-code
    mount <cvm_ip>:/<tgt_contr_name> /opt/xtract-vm/datamover/CVM_<cvm_ip>/<tgt_storage_container_uuid>
    df -h | grep datamover
    ```

**7. Avviate la migrazione.** Uscite dall’appliance e avviate il piano dall’interfaccia
di Move.

### Qualche accorgimento in più

 * **Il mount non sopravvive al riavvio.** È un mount manuale, non scritto in `/
   etc/fstab`: se riavviate l’appliance, rifatelo prima di riprendere le migrazioni.
 * **Un mount per ogni container.** Il percorso contiene l’UUID del container: se
   migrate verso più container, ripetete i passi dal 2 al 6 per ciascuno.
 * **La whitelist del container sostituisce quella globale.** Una volta impostata,
   per quel container vale solo la whitelist del container e non più quella del 
   cluster. Se il container è già esposto via NFS ad altri sistemi tramite la whitelist
   globale, per esempio un proxy di backup, aggiungete anche i loro indirizzi.
 * **Fate pulizia alla fine.** Conclusa la migrazione, smontate il container con`
   umount` e togliete l’IP di Move dalla whitelist: un accesso NFS in meno da tenere
   sotto controllo.
 * **Resta un workaround.** La procedura è nella guida di Move 6.0: verificate che
   sia riportata anche in quella della versione che usate, o chiedete conferma al
   supporto Nutanix, e provatela prima con una VM pilota.

## Come lo imposterei in un progetto

 * **Nuovi progetti da vSphere ad AHV:** Move 6.3.3 con DirectPath come prima scelta,
   con un’appliance dedicata nell’ambiente vSphere di origine.
 * **Appliance esistenti con il VDDK già caricato:** nessuna urgenza di cambiare.
   La 6.3.3 non è aggiornabile, quindi la tratterei come un’appliance di progetto,
   da distribuire per la migrazione e dismettere alla fine.
 * **Prima della migrazione massiva:** un pilota con VM rappresentative, Windows
   e Linux, con Secure Boot e con dischi grandi, misurando i tempi di sincronizzazione
   e di cutover.
 * **Preparazione:** ruolo vCenter aggiornato con i due privilegi, nomi dei datastore
   univoci, nessuna sovrapposizione con le reti 172.17 e 172.18 e, se l’appliance
   ha due schede, il workaround multihomed pronto.

Con DirectPath Nutanix toglie di mezzo la dipendenza più fragile del percorso da
VMware ad AHV. Il prezzo è una release speciale, con i suoi vincoli: conoscerli 
in anticipo fa la differenza tra un pilota che va liscio e uno che si blocca al 
primo piano di migrazione.

## Riferimenti

 * [Nutanix Move 6.3.3](https://next.nutanix.com/product-updates/nutanix-move-6-3-3-45958):
   annuncio e sintesi delle note di rilascio (Nutanix Community)
 * [Flexible VM Migrations to the Nutanix Cloud Platform with Move DirectPath](https://www.nutanix.com/blog/flexible-vm-migrations-to-the-nutanix-cloud-platform-with-move-directpath)(
   blog Nutanix)
 * [Move 6.0: Setting Up a Multihomed Environment](https://portal.nutanix.com/page/documents/details?targetId=Nutanix-Move-v6_0:top-set-up-multihome-t.html)(
   Nutanix Portal)
 * [Nutanix Move 6.3](https://next.nutanix.com/product-updates/nutanix-move-6-3-45782)
   e [Nutanix Move 6.0](https://next.nutanix.com/product-updates/nutanix-move-6-0-44839)(
   Nutanix Community)