MAJ 28.08.2012 : Veeam nous confirme que ce bug à été corrigé dans le patch 1a 6.1.0.204, au cas ou vous auriez la version 6.1.0.203 (une “early” version du patch 1), assurez vous de re-télécharger la dernière version.

Nous avons pu observer par hasard la fuite mémoire d’une console veeam B&R 6.1 (6.1.0.181) laissée ouverte dans une session RDP pour un accès plus rapide :

Tom Sightler, Solutions Architect chez Veeam, nous confirme le leak et conseil de ne pas laisser le client ouvert tant que le bug n’est pas résolu.

[...] the 6.1 GUI has a pretty big leak. The larger the environment the faster it seems to grow. In some cases it only takes a few hours to get so big as to impact performance. I’ve even seen cases where the memory used by VeeamShell is large enough to cause problems with backup jobs. For now the only workaround is to keep the GUI closed when not in use.

Nous nous sommes donc rabattu sur les informations remonté via les API CIM :

Tant qu’on y était, on a fignolé le truc pour que ça ne remonte que les cluster non uniformes :

Get-BIOSMismatch

Si vous préférez un bon vieux one-liner qui vous affiche les version des BIOS de tous vos ESX, c’est par ici :

Get-View -ViewType HostSystem|?{$_.Runtime.ConnectionState -eq "connected"}|sort name|select name,@{n="BiosVersion";e={[Regex]::Match(($_.Runtime.HealthSystemRuntime.SystemHealthInfo.NumericSensorInfo|?{$_.name -match "bios" -and $_.SensorType -match "Software Components"}).name,"BIOS (.*) (20[0-9]{2,2}-[0-9]{2,2}-[0-9]{2,2})").groups[1].value}},@{n="ReleaseDate";e={[Regex]::Match(($_.Runtime.HealthSystemRuntime.SystemHealthInfo.NumericSensorInfo|?{$_.name -match "bios" -and $_.SensorType -match "Software Components"}).name,"BIOS (.*) (20[0-9]{2,2}-[0-9]{2,2}-[0-9]{2,2})").groups[2].value}}

PS : Il se peut que les infos visibles dans l’onglet “Hardware Status” du vSphere client ne correspondent pas à celle remonté en powershell, dans ce cas suivez les instructions de la kb 1037330, si cela ne suffit pas il faudra rebooter l’ESX.

A Windows VM may fail to boot properly if streaming over Citrix Provisioning Services (PVS). This is an intermittent fault, and rebooting the VM should resolve the issue.

[...]

Intel Errata for Nehalem, Sandy Bridge, and Westmere CPU implementations of C-states may lead to system instability, apparently random freezes or reboots — including during installation. Users with Nehalem, Sandy Bridge and Westmere CPUs are advised to disable C-states in the system BIOS as detailed in the Knowledge Base article CTX127395

De plus nous crevons de jalousie à l’idée de ne pas pouvoir faire tourner Windows 8 sur ESX 5 alors que XenServer 6 le supporte nativement. Pour nous venger, et grâce au vHV d’ESX 5.0, nous avons virtualisé un XenServer 6.0 qui lui-même virtualise un Windows 8 (dont le futur hyperviseur va supporter le “live storage migration”, cette technologie futuriste qui permet de déplacer une vm d’un stockage vers une clef usb sans interruption de service !).

Que cela ne vous empêche pas de faire un petit tour de piste avec…

Si c’est déjà trop tard, ou pire si comme sur notre lab votre VCDB est full (à cause de la limitation à 4Go de la version SQL Express 2005, poussé à 10Go sur la version 2008R2 au passage), il vous faudra faire un truncate de VPX_EVENT et si besoin utiliser le script posté par Frank Brix Pedersen sur son blog pour purger la table VPX_EVENT_ARG (en raison de contraintes sur la table).

Pour vous donner un ordre d’idée, on parle de plusieurs Go par jour :

