Cette update est accompagnée de la fin du support Général pour ESX(i) 3.5 et pour VC 2.5 fixée au 21/05/2010. La fin du support étendu est quant à lui fixé au 21/05/2013, ce qui laisse encore un peu de temps pour l’upgrade.

Pour les plus parano, la liste des EOS pour vSphere est disponible ici

VMware recommande l’update des VMtools en cas de mise à jour des hosts et attire notre attention sur la matrice de compatibilité vcenter/esx(i).

ESXi 3.5 U5 Installable Release Notes
ESXi 3.5 U5 Embedded Release Notes
ESX 3.5 U5 Release Notes

Ken Cline, un membre reconnu de la communauté et depuis peu Senior Consultant chez VMware, a bouclé il y a quelques jours son “Great vSwitch Debate”. Tout a commencé sur le forum VMware et a fini sur son blog par un énorme article en 8 parties.

Il est question d’à peu près tout ce qu’un admin VMware doit savoir sur le fonctionnement d’un vSwitch et des config optimales en fonction du nombre de cartes réseau physiques disponibles.

La partie 3 est particulièrement intéressante techniquement car Ken détaile les différentes méthodes de load-balancing. On y apprend, par exemple, l’utilisation des ports d’un vSwitch en fonction de la séquence de démarrage des vm :

Incontournable pour n’importe quel vAdmin…

VIX API est une bibliothèque permettant de créer des scripts et des programmes compilés pour interagir avec des host et/ou des vm. Mais ce qui nous intéresse ici, c’est un précieux utilitaire qui permet d’exécuter des commandes DANS les vm : vmrun

Voici un extrait liste des commandes de cet outil génial qui vous permettra, par exemple, d’installer un agent ou de déployer des mises à jour sur des vm en DMZ et donc non joignable depuis votre réseau de production :

Quelques exemples :

Supprimer un fichier dans une VM :

C:\Program Files\VMware\VMware VIX\vmrun.exe -T ESX -h https://vcenter.vmware.com/sdk -u vcadmin -p "vcpassword" -gu gadmin -gp "gpassword" deleteFileInGuest "[datastore] VM/VM.vmx" c:\test.txt

Copier un fichier depuis le vCenter vers une vm :

C:\Program Files\VMware\VMware VIX\vmrun.exe -T ESX -h https://vcenter.vmware.com/sdk -u vcadmin -p "vcpassword" copyFileFromHostToGuest "[datastore] VM/VM.vmx" c:\vctemp\agent.exe c:\utils\agent.exe

Faire un screenshot d’une vm :

C:\Program Files\VMware\VMware VIX\vmrun.exe -T ESX -h https://vcenter.vmware.com/sdk -u vcadmin -p "vcpassword" captureScreen "[datastore] VM/VM.vmx" c:\vm.png

Pour ceux qui commence à aimer le powershell (merci le VI toolkit), une library .NET est maintenant disponible.

Update : VMWareTasks est maintenant disponible sur codeplex

Merci à “Windows” qui se verra remettre son mojito comme promis !

Xtravirt est le spécialiste du “VI3 in a box”. Leurs whitepapers pour faire tourner ESX sur VMware Workstation sont en effet bien connu de la communauté VMware, mais la licence pour Workstation restait le point faible de cette technique.

Il semble que ce soit de l’histoire ancienne si l’on en croit la récente publication des whitepapers “How to Install ESX 3.5 and ESXi as a VM on VMware Server 2.0″ et “How to Install VMware ESX3.5 on VMware Player as a VM”.

Malheureusement, nous n’avons pas été en mesure d’accomplir une install stable que ce soit pour ESX ou pour ESXi sur VMware Server 2.0 alors que cela ne nous a posé aucun problème sur Workstation 6.5

Un membre d’Xtravirt confirme pourtant sur VM/ETC que cela ne pose aucun problème. Un mojito offert à celui ou celle qui nous envoi un screenshot le prouvant !

VMware reconnait le miracle.

