Sto lavorando presso un cliente a un progetto di rinnovo tecnologico della sua infrastruttura VMware. Attualmente, la piattaforma è basata su ESX 3.5 e vCenter 2.5, quindi parecchio arretrata. La fase di aggiornamenti vari non è un problema, se non che seguendo forse troppo alla lettera alcune raccomandazioni del passato, il cliente ha fatto un uso molto esteso dei dischi RDM fisici, volendo garantire prestazioni ottimali alle varie virtual machine.
Ho trovato quindi parecchie virtual machines con il disco di sistema in formato VMDK, a cui è abbinato un secondo disco (dedicato di volta in volta ai dati dei vari applicativi, principalmente database, application server o posta elettronica) in formato RDM, di tipo fisico.
Nell’ottica di implementare un completo piano di data protection completamente basato sulle librerie VADP di VMware, la soluzione suggerita è stata di convertire tutti quei dischi RDM in semplici VMDK. Con le ultime versioni di vSphere, non ci sono infatti differenze prestazionali per giustificare l’uso di RDM se non in presenza di cluster Microsoft o altre configurazioni che prevedono i dischi condivisi tra più VM, mentre di contro non si può fare una snapshot di disco RDM fisico, impendendone quindi il backup se non con degli agent installati direttamente nel Guest OS.
Per validare la procedura, e tranquillizzare il cliente, ho realizzato un piccolo test per documentare l’attività di conversione. Questa attività potrà essere fatta solo dopo aver aggiornato l’infrastruttura almeno a vSphere 4, dato che (in base alla KB1005241) una storage vmotion su ESX 3.5 di un virtual RDM non lo converte in VMDK, cosa che invece avviene con vSphere 4.0 e successivi.
Nel mio laboratorio, ho creato per prima cosa una semplice VM Windows 2003, con un disco primario vmdk da 20 Gb e un secondo disco RDM fisico da 5 Gb:
Per realizzare la conversione, sarà necessario un fermo della VM, bisogna quindi programmare bene la manutenzione in base ai servizi che la VM ospita.
Arrestata la VM, editiamo i suoi settings e rimuoviamo il disco RDM. Prendete nota del Virtual Device Node (0:1 nel mio caso), in seguito dovremo riconnettere il disco con lo stesso valore.
Selezioniamo l’opzione “Deletes files from datastore”. Non dobbiamo spaventarci: essendo un disco physical RDM, verranno unicamente cancellati i pointer e non il contenuto del disco stesso.
Andiamo quindi ad aggiungere un nuovo disco alla stessa VM, scegliendo nuovamente un device RDM disk e utilizzando la stessa LUN precedentemente rimossa:
Impostiamo questa volta il compatibility mode “virtual”, e scegliamo lo stesso valore di device node usato precedentemente. Questo fa in modo che il Guest OS veda il disco esattamente come prima.
Possiamo a questo punto riavviare la VM. Il fermo totale, facendo queste operazioni correttamente, sarà durato al massimo un paio di minuti. Successivamente, una storage vmotion permetterà di convertire il virtual RDM in VMDK senza ulteriori fermi della VM (da prevedere invece se non si possiede una licenza dotata di SVMotion):
