Administrators = root

Dans le what’s new de vSphere 6.0 nous avions remarqué un paragraphe intéressant concernant la gestion des comptes locaux des ESX avec esxcli :

ESXi 6.0 enables management of local accounts on the ESXi server, using new ESXCLI commands. The ability to add, list, remove, and modify accounts across all hosts in a cluster can be centrally managed using a vCenter Server system. Previously, the account and permission management functionality for ESXi hosts was available only with direct host connections. Setting, removing, and listing local permissions on ESXi servers can also be centrally managed.

Nous avons enfin pris le temps de tester cette nouvelle fonctionnalité et pouvons confirmer qu’il est maintenant possible de changer le password du compte root des ESX sans le connaitre pour peu qu’on soit admin du vcenter (alors qu’il fallait bien une connexion direct pre 6.0) :

Get-VMHost|%{($_|Get-EsxCli).system.account.set($null,"root","NewPassword","NewPassword")}

Par contre, les contraintes de cette manipulation sont nombreuses comparé à un simple “passwd” :

An uppercase character that begins a password does not count toward the number of character classes used.

A number that ends a password does not count toward the number of character classes used.

Nous avons aussi découvert à nos dépends qu’un $ au milieu du password était mal interprété. Il convient donc d’être vigilant et de bien tester que le changement soit effectif.

Dump ElasticSearch en Powershell

Parce que les logs d’ESXi sont particulièrement éphémères, il est fortement recommandé de les rediriger vers un syslog. Dans le cadre d’un SR chez VMware, il nous a fallu extraire le contenu d’une appliance SexiLog pour plusieurs ESX sur une période donnée. On a fait chauffé le notepad++ pour faire un truc en powershell qui fait le taff comme il faut :

$i=0
$pre = '{"fields" : ["message"],"from":'
$post = ',"size": 2000,"query":{"filtered":{"query":{"bool":{"should":[{"query_string":{"query":"hostname.raw:esx.vmware.com"}}]}},"filter":{"bool":{"must":[{"range":{"@timestamp":{"from":1450738800000,"to":1450997999999}}}]}}}}}'
$msgs=1

while ($msgs) {
$msgs=$false
$body = $pre + $i + $post
$msgs=(Invoke-RestMethod -URI "http://demo.sexilog.fr:9200/_search?pretty=1" -Method 'POST' -ContentType 'application/json' -Body $body -TimeoutSec 5).hits.hits.fields.message
$msgs|%{$_.Trim()}|Out-File -FilePath c:\temp\esx.vmware.com.log -Append
$i=$i+2000
}

Il convient de remplacer les FQDN esx.vmware.com et demo.sexilog.fr par les vôtres et d’ajuster les valeurs from/to en epoch.

Le script extrait tous les messages pour le serveur donné, sur la période donné vers un fichier de log par batch de 2000 :

Et une fois l’export terminé, le script se termine par une erreur “attendue” :

A titre indicatif, il a fallut 1h pour extraire 1Go de log. Egalement dispo sur GitHub si besoin.

Tags: , ,

Hyper-VIX

Ya pas à dire, quand il s’agit de marketer une fonctionnalité vielle de 7 ans comme si c’était une nouveauté, on peut vraiment compter sur Microsoft.

En effet, à la lecture du titre de cette news “Using PowerShell Direct and other new features in Hyper-V on Windows 10” on s’attend clairement à un truc révolutionnaire. Vous ne pouvez pas dire le contraire, “Powershell Direct” ça claque !

Alors, naïfs, on se précipite sur TechNet pour en savoir plus ! Mais là, comme pour le coup du Smart Paging, c’est le drame :

It is a new way of running PowerShell commands inside a virtual machine from the host operating system easily and reliably
[...]
Note: This only works from Windows 10/Windows Server Technical Preview Hosts to Windows 10/Windows Server Technical Preview guests.

Bon là on ne va pas y aller par 4 chemins, on est sur du réchauffé++ car je rappel pour ceux qui n’étaient pas encore nés que cette feature existe chez VMware depuis 2009 :

Invoke-VMScript: Runs the specified PowerShell script in the guest OS of each of the specified virtual machines.

Et depuis 2011, elle supporte le SSO :