Il y a 15 jours, nous vous avons annoncé l’Update 4 d’ESX(i) en oubliant de préciser que cette mise à jour apportait le support des derniers Xeon Nehalem-EP.

Si le Nehalem destiné au grand public (core i7) est déjà disponible depuis plusieurs mois, sa version serveur (Xeon 5500) ne l’est que depuis quelques jours.

Ce nouveau Xeon signe le retour de l’Hyperthreading et intégre un contrôleur mémoire triple canal. Vous l’aurez compris, c’est au tour d’Intel de profiter du NUMA et de tous les avantages qu’AMD et son RVI savent exploiter depuis bien longtemps. Mais ce n’est pas tout. Pour ceux que curiosité démange, je vous invites vivement à consulter l’article du célebrissime Doc TB sur l’analyse d’architecture du Nehalem.

Comme le souligne lemagit.fr (dans un article bientot payant mais dont le cache google aura raison), cette nouvelle gamme de Xeon surpasse les Opteron d’AMD sur le plan des performances mais aussi sur la grille des tarifs !

Les meilleurs serveurs Intel sont donc environ 57 % plus rapides au test SpecJbb que les meilleurs Opteron… mais 58 % plus chers.

Toujours selon lemagit.fr, les gains sur ESX 4 sont nettement meilleurs que sur ESX 3 : la faute à VMware VMDirectPath et VT-d.

AMD souhaite donc profiter de ce paradoxe pour ajouter à sa gamme d’Opteron un modèle plus véloce en avril et rendre disponible la version 6 core en juin. Tout cela toujours avec une politique de prix très agréssive. La version quadri-sockets du Xeon Nehalem ne devrait arriver qu’à la fin de l’année.

Pour ceux qui voudraient en savoir plus sur la conception des CPU, je vous conseille un vieil article de 2003 auquel nous avons participé : Les secrets du wafer.

VMware semble avoir pris très au serieux cette vidéo en contre-argumentant chaque “Myth”. Ils doivent bien se marrer chez Citrix…

Reste à savoir si le produit sera égallement disponible en même temps…

Son script est fait à l’origine pour un host, nous l’avons adapté pour un cluster (il possible de mettre le nom d’un datacenter ou d’un folder sans modification) :

Param ($cluster = "")
#$cluster = "vmcluster"
$iscsiHba = "vmhba32" #might be vmhba33
$iscsiServer = "iscsi_ip"
$iscsiPort = 3260
 
$target = New-Object VMware.Vim.HostInternetScsiHBASendTarget
$target.address = $iscsiServer
$target.port = $iscsiPort
$iscsiauth = New-Object VMware.Vim.HostInternetScsiHbaAuthenticationProperties
#$iscsiauth.ChapAuthEnabled = "true"
#$iscsiauth.ChapName = "user"
#$iscsiauth.ChapSecret = "password"
$h = Get-VMHost -Location $cluster
Foreach ($hostView in ( Get-View -VIObject $h)) {
$storageSystem = Get-View $hostView.configManager.storageSystem
# Enable software iSCSI controller
$storageSystem.UpdateSoftwareInternetScsiEnabled($true)
# Add iSCSI Server for dynamic discovery
$storageSystem.AddInternetScsiSendTargets($iscsiHba, $target)
$storageSystem.UpdateInternetScsiAuthenticationProperties($iscsiHba,$iscsiauth)
# Scan for iSCSI devices
$storageSystem.RescanHba($iscsiHba)
}

Pour des besoins spécifiques (typiquement de performance et/ou de coût), il est parfois nécessaire de déplacer (à chaud bien sur) l’un des vmdk d’une VM sans pour autant déplacer les autres.

Pour cela il faut faire appel au script svmotion.pl disponible dans le VI Remote CLI ou inclus dans l’appliance VIMA.

Malheureusement, et contre toute attente, ce script n’est pas fonctionnel à 100%. En effet, la commande svmotion –interactive ne vous permet pas de déplacer qu’une partie des vmdk mais toute la VM.