Ce bug est d’autant plus sournois qu’il n’apparaît pas immédiatement et semble attendre que la victime soit en confiance avant d’agir (et difficile à reproduire de surcroît)…

]]> http://www.hypervisor.fr/?feed=rss2&p=2986 0 http://www.hypervisor.fr/?p=2945 http://www.hypervisor.fr/?p=2945#comments Sun, 01 May 2011 23:35:16 +0000 NiTRo http://www.hypervisor.fr/?p=2945 MAJ 18/03/2011 : Comme nous le précise Tntteam, c’est ironiquement ce même patch qui corrige le problème (KB1037190)

En appliquant la mise à jour ESXi410-201104401-SG dispo depuis le 28/04/2011 (la première update depuis l’Update 1 de la 4.1)  sur notre lab à l’aide de VUM, nous nous sommes retrouvés avec cette erreur : “The host returns esxupdate error codes: 10“. Plus précisément, en utilisant la fonction “Scan…” de VUM directement sur un des ESXi d’un cluster car l’erreur retournée lorsque nous avons tenté un “Scan for Updates” sur ce cluster était beaucoup trop vague.

Heureusement, la réponse à ce problème a été particulièrement bien détaillée par un membre de VMware dans un thread sur le forum de l’éditeur :

[...]/tmp was added in 4.1U1 to the list of directories “cleaned” by /sbin/tmpwatch.sh.  (tmpwatch.sh is run by root’s crontab /var/spool/cron/crontabs/root).  tmpwatch is not aware that /tmp/scratch is special and needs to be left alone.

[...] On ESXi Installable, /scratch is a symlink to some /vmfs/volumes/… place, not assaulted by tmpwatch.

[...] So only Embedded is affected, and then only a subset (diskless machines), and then a subset of those (without suitable scratch space on the boot USB key).

Pour résoudre le problème en attendant un prochain patch, plusieurs solutions sont à votre disposition (merci aux membres du forum ainsi qu’à filbo pour les détails) :

• Utiliser des supports USB/SD supérieurs à 5Go (pour la partition scratch soit bien créée à l’install)
• Rediriger la scratch vers un volume vmfs via les advanced settings (ScratchConfig.ConfiguredScratchLocation)
• Modifier le script /sbin/tmpwatch.sh (la pire des solutions pour des raisons évidentes)
• Recréer le répertoire manquant via mkdir -p /tmp/scratch/var/tmp (la solution la plus rapide car ne nécessite pas de reboot mais non durable)

La version 5.0.2.224 de Veeam Backup & Replication est sortie le 1er avril mais ce n’est pas pour cela qu’elle contient un bug lié à la nouvelle feature “Deleted VMs retention period” qui a pour effet de supprimer tous vos restore points vieux de plus de 14j :

New “Deleted VMs retention period” feature is behaving incorrectly, causing backup files older than specified amount of days to be deleted even if they contain VMs which had not been deleted from infrastructure.

Le workaround ainsi que les détails sont dispo sur le forum de Veeam.

Voici l’extrait de cette feature qui reste néanmoins très intéressante (quand le problème sera réglé) :

Automated retention for removed and deleted VMs. Data belonging to removed or deleted VMs will now be automatically cleaned up from backup files according to new UI retention setting in days. Previously, it was necessary to remove such VMs from backup manually to explicitly confirm that VM data is no longer needed.

]]> http://www.hypervisor.fr/?feed=rss2&p=2842 0 http://www.hypervisor.fr/?p=2768 http://www.hypervisor.fr/?p=2768#comments Sun, 27 Mar 2011 14:23:17 +0000 NiTRo http://www.hypervisor.fr/?p=2768 Après des mois de tapage makerting autour de Dynamic Memory (ballooning farceur) et Remote FX (RDP++), le lancement officiel du SP1 de Windows 2008 R2/Hyper-V R2 s’est fait sans grosses explosions blogesques puisqu’on en connaissait déjà les détails (mise à part la critique de l’excellent whitepaper Project VRC Phase III au sujet de l’ASLR sur le Windows Virtualization Team Blog).

