Questo post è disponibile anche in: Inglese

Una delle possibili complicazioni nell’uso dei dischi vmdk di tipo thin è che sono dischi che crescono solo. Ovviamente crescono quando aggiungete dati, ma se ne cancellate, il vmdk non si riduce mai. Questo “problema”, a dire il vero, è più legato ai sistemi operativi guest e a come gestiscono il filesystem: quando un file cancellato, solo i suoi metadati (o parte di essi) sono rimossi, ma i blocchi dati rimangono (ovviamente potranno essere sovrascritti da nuovi file).

Di fatto lo spazio occupato che si vede dal sistema operativo guest difficialmente corrisponderà a quello che si vede a livello di VMware guardando lo spazio usato dal vmdk (questo di solito sarà più grosso).

L’unico modo documentato per ridurre lo spazio di vmdk thin è quello di riempire i blocchi liberi del filesystem guest con zeri (per Windows si può usare sdelete e per Linux il comando dd) e quindi sfruttare una storage migration (a freddo oppure a caldo con lo Storage vMotion) per spostare i file della VM da un datastore ad un altro. Per maggiori informazioni vedere:

Questa tecnica però presenta alcuni vincoli che potrebbero rivelarsi veri e propri problemi: servono almeno due datastore (ma anche abbastanza spazio per contenere la copia dei file della VM), per l’operazione a caldo servono le “costose” versioni Enterprise o Enterprise+ editions (le uniche che includono lo Storage vMotion), questa operazione richiede risorse di calcolo e di I/O (anche se con il VAAI queste possono essere ridotte in modo significativo).

Ma c’è anche un altro grosso requisito, senza il quale la procedura non funziona: in vSphere 4.x i due datastore devono avere un block size different! Il motivo è spiegato chiaramente nel blog di Duncan Epping in un post specifico (Blocksize impact?) ed è legata alla nuova architettura dei datamover (in particolare fs3dm) introdotta con vSphere 4.0.

E cosa succede con vSphere 5.0? Dalle prove che ho fatto (ma come del resto confermato anche dallo stesso Duncan negli ultimi commenti del citato post) sembra proprio che vi sia lo stesso requisito! Anche nel caso dei datastore formattati con VMFS5!

Solo che in questo caso si aggiunge un altro problema: nei datastore VMFS5 creati da zero il block size è unificato e fisso a 1MB. Quindi la procedura di reclaim dello spazio NON funzionrebbe mai. Anche provando tra VMFS3 e VMFS5, forzando la conversione al formato thin, provando a passare prima a thick e poi a thin… il risultato non cambia… se il block size è lo stesso non c’è alcun reclaim.

E quindi se soluzioni vi sono? Personalmente vedo solo questi possibili workaround:

  • Utilizzato il “trucco” suggerito da William Lam (sempre nel post precedente): impostare temporaneamente a 0 il parametro avanzato (e nascosto) /config/VMFS3/intOpts/EnableDataMovement (usando SSH e il comando vsish presente sugli host). In questo modo verrà utilizzato il vecchio datamover.
  • Creare un datastore VMFS3 (si può fare anche da ESXi 5) con un block size maggiore (e poi se serve convertirlo a VMFS5).
  • Non usare i dischi thin o non preoccuparsi della corrispondenza dello spazio usato.
  • Usare il VMware Standalone Converter per realizzare un V2V a livello di volume (con però il problema del downtime richiesto e possibili altri piccoli problemi, come il cambio di MAC address e UUID della VM).
  • Usare datastore NFS anziché quelli a blocchi basati su VMFS.
Andrea MauroAbout Andrea Mauro (2794 Posts)

Virtualization, Cloud and Storage Architect. Tech Field delegate. VMUG IT Co-Founder and board member. VMware VMTN Moderator and vExpert 2010-18. Dell TechCenter Rockstar 2014-15. Microsoft MVP 2014-16. Veeam Vanguard 2015-18. Nutanix NTC 2014-18. PernixPro 2014-16. Several certifications including: VCDX-DCV, VCP-DCV/DT/Cloud, VCAP-DCA/DCD/CIA/CID/DTA/DTD, MCSA, MCSE, MCITP, CCA, NPP.


Related Post:

Share