All VIX cmdlets support using SSPI for Windows guest machines if the underlying vCenter Server is 5.0 version. This might not be valid for users who are local, and not domain users. VIX cmdlets are Invoke-VMScript, Copy-VMGuestFile, *-VMGuestNetworkInterface, *-VMGUestRoute, and Set-HardDisk when used for guest disk resizing.

Et pour ceux qui l’ignorait, ce n’est évidement pas limité à Windows comme c’est le cas d’Hyper-V :

ScriptType: Specify the type of the script. The valid values are PowerShell, Bat, and Bash. If the virtual machine OS is Windows, the default value is PowerShell. If the virtual machine OS is Linux, the default value is Bash.

Tags: , ,

Failing restore from old Win8 checkpoint

Alors que Windows 2012 R2 est officiellement supporté comme GuestOS depuis ESXi 5.0 U1, un changement de la fameuse feature VM-Generation ID rend impossible le vmotion vers un ESXi de version supérieure comme le détail la kb 2033723:

Due to changes in Microsoft’s virtual machine generation counter specification that was introduced in the Windows 8 Release Preview and Windows Server 2012 RC, corresponding changes were also required in the virtual machine BIOS. Snapshots, checkpoints and VMotion actions of virtual machines with these versions of Windows are not compatible between ESXi hosts that have implemented different revisions of Microsoft’s virtual machine generation counter specification.

Snapshots and checkpoints of virtual machines with Windows 8 or Windows Server 2012 that are taken on a host running ESXi 5.0 Update 1 or ESXi 5.0 P03 will not resume on a host running later versions of ESXi ( ESXi 5.0 Update 2, ESXi 5.1, etc.) and the reverse.

VMotion is prevented between hosts running ESXi 5.0 Update 1 or ESXi 5.0 P03 to and from hosts running later versions of ESXi.

2015-11-05T15:01:32.804Z| vmx| I120: DUMPER: Group ‘VMGenCtr’ not found.
2015-11-05T15:01:32.804Z| vmx| I120: CPT: could not find group VMGenCtr
2015-11-05T15:01:32.804Z| vmx| I120: DUMPER: Item ‘AddrReg’ [-1, -1] not found.
2015-11-05T15:01:32.804Z| vmx| I120: DUMPER: Item ‘CtrCount’ [-1, -1] not found.
2015-11-05T15:01:32.804Z| vmx| I120: DUMPER: Item ‘CtrCountX’ [-1, -1] not found.
2015-11-05T15:01:32.804Z| vmx| I120: VMGenCtrCheckpoint: Failing restore from old Win8 checkpoint
[...]
2015-11-05T15:01:32.804Z| vmx| I120: [msg.checkpoint.migration.failedReceive] Failed to receive migration.
2015-11-05T15:01:32.804Z| vmx| I120: [msg.checkpoint.mrestoregroup.failed] An error occurred restoring the virtual machine state during migration.

Evidemment la solution proposée par VMware passe par un shutdown de la VM mais lors d’une grosse migration ça fait pas sérieux donc nous avons cherché un vrai workaround.

Sachant que cette feature est exclusivement utilisé par Active Directory Domain Services (pourquoi l’imposer à toutes les VM d’ailleurs ?!), nous avons chercher à la désactiver pour que le resume du vmotion sur l’ESXi de destination ne pose plus de problème. Et pas plus loin que dans une autre kb vmware, nous avons trouvé la solution:

The workaround involving adding the vmGenCounter.enable parameter to the virtual machine .vmx file may cause the new snapshot protection for domain controllers introduced in Windows 8/Windows Server 2012 to stop functioning.

Un petit coup de PowerCLI pour appliquer le setting à chaud :

Get-VM Windows2012R2|Get-View|%{$_.ReconfigVM((New-Object VMware.Vim.VirtualMachineConfigSpec -Property @{extraconfig=@((New-Object VMware.Vim.optionvalue -Property @{Key="vmGenCounter.enable";Value="FALSE"}))}))}

Et le vmotion passe en douceur :)

Tags: , ,

Monitor, like a boss.

Si comme nous, vous cherchiez une solution de monitoring cluster centric, ne cherchez plus. Nous l’avons faites pour vous :

Très loin des dashboard cacti fastidieux à réaliser et limités en scalabilité, nous avons voulu une appliance la simple possible : deploy, add vcenter, relax!

Tags: , , , ,