Mais maintenant que les migrations commencent sur les environnements de production, un problème lié au stockage (pas encore clairement identifié) à été signalé vendredi sur Twitter. Ca va même très loin pour certains :

[...] in my case running a validation report even damaged the MBR record on the LUNS making them inaccessible to Cluster Shared Volumes. So I lost a good part of my production Hyper-V servers (Thank you back-up).

Testez bien avant de patcher, ou migrez vers ESX avec vCenter XVP Manager

“This time it’s gonna be different. Trust me.”

• Votre vCenter est en 32bit et vous souhaitez le migrer en 64bit
• Ou, votre vCenter est sous W2K3, vous souhaitez le migrer sous W2K8R2
• Ou, votre vCenter est sous W2K8, vous souhaitez le migrer sous W2K8R2
• Et, votre vCenter a déja “subi” une upgrade (2.5>4.0 ou 4.0>4.0 U1 par ex.)
• Et, sous [HKLM\SOFTWARE\VMware, Inc.\VMware VMware VirtualCenter] la valeur “DbServerType” est à “Custom“

VMware a pourtant tout prévu dans son script vcenterbackup.py :

# Checking registry entry for ‘dbServerType’ is not enough because when
# user upgrades from previous version of VC to newer version, it changes
# to ‘Custom’ although user is using bundled DB.

Et effectivement, même avec la valeur à “Custom”, la base est bien sauvegardée mais PAS restaurée sur le nouveau vCenter.

Pour résoudre facilement le problème, il suffit de changer cette valeur en “Bundled” (dans [HKLM\SOFTWARE\VMware, Inc.\VMware Update Manager] aussi si besoin) AVANT l’execution du script backup.bat

Autre problème, coté base ADAM cette fois, dont nous devons la résolution à Gregg Robertson :

Active Directory Web Services encountered an error while reading the settings for the specified Active Directory Lightweight Directory Services instance.  Active Directory Web Services will retry this operation periodically.  In the mean time, this instance will be ignored.

Instance name: ADAM_VMwareVCMSDS

C’est la valeur “Port SSL” sous [HKLM\System\CurrentControlSet\Services\VMwareVCMSDS\Parameters] qui est vide ET au mauvais format (REG_SZ). Il faut la supprimer et la remplacer par une valeur REG_DWORD à “636” puis relancer (dans l’ordre) le service “ADAM_VMwareVCMSDS” suivit de “ADWS”.

Et dernier petit détail, après la migration il peut arriver que le log file de la base VIM_VCDB (VIM_VCDB.ldf) soit plein, provoquant l’arrêt du service vpxd. Vérifiez de ce coté en premier si cela venait à arriver sur le vCenter de destination.

Bonne migration !

Upgrading VMware Tools in a virtual desktop causes PCoIP connections to fail

To avoid this issue, do not upgrade to ESX 4.0 Update 2 if you are using View 4.x with PCoIP.

Si vous utilisez View 4 en environnement ESX 4.0 U1, ne bougez plus et soyez attentif à la résolution de ce problème sur cette kb.

Il semblerait que l’update pour le .NET framework du 8 juin bloque la connexion du client vSphere.

L’Update 1 de vSphere 4.0 est décidément maudite. Après le bug d’ESX 4.0 U1 fin novembre, c’est au tour de vCenter de souffrir d’un bug (encore inconnu) avec certain ESXi 4.0 :

If you have ESXi hosts connected to vCenter Server 4.0, do not upgrade vCenter Server to Update 1 at this time

Moralité, patientez et maquettez avant d’upgrader…

Extrait que la kb Microsoft :

This problem occurs because spurious interrupts are generated on the computer that uses Intel code-named Nehalem processors. These interrupts are caused by a known erratum that is described in the following Intel documents.

MAJ 27/11/2009 : Il semblerai que ce bug soit uniquement lié aux serveurs HP.

