Hypervisor.fr

Alors que Microsoft continue à prétendre que le mécanisme de memory overcommit est dangereux pour votre production (mais, certainement comme pour Vmotion, lorsque cette fonction sera disponible sur Hyper-V, ce sera un gain pour la dynamicité du datacenter…), notre confrère CTXBLOG nous confirme que XenServer 6 sera capable de “Dynamic Memory Control & Overcommit”. Virtualization.info rapporte que RedHat est également très actif sur le sujet.

VMware, soucieux de conserver son avance en la matière, ajoutera un nouveau mécanisme de memory overcommit dans sa future version : la “memory compression”. Il s’agirait d’une compression dynamique de pages, ultime étape avant le swapping.

HyperviZor.com a d’ailleurs dédié un superbe diagrame à ce sujet :

Tags: memory overcommit

N’ayant pas eu le plaisir de participer aux TechDays 2010 (17000 visiteurs), la curiosité nous a conduits jusqu’aux vidéos des Plénières. Le silverlight n’étant pas encore parfaitement maitrisé par Microsoft, impossible de naviguer dans la vidéo sans avoir tout en buffer… Nous nous sommes donc permis de mettre sur Dailymotion un extrait d’une démo de Live Migration grâce à SCVMM R2 :

La VM à migré sans interruption, tout le monde est en plein extase : bienvenue en novembre 2003 !

Tags: Bullshit

Pour activer Fault Tolerance sur une VM ou pour garantir les meilleurs performances -pour le stockage-, le (ou les) vmdk doit être au format Thick EagerZeroed (cf la liste des différents formats). Depuis vSphere 4.0 il possible de choisir ce format lors de la création de la VM (grâce à l’option “support clustering features”) mais, par la suite, seul le format Thick est disponible lors d’un storage vmotion.

Jusqu’alors, la seule solution était de cloner le vmdk (en GUI ou avec vmkfstools) au bon format et de la substituer à l’ancien. Mais en fouillant dans le SDK et grâce à l’outil Project Onyx, nous avons identifié les propriétés correspondant au format d’un vmdk et Luc Dekens nous a aider à les integrer dans un script de “re-configuration”

Avec ce script, vous pourrez changer le format du (ou des) vmdk d’une VM en Thick EagerZeroed sans création de vmdk supplémentaire.

param([string] $vmName)
$vm = Get-VM -Name $vmName |Get-View
$spec = New-Object VMware.Vim.VirtualMachineConfigSpec
$vm.Config.Hardware.Device | where {$_.GetType().Name -eq "VirtualDisk"} | % {
 
	$deviceChange = New-Object VMware.Vim.VirtualDeviceConfigSpec
	$deviceChange.operation = "edit"
	$deviceChange.device = $_
	$deviceChange.device.backing.thinProvisioned = $false
	$deviceChange.device.backing.eagerlyScrub = $true
	$spec.DeviceChange += $deviceChange
}
$vm.ReconfigVM_Task($spec)

Malheuresuement, cette manipulation ne peut PAS être effectuée à chaud…

Tags: PowerCLI, powershell, scripting

Sachant qu’il n’est pas recommandé de dépasser la barre des 32 hosts ESX(i) par volume VMFS, voici un petit script pour vous faire une idée sur votre infra en quelques secondes :

Get-Datastore|?{$_.Type -match "VMFS"}|get-view|?{($_.Host).count -gt "1"}|select name,{$_.host.count}

Tags: powershell

MAJ 25/01/2011 : La kb à été mise à jour et une solution à chaud existe maintenant via les advanced settings du vcenter.

Dans de rare cas de figure, vous aurez peut être à relier des VM par un lien réseau interne à l’ESX. Il vous faudra donc pour cela créer un vSwitch sans attachement physique comme celui-ci :

Sachez par contre que si vous devez maintenir ce lien au sein d’un cluster, en cas de vmotion vous aurez droit à cette erreur :

En effet, selon la kb VMware relatif à ce sujet :

VMware does not support VMotion migration of virtual machines that are connected to an internal only switch

Mais sur le forum VMware, un français nous donne la parade :

<migrate>
<test>
<CompatibleNetworks>
<VMOnVirtualIntranet>false</VMOnVirtualIntranet>
</CompatibleNetworks>
</test>
</migrate>
You have to create this section at the end of the vpxd.cfg file but still in the section <config>

Et un restart du service vpxd…

Tags: VMotion