VMFS on Zwindler's Reflection

Hack : diminuer la taille du VMDK d’une VM Linux LVM

Wed, 14 Mar 2018 12:45:43 +0000

Réduire un VMDK

Note : cet article n’est pas écrit par moi mais par mon ami et ancien collègue Steve aka ventreachoux85 (ahahah faut assumer maintenant Steve), que j’héberge avec grand plaisir sur le blog :-)

Note 2: Comme toute opération sur des disques, des partitions, des filesystems, elles sont à faire avec des backups préalables. Cette opération est dangereuse et est à vos risques et périls => vous voilà prévenus.

Sur un serveur Linux (CentOS 6.9 pour la petite histoire) hébergé sur un serveur VMware, je souhaite réduire la taille de mon disque virtuel de 75 Go car la volumétrie ne va pas bouger. S’il est simple d’agrandir un disque virtuel sous VMware, le réduire est une autre paire de manches !

Si la machine avait été un serveur Windows, voilà ce que j’aurai fais :

Réduction du volume depuis l’utilitaire de gestion de disques
Modification de l’extent description directement sur le fichier .vmdk depuis l’ESXi (en SSH)
Migration de la VM sur un autre datastore => elle aurait eu la taille voulue à l’issue de l’opération

Je ne détaille volontairement pas cette procédure car celle qui suit est similaire et nous allons prendre le temps de tout voir.

Et donc du coup, là c’était pas pour des windows, mais pour des machines sous Linux ! J’ai demandé son avis à zwindler, qui m’a demandé en échange de rédiger une petite procédure pour le blog ;-)

Réduction du FS

Voilà donc à quoi ressemble les disques de mon serveur avant l’opération :

Dans mon cas, je n’ai pas besoin de réduire les Filesystems, j’ai déjà beaucoup de PE de disponibles. S’il avait fallut le faire, on aurait été obligé de réduire les FS à froid (dans le cas ext*), voire même de passer par un liveCD si on avait du redimensionner « / » ou un autre FS vital pour l’OS.

Réduire un VMDK partitionné pour du LVM

Le problème avec la commande pvs est que la taille utilisée et la taille disponible est arrondie pour être au format « human readable » d’Unix. Idéalement, il nous faut une mesure exacte pour redimensionner au plus juste.

Une des manières simples de le faire est d’utiliser l’unité « secteur » de la commande pvs (512 octets). Il faut faire la différence entre le PSize et le PFree pour avoir la taille définitive du disque :

Après un rapide calcul, si je veux réduire le disque de tous les PE disponibles :

209453056 – 164757504 = 44695552

La nouvelle taille du PV sera de 44965552 secteurs

Note de zwindler : Personnellement j’aurai laissé quelques PE, par habitude (limitations de LVM1 pénibles quand il n’y a plus de PE) et parce que je suis un froussard, mais a priori « ça marche ».

On redimensionne le disque

A noter, malgré le fait qu’on ait spécifié qu’il ne devait pas rester de PE de libre, a priori il en reste quand même quelques uns. Je ne sais pas si c’est une sécurité du pvresize ou si c’est lié aux arrondis et à la taille d’un PE sur ce PV. C’était une erreur de calcul (cf voir les commentaires).

Pour vérifier que tout va bien, un petit pvscan/vgscan.

Réduire la partition

A partir de là, ça se corse. On a réduit sans trop de difficulté le PV qui héberge nos LV, mais il nous reste maintenant à réduire la partition qui héberge ce PV. Même si théoriquement on peut le faire à chaud, zwindler m’a conseillé de faire ça à froid.

Pour autant, si vous vous sentez l’âme d’un aventurier et/ou avec un OS récent et/ou que vous n’avez pas le choix, vous pouvez toujours aller lire ce post sur Ask Ubuntu.

Le plus safe est quand même d’arrêter la VM puis booter sur un liveCD avec GParted.

Clic droit sur la partition à modifier – désactiver (sinon impossible de la redimensionner)

Sélectionner la partition puis Redimensionner / Déplacer

