Hypervisor.fr

Jusqu’à aujourd’hui, la meilleure façon de comparer les recommandations du vSphere Hardening Guide (4.0 et 4.1) à une infrastructure était l’utilisation du script vSphere Security Hardening Report Check de William Lam qui nécessite une vMA ou la présence du vCLI.

Depuis ce matin, VMware offre VMware Compliance Checker for vSphere qui s’installe rapidement sous Windows (nécessite une JRE) et s’utilise via une GUI minimaliste :

Le report (sous forme de page web -incompatible avec Chrome !?-) est bien clean et contient le détail de chaque check :

Nous vous rappelons également l’existence du plugin SiteSurvey Report permettant de tester rapidement la capacité des membres d’un cluster à supporter Fault Tolerance :

Tags: Fault Tolerance, Hardening

MAJ 02/02/2012 : remplacement du script par un one-liner

Lors d’une tentative de svmotion nous avons été confronté à un timeout sans plus de détails :

C’est dans le vmware.log de la vm qu’on trouve la cause de l’échec (c’est souvent le cas d’ailleurs…) :

Migrate_SetFailure: The migration has exceeded the maximum switchover time of 100 second(s).  ESX has preemptively failed the migration to allow the virtual machine to continue running on the source. To avoid this failure, either increase the maximum allowable switchover time or wait until the virtual machine is performing a less intensive workload.

Pourtant, depuis vSphere 4.0, un svmotion ne nécessite plus une phase de recopie de la ram grâce au “Fast Suspend/Resume” comme détaillé dans une session du vmworld 2009. Il ne nous restait donc plus que la piste de l’activité des vmdk mais la kb dédié à ce problème (Using Storage vMotion to migrate a virtual machine with many disks may timeout) fait référence à des messages d’erreurs aux quels nous n’avons pas été confrontés.

Dans le doute et n’ayant pas le temps d’investiguer d’avantage, nous avons augmenté les valeurs de “switchover time” pour vmotion et svmotion à l’aide de ce script PowerCLI, ce qui nous a permis de régler le problème :

Get-View -ViewType VirtualMachine|?{-not $_.Config.Template}|%{$_.ReconfigVM((New-Object VMware.Vim.VirtualMachineConfigSpec -Property @{extraconfig=@((New-Object VMware.Vim.optionvalue -Property @{Key="vmotion.maxSwitchoverSeconds";Value="200"});(New-Object VMware.Vim.optionvalue -Property @{Key="fsr.maxSwitchoverSeconds";Value="200"}))}))}

Le paramètre ”vmotion.maxSwitchoverSeconds”, nous l’avons trouvé dans les commentaires d’un post très intéressant du blog VMware Uptime au sujet d’une fonctionnalité peut connu de vmotion (vSphere 4.1+) : “quick resume“

In the event the VM passes the 100 second check, VMotion will stun the source and start running on the destination. While the destination runs, the source will transmit the remaining pages to the destination using the “quick resume” capability introduced with vSphere 4.1.

Vous avez bien lu, la vm de destination est démarrée alors le vmotion n’est techniquement pas terminé et les pages restantes sont migrées en tache de fond. Surpuissant.

Comme le précise Duncan dans son post concernant ce sujet, l’impact sur les performances en cas d’accès à une page restée sur la vm source (accès via le réseau donc) compense largement l’agilité de la solution dans la majorité des cas.

Tags: PowerCLI, scripting, SVMotion, troubleshooting, VMotion

Pour les besoins d’une maquette nous avons compilé un batch qui install en auto un vcenter + sql express et tous ses composants (vi client, update manager + plugin et converter + plugin) à partir d’une UNC :

start /wait \\server\share\VMware-VIMSetup-all-4.1.0-345042\vpx\VMware-vcserver.exe /q /s /w /L1033 /v" /qr DB_SERVER_TYPE=Bundled USERNAME=\"hypervisor\" COMPANYNAME=\"hypervisor\" LICENSEKEY=xxxxx-xxxxx-xxxxx-xxxxx-xxxxx FORMAT_DB=1 /L*v \"%TEMP%\vmvcsvr.log\""
start /wait \\server\share\VMware-VIMSetup-all-4.1.0-345042\vpx\VMware-viclient.exe /q /s /w /L1033 /v" /qr"
start /wait \\server\share\VMware-VIMSetup-all-4.1.0-345042\updateManager\VMware-UpdateManager.exe /L1033 /v" /qr VMUM_SERVER_SELECT=%computername% VC_SERVER_IP=%computername% VC_SERVER_ADMIN_USER=\"administrator\" VC_SERVER_ADMIN_PASSWORD=\"password\" VCI_DB_SERVER_TYPE=Bundled VCI_FORMAT_DB=1 /l*v %TEMP%\vumerver.log"
start /wait \\server\share\VMware-VIMSetup-all-4.1.0-345042\updateManager\VMware-UMClient.exe /q /s /w /L1033 /v" /qr"
##start /wait \\server\share\VMware-converter-all-4.3.0-292238\VMware-converter-all-4.3.0-292238.exe /s /v" /qn ADDLOCAL=ALL /l*v %TEMP%\vmconvservermsi.log"
start /wait \\server\share\VMware-VIMSetup-all-4.1.0-345042\converter\VMware-Converter.exe /q /s /w /L1033 /v" /qr  VC_SERVER_IP=%computername% VC_SERVER_ADMIN_USER=\"administrator\" VC_SERVER_ADMIN_PASSWORD=\"password\" /l*v %TEMP%\vmconserver.log"
start /wait \\server\share\VMware-VIMSetup-all-4.1.0-345042\converter\VMware-Converter-Client.exe /q /s /w /L1033 /v" /qr"
reg add HKLM\system\currentcontrolset\services\vpxd /v dependonservice /t REG_MULTI_SZ /d ProtectedStorage\0lanmanworkstation\0MSSQL$SQLEXP_VIM /f

Les chemins et informations diverses sont mettre à jour en fonction de la version du vCenter à installer (ces commandes sont compatibles 4.x à l’heure ou nous écrivons ce billet). La ligne commentée concerne la version standalone de converter et la dernière ligne rajoute une dépendance au service mssql sur le service vpxd.

Vous trouverez dans les documents de références VMware les différents paramètres des msi :

Tags: batch, scripting, unattended, vCenter

MAJ 11/04/2011 : La version 5.0.2.230 annule et remplace la version buggée

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.

Tags: bug, veeam

MAJ 14.04.2013 : 2 ans après ce post, Andreas Peetz nous rapporte qu’avec la bonne combinaison de settings, il est meme possible de faire un vmotion en Intel et AMD !

Dans la lignée des posts de William Lam sur l’utilisation de l’utilitaire “strings”, nous avons par hasard découvert que ProcessExplorer (du célèbre Mark Russinovich) avait une fonction similaire. Et c’est évidement par vpxd.exe que nous avons commencé :

Et vous vous en doutez, si nous vous en parlons c’est que nous y avons trouvé quelques pépites comme une liste de paramètres pour overrider un maximum de limitations pour vmotion (et svmotion pour ceux qui ont l’oeil) :

Read more …

Tags: strings, vpxd