Hypervisor.fr

Après un faux départ, NexentaStor 3.1 est enfin (re)disponible ! En plus des quelques nouvelles features et corrections de bug, la grosse bonne nouvelle c’est le support de VAAI pour ESXi 5+ (contrairement à ce qui avait été annoncé) y compris pour la version Community Edition. Ce qui en fait la toute première et seule solution VAAI gratuite, pour le mode block uniquement. Voici la liste des routines VAAI supportées :

• SCSI Write Same (zeroing)
• SCSI ATS (lock only the specific region on the LUN)
• SCSI Block Copy (instruct the array to perform a block copy)
• SCSI Unmap (return freed blocks in a zvol)

Je vous laisse imaginer l’intérêt d’une solution gratuite (jusqu’à 18To raw max pour la CE) supportant VAAI et reposant sur ZFS (ARC, L2ARC, in-line deduplication, in-line compression, snapshots and copy-on-write clones, RAID-Z, native NFSv4 ACLs, continuous integrity checking and automatic repair, …) face à toutes les appliances payantes du marché.

Et juste pour le plaisir des yeux :

Tags: nexenta, VAAI

Pour appliquer à chaud des settings comme un changement de VMM ou de swapfile, l’idéal c’est un bon vieux vmotion (grâce au “Power-on VM on destination host“). Le problème c’est que sur un cluster, le plus simple est de mettre les ESX en maintenance mode à tour de rôle mais c’est aussi le plus pénible ! Le top c’est un petit OneLiner de derrière les fagots qui va “secouer” vos VM :

get-vm|?{$_.PowerState -eq "PoweredOn"}|%{move-vm -vm $_ -destination (get-random @((($vmhost = $_.Vmhost).Parent|get-view).host|%{get-view $_}|?{$_.Runtime.ConnectionState -eq "connected" -and !$_.Runtime.InMaintenanceMode -and $_.Runtime.StandbyMode -eq "none" -and $_.name -cne $vmhost.name})).name -whatif}

Pour être un peu plus précis, ce script va faire un vmotion sur un des autres ESX disponibles du cluster parent. OneLiner oblige, ce script ne tient pas compte des vm qui seraient déplacées par DRS avant son passage. Il est par contre nécessaire d’avoir un minimum de “mou” sur le cluster en question pour éviter une vilaine contention.

Dans l’état, le script vous affichera la liste des vmotion, il suffit d’ôter le “-whatif” et relancer pour agiter la pulpe

Tags: DRS, oneliner, PowerCLI, powershell, scripting, VMotion

Au détour d’un post sur le VMware vSphere Blog, nous avons repéré un lien vers un pdf qui vaut son pesant de cacahuètes : The Design and Evolution of Live Storage Migration in VMware ESX. Pour faire simple, il s’agit d’un document rédigé par un groupe d’ingénieurs de chez VMware détaillant les différents mécanismes de svmotion depuis ESX 3.0 à ESXi 5.0 (y compris le futur Mirror Mode), que du bonheur !

Tags: SVMotion

Il y a 1001 raisons que vous rencontriez ce genre d’erreur en essayant un “Remediate” sur un cluster (c’est d’ailleurs pour ça que le message est aussi vague…) :

Le problème c’est que LE serveur qui empêche le Remediate bloque la mise à jour de l’ensemble du cluster ou pire fait échouer la tache en cours de route car il n’existe pas d’option “skip” en GUI, mais en PowerCLI (+VUM cmdlets) on fait ce qu’on veut ! Voici un petit onliner qui va mettre à jour chaque serveur du cluster l’un après l’autre même si l’une des mises à jour échoue, vous pourrez ainsi troubleshooter après coup :

Get-Cluster "mon_beau_cluster"|Get-VMHost|%{$_|Remediate-Inventory -baseline (Get-Baseline "ESXi 4.1 U1 Up") -HostFailureAction FailTask -ClusterDisableDistributedPowerManagement 1 -ClusterDisableHighAvailability 1 -ClusterDisableFaultTolerance 1 -HostDisableMediaDevices 1 -Confirm:$false}

Naturellement, vous obtiendrez la liste de vos baselines avec la comment “Get-Baseline”. Et voila le résultat :

On peut refaire un petit scan derrière :

Get-Cluster "mon_beau_cluster"|Get-VMHost|%{$_|Remediate-Inventory}
 

Tags: scripting, VUM

MAJ 06/08/2011 : C’est nettement moins stratégique maintenant que VMware a rectifié le tir…

MAJ 29/07/2011 : Veeam nous a confirmé que le ratio est bien vm/hyperviseur et qu’ils sont aussi surpris que nous le sommes de ce chiffre d’autant plus que radio moquette est au taquet avec les rumeurs autour des modifications de licencing VMware…

MAJ 19/07/2011 : Ayant mal interprété les informations, nous avons contacté Veeam pour plus de précisions.

En plein délire autour du nouveau mode licensing de VMware, Veeam vient de lancer V-index, un genre de baromètre de la virtualization qui sera mis à jour tous les trimestres.

En plein milieu de la home page, le taux de consolidation moyen de 544 grands comptes : 6:1 vm/host, c’est à dire à peine plus que ce que VMware avance mais que personne ne semble croire au moins la moitié de ce que VMware annonce (on suppose que la moyenne est supérieure à 2 sockets par host) :

The average number of VMs per physical processor is 5.7. I know this may be counter-intuitive to some customers who are pushing the envelope, but the detailed distribution of consolidation ratios is on the graph below.

Encore plus fort, le taux de consolidation “percu” (si, si !) serait supérieur au taux de consolidation réel, 9,8 contre 6,3 (déja on gagne 0,3 en passant de la home au détail) :

Perceived consolidation ratio based on respondents’ own assessment. Actual ratio based on calculation of number of virtual machines divided by number of physical hosts for each individual respondent. Hence perceived consolidation differs from actual.

On y apprend aussi que XenServer serait mieux implanté de 2% qu’Hyper-V, fraîchement entré dans le carré VIP des Leaders selon la boule de cristal de Gartner…

C’est quand meme sympa de la part de Veeam vous ne trouvez pas ?

Et pour ceux qui ne serait pas fort  en calcul mental, un petit quote des commentaires enflammés de futur ex-client VMware :

Also, vSphere 5 supports 1 TB of RAM in a VM, but why would I virtualize that server if I have to pay VMware 22x Ent Plus licenses at $3,500 ($77,000) to run that much RAM in a VM? Why wouldn’t I just save the $77K and keep it a physical server…?

Ça aurait été mieux un pigeon comme logo plutôt qu’un mouton non ?