Eviter de bloquer une VM lors d'un commit

Rédigé par kriko - - Aucun commentaire

Vous désirez faire un commit sur une VM passée en REDO mais le fichier REDO a atteint une taille conséquente : pendant la durée du commit, la VM ne répondra plus.

Pour pallier cet inconvénient, il suffit de faire un second REDO (fichier .REDO.REDO) puis de faire un commit du premier fichier REDO dans le vmdk principal et enfin de faire un commit du second REDO (qui lui est petit) dans le vmdk.

Prenons l'exemple d'une VM /home/vmware/vm/vm.vmx avec un disque en scsi0:0 déjà en REDO. Le jeu de commande à passer est le suivant :

# vmware-cmd /home/vmware/vm/vm.vmx addredo scsi0:0
# vmware-cmd /home/vmware/vm/vm.vmx commit scsi0:0 1
# vmware-cmd /home/vmware/vm/vm.vmx commit scsi0:0

Explications :

  • La première commande va créer un fichier .REDO.REDO
  • La seconde commande va faire un commit du .REDO dans le vmdk. Ceci grâce à la présence du 1 dans la ligne de commande. Durant ce commit la VM ne sera pas figée car elle dispose du .REDO.REDO pour travailler. A l'issue de cette commande le .REDO.REDO est automatiquement renommé en .REDO
  • Enfin, la troisième commande va effectuer le dernier commit du petit .REDO créé au point 1

Cloner une VM

Rédigé par kriko - - Aucun commentaire
Le clonage d'une VM est relativement aisé. Vous pouvez le faire par Virtual Center avec l'option Clone mais ceci nécessite l'arrêt de la VM. De plus, Virtual Center a le défaut de masquer toute la partie sous-jacente des VMs. Ceci peut être génant lorsque vous avez mis en place certaines conventions de nommage pour les fichiers vmx et vmdk. La méthode que je préfère utiliser est la suivante. Elle concerne les VMs Windows. Pour les VMs Linux, la méthode reste valable. Je vais prendre l'exemple du clonage de la VM suivante :
  • Nom de la VM source : f098st56
  • Disques de la VM source : f098st56.disk0.vmdk et f098st56.disk1.vmdk
  • Nom de la VM cible : f098st57
Pour cloner f098st56 en f098st57, procéder comme suit :
  • Passer les disque f098st56.disk0.vmdk et f098st56.disk1.vmdk en mode REDO à l'aide de la commande vmkfstools addredo
  • Toujours à l'aide de vmkfstools, effectuer une copie des disques f098st56.disk0.vmdk et f098st56.disk1.vmdk respectivement en f098st57.disk0.vmdk et f098st57.disk1.vmdk.
  • Faire une commit des disques de la VM d'origine.
  • A l'aide de l'interface Web de VMware, créer une nouvelle VM nommée f098st57. Prendre bien garde à ne pas la connecter au réseau sans quoi, une fois démarrée, il y aurait un conflit de nom et d'adresse IP sur le réseau
  • Ouvrez une console et démarrez la VM f098st57
  • Si la VM faisait partie d'un domaine, repassez la en Workgroup
  • Utilisez ensuite l'utilitaire de Sysinternals newsid (voir la page des liens pour le télécharger) afin de changer le nom Netbios f098st56 en f098st57 et générer un nouveau SID. le changement de SID est impératif si vous êtes en Workgroup, il reste conseillé si vous êtes dans un domaine. Remarque importante : si le service Schedule de votre VM utilisait un compte spécifique pour le service AT, veillez à remettre le service AT sous le compte LocalSystem avant de changer le SID, sinon vous ne pourrez plus le faire après l'utilisation de newsid et les commandes AT ne se lanceront plus. Ceci est valable aussi si vous utilisez sysprep pour cloner des machines. Cf l'article Microsoft http://support.microsoft.com/kb/321204/en-us
  • Une fois le nom Netbios et le SID changés, donnez une nouvelle adresse IP à la nouvelle VM f098st57. Vous pouvez alors la reconnecter au réseau.
  • Faite une recherche dans le registre pour remplacer les entrées contenant encore f098st56 par f098st57.
  • Le cas échéant, réinscrivez la nouvelle machine dans le domaine

Empêcher VMware d'effectuer un COMMIT à l'arrêt d'une VM

Rédigé par kriko - - Aucun commentaire

C'est le piège : quand une VM a été passée en mode REDO à chaud (par la commande vmkfstools addredo), le commit est implicite lors de l'arrêt de la VM ! Ceci peut être très génant si l'on ne veut justement pas conserver les modifications apportées à la VM depuis le passage en mode REDO. Deux méthodes permettent d'empêcher le commit tout en arrêtant la VM :

La méthode brutale :
Faire un ps -eafwww | grep "" et relever tous les process associés à la VM. Voici typiquement le résultat de la commande :

[root@esx29801 root]# ps -eafwww | grep "f098st42.vmx"
UID  PID  PPID C STIME  TTY TIME   CMD
root 9885    1 0 Mar 28 ? 00:15:16 /usr/lib/vmware/bin/vmware-vmx ...
root 9886 9885 0 Mar 28 ? 00:00:18 vmware-mks -A 11 -D 13 -S -L ...
root 9893 9885 0 Mar 28 ? 00:00:00 /usr/lib/vmware/bin/vmware-vmx ...
root 9894 9893 0 Mar 28 ? 01:11:39 /usr/lib/vmware/bin/vmware-vmx ...

Il ne reste plus qu'à faire un kill -9 des PIDs, puis de supprimer le fichier .REDO et le tour est joué

Méthode douce :

Faire un REDO de REDO. Autrement dit repasser une commande vmkfstools addredo. Ceci va créer un fichier .REDO.REDO. Ensuite, arrêter normalement la VM. Le .REDO.REDO est commité dans le .REDO et le fichier .vmdk principal n'est pas affecté. La VM étant arrêté, vous pouvez alors supprimer alors le fichier .REDO restant puis la redémarrer.

Effectuer un COMMIT à chaud

Rédigé par kriko - - Aucun commentaire

Utilisez la commande vmkfstools avec l'option commit. A noter que pendant la phase de commit, la VM ne répond quasiment plus. Si le fichier REDO est d'une taille conséquente, la VM pourra apparaîtra comme bloquée pendant un certain temps donnant l'illusion qu'elle est plantée. La syntaxe de la commande commit est la suivante :

vmkfstools <fichier_vmx> commit <scsi_id>
  • <fichier_vmx> est le nom du fichier de configuration de la VM (avec son chemin complet) ;
  • <scsi_id> représente l'entrée scsix:y présente dans le fichier de configuration à laquelle est rattachée le disque que vous voulez passer en mode REDO ;

Par exemple, pour la VM configurée dans /home/vmware/vm1/vm1.vmx et le disque situé en ID 0:0, passez la commande suivante :

vmkfstools /home/vmware/vm1/vm1.vmx commit scsi0:0
Fil RSS des articles de ce mot clé