A propos des Storage Policies / Storage Capabilities sur vCenter et vCloud Director (MAJ)

A l’occasion de la sortie de vSphere 5.5, j’ai eu l’occasion de commencer les tests préparatoires à la migration de notre production vers cette nouvelle release. A ce sujet, j’ai été confronté à de nombreuses difficultés autour des Storage Policies et Storage Profiles, que nous utilisons pour spécifier les classes de service au niveau stockage sur notre vCloud Director (lui aussi à passer en 5.5). D’autre part, historiquement, comme beaucoup, et malgré les préconisations de VMWare, nous utilisons encore souvent le VMWare Client, certes assez lourd en mémoire, mais tout de même beaucoup plus efficace (et encore obligatoire pour Update Manager par exemple).

La combinaison de ces deux facteurs (utilisation historique de VMWare client et migration en 5.5) m’a conduit à découvrir un “bug” ou en tout cas un problème à prendre en compte AVANT de migrer une infrastructure pilotée, même en partie, par vCloud Director. En effet, nous utilisons donc les “Storage Capabilities”, des mots-clefs créés de toutes pièces (Gold, Silver, Bronze, par exemple) et affectés aux datastores pour spécifier nos classes de service stockage sur le vCloud. En vCloud Director 5.1 et vCenter 5.1, pas de souci, les infos étaient remontées correctement sur vCloud et nous pouvions les utiliser dans le paramétrage des Providers VDC.

Pour rappel, ces mot-clefs “Storage Capabilities” sont créés dynamiquement lorsque vous utilisez la fonction contextuel à un datastore ou une cluster DRS “Assign User-defined Storage Capability” :

… ensuite, vous les associez à des Storage Profiles, afin d’obtenir un profil de correspondance avec les datastores (et donc ses capacités de stockage).

Vous noterez que tout ceci est issue de l’interface du client lourd historique VMWare.

Or, depuis la migration en 5.5, visiblement, vCloud Director n’est plus capable de remonter ces Storage Profiles directement issus des mot-clefs Storage Capabilities. Si vous ne migrez pas votre vCenter et que vous commencez par vCloud Director, dans un premier temps (c’est l’ordre logique d’ailleurs), tout semble continuer à fonctionner normalement pour l’existant. Mais première surprise, si vous tentez d’ajouter un nouveau Provider VDC sur votre vCloud, vous noterez que tous les Storage Profiles non encore utilisés sur vCloud sont désormais absents, lors de la sélection des capacités de stockage.

Cela empire ensuite lors de la migration de votre vCenter : tous les Storage Profiles historiques disparaissent, purement et simplement ! Bien embêtant, pour dire le moins, si vous souhaitez faire des modifications ensuite. Encore plus embêtant, le vCloud director refuse ensuite toute opération sur une vApp provisionnée sur un VDC adossé à ces Storage Profiles ! En gros, vous êtes bloqués !

A posteriori, l’analyse que j’en ai, est que les storage profiles déclarés via le VMWare client utilisent la mécanique des mots-clefs “storage capabilities”, qui n’est pas reprise/pas compatible avec vCenter 5.5. En effet, dans l’interface web vCenter par contre, on retrouve bien tous nos petits historique ainsi que “la nouvelle mécanique” de gestion de ces classes de service, qui utilisent désormais le système de “tagging” générique, introduit avec vCenter 5.1 (si ma mémoire est bonne). Je n’ai pas encore fait l’exercice de supprimer et recréer directement les storage profiles (via la nouvelle méthode des tags) pour voir si vCloud retrouve ses petits.

Pour utiliser le nouveau système, vous devez désormais aller sur chaque datastore via l’interface web et associer “un tag” à celui-ci :

… puis ensuite aller créer une “Storage Policy” et l’associer à ce tag. C’est le même principe que précédemment, mais via l’interface Web. Or, cela ne doit pas renseigner les mêmes tables vCenter et induire une confusion lors de la migration.

En attendant de nouvelles infos, je vous conseille vivement d’être extrêmement vigilent quand à vos profils de stockage sur vCenter AVANT de migrer votre système. Un petit appel à VMWare ne ferait pas de mal pour en savoir plus. C’est d’ailleurs ce que je viens de faire. Je vous tiendrai au courant des réponses que j’aurai pu récupérer à ce sujet.

Accessoirement, sachez que pour pouvoir m’en sortir, j’ai été contraint d’aller faire du ménage directement dans la base vCloud Director, pour récuperer un portail “cohérent” avec le vCenter. En effet, vCD est particulièrement susceptible quand une décohérence existe entre les données du vCenter et ses propres infos (le “force delete” n’existe pas vraiment dans l’interface …).

Et pour finir, une dernière illustration pour bien comprendre que les deux versions de vCenter sont visiblement cablées différemment de ce coté là :

Home Page d’un vCenter 5.1, vous notez la section “Storage Profiles”

Home Page d’un vCenter 5.5, vous notez la section “Storage Policies”

MAJ : Après quelques allers/retours VMWare, il semble que le problème soit connu de VMWare et en cours d’investigation ! De plus, j’ai bien eu la confirmation que la méthode de gestion des storage profiles/policies a bien changée complètement avec vCenter 5.5, comme je le pressentait. Un petit KB chez VMWare, qui décrit le bug.