Hypervisor.fr

Malgré tout le travail des développeurs, la version 4.1 du PowerCLI ne permet toujours pas d’utiliser la cmdlet “get-content -wait” sur un fichier situé dans un datastore vmware. Impossible donc de suivre le fichier vmware.log d’une VM pour une séance de troubleshooting. Impossible ? Non ! Rien n’est impossible en powershell :

Nous avons concocté un script qui va, via la cmdlet Copy-DatastoreItem, copier le fichier vmware.log de la VM dans le répertoire temporaire de l’utilisateur, en afficher le contenu avec un code couleur en fonction de la source (vmx, vcpu, mks, etc…), recopier le fichier toutes les 5 secondes (paramétrable avec -delay=”x”) et en extraire à chaque fois le différentiel pour l’afficher à la façon de “tail -f“. Si le fichier vmware.log est locké ou déplacé pendant l’exécution du script (vmotion/svmotion par exemple), le script va bouclé jusqu’à ce qu’il soit de nouveau disponible et chercher le nouvel emplacement du fichier si besoin.

Dans la vidéo si dessus, les éléments successifs correspondent à des opérations (vmotion, snapshot, etc…)

L’intégralité de ce qui a été affiché dans la console est également redirigé vers un fichier log consolidé $env:temp\”nom-de-la-vm”-full.log (par ex : C:\DOCUME~1\admin\LOCALS~1\Temp\1\vm-full.log)

download

Tags: PowerCLI, powershell, scripting, troubleshooting

Le VMworld 2010 SF est pour très bientôt et le contenu des sessions du VMworld 2009 est désormais disponible gratuitement :

VMworld 2010 content access will be restricted to attendees and subscription owners. Content from all previous years is free for all community members.

Les vidéos “Technology and Architecture” sont de véritables mines d’or technique pour les amateurs de cambouis virtuel, alors profitez en !

Tags: vmworld

Encore une petite fonction pratique ayant fait son apparition avec la 4.1 :

On retrouve facilement sa trace dans le SDK pour en faire un script powershell :

get-vm | foreach-object {
$vmConfigSpec = New-Object VMware.Vim.VirtualMachineConfigSpec
$vmConfigSpec.bootOptions = New-Object VMware.Vim.VirtualMachineBootOptions
$vmConfigSpec.bootOptions.bootRetryDelay = "20000" # in milisec
$vmConfigSpec.bootOptions.bootRetryEnabled = $true
(Get-View $_.ID).ReconfigVM($vmConfigSpec)
}

Que ce soit pour du PXE ou pour des incidents de NFS/iSCSI, cette fonction peut rapidement devenir indispensable…

Tags: PowerCLI, powershell, scripting

Il y a quelques jours, Maish a fait sur son blog un petit HOWTO pratique pour rapidement profiter de l’authentification AD fraîchement ajouté à la version 4.1 d’ESXi. Dans son post, Maish ajoute le groupe admin de son domaine MANUELLEMENT dans les permissions d’ESXi après l’avoir joint à ce même domaine. Nous venons de faire une trouvaille très intéressante dans les logs d’ESXi après cette manip (le nom du domaine à été remplacé volontairement pas “ADMS”) :

Hostd: [2010-07-23 23:13:26.774 FFC07E90 warning 'UserDirectory'] Group lookup failed for ‘ADMS\ESX Admins’

Après un rapide coup de google, voici l’explication dans le visdk41pubs :

By default, the ESX host assigns the Administrator role to the “ESX Admins” group. If the group does not exist when the host joins the domain, the host will not assign the role. In this case, you must create the “ESX Admins” group in the Active Directory. The host will periodically check the domain controller for the group and will assign the role when the group exists.

Il suffit donc de créer ce groupe et d’y ajouter les groupes/utilisateurs de votre choix pour qu’ils aient automatiquement le role “Administrator” sur l’ESXi :

Elle est pas belle la vie ?!

Tags: AD

La GUI de Veeam B&R ne permet de restaurer qu’une VM à la fois :

C’est là que les cmdlet VBK entrent en jeu (présentes depuis la version 4.0), et plus particulièrement Set-VBRRestoreVM (la liste de toutes les cmdlet est dans le userguide) mais pour lister les VM disponibles dans un backup importé, il faut ruser car le “job” n’existe pas (Get-VBRJob ne renvoi que les jobs de backup) :

Get-VBRJobRestorePoints job_imported *|select ObjectName

Il faut ensuite choisir une “destination” au sens Veeam (host, datasore, ressourcepool, path) :

Get-VBRJobDestination esx.vmware.local datastore

Et lancer la commande qui restaure les VM :

Get-VBRJobRestorePoints job_imported *|%{Set-VBRRestoreVM $_ (Get-VBRJobDestination esx.vmware.local datastore) thin}

Exemple en images :

Vous pouvez évidement jouer sur le filtre de nom des RestorePoints (dans notre cas, 1 full par VM) :

Tags: powershell, veeam