Il faut pour cela taper la commande complète, comme par ex :

$ svmotion.pl –url=https://virtualcenter.domain.com/sdk –username=”domaine\user” –password=”password” –datacenter=VMDC –vm=”[old_datastore] VM/VM.vmx: new_datastore” –disks=”[old_datastore] VM/VM.vmdk: new_datastore, [old_datastore] VM/VM_1.vmdk: old_datastore”

Cette commande va déplacer la VM vers le nouveau datastore ainsi que le 1er vmdk et laisser le second sur l’ancien datastore.

Il n’est pas possible de déplacer UNIQUEMENT un vmdk avec cette version du script (cela pourrai changer avec ESX 4 d’après certaines rumeurs…) ce qui signifie que l’on déplace la vm avec ou sans les vmdk et non l’inverse.

Par conséquent, la seule solution pour ne déplacer qu’un vmdk facilement consiste à créer un vmdk supplémentaire à votre vm (1Mo), faire un svmotion du vmdk à déplacer et celui d’1Mo, puis de refaire l’opération inverse avec seulement celui d’1Mo pour “ramener” le vmx au bon endroit. C’est tordu mais ca fonctionne.

/!\ Il est impératif de repréciser à chaque fois l’emplacement d’origine et de destination des TOUS les vmdk dans la commande. /!\

Toutes ces manipulation peuvent être faites graphiquement avec le plugin VIP-SVmotion mais cela reste moins clair qu’en ligne de commande pour ce genre de manipulations.

Tout d’abord, nous vous conseillons vivement de consulter (si ce n’est pas déjà fait) le pdf de Carl A. Waldspurger sur les différentes techniques de “conservation” de la mémoire utilisé par VMware ESX.

Ce document traite notamment de l’un des points fort d’ESX, le Transparent Page Sharing. Pour faire simple, cette fonction fait pointer des pages mémoires identiques (aux seins de différentes VM) vers une page physique.

Voici l’exemple d’un host ESX 3.5 hébergeant 70 VM (presque toutes sous Windows 2003) qui ont 25Go de pages mémoire en commun. Ces 25Go n’occupent que 4Go de RAM physiquement :

D’après VMware, l’overhead de cette fonction n’excéderait pas 1%.

Malheureusement, d’après la récente expérience de Duncan le TPS ne ferait pas bon ménage avec le RVI.

Le RVI (fonctionnalité des CPU AMD) est considéré comme le second niveau de virtualisation matériel. Il permet une accélération matériel de la gestion des transactions vRAM <> pRAM (MMU). En effet, la gestion RAM physique/RAM virtuelle (dans les VM) est traditionnellement gérée de façon logiciel par l’hyperviseur. le RVI permet donc de s’affranchir du coût CPU qu’engendre cette gestion (virtualized MMU).

Jason nous en explique un peu plus sur le fonctionnement du RVI sur son blog et nous informe que la version d’Intel (l’EPT) de cette technologie devrait être disponible dans le courant de l’année.

A la demande de Duncan, Carl nous explique que le RVI fonctionne majoritairement en mode “large pages” (2Mo) ce qui n’est pas compatible avec le TPS (qui ne fonctionne que sur des pages de 4ko).

Cette explication est d’ailleurs confirmée par un white paper VMware sur l’utilisation des “larges pages” :

In ESX Server 3.5 and ESX Server 3i v3.5, large pages cannot be shared as copy‐on‐write pages. This means, the ESX Server page sharing technique might share less memory when large pages are used instead of small pages.

Nous ignorons encore de quelle différence il est question mais le véritable problème est une possible dégradation de performance en cas de memory overcommit trop important:

When free machine memory is low and before swapping happens, the ESX Server kernel attempts to share identical small pages even if they are parts of large pages. As a result, the candidate large pages on the host machine are broken into small pages.

Pour ceux qui veulent se faire du mal, suivez le link.

