While searching around I stumbled on a post Seagate's Seek Error Rate, Raw Read Error Rate, and Hardware ECC Recovered SMART attributes. In this post, the author explains that all the values are actually 48 bits, and due to the way they are encoded it follows that those values are large. More specifically, raw value of the Seek error rate attribute should be converted to hexadecimal and then upper 16 bits are number of errors, while lower 32 bits are total number of seeks.

In this concrete case the raw value for Seek error rate is 17262017054, or 0x000404E57A1E. The first 16 bits is 0x0004 and the last 32 bits are 0x04E57A1E. What this means is that there were 4 seek errors (meaning the head wasn't positioned correctly after being moved to some track) but there were 82147870 seeks in total. So, this is very very small fraction of errors.

Ooooook. Sur un disque dur Seagate, une valeur positive pour l'attribut SMART « Raw Read Error Rate » ou pour l'attribut « Seek Error Rate » ne signifie pas forcément que le disque commence à aller mal…

Dans le monde de la virtualisation, il y a deux types d'image disque :

• Image statique / pré-allouée / thick provisioning : sur le support de stockage, le fichier image occupe réellement l'espace disque attribué à la machine virtuelle. Un disque dur virtuel de 50G occupe réellement 50G, même si la machine virtuelle n'utilise réellement que 5G d'espace. Avantages : les performances accrues et la prévisibilité de l'occupation des supports de stockage ;
  
  
• Image dynamique / sparse image / thin provisioning : sur le support de stockage, le fichier image occupe réellement l'espace maximal utilisé par la machine virtuelle. Si notre machine virtuelle a un disque dur de 50G mais n'en a toujours utilisé que 5G tout au plus, le fichier image occupera 5G. Attention : si la machine utilise 15G puis redescend à 5G, le fichier image occupera toujours 15G. Cette faculté repose sur une fonctionnalité des systèmes de fichiers modernes : les fichiers sparses / comportant des zones vides. Avantage : réduction des coûts par densification et flexibilité, il est possible d'allouer plus d'espace que ce dont on dispose en réalité sur les supports de stockage donc on peut créer plus de machines virtuelles sur un même hyperviseur… en espérant que toutes les machines virtuelles ne réclament pas le max qu'on leur a attribué sinon ça va trèèès mal se passer tendance crash des machines virtuelles voire corruption de fichiers.

Dans les deux cas, il est possible d'accroître la taille d'une image disque après coup : d'abord dans les paramètres de la machine virtuelle sur l'hyperviseur, puis à coup de gparted ou autre outil de gestion de disques à l'intérieur de la machine virtuelle, et enfin au niveau des systèmes de fichiers.

En passant, à l'intérieur des machines virtuelles, le plus flexible est d'utiliser une seule partition avec du LVM. Ainsi, accroître la taille du volume logique pris entre deux autres volumes logiques ne nécessite pas de déplacer les données (ce qui est une opération chronophage est risquée si l'opération est interrompue) comme c'est le cas avec des partitions. J'enfonce des portes ouvertes ? Ce n'est pas encore acquis pour tout le monde en 2017.

Comment faire pour passer d'une image statique (thick) à une image dynamique (thin) avec VMware ?

Au préalable, il peut être intéressant de remplir de 0 l'espace disque non alloué de la machine virtuelle (ne pas réaliser l'étape comportant vmkfstools !). Ainsi, l'image thin n'occupera pas l'espace de l'image statique mais directement l'espace réellement utilisé par la machine virtuelle.

On éteint la machine virtuelle.

On active SSH sur l'ESXi. On se déplace jusqu'à l'emplacement des fichiers de la machine virtuelle : cd /vmfs/volume/<nom_banque_données>/<nom_machine_virtuelle>. Pour trouver ce chemin, rien de mieux que de regarder dans les paramètres de la machine virtuelle avec Vsphere client.

On effectue la conversion : vmkfstools -i <nom_image_disque>.vmdk -d thin <nom_image_disque>-thin.vmdk.

Avec le client Vsphere, on retire l'ancien disque de la machine virtuelle puis on ajoute le nouveau.

On démarre la machine virtuelle.

Si tout est OK, on peut supprimer l'image statique : rm <nom_image_disque>.vmdk.

Après avoir récupéré l'espace disque non utilisé dans un fichier qcow2 KVM, on voudrait récupérer l'espace disque non utilisé dans l'image disque d'une machine virtuelle fonctionnant sous VMware. Oui, je sombre dans la folie et la crasse.

Si le système virtualisé est un GNU/Linux

$ sudo -i
# apt-get install zerofree
# mount -o remount,ro /
# # Évidemment, ça ne va pas fonctionner

# echo u > /proc/sysrq-trigger

# zerofree -v /dev/sdXy

# poweroff

Évidemment, il faut faire ça pour toutes les partitions…

Si le système invité est un winwin

Il faut utiliser l'utilitaire sdelete. La dernière version en date, la 2.0, ne fonctionne pas : elle reste bloquée à 100 %. Il faut donc récupérer la dernière version fonctionnelle, la 1.61. N'oublie pas d'utiliser VirusTotal. Je mets à disposition une copie : sdelete 1.61.

Ensuite, on ouvre une console en administrateur (rechercher cmd, clic droit -> Exécuter en tant qu'administrateur) et on lance sdelete -z c:.

Attention : contrairement à zerofree, sdelete va remplir de 0 toooouuuut l'espace disque (et pas juste les blocks non alloués) donc le fichier image de la machine virtuelle va grossir jusqu'à atteindre la taille max de la partition !

Évidemment, il faut faire ça pour toutes les partitions…

À la fin de l'opération, on éteint la machine virtuelle.

Note : oui, au lieu d'utiliser sdelete, on aurait aussi pu démarrer la machine virtuelle sur un live CD GNU/Linux et utiliser la commande ntfswipe. Tout comme sdelete, ntfswipe fait monter l'espace disque utilisé par l'image disque à la taille de la partition, mais sdelete permet de maintenir le service en état de fonctionnement alors qu'un live CD interrompt immédiatement le service rendu par la machine virtuelle.

Sur l'hyperviseur

On active SSH sur l'ESXi, on s'y connecte puis on utilise la commande : vmkfstools -K /vmfs/volumes/<nom_banque_données>/<nom_machine_virtuelle>/<nom_image_disque>.vmdk. Pour trouver ce chemin, rien de mieux que de regarder dans les paramètres de la machine virtuelle avec Vsphere client. On attend et on démarre la machine virtuelle. \o/

Note : je ne sais pas comment cela se passe en présence de snapshots : je les ai supprimé avant de faire cette manipulation.