Si vous avez des hosts ESX 4.0 (ESXi n’est pas concerné) avec des agents installés (IBM Director, HP Insight, etc…) NE FAITES PAS l’upgrade (avec VUM) vers la version 4.0 U1 AVANT d’avoir désactivé ces agents :

Upgrading ESX 4.0 to 4.0 U1 using Update Manager fails or times out and rebooting the host results in a purple diagnostic screen

[...]

To avoid this issue, prior to the update, disable all 3rd party management agents running on the ESX 4.0.0 server before applying the update.

MAJ 02/02/2010 : Comme annoncé par VMware, l’Update 1 d’ESXi 4.0 (build 208167) corrige ce problème (partition VMFS à supprimer avant l’upgrade) :

MAJ 12/08/2009 : Nous avons tenté un “repair” avec le CD d’install d’ESXi et un backup/restore avec la commande vicfg-cfgbackup (depuis une VIMA/vMA) sans succès. La MAJ semble pour le moment impossible dans cette situation. D’après radio moquette, il faudrait attendre ESXi 4.0 U1 !

A mesure de son adoption dans les datacenter, les effets de bords d’update/upgrade d’ESX(i) 4 apparaissent. Si l’on en croit la release note, la version embedded d’ESXi à beaucoup de mal à être mise à jour. Malheureusement elle n’est pas la seule car la version installable peut également souffrir des mêmes maux dans certaines circonstances :

Après plusieurs Upgrade effectuées sans l’ombre d’un bug (que ce soit avec VUM ou Host Update Utility), nous avons eu récemment cette déplaisante surprise :

Après un rapide googling, un membre du forum VMware dévoile la douloureuse explication : Sur certains types de serveurs (IBM LS42 et x3850 M2 pour notre part), l’installeur d’ESXi 3.5.0 ne créer pas l’une des partitions nécessaire à l’upgrade.

Aucune solution pour l’instant, sinon une fresh install en ESXi 4 du serveur (ou des dizaines pour certains…)

MAJ 12/08/2009 :

Tentative de “repair” avec le CD d’install d’ESXi 4.0.0 :

Tentative avec la commande vicfg-cfgbackup :

Ces failles permettraient un memory leak du host au guest (interceptions de données provenant de la zone mémoire d’autres VM ?) et pire encore : exécuter du code sur le host via un guest (via le support Direct3D, actif par défaut sur ESX(i) 4.0).

Les seules “protections” possible seraient :

• Patcher
• Ne pas installer les pilotes graphiques des vmtools (!)
• Désactiver le driver SVGA (sous Windows)
• Désactiver le support 3D (pour les vmx en v7)

Cette faille à été corrigée par VMware avant la version GA (build 140815) d’ESX(i) 4.0 et patchée sur tous les autres produits encore supportés. Les version non patchées restes bien évidement vulnérables.

Sachez cela :

Pour rappel, cette option est un watchdog de VM qui vérifie de façon plus ou moins régulière la disponibilité des vmtools :

Cette option permet donc de rebooter une vm ayant subit un BSOD, un kernel panic ou si l’OS est devenu trop “bancale”. Très pratique donc.

Malheureusement, l’update 3 d’ESX 3.5 à quelque peut gâchée la fête. En effet, un vmotion vers un host 3.5 U3 “peut” provoquer un reboot de la VM lorsque l’option “virtual machine monitoring” est activée.

Concrètement, les vmtools de la VM ne renvoyait plus de “heartbeat” donc elle était considérée comme HS et un signal de reset était renvoyée à la VM. Démonstration (extrait du vmware.log d’une VM) :

12:35:49.421: vmx| MigrateStateUpdate: Transitioning from state 0 to 7. <– début du VMotion

[...]

12:35:50.132: vmx| MigrateWaitForData: waiting for data.
12:35:50.132: vmx| MigrateStateUpdate: Transitioning from state 7 to 8.
12:35:50.778: vmx| MigrateStateUpdate: Transitioning from state 8 to 9.
12:35:54.892: vmx| MigrateWaitForData: Waited for 4.76 seconds.
12:35:54.892: vmx| MigrateStateUpdate: Transitioning from state 9 to 10.

