Mar/1022

Les VMs en Debian sont officiellement supportés depuis vSphere, mais la mise à jour des VMwareTools ne reste pas si simple que dans une RedHat. Il faut d’abord supprimer les précédents VMwareTools et les modules chargées avant de lancer l’installation.

Voici les commandes pour la mise à jour des VMwareTools (ESX4.0 update1) d’une Debian 5 32bits:

dpkg --purge vmwaretools
rm -rf /etc/vmware-tools/
rm -f /lib/modules/2.6.26-2-686/misc/vm*
reboot

Après le redémarrage de la VM, lancer l’installation des VMware Tools

mount /media/cdrom0
cp /media/cdrom0/VMwareTools-4.0.0-208167.tar.gz .
tar -zxvf VMwareTools-4.0.0-208167.tar.gz
cd vmware-tools-distrib
./vmware-install.pl
vmware-config-tools.pl

Il ne reste plus qu’à répondre aux questions (normalement les valeurs par défaut) et redémarrer la VM pour que le status des VMware Tools des VMs Debian passe de « Out of Date » à « OK ».

Mar/1012
Par , Dans KB, VMware

Il m’est déjà arriver plusieurs fois que le CPU0 (celui du Service Console) d’un ESX sature à 100%.

En regarde plus en détail avec top, on constate que c’est le processus ftPerl qui sature le Service Console.

Ce problème existe sur des ESX en 3.0 et en 3.5 jusqu’à l’update 4 (peut être résolu depuis), il est lié un problème dans la configuration du Cluster.

Résolution:

  • le plus simple mais seulement temporaire, faire un « Reconfigure HA » sur cette ESX. Résolution temporaire car le problème reviendra plus tard.
  • la solution permanente est de créer un nouveau et de migrer les VMs et les ESX dans ce nouveau Cluster et supprimer l’ancien. Une KB existe chez VMware expliquant la recréation de Cluster.

Référence:

Mar/10100
Par Dans KB, VMware

En essayant de sauvegarder juste le disque système (scsi0:0) d’une VM avec Veeam Backup 4, j’ai eu un message d’erreur surprenant:

File <unspecified filename> is larger than the maximum size supported by datastore ‘<unspecified datastore>

Le disque système ne fait que 15 Go dans un VMFS de 500 Go (avec plus de 300 Go de libre). En plus du disque système j’ai un disque RDM (virtual) de 2 To.

Je pensais que le problème venait de la partie sélection de disque dans le Job de sauvegarde. Mais le problème est ailleurs, en effet un simple Snapshot sur la VM produit la même erreur.  Ce problème affecte les Snapshots et donc potentiellement tous les produits de sauvegarde.

L’explication:

vSphere a changé la manière dont sont gérer les Snapshots (et notamment les pré-requis). Le block-size du volume de destination du Snapshot est comparé avec la taille de disques de la VM. Dans mon cas, le block-size du VMFS de destination du Snapshot est de 2 Mo soit une taille maximum de 512 Go alors que mon RDM fait 2 To.

Cf. la KB 1012384 de VMware

Résolution:

  • Soit mettre le disque RDM en mode Indepent, mais il ne pourra pas être sauvegardé.
  • Soit déplacer (avec SVmotion) toutes les VMs de ce VMFS, le supprimer, le recréer avec un block-size supérieur, enfin faire revenir toutes les VMs sur le VMFS.
Mar/10100

Microsoft propose un Lab en ligne pour tester l’implémentation de XenDesktop 4 sur Hyper-V R2.

Il est disponible à l’adresse: https://cmg.vlabcenter.com/default.aspx?moduleid=281742e3-2613-42da-bd58-2c3578f039b4

Le Lab dure 1h30, ce qui est trop court pour s’amuser mais ca permet de voir la base de l’implémentation.

Voici le contenu du lab:

  • Mettre en oeuvre l’AD pour XenDesktop (config DHCP pour le PXE et créer une OU)
  • Créer une ferme de Bureau Virtuel sur le DDC
  • Finaliser la configuration du PVS avec l’assistant
  • Créer et formater un vDisk
  • Installer XenConvert et l’agent XenDesktop dans une VM de référence
  • Capturer l’image de la VM de référence
  • Créer un template de bureau virtuel et provisionner plusieurs bureau à partir du template
  • Configurer les propriétées du Pool de bureau virtuel
  • Se connecter à un bureau virtuel

Le manuel du Lab est dispo en version PDF.

Mar/1090

Bienvenue sur le Blog VMnerds : consacré à la virtualisation.

C’est le premier post et ce n’est qu’un début.

VMnerds