Attention : lors du premier redimensionnement, GParted ne prend ne réduit pas au maximum la partition. Il reste 2 Go qui sont inutilisés.

On lance un nouveau redimensionnement pour récupérer la place disponible !!

Note de zwindler : moi j’aurai laissé comme ça ;-)

ATTENTION

On voit que /dev/sda2 fait 21.44 Go après le pvresize (cf. screenshot précédent). En essayant de réduire au maximum la place utilisée, on peut tout casser (expérience vécue !!!). Pour plus de sécurité, je conseille de resizer à l’entier supérieur (donc dans notre exemple 22 Gio soit 22528 Mio)

Redimensionner le VMDK

Maintenant que le disque est modifié au niveau de l’OS, il faut le redimensionner au niveau de VMware.

Et là, rebelote : c’est pas « simple » à faire. En effet, VMware ne supporte pas la réduction des VMDK (que ce soit à chaud ou à froid).

Note: You cannot shrink virtual disks using vmkfstools in ESXi as the hypervisor is not aware of the file system layout and cannot ensure a safe shrink operation.

Heureusement, des petits malins ont trouvés la technique depuis bien longtemps :

Se connecter en SSH sur l’ESX qui héberge la VM, se rendre dans le dossier de la VM et faire un vi sur le fichier NomVM.vmdk, qui est un fichier texte (configuration), contrairement au fichier NomVM-flat.vmdk qui contient les données réelles.
Modifier la valeur suivante :

# Extent description
RW 209715200 VMFS "testsba-flat.vmdk"

La nouvelle valeur du paramètre extent description sera « 22 GB = 22 x 1024 x 1024 x 1024 / 512 (octets/secteur) = 46137344 secteurs »

# Extent description
RW 46137344 VMFS "testsba-flat.vmdk"

Déplacer la VM vers un autre Datastore

A partir de là, vous vous dites : « cool ! j’ai récupéré l’espace disque ». Et vous êtes déçus car rien ne se passe.

En effet, ce paramètre n’est pris en compte que lors de la création du disque, lorsque le fichier contenant réellement les données (le fameux NomVM-flat.vmdk dont je vous ai parlé plus tôt) est créé. Vous pouvez mettre n’importe quoi, ça ne changera rien du tout.

Cependant, si vous avez la licence qui va bien sur votre cluster, vous pouvez feinter le cluster pour lui faire recréer un disque à chaud de la bonne taille avec un simple Storage vMotion.

Avant le Storage vMotion :

Après le Storage vMotion :

Pourquoi ça marche ?

Petit aparté de zwindler : Pour bien comprendre ce qu’il se passe, il faut comprendre comment marche un Storage vMotion. Au moment où vous demandez à VMware de déplacer un disque d’un datastore à l’autre, voici l’enchaînement des opérations :

Prise d’un snapshot du disque initial
Création d’un disque sur le datastore cible. Ce disque est identique au disque initial au moment du snapshot via la commande vmkfstools. Cette commande relis la valeur contenu dans extent description pour savoir quelle taille le fichier doit faire physiquement, ce qui nous permet de feinter VMware et d’avoir un disque à la bonne taille._
_
L’ensemble des IO depuis le snapshot sont écrites simultanément sur les deux datastores, ce qui permet d’avoir 2 copies identiques au moment de la fin de la copie du snapshot
Migration de la VM sur le nouveau disque
Suppression de l’ancien disque hébergé par l’ancien datastore

Note de zwindler : j’étais persuadé d’avoir fais un article là dessus (et en fait pas du tout) mais il est évidemment possible de faire la même chose à la main sans Storage vMotion, simplement avec vmkfstools à la main.

Boot de la machine

Pour finir, une fois la VM bootée, il reste encore une petite opération de maintenance à réaliser. Il y a une petite différence de nombre de secteurs suite au redimensionnement.

Il suffit de faire un pvresize avec le nombre de secteurs indiqué par la commande pvs précédente :

Tout est dorénavant OK :

