Hypervisor.fr

MAJ 15/10/2012 : En complément, voici un autre oneliner qui vous permettra de faire un “resume” des jobs volontairement arrêtés (v5/v6) :

Add-PSSnapin VeeamPSSnapIn ; Get-VBRJob|?{$_.GetLastResult() -eq 'Failed'}|?{($_|%{$_.FindLastSession()}|%{$_.info}).Description -match 'Job has been terminated'}|%{Start-VBRJob $_ -RetryBackup -RunAsync}

Add-PSSnapin VeeamPSSnapIn ; Get-VBRJob|?{$_.GetLastResult() -eq 'Failed'}|?{($_.FindLastSession()|%{$_.GetDetails()}) -match 'Job has been terminated'}|%{Start-VBRJob $_ -RetryBackup -RunAsync}

MAJ 07/11/2011 : Apparemment ce sera possible dans la v6.

L’une des petites options pratiques qui rapprocherai veeam backup de la perfection serai de pouvoir définir une heure limite d’exécution par job. Par exemple, vous ne voulez peut être pas qu’un job continue après 7h du matin. Pour ça il vous suffit de coller ce petit one-liner en tache planifiée sur votre serveur veeam et tous les jobs au statut ”Working” serons stoppés :

Add-PSSnapin VeeamPSSnapIn ; Get-VBRJob|?{$_.GetLastState() -eq "Working"}|%{Stop-VBRJob $_ -RunAsync}

Tags: powershell, scripting

V-index vient de mettre à jour les résultats de son étude en ligne pour Q3 2011 et c’est encore plus étonnant que la cuvée précédente :

• Average virtual machine to physical host  consolidation ratio : 5,1
• Primary Hypervisor usage for Desktop virtualization : 54,2%
• Reasons given for changing primary hypervisor  for Server virtualization - Features offered by alternative hypervisors : 47,4%
• Main concerns preventing increased virtualization – Backup and restoration: 33%

On note l’absence totale de l’aspect “sécurité” pour les “Main concerns preventing increased virtualization” et le taux de consolidation moyen dramatiquement bas.

Tags: v-index

Lorsque le matériel le permet et qu’il est configuré pour cela, ESX peut lui même (comme Hyper-V !) ajuster les différents C-States (modes d’économie d’énergie du CPU) afin d’être plus ou moins agressif en terme de consommation électrique. Les différents réglages et leurs comportement sont détaillés dans le Resource Management Guide mais il s’agit d’un réglage par host, à l’inverse de DPM qui agit au niveau d’un cluster. Ce qui signifie qu’il vous faudra scripter tout réglage post déploiement mais ça tombe bien, on est la pour ça !

Get-View -ViewType hostsystem -Property ConfigManager.PowerSystem -Filter @{"name" = "^esxsrv$"}|%{Get-View $_.ConfigManager.PowerSystem|%{$_.ConfigurePowerPolicy(2)}}

Avec ce petit one-liner, vous pourrez changer de 1 (low power) à 3 (high performance) la stratégie de gestion d’énergie des ESX correspondant au filtre de la cmdlet Get-View.

Nous rappelons que sur ESX 4, la stratégie par défaut est “High Performance” alors que sur ESX 5 la stratégie par défaut est ”Balanced” malgré son comportement :

The VMkernel uses the available power management features conservatively to reduce host energy consumption with minimal compromise to performance.

Voici un exemple des gains potentiels sur ESXi 5 :

Tags: DPM, PowerCLI, scripting

Il est parfois nécessaire de faire un rescan/refresh de la partie stockage de plusieurs ESX au delà d’un seul cluster. Depuis vSphere 4, la fonction “Rescan for Datastores…” disponible au niveau du cluster améliore grandement l’administration quotidienne mais la fonction “Refresh host storage system“, qui permet par exemple de rafraichir l’espace disponible sur les partages NFS, n’est disponible qu’individuellement sur chaque host.

Voici donc un petit one-liner qui permet de combiner les actions de rescan et refresh :

Get-View -ViewType HostSystem -Property ConfigManager.StorageSystem -Filter @{"Name"="^vmvisor"}|%{Get-View $_.ConfigManager.StorageSystem|%{$_.RescanAllHba();$_.RefreshStorageSystem()}}

L’équivalent en moins rapide mais en plus simple :

Get-VMHost vmvisor*|Get-VMHostStorage -RescanAllHba -Refresh

Vous aurez remarqué que nous n’avons pas inclus de RescanVmfs car selon le vSphere API Reference, la méthode RefreshStorageSystem l’intègre :

The RefreshStorageSystem method obtains information from the host platform and it performs a rescan of VMFS volumes. It does not look for new devices.

Bonus : la même commande pour la partie réseau, dont le refresh n’est aussi disponible qu’individuellement sur chaque host :

Get-View -ViewType HostSystem -Property ConfigManager.NetworkSystem -Filter @{"Name"="^vmvisor"}|%{Get-View $_.ConfigManager.NetworkSystem|%{$_.RefreshNetworkSystem()}}

Inutile de vous rappeler qu’il vous faudra ajuster le filtrage de la commande Get-View à votre nomenclature.

Tags: iSCSI, NFS, PowerCLI, powershell, scripting, VMFS

Alors que la dernière mouture de note hyperviseur préféré essuie ses premiers plâtres coté stockage avec un bug VAAI (kb 2007427) et un autre sur l’iSCSI software (kb 2007108), nous avons déniché un workaround à un autre problème (concernant le nouveau syslog d’ESXi) pour lequel la solution préconisé par VMware est un reboot. Pas très datacenter-friendly, vous en conviendrez.

Le problème en question concerne l’arrêt du daemon vmsyslogd lorsque le datastore désigné pour accueillir les logs n’est pas accessible (ou a été indisponible trop longtemps). La kb 2003470 fait état du problème lorsque l’ESXi est en boot from SAN mais le problème est identique lorsque le paramètre Syslog.global.logDir pointe vers un datastore NFS qui serait indisponible lors d’une coupure réseau.

Ce problème est d’autant plus fâcheux (mais en même temps évident) que c’est ce même daemon qui transmet les messages au Syslog.global.logHost, ce qui signifie que si vous devez troubleshooter un effet de bord suite à une coupure réseau ou SAN trop longue et que vous redirigiez les logs sur un datastore “remote”, vous n’avez plus de logs pour le faire. Et VMware voudrait vous faire rebooter rien que pour ça !

Heureusement, le reboot peut être facilement évité en faisant un reload du daemon ou (si le process à été tué ou si le watchdog n’a pas réussi à relancer le process) en lançant manuellement le daemon (le reload génère une erreur lorsque le process ne tourne plus) :

esxcli system syslog reload

/usr/lib/vmware/vmsyslog/bin/vmsyslogd

Un petit détail en passant, sur la version embedded d’ESXi 5.0 le daemon syslog n’est pas configuré (/scratch/log par défaut) si la partition scratch est absente :

Autre petit détail intéressant, contrairement aux précédentes versions d’ESXi, vous pouvez maintenant utiliser le même chemin pour tous vos ESXi et activer le paramètre  Syslog.global.logDirUnique qui créera automatiquement un sous répertoire au nom FQDN du serveur pour y placer les logs.

Dernier point qui a également son importance, le “format syslog” d’ESXi est nettement mieux respecté dans cette nouvelle version ce qui permet d’améliorer le filtrage lorsqu’on redirige vers une plateforme type rsyslog+loganalyzer :

Tags: syslog