Veeam “failed to modify disk” nel ripristino di VM Linux da VMware a Hyper‑V: cause, soluzioni e checklist completa

Stai provando a ripristinare con Veeam il backup di una VM Linux da VMware a Hyper‑V e il job si interrompe con “failed to modify disk”? Questa guida pratica ti aiuta a individuare la causa reale e a completare il ripristino, con checklist, comandi PowerShell e procedure alternative collaudate.

Indice

Panoramica del problema

L’errore failed to modify disk compare tipicamente nella fase in cui Veeam interagisce con l’host Hyper‑V per creare o collegare il disco virtuale della VM di destinazione (ad esempio conversione VMDK→VHDX, creazione/espansione del file VHDX, collegamento del disco al controller virtuale o modifica di un checkpoint). La radice del problema, però, quasi mai è “il disco” in senso stretto: più spesso è un mismatch di formato, una incompatibilità di generazione della VM, un percorso/permesso di scrittura non idoneo, oppure una conversione incompleta della catena di snapshot del sorgente.

Prima di ripetere il ripristino in loop, dedica qualche minuto a tre verifiche chiave: formato e dimensioni del disco, permessi e percorso di destinazione, connettività e parametri del job. Di seguito trovi una checklist ragionata con azioni concrete.

Soluzioni e verifiche consigliate (checklist)

Area da controllare	Azione pratica
Formato disco	Hyper‑V accetta VHD/VHDX. Se l’immagine è in VMDK, convertila (es. conversione interna Veeam durante il Restore to Microsoft Hyper‑V, oppure strumenti come StarWind V2V o `qemu-img`). Nota: `Convert‑VHD` converte tra VHD e VHDX, non legge VMDK.
Dimensione disco	Verifica che il disco non superi il limite supportato da Hyper‑V (64 TB per VHDX, 2 TB per VHD). Ridimensiona/partiziona se necessario prima del ripristino.
Tipo di disco	In caso di incompatibilità, preferisci fixed (statica). Assicurati che eventuali dischi GPT/UEFI siano associati alla generazione di VM corretta (Gen 2 per EFI/GPT, Gen 1 per BIOS/MBR).
Permessi	L’account usato in Veeam deve essere membro di Hyper‑V Administrators e avere scrittura sul percorso di archiviazione dei VHDX (NTFS/CSV/SMB). Verifica anche le ACL della share se la destinazione è remota.
Rete & Firewall	Conferma con un ping o `Test‑NetConnection` che Veeam Backup Server ↔ Host Hyper‑V comunichino sulle porte richieste (per impostazione predefinita TCP 2500‑3300 per i Data Mover). Escludi blocchi di AV/IDS.
Parametri del job	In Veeam scegli Restore to Microsoft Hyper‑V → host corretto, datastore/percorso valido, opzione Enable network mapping solo se necessaria. Evita di accendere la VM al termine finché non hai verificato i driver.
Log Veeam	Analizza Restore.log e i log del job. I messaggi appena prima dell’errore indicano quasi sempre il disco o la fase incriminata (creazione file, attach, espansione, merge).
Aggiornamenti	Applica le ultime cumulative update sia per Veeam (patch & build recenti) sia per Hyper‑V (Windows Update). Molte incompatibilità di formato sono state corrette in versioni successive.
Compatibilità guest	Verifica che la distribuzione Linux disponga dei driver Hyper‑V (`hvvmbus`, `hvstorvsc`, `hvnetvsc`, `hvballoon`) nel kernel (≥ 3.10). In caso contrario, abilita modalità legacy o aggiorna kernel/initrd.
Supporto Veeam	Se il problema persiste, apri un ticket allegando i log raccolti con Veeam Support Collector; l’errore “failed to modify disk” può mascherare bug specifici già noti al supporto.

Diagnostica rapida: capire dove fallisce

Il modo più veloce per orientarsi è capire in quale micro‑fase fallisce la modifica del disco:

Creazione file VHDX: errori tipo “Access is denied”, “The system cannot find the path specified”, “There is not enough space” puntano a permessi/percorso/spazio.
Attach al controller: messaggi riferiti a SCSI/IDE/Generation indicano mismatch Gen1/Gen2, oppure un disco EFI collegato ad una VM BIOS.
Espansione/resize: tipico quando la destinazione è VHD (limite 2 TB) o quando si tenta di estendere oltre i limiti del filesystem di destinazione.
Merge/checkpoint: presenti catene di snapshot consolidate male sul sorgente; meglio fare export in VHDX e collegarlo a una VM nuova, poi boot e cleanup.

Guida passo‑passo alla risoluzione

Verifica prerequisiti su Hyper‑V: spazio, percorso e permessi

Assicurati che il percorso di destinazione sia locale o un CSV (in cluster) con spazio sufficiente e con ACL coerenti. Se è una share SMB, verifica sia le ACL NTFS che quelle della share.

# Spazio disponibile sul volume di destinazione
Get-Volume | Sort-Object DriveLetter | Select DriveLetter, FileSystemLabel, SizeRemaining

Verifica percorso e ACL NTFS

$dst = "C:\ClusterStorage\Volume1\VMs\Linux01"
Test-Path $dst
icacls $dst

Verifica appartenenza al gruppo Hyper-V Administrators

Get-LocalGroupMember -Group "Hyper-V Administrators"

Consiglio: se ripristini in un cluster, usa il percorso CSV (C:\ClusterStorage\VolumeX\...) e non un percorso locale come D:\ su un singolo nodo, a meno che tu non sappia esattamente cosa stai facendo.

Test di connettività e porte Veeam ⇄ Hyper‑V

Conferma che il Veeam Backup Server e l’host Hyper‑V possano parlare sulle porte necessarie (di default TCP 2500‑3300). Esegui un test mirato:

# Test porta Data Mover (esempio 2501)
Test-NetConnection -ComputerName HVHOST01 -Port 2501

Disattiva temporaneamente il firewall solo per diagnosi (richiede policy di sicurezza!)

Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled False

Se usi antivirus/EDR, crea eccezioni appropriate per i processi Veeam e per la cartella di destinazione dei VHDX: blocchi in scrittura generano spesso l’errore generico sulla “modifica disco”.

Conversione e formato del disco: quando e come farla

Durante un Restore to Microsoft Hyper‑V, Veeam può convertire in automatico i dischi VMware (VMDK) in VHDX. In alternativa, se il ripristino diretto continua a fallire, esporta prima il contenuto del backup in VHDX e poi crea manualmente la VM:

In Veeam: Files > Disk Exports (o funzione equivalente) → Export Disk Content as Virtual Disk → scegli VHDX.
Su Hyper‑V: crea una nuova VM (Gen 1 o Gen 2 in base a MBR/BIOS oppure GPT/UEFI), senza disco.
Collega il VHDX esportato alla VM e prova l’avvio.

Attenzione a Convert‑VHD: il cmdlet converte solo tra VHD e VHDX. Se parti da VMDK e vuoi restare fuori da Veeam, usa strumenti dedicati (es. StarWind V2V, qemu-img).

Dimensioni, block size e settore logico

Hyper‑V supporta VHDX fino a 64 TB, ma controlla anche block size e logical/physical sector size del file, specialmente se ripristini su storage con settori 4K nativi.

# Ispeziona un VHD/VHDX già presente
Get-VHD -Path "C:\ClusterStorage\Volume1\VMs\Linux01\disk0.vhdx" |
Select Path, VhdType, VhdFormat, FileSize, Size, BlockSize, LogicalSectorSize, PhysicalSectorSize

Se necessario, puoi rigenerare un VHDX con parametri espliciti e poi iniettare i dati con un secondo passaggio (approccio avanzato).

Tipo di disco e generazione della VM

Gen 1: BIOS/MBR, disco di boot su IDE. Adatta a sistemi legacy.
Gen 2: UEFI/GPT, Secure Boot opzionale, solo controller SCSI per il boot. Necessita dei driver Hyper‑V nel kernel.