Pour les autres, sachez qu’avec le software initiator il n’est pas possible de faire du load balancing vers une seule et même target iscsi . Utilisez plusieurs target si vous souhaitez exploiter tout le potentiel de vos NIC. Ou attendez ESX 4…

vCenter (aka VirtualCenter) Server 2.5 Update 4 (build 147633) est sorti hier soir dans une certaine indifférence malgré les nouveautés :

• Supports customization of Windows Server 2008 guest operating systems
• Performance Overview Charts (Performance Overview plug-in)
• VMware Converter Enterprise Update 4 for VC 2.5
• VMware Update Manager 1.0 Update 4 for VC 2.5

Le changelog est assez conséquent et on peut y trouver quelques correctifs qui apportent également quelques fonctionnalités supplémentaires :

In Addition to Virtual Machine Heartbeats the Virtual Machine Monitoring Service Monitors a Virtual Machine’s Disk and Network Activity

Starting with the VirtualCenter 2.5 Update 4 release, the virtual machine monitoring service also monitors a virtual machine’s disk and network activity. Even if no heartbeats are received within the failure interval, the virtual machine remains powered on unless no disk or network activity is detected for a predetermined I/O stats interval.

Concernant le plug-in Performance Overview Charts, même s’il est un peu complexe à mettre en place, le résultat en vaut la peine :

En suivant une discussion sur le blog de Duncan Epping (Senior PSO Consultant chez VMware) concernant le design d’un cluster HA répartie sur 2 châssis de lames, nous somme tombés sur un post détaillant le fonctionnement précis de VMware High Availability (HA). Duncan nous a autorisé à le traduire.

Avec les dernières version d’ESX 3.5 & VirtualCenter 2.5, un cluster HA peut contenir 32 nœuds maximum. Contrairement à un cluster XenServer (par exemple…), les différents noeuds d’un cluster HA n’ont pas besoin d’un quorum pour communiquer entre eux. Cet avantage, on le paye forcement d’un inconvénient…

En fait, les nœuds d’un cluster HA ne communiquent pas totalement entre eux : Les 5 premiers (tant qu’ils restent online) serveurs  ajoutés au cluster (primary nodes) se communiquent, via le réseau, les réglages du cluster, leurs état et l’état des autres serveurs (secondary nodes). Les autres serveurs (1 à 27) communiquent leur état aux primary nodes. Tout cela chaque seconde (valeur par défaut, modifiable via l’option das.failuredetectioninterval).

L’un des 5 primary nodes assume le rôle de fail-over coordinator qui coordonnera le redémarrage des vm d’un ou des nœuds HS. Les VM sont redémarrées dans l’ordre où elles ont été coupées (priorité prise en compte).

Malheureusement, un nœud primaire n’est re-promu que si le nœud HS est placé en maintenance mode ou retiré du cluster. Par conséquent, si les 5 nœuds primaires “tombent” aucune vm ne sera redémarrée car aucun  fail-over coordinator ne sera disponible pour gerer cette action.

C’est pour cette raison qu’il est impossible de fixer la tolérance du cluster à plus de 4 nœuds :

Conséquence : En considerant un cluster de 32 nœuds répartis sur 2 châssis (16+16), il est probable que les 5 primary nodes soient dans le même châssis.

le fichier /var/log/vmware/aam/aam_config_util_listnodes.log contient la liste des nœuds et leur type (primary ou secondary) :

La ré-élection d’un primary node étant aléatoire, jouer avec le maintenance mode risque de vous faire perdre la tête, même si c’est la seule solution pour forcer un changement de type.

Ducan suggère une alternative plus sûre qui consiste à créer de plus petit clusters (dans notre cas, 4x 8 nœuds) et de les répartir sur les 2 châssis. Le but étant de diminuer la probabilité que plus de 4 nœuds “tombent” simultanément.

ESX 4 nous fera peut etre grace d’une alternative plus techniquement correct…