[Tutoriel] Récupérer l’espace non réclamé via l’API VAAI de VMware et l’instruction UNMAP

Sat, 19 Mar 2016 11:30:55 +0000

Contexte

La plupart des solutions de stockages estampillés Entreprise sont certifiés pour fonctionner de manière optimisée avec VMware, via l’API VAAI (baies EMC², HP, etc, mais aussi des solutions logicielles comme Datacore et même certains NAS Synology/QNAP/…).

Cette API permet entre autre d’accélérer les performances de certaines opérations d’exploitation, comme par exemple la copie de machines virtuelles ou le déploiement de templates. Elle permet également à VMware d’indiquer au stockage (à la baie de disques par exemple) qu’un Datastore (un ou plusieurs LUN) dispose de blocs qui ont été libérés.

Ceci est particulièrement utile dans le cas où le LUN est en Thin Provisioning, car dans ce cas là, de l’espace précédemment consommé peut être libéré côté baie via l’instruction UNMAP.

Exemple

On dispose d’un LUN de 500 Go en Thin Provisioning, présenté à un serveur VMware. On a créé un Datastore dessus et ajouté un VMDK qui prend 100 Go. Comme le LUN est en Thin provisioning, seul 100 Go (environ) est réellement utilisé sur la baie de disques.

Imaginons maintenant que le VMDK est supprimé du Datastore. Côté VMware, le Datastore sera bien vu comme vide car le VMDK a été détruit. Par contre côté baie de disques, le LUN fait toujours 100 Go car la baie de disques n’est pas « au courant » de la libération de l’espace pris par le VMDK.

On peut se connecter sur le serveur VMware pour réclamer cet espace disque en envoyant à la baie de disques une commande VAAI UNMAP.

Procédure de réclamation de l’espace disque

Pour une baie EMC de type VNX 5X00 et un LUN de 1500 Go. Le LUN fait 1460 Go sur la baie, pourtant beaucoup d’espace a été libéré sur le Datastore.

En se connectant en SSH sur un VMware, on lance la commande suivante :

esxcli storage vmfs unmap -l MONDATASTOREANETTOYER

Au bout que quelques minutes (peut durer longtemps si il y a beaucoup d’espace à réclamer), l’espace commence à se libérer :

Plus d’information sur le site de VMware

kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2057513 (lien mort, comme tout chez VMware)
kb.vmware.com/selfservice/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalId=2014849 (lien mort, comme tout chez VMware)
kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2057513 (lien mort, comme tout chez VMware)
lien mort, j’utilise Internet Archive

vSphere 6.0 : Volumes VMFS désapprouvés

Sat, 31 Oct 2015 11:30:57 +0000

Symptômes

Si vous venez de passer à vSphere 6.0 comme moi, vous êtes peut être tombés sur le bug suivant. Dans un cluster vCenter, vous ajouter une datastore à partir d’un LUN que vous venez de créer. Celui ci est bien créé dans la toute dernière version (5.61), mais pour une raison inconnue, un avertissement « VMFS désapprouvés » apparaît sur tous les autres membres du clusters.

ou en anglais (l’erreur me semble souvent plus parlante en anglais chez VMware … c’est assez énervant) :

Pourtant nous sommes bien dans la dernière version, le datastore est bien visible sur tous les serveurs et même utilisable sans soucis.

Et bien ne vous fatiguez pas, c’est effectivement un bug, référencé par le KB suivant (lien mort).

Mais …

Currently, there is no resolution.

Ah ben cool sympa merci !

Contournement

En fait, ils donnent quand même une astuce pour contourner le problème, mais on ne peut pas dire que ça soit particulièrement pratique à mettre en place. En effet, l’erreur disparaît si vous redémarrez les agents de management de l’hôte.

Déjà, ça veut dire que vous devez passer sur TOUS vos serveurs et appliquer la procédure un par un (on peut le faire de différentes manières, notamment par ssh donc …), mais surtout, votre hôte devient temporairement inaccessible et donc c’est potentiellement problématique (surtout dans un cluster!).

Pour rappel, voici le KB (lien mort) qui liste les méthodes pour le faire. Moi je l’ai fais via la console (en iLO).

Sinon vous pouvez le faire par ligne de commande comme ceci :

/etc/init.d/hostd restart
/etc/init.d/vpxa restart

En attendant mieux, il va falloir faire avec. Je ne manquerait pas de vous donnez la solution si VMware venait à réagir dans les prochains jours, mais il est fort à parier que cela passera par un patch à appliquer sur vos serveurs.

Lire du VMFS en Java, mais en prenant un peu de recul

Sun, 31 Oct 2010 18:14:33 +0000

Dans mon précédent article, j’ai parlé de la possibilité de lire des partitions VMFS depuis n’importe quel OS capable de faire fonctionner du java un peu récent, à l’aide d’un driver libre pour le VMFS (v3).

Pour introduire l’utilisation de ce driver, j’avais parlé de mon cas personnel. Pour rappel, je dispose d’un vieux disque encore partitionné en VMFS, mais je n’ai plus le serveur ESX(i) pour le lire. Je m’étais extasié devant la possibilité de brancher un disque dur sur un port USB de n’importe quelle machine Linux/Windows, et de pouvoir explorer le contenu de mon disque dur, ce qui serait bien utile dans mon cas.

Cependant, je m’étais ensuite posé la question quant à l’utilité d’un tel driver pour les professionnels. Contrairement à mon disque tout simple, les pros disposent souvent de stockages montés en RAID pour héberger leurs disques en VMFS. Le fait que l’on ne puisse pas de façon simple/pratique pour brancher sur USB une grappe RAID sortant d’un serveur ou d’une baie SAN qui vient de cramer m’avait un peu refroidi. Mais ce n’est que parce que j’avais mal lu…

Et bien en relisant d’un peu plus près les possibilités offertes par l’outil, j’ai réussi à trouver l’information qui me manquait pour justifier l’utilité d’un tel projet (il est quand même un peu conséquent, en termes de travail). Non seulement le driver est capable de lire n’importe quel volume qui a été monté sur votre système, mais il semblerait bien qu’il soit également capable de lire (nous parlons bien lecture seule) les volumes VMFS accessibles via SSH.

Et là forcément, l’outil prend tout son sens. Un article (sur vmforensics.org qui n’a malheureusement jamais été sauvegardé par Internet Archive) parlant de tout cela beaucoup mieux que je ne pourrais le faire (n’ayant plus de serveur ESXi sous la main pour le moment).

Enfin, pour les gourmands (ou les fous furieux?), voici comme promis le hotfix du jar de fluidops, avec l’ajout d’une fonctionnalité dans la CLI qui permet de copier le contenu complet d’un dossier, l’équivalent d’un cp -r (ici). Cela pourrait être pratique pour des personnes qui voudraient copier en une seule commande l’ensemble des fichiers d’une machine virtuelle (et sans utiliser le serveur WebDAV).

Attention tout de même! Cette version n’est pas une version officielle. J’ai modifié moi-même les sources (r95) sur code.google.com/p/vmfs/, et j’y ai ajouté la fonction recursefilecopy. Même mise en garde que d’habitude : je ne suis pas responsable de problèmes qui résulteraient de l’utilisation/la mauvaise utilisation de ce jar. Ceci étant dit : « Chez moi, ça marche », comme dirait l’autre…

Lire du VMFS en Java, ou comment récupérer des VMs stockées dans un serveur Kapout

Wed, 20 Oct 2010 13:43:51 +0000

Qui n’a jamais rêvé de disposer d’un outil vous permettant de lire du VMFS, cet obscur file system qui ne semble être supporté que par ESX et ESXi? Peut être que ce genre de problématiques ne concerne pas grand monde, tout compte fait ;-)

Mais pour ceux qui se sentent concernés, voici un petit lien vous conduisant sur un projet Java contenant un « driver » pour lire le VMFS (v3). Je ne l’ai pas testé sous tous les systèmes qui font tourner Java (100% des OS un peu récents?) bien entendu, mais ça a plutôt l’air de bien marcher (au moins sous Linux et Windows 7, avec un JRE à jour).

Comme indiqué sur le site, la version r95 du driver permet de naviguer dans l’arborescence, d’afficher les fichiers et les dossiers (récursivement ou non), d’afficher des informations sur un fichier précis, et de copier un fichier vers le disque local. Et en bonus track, il est également capable de s’interfacer avec un serveur WebDav qui permet d’explorer et/ou carrément de monter le disque sur certains OS (non testé, je n’y connais rien en WebDav)

The VMFS volume can then be browsed using any HTTP browser, or it can be mounted as a file system on many operating systems.

Petit « détail » auquel je n’avais pas vraiment pensé initialement, mais l’opération se corse probablement pas mal si vous disposez d’un quelconque RAID (100% des pros?), puisqu’il devient pratiquement impossible de brancher le disque bêtement avec un adaptateur USB, comme je l’ai fais moi avec mes VMs sur mon stockage non redondé.

J’imagine qu’il est alors nécessaire de monter les disques en RAID tels qu’ils l’étaient sur la machine voulue, et je ne suis même par certain que cela soit trop possible (je devrais me pencher un peu sur le fonctionnement du RAID, je ne connais que la théorie…).

Pour info, j’avais un disque dur qui contenait mes VMs sous ESXi, que je voulais garder sous le coude, au cas où je voudrais les refaire fonctionner dans un Workstation ou de nous sous ESXi (j’ai bêtement activé une licence 2k3 r2 et une autre 2k8 r2 sur mes VM, juste avant de passer sous XenServer). Je l’ai branché sur un boitier disque dur SATA/USB, et j’ai pu naviguer en ligne de commandes dans mon disque, et copier des fichiers sur le disque local instantanément.

Pour ceux qui auraient un peu de mal à suivre les indications d’aide sur le site du projet, voici un petit walkthrough sous Windows. Je rappelle qu’il est nécessaire d’avoir au moins votre client java à jour, ce que tous le monde devrait faire tout le temps, mais bon…

Récupérez le disque à explorer, et le brancher sur un adaptateur SATA/USB
Ouvrez un interpréteur de commande (cmd.exe pour les « old school », Powershell pour ceux qui veulent se la péter ;-p)
Récupérez le numéro du disque par rapport à l’OS. Pour se faire:
- tapez « diskpart » dans votre interpréteur de commandes
- puis « list disk »
- le résultat retourné devrait être la liste des disques vus par le système, et vous devriez voir votre disque
- notez son numéro (qu’on appellera [X])
Placez vous dans le dossier contenant le JAR du projet, puis tapez la commande « java -jar fvmfs.jar .PhysicalDrive[X] [commande] »

Remplacez évidemment [commande] par la commande du CLI que vous souhaitez utiliser :

« dirall / » vous renverra l’ensemble de l’arborescence de votre disque
« filecopy [fichier_source] [fichier_destination] » vous copiera le fichier situé sur votre VMFS au chemin [fichier_source] vers le chemin [fichier_destination] sur votre disque local

La seule chose que je n’arrive pas à comprendre c’est pourquoi ils n’ont pas ajoutés quelques commandes simples comme « copier l’ensemble du disque sur un emplacement local ». On a rarement besoin d’UN seul fichier quand on sauve une VM (composée de fichiers vmdk/nvram/vmsd/vmx/vmxf/…). D’autant plus que le JAR dispose pourtant de toutes les commandes de bases qui permettraient de faire « facilement » cette commande (notamment dirall sur la cible de la copie, puis une boucle avec filecopy)!

Si j’ai un peu de temps, je pense que je jetterai un œil aux sources, pour voir si je ne peux pas patcher leur jar. En attendant que je prenne la peine de réinstaller un environnement de développement Java, voici un script TRES SALE en PowerShell qui fait la même chose ici.