Se nel backup la VM usa GPT/EFI, crea una VM Gen 2. Un mismatch (EFI su Gen 1 o MBR su Gen 2) porta a errori nella fase di collegamento/creazione del disco e, anche se il ripristino passasse, a un boot failure.

Per le distribuzioni moderne, abilita Secure Boot impostando il modello “Microsoft UEFI Certificate Authority” solo se il tuo Linux lo supporta; in caso di dubbi, disabilita Secure Boot fino al primo avvio riuscito.

Parametri del job Veeam: impostazioni consigliate

Avvia Restore to Microsoft Hyper‑V dalla VM (o dall’intero job).
Seleziona host di destinazione e percorso CSV/NTFS corretto.
Lascia disabilitato “Power on VM after restore” al primo tentativo.
Usa “Network mapping” solo se indispensabile: eventuali errori in questa fase possono confondere la diagnostica.
Preferisci VHDX dinamico per velocità; se sospetti incompatibilità lato storage, prova con VHDX fixed.

Log Veeam e registri Hyper‑V: dove cercare

I log di ripristino Veeam si trovano usualmente in C:\ProgramData\Veeam\Backup. Cerca parole chiave come modify, attach, resize, access denied, not enough space. Esempio:

# Esempio di ricerca mirata nei log di restore
$logRoot = "C:\ProgramData\Veeam\Backup"
Get-ChildItem $logRoot -Recurse -Include Restore.log |
  Select-String -Pattern "failed to modify disk","attach","resize","access is denied","not enough space" |
  Select Path, LineNumber, Line

Controlla anche i log Hyper‑V nel Visualizzatore eventi: Applications and Services Logs > Microsoft > Windows > Hyper‑V‑VMMS > Admin. Se vedi errori come “Failed to add device ‘Virtual Hard Disk’” o “Failed to open attachment”, sei di fronte a problemi di percorso/ACL o formato file.

Aggiornamenti e versioni

Allinea quanto prima:

Veeam Backup & Replication alla build recente supportata.
Windows Server dell’host Hyper‑V con gli ultimi aggiornamenti cumulativi.
Driver/firmware dello storage di destinazione (SAN/NAS/HBA).

Molte segnalazioni “failed to modify disk” si risolvono aggiornando componenti che migliorano la gestione VHDX/SMB/CSV.

Compatibilità guest Linux: driver Hyper‑V e initrd

Dopo il ripristino, il sistema deve vedere controller SCSI Hyper‑V e bus virtuale. Verifica i moduli:

# All'interno della VM Linux
lsmod | egrep "hv_(vmbus|storvsc|netvsc|balloon)"

Se i moduli non sono presenti (o non inclusi nell’initrd):

Debian/Ubuntu: sudo apt update && sudo apt install linux-image-virtual hyperv-daemons e poi sudo update-initramfs -u.
RHEL/CentOS/Alma/Rocky: sudo yum install hyperv-daemons (o pacchetti equivalenti) poi sudo dracut -f.
SLES/openSUSE: sudo zypper in hyper-v (o metapacchetti equivalenti), ricostruisci l’initrd.

Rimuovi o disabilita eventuali servizi VMware Tools obsoleti e verifica /etc/fstab per mount di device nominati in modo non persistente; preferisci UUID o LABEL.

Procedura alternativa: conversione offline + creazione manuale

Quando il ripristino diretto continua a generare “failed to modify disk”, la via più rapida per sbloccare la situazione spesso è la conversione offline:

Esporta il disco dal backup in VHDX.
Su Hyper‑V, crea una VM nuova con la generazione corretta e un disco placeholder; spegni la VM e scollega il placeholder.
Collega il VHDX esportato al controller appropriato (IDE per Gen 1 come disco di boot, SCSI per Gen 2).
Imposta l’ordine di boot, disabilita temporaneamente Secure Boot se necessario, avvia la VM.

Questa procedura isola il problema (conversione file vs. orchestrazione del job) e spesso permette di accendere la VM e fare gli aggiustamenti lato guest prima di rimetterla in produzione.

Controller e mapping: IDE/SCSI, boot e dischi dati