Thomas Ackerson de mainesysadmin.com à posté sur son blog un article pour configurer le syslog d’ESX et permettre de regrouper les logs de tous vos ESX vers un serveur syslog.

C’est evidement la meme méthode que pour un syslog standard puisque la COS d’ESX est une RHEL 3 :

• vi /etc/syslog.conf
• *.*    @syslog.domaine.com à ajouter à la fin du fichier
• esxcfg-firewall -o 514,udp,out,syslog pour ouvrir le firewall
• esxcfg-firewall -l pour relancer le firewall
• service syslog restart pour relancer le service syslog

Pour ESXi c’est encore plus simple, il suffit d’aller dans les Advanced Settings du serveur (ou d’utiliser la commande powershell Set-VMHostSysLogServer du VI Toolkit) :

Avec syslog-ng et php-syslog-ng, on obtient un outil indispensable :

MAJ 09/03/2009 :Le symptôme est différent pour ESXi, l’install freeze :

MAJ 09/03/2009 : kduke nous informe (dans les commentaires de ce post) qu’il est possible de contourner le problème en plaçant le CPU ayant le stepping le plus récent en CPU0. Cette manipulation est conseillé par VMware.

Retour d’expérience :

Ce matin, après une installation d’ESX 3.5 (avec l’iso esx-3.5.0_Update_3-123630.iso) impossible de faire booter la machine (IBM eServer BladeCenter HS21 8853G3G). Après analyse du dump log, une seule piste : WARNING: VMK: 538: Initialization of vmkernel failed, status 0xbad0001

3 clics sur Google plus tard, une solution potentielle est donné par membre du forum VMware : les stepping des cpu de la machine ne serait pas identique.

Après download et boot de l’iso CPU Identification Utility (dispo sur le site de VMware), la solution apparaît :

C’est bien la différences des stepping qui est la cause du problème, après changement de cpu l’ESX boot (sans modification quelconque) et le CPU Identification Utility nous confirme :

Moralité : Sur un ESX, les stepping des différents cpu doivent être identiques au sein du même serveur.

Il faut rajouter dans la section <vpxd> du fichier C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter\vpxd.cfg le paramètre suivant :

<ResourceManager>
<maxCostPerHost>16</maxCostPerHost>
</ResourceManager>

Suivi d’un redémarrage du service VMware VirtualCenter Server (vpxd).

Sachant qu’un vmotion “coute” 4 points (une migration à froid coute 1 point), la valeur souhaité doit etre multipilé par 4 (6 vmotion = 24 points). Cette valeur est à considérer par host, dans notre exemple nous autorisons donc 4 vmotions simultanés par host.

]]> http://www.hypervisor.fr/?feed=rss2&p=442 0 http://www.hypervisor.fr/?p=436 http://www.hypervisor.fr/?p=436#comments Tue, 30 Dec 2008 11:06:51 +0000 NiTRo http://www.hypervisor.fr/?p=436 Jason Boche à posté sur son blog un diagramme très clair des ports TCP/UDP utilisés dans une Infrastructure VI3 complète. Parfait pour rassurer votre équipe réseau.

il devient alors nécéssaire de killer le process en charge de la VM via la commande kill <id> -9

Pour trouver le process correspondant, il faut utiliser la commande ps -efww |grep <vmx> :

ps -efww |grep W2K3_STD_SP1_FR.vmx
root      2527     1  0 12:16 ?        00:00:00 /usr/lib/vmware/bin/vmkload_app /usr/lib/vmware/bin/vmware-vmx -ssched.group=host/user -# name=VMware ESX Server;version=3.5.0;licensename=VMware ESX Server;licenseversion=2.0 build-64607; -@ pipe=/tmp/vmhsdaemon-0/vmx5161adf574f530a4; /vmfs/volumes/6b1fe479-38e54d7a/W2K3_STD_SP1_FR/W2K3_STD_SP1_FR.vmx

Dans certain cas, il est aussi nécessaire d’exécuter la commande service mgmt-vmware restart si une tache reste bloquée sur le VC.