Ne déplacez jamais les SVMs, ces VMs de Services pour VMware NSX.
Ces VMs tierces très spécifiques fournissent des fonctions additionnelles, généralement réseau, à NSX.
Elles sont généralement attachées à un host, donc il paraît évident qu’on ne doit pas tenter de vMotion.
Ce qui paraît moins évident, c’est qu’il ne faut pas non plus faire de Storage vMotion, pour une raison pas vraiment expliquée (extrême sensibilité aux I/O disque figés quelques micro secondes en fin de déplacement ?).
Je me suis donc fait avoir, et en voulant réorganiser des datastores, j’ai provoqué un PSOD simultané sur les 4 ESXi d’un cluster ! Plus un host debout, donc plus une VM, et pour couronner le tout parmi ces VMs il y avait les firewalls permettant de joindre les VMs des autres clusters.
Bref, la panade…
Ce n’est pas vraiment documenté, ni chez VMware ni chez les éditeurs de ces VMs de service, si ce n’est dans un KB publié apparemment le 06 janvier 2016 et révisé le 27 janvier. C’est un bug actuellement sans solution.
https://kb.vmware.com/kb/2141410
Le contournement officiel ? Ne faire ni vMotion ni Storage vMotion lorsque la VM est active.
NSX et son écosystème ne sont visiblement pas encore matures…