Gen 1: il disco di boot deve stare su IDE. I dischi dati possono essere su SCSI.
Gen 2: tutti i dischi sono su SCSI; non esiste IDE.
Se vedi errori “add device Virtual Hard Disk”: prova a cambiare controller, canale e posizione del disco.

CSV, SMB e percorsi UNC: best practice

Su cluster Hyper‑V, usa CSV (C:\ClusterStorage\...). Per ripristini su SMB 3.x assicurati di:

Concedere all’account del job Veeam Full Control sia a livello NTFS sia di share.
Verificare cifratura SMB e firme: policy troppo restrittive possono rallentare o bloccare operazioni di creazione VHDX.
Evitare percorsi con nomi troppo lunghi o caratteri speciali non supportati.

Spazio, quota e thin provisioning

Anche con VHDX dinamico serve overhead per la creazione del file. Se lo storage ha quote o thin provisioning, potresti superare i limiti durante la fase di “modify disk”. Verifica spazio e soglie lato array/NAS.

Snapshot differenziali e catene lunghe

Catene di snapshot molto lunghe su VMware possono creare VMDK consolidati non “puliti” ai fini della conversione. Meglio eseguire una consolidation sul sorgente e un backup fresco prima della migrazione. In caso di dubbio, procedi con l’export VHDX e ripristino manuale.

Script di diagnostica rapida (PowerShell) per l’host Hyper‑V

Lo snippet seguente esegue i controlli più comuni: spazio su disco, appartenenze ai gruppi, porte di rete, percorso di destinazione e verifica del modulo Hyper‑V.

# Parametri
$HyperVHost = "HVHOST01"
$DestPath   = "C:\ClusterStorage\Volume1\VMs\Linux01"

Write-Host "== Spazio disponibile =="
Get-Volume | Select DriveLetter, SizeRemaining | Format-Table -Auto

Write-Host "== Verifica percorso di destinazione =="
if (Test-Path $DestPath) { "Percorso OK: $DestPath" } else { "Percorso NON esistente: $DestPath" }

Write-Host "== Appartenenza Hyper-V Administrators =="
Get-LocalGroupMember -Group "Hyper-V Administrators" | Select Name, PrincipalSource

Write-Host "== Connettivita' porta Data Mover (es. 2501) =="
Test-NetConnection -ComputerName $HyperVHost -Port 2501

Write-Host "== Modulo Hyper-V =="
Get-Module -ListAvailable Hyper-V | Select Name, Version

Risoluzione per casi tipici

“Access is denied” durante la creazione del VHDX

ACL NTFS e permessi della share insufficienti → concedi Full Control all’account del servizio/Job.
Antivirus/EDR blocca la creazione → crea esclusioni per percorso e processi Veeam.
Ripristino verso percorso locale di un nodo cluster → usa il CSV condiviso.

“The system cannot find the path specified”

Percorso errato o volume non montato → valida il path e lo stato dei CSV.
Nome VM/percorso con caratteri non supportati → rimuovi caratteri speciali, accorcia il nome cartella.

“Not enough space on the disk” o fallimento in fase di resize

Il VHDX finale supera lo spazio disponibile → libera spazio o scegli VHDX dinamico.
Superamento dei limiti VHD (2 TB) → usa VHDX.

Errore in fase di attach al controller

VM Gen 1 con disco GPT/EFI → ricrea come Gen 2.
Disco di boot su SCSI in Gen 1 → sposta su IDE (Controller 0, posizione 0).
Controller SCSI saturo o posizione non disponibile → cambia numero di controller/porta.

La VM si avvia ma non vede il disco o cade in emergency mode

Mancano i moduli Hyper‑V nel kernel/initrd → ricostruisci initramfs (vedi sezione compatibilità).
/etc/fstab con device /dev/sdX rigidi → sostituisci con UUID/LABEL.
Secure Boot attivo su distro non firmata → disabilitalo temporaneamente.

Suggerimenti supplementari