[...]

12:35:55.438: vcpu-0| MigrateStateUpdate: Transitioning from state 10 to 11.
12:35:55.438: vcpu-0| Migrate_ClearDoneState: cleared state.  State was 11. <– fin du VMotion
12:35:55.438: vcpu-0| MigrateStateUpdate: Transitioning from state 11 to 0.
12:35:55.438: vcpu-0| Done Sync monModules(4).

[...]

12:38:00.886: vmx| TOOLS received request in VMX to set option ’synctime’ -> ‘1′
12:38:00.893: vmx| VMXVmdb_LoadRawConfig: Loading raw config
12:38:17.867: vmx|
12:38:17.867: vmx|
12:38:17.867: vmx| VMXRequestReset <– reset de la VM par le virtual machine monitoring

Le patch ESX350-200811401-SG censé résoudre le problème, ne résout malheureusement rien.

Heureusement, comme nous l’avions annoncé dans la news précédente, ce workaround lui fonctionne bien (tests à l’appui).

Faire modifier un fichier manuellement sur X serveurs vi ssh c’est tellement plus fun que de mettre à dispo un vrai patch…

Il y a quelques jours, nous découvrions avec grand étonnement plaisir que VMware avait rendu les api RCLI pour ESXi read-write pour la version gratuite, grâce à l’update 3.

Mais en fait, non :

With the release of VMware ESXi 3.5 Update 3, some API calls became freely available.  As it turns out, these new APIs were opened up unintentionally.  This inadvertent change happened when VMware was resolving an API-related bug.

Only customers who downloaded the free version of ESXi have been affected.  VirtualCenter and VI (Foundation, Standard, Enterprise) customers are not affected.

My VMware contacts tell me that this bug will be fixed shortly, and the next release will lock down the RCLI again.

Merci à Rich Brambley pour l’info.

MAJ 03/12/2008 : VMware a enfin rendu disponible le patch corrigeant ce problème.

A peine l’histoire du “timebomb” de l’update 2 oubliée, un nouveau bug frappe la dernière update (build 123630) d’ESX 3.5

Ce bug touche l’option “Virtual Machine Monitoring” qui reboot les VMs ne renvoyant plus de “heartbeat“. Lorsque cette option est activée dans un cluster HA/DRS et qu’une VM subit un Vmotion (vers un serveur ayant recu l’update en question) sur recommandation du DRS, il y a de fortes probabilitées que cette VM soit rebootée une fois le Vmotion terminé.

ivobeerens.nl nous apprend qu’il suffit de désactiver l’option pour contourner le problème et qu’une update sera disponible dans la journée du 20 novembre 2008 :

“I made a support request @ VMware. The told me today that 20 November patch 10 for VMware 3.5 Update 3 will be released. Patch 10 fixes SOME random reboot problems in Update 3. I hope it resolves this nasty issue.”

Le forum de vmware commence à flamber… (ici, ici et ici)

Autre détail, les VM sous Windows ayant souffert du problème présentent ce symptôme dans l’eventlog :

MAJ 20/10/2008 : L’erreur n’était pas dans le paramettre mais dans la valeur, c’est “true” ou “false” qu’il faut utiliser. Merci Peter

VMware vient de rendre disponible l’Update 3 (build 119598) de VirtualCenter.

Entre autres correctif de bugs, cette update permettra de désactiver (via l’option das.bypassNetCompatCheck et non das.bypassNetworkVerification) le “HA network compliance check” instauré par l’Update 2 forçant les membres d’un cluster HA à avoir une configuration réseau identique pour les Service Console.

Autre correctif intéressant, celui du bug de “Guest customization” qui permet de lancer un sysprep sur environnement Windows après déploiement de template, clone ou P2V. En effet, un VC 2.5 mis à jour en Update 2 ne lançait plus le sysprep dans la vm.