Conversione offline: se il ripristino diretto continua a fallire, esporta prima il backup in VHDX con Export Disk Content as Virtual Disk di Veeam, quindi crea manualmente la VM in Hyper‑V e collega il disco.
Verifica generazione VM: per distribuzioni EFI/GPT usa una VM di Generazione 2; per BIOS/MBR resta su Generazione 1. Un mismatch genera tipicamente errori di modifica disco.
Snapshot differenziali: elimina snapshot residui prima del backup; catene troppo lunghe possono produrre dischi consolidati non accettati da Hyper‑V.

Procedure operative consigliate (end‑to‑end)

Scenario A: ripristino diretto con conversione automatica

In Veeam, avvia Restore to Microsoft Hyper‑V.
Seleziona host, percorso CSV/NTFS, e disattiva avvio automatico.
Verifica mapping dei dischi: per Gen 1 il disco di boot su IDE 0:0.
Esegui il job e monitora i log. In caso di errore, annota la micro‑fase e consulta la sezione specifica sopra.

Scenario B: export VHDX + creazione VM manuale

Esporta il disco in VHDX dal backup.
Crea VM in Hyper‑V con generazione appropriata.
Collega il VHDX esportato come disco di boot (IDE Gen 1 / SCSI Gen 2).
Prima accensione con Secure Boot disabilitato, poi riattivalo se supportato.
All’interno del guest, verifica driver, fstab e rete; quindi spegni e crea un checkpoint di sicurezza.

FAQ rapide

Posso ripristinare dischi > 2 TB? Sì, ma devi usare VHDX (fino a 64 TB). Con VHD sei limitato a 2 TB.

Convert‑VHD funziona con VMDK? No. Convert‑VHD gestisce conversioni tra VHD e VHDX. Per VMDK usa la conversione del restore Veeam, StarWind V2V o qemu-img.

Meglio dischi dinamici o fissi? Dinamici per rapidità e uso efficiente dello spazio; fissi se sospetti incompatibilità con lo storage o vuoi prestazioni predicibili.

Quando attivare Secure Boot? Solo dopo il primo avvio riuscito, e scegliendo il template adatto alle distribuzioni Linux moderne. In caso di dubbi, lascialo disattivato per il primo boot.

Perché vedo “failed to modify disk” anche se lo spazio sembra sufficiente? Quote, thin provisioning o blocchi di antivirus/EDR possono impedire la crescita del file VHDX durante la creazione.

Checklist finale (pronta all’uso)

Formato destinazione: VHDX, dimensione <= 64 TB.
Generazione VM coerente con MBR/BIOS (Gen 1) o GPT/UEFI (Gen 2).
Percorso CSV/NTFS corretto, ACL NTFS e permessi di share OK.
Connettività Veeam ⇄ Hyper‑V su porte 2500‑3300 verificata.
Storage con spazio sufficiente, senza quote/blocchi EDR.
Parametri del job puliti: niente mapping superflui, power‑on disabilitato.
Log analizzati: identifica la micro‑fase dell’errore.
In caso di persistenza: export in VHDX e creazione manuale della VM.
Alla prima accensione: driver Hyper‑V nel guest, initrd ricostruito se necessario, fstab con UUID.

Conclusione

“Failed to modify disk” è un errore generico che spesso nasconde una causa ben precisa: formato non supportato, percorso/permessi inadeguati, mismatch di generazione o limiti fisici del disco. Con la checklist e le procedure qui sopra puoi ridurre rapidamente il perimetro, correggere l’ostacolo specifico e completare la migrazione V2V da VMware a Hyper‑V con Veeam. Se dopo gli interventi suggeriti l’errore persiste, raccogli i log e coinvolgi il supporto: in alcuni casi esistono fix mirati già disponibili per scenari particolari.

Riepilogo dei suggerimenti supplementari

Preferisci VHDX e, quando non serve, evita passaggi di conversione aggiuntivi.
Usa Gen 2 per EFI/GPT e Gen 1 per BIOS/MBR: questa scelta da sola elimina molte anomalie di attach.
Riduci la complessità: niente network mapping iniziale, niente power‑on automatico.
Se incontri ancora l’errore, export → crea VM → collega disco è spesso la via più rapida al successo.

Con questa checklist dovresti individuare la causa concreta e completare il ripristino senza l’errore.