By restricting ESXi Shell access for the vpxuser, you prevent attackers, which can also be insiders who have access to vCenter Server the ability to just change the ESXi root password without knowing the original password.

Après l’énorme succès de notre billet Administrators = root qui vous permet de reset le mot de passe root de vos ESX sans le connaître (si vous êtes admin du vCenter) grâce à Get-EsxCli, voici une nouvelle méthode utilisable depuis vSphere 6.7 U2 qui nécessite encore moins de droits :

Updates a local user account using the parameters defined in the HostLocalAccountManagerAccountSpecification data object type.

Required Privileges Host.Local.ManageUserGroups

(Get-View (Get-VMHost|Get-View).ConfigManager.AccountManager).UpdateUser($(New-Object VMware.Vim.HostAccountSpec -Property @{id="root";password="VMw4re!"}))

Attention, contrairement à la méthode Get-EsxCli, cette fois un petit event va vous trahir instantanément :

Datastore UUID is required when a cluster UUID is specified

Get-VMHost|%{($_|get-esxcli).vsan.datastore.add($null, "vsanDatastore2", "11111111-1111-1111-1111-111111111111")}

En utilisant $null pour la propriété ClusterUUID, ca passe crème.

MAJ 18/05/2021 : On me signale dans l’oreillette que VMware supporterai officiellement cette méthode :

Engineering have advised that the procedure you are carrying out is applicable to your specific need and is considered supported from us

Tous les admin VMware le savent, après renommage d’une VM il convient de faire un petit Storage vMotion (aka d-motion pour les boomers) pour “propager” le nouveau nom aux fichiers de la VM en question. Et pour ceux qui l’ignorait encore, cette feature était un bug jusqu’à la version 5.0 U2 d’ESXi.

Évidement, cela nécessite d’avoir un 2eme datastore (idéalement avec des performances identiques et la bonne volumétrie) pour faire l’aller-retour de la VM (ou un Storage Pod) ce qui n’est pas souvent le cas sur un cluster vSAN pour des raisons évidentes.

Jusqu’à maintenant, les seules solutions étaient de … ne rien faire ou de connecter un datastore NFS ponctuellement pour faire le svmotion. Mais en cherchant à faire du HCI mesh en ligne de commande nous sommes tombé sur la solution (très discrètement documenté) : esxcli vsan datastore add pour créer un 2eme datastore sur le vmdk namespace.

Cette feature semble être apparu à partir de la version 6.7 U3 et est évidement accessible en PowerCLI également. Il suffit donc d’ajouter un “datastore” vSAN en précisant le nom et l’UUID de votre choix si vous le souhaitez. Il est nécessaire d’exécuter cette même commande sur tous les ESX du cluster avec le même nom et le même UUID.

Add a new datastore to the vSAN cluster. This operation is only allowed if vSAN is enabled on the host. In general, add should be done at cluster level. Across a vSAN cluster vSAN datastores should be in sync.

Voila ce que ça donne sur un cluster à 3 noeuds :

On peut donc maintenant faire notre svmotion aller-retour sans perte de performances.

Une fois l’operation terminé on peut utiliser la commande “remove” en precisant le nom et l’UUID du datastore ou carrément la commande “clear” :

Remove all but the default datastore from the vSAN cluster. This operation is only allowed if vSAN is enabled on the host. In general, add should be done at cluster level. Across a vSAN cluster vSAN datastores should be in sync.

Et aucun risque de se rater, si une vm est toujours présente sur le datastore, vous aurez droit à une belle erreur. Après avoir fait du ménage, ça passe crème :

vSphere 5 introduces a new enhancement that ensures vMotion will not fail due to memory copy convergence issues. As noted in the “Architecture” section, transfer of the virtual machine’s memory contents during the vMotion process involves an iterative precopy procedure. In most cases, a precopy iteration should take less time to complete than the previous iteration. However, a pathological case where the virtual machine modifies memory faster than it can be transferred—due to workload characteristics or network infrastructure limitations—results in aborting vMotion in vSphere 4.1 and prior releases, because precopy fails to make forward progress. The enhancement in vSphere 5 slows down the virtual machine during such pathological cases and ensures that the memory modification rate is slower than the precopy transfer rate, thereby preventing any possible vMotion failures.

Vous l’aurez compris, si l’ESX source n’arrive pas à “dépiler” la vram suffisamment vite lors d’un vMotion, l’execution de la VM en question est ralentie jusqu’à ce qu’une convergence soit possible, dans la limite des timeout par défaut.

Cette fonctionnalité semble parfaite pour les monster VM qu’on a du mal à évacuer lors d’un passage en maintenance mode mais elle est aussi très “problématique” lorsque l’infrastructure réseau n’est pas ou plus adaptée. D’où le très discret “network infrastructure limitations” dans le descriptif.

En l’occurence, le client en question mène une campagne de “refresh” de son parc afin de remplacer des machines ayant largement dépassé leur date de péremption technique. Mais sans faire évoluer son réseau. Il se retrouve donc avec machine de 2To de RAM sur un réseau 1GbE.

Evidement, à mesure que des VM de plus en plus grosses sont provisionnées sur ces environnements, les fenêtres de maintenance sont de plus en plus grande mais surtout des ralentissements apparaissent lors des mise en maintenance ou simplement quand DRS déplace de VM :

018-12-13T16:32:29.378Z cpu18:74031)VMotion: 4943: 7811810961774337297 S: Not enough forward progress, enabling SDPS (Pages left to send: prev2 693298, prev 461605, cur 497489, network bandwidth ~28.619 MB/s, 94% t2d)
2018-12-13T16:38:32.426Z cpu188:72874)VMotion: 4943: 7811810962073701659 S: Not enough forward progress, enabling SDPS (Pages left to send: prev2 126959, prev 18467, cur 15909, network bandwidth ~60.158 MB/s, 103% t2d)

SDPS fait son boulot et il le fait bien alors évidement pour faire passer des VM de 256Go qui bossent fort dans du 1GbE ca pique… Donc la prochaine fois qu’on vous dit que la bande passante de vmotion peut être sacrifiée, vous saurez quoi répondre.

Evidement, il y a un (mauvais) plan B :

To work around this issue, the Stun During Page Send (SDPS) feature can be disabled on a per-host basis.
[...]
Change the value of Migrate.SdpsEnabled to 0.

Nous en profitons pour souligner un autre “petit” détail du texte au sujet du Page Tracing :

During the pre-copy phase, the vCPU’s, in use by the virtual machine, are briefly stunned to install the page tracers.

On va en profiter pour remercier VMware, Veeam et toute la communauté pour les nominations de vExpert, vExpert vSAN et Veeam Vanguard de cette année, c’est toujours un honneur. 10 étoiles ca commence à faire

Nous avons même eu droit à une “honorable mention” dans un des vSpeaking Podcast de VMware pour SexiGraf. La classe

Et puisque c’est les 30 ans du World Wide Web ET de/du la/le Game Boy, nous nous sommes permis :

la VCSA 6.7 introduit le backup automatique programmé mais toujours pas le support du SMB (raison pour laquelle nous avions boudé la feature en 6.5). En fouillant dans la doc, nous nous sommes aperçu que le protocole webdav était supporté, c’est certainement ce que VMware sous-entend par http et https bien que ce ne soit pas extrêmement clair.

En grand fan et utilisateur intensif de NextCloud que nous sommes, nous avons testé le backup en secure webdav (https) vers un nextcloud avec succès et ce très facilement (on s’attendait à des histoires d’url comme c’est souvent le cas avec le webdav) :

Reste plus qu’à tester le restore maintenant

Donc pour donner une url plutôt que de retaper une fois de plus l’explication, voici l’extrait du VMware Virtual Networking Concepts qui fait foi :

The speed and duplex settings found in physical networking are not relevant in the virtual network, because all the data transfer takes place in the host system’s RAM, nearly instantaneously and without the possibility of collisions or other signaling-related errors.

Et si vous en aviez encore besoin, en voici la preuve :

iperf win64 entre 2 cartes e1000 "bridée" à 100Mo

iperf entre 2 cartes vmxnet3

]]> http://www.hypervisor.fr/?feed=rss2&p=5822 1 http://www.hypervisor.fr/?p=5815 http://www.hypervisor.fr/?p=5815#comments Fri, 07 Jul 2017 11:03:29 +0000 NiTRo http://www.hypervisor.fr/?p=5815 Lors d’une petite session de PowerCLI avec les célèbres (mais bientôt deprecated) VIX APIs, nous nous sommes heurté à une limite de sécurité bien connue des admins Microsoft: le Kerberos Double Hop.

Pour résumer, nous avions besoin d’exécuter un script situé sur un share depuis un ensemble de VM et nous avons bien évidement tenté de profiter du fait que VIX supporte le SSO, comme des gros fainéants. Et là, c’est le drame:

When using Integrated Security, anonymous access is disabled, and impersonation is turned on, a security measure kicks in and doesn’t allow your site to access resources on any network servers.  This includes access to a UNC path directly from IIS or SQL Server using Windows authentication.

Il nous a suffit de passer les credentials à l’Invoke-VMScript pour que l’UNC devienne accessible:

Apres un crash de carte SD de boot, sans backup du state.tgz (sinon c’est pas drôle), nous devions ré-enregistrer les VM présentent sur ce host en standalone. Ces VM étant des replicas Veeam, nous ne pouvions pas risquer de perdre le MoRef, donc obligation de les enregistrer en direct sur l’ESX fraichement redeployé. Et comme il y en avait plus de 150, pas question de le faire à la main donc pourquoi ne pas utiliser le script de Luc ? Oui pourquoi ? Et bien parce que nous voulions le faire avec un oneliner bien sur !

Voici donc un oneliner qui va chercher les fichiers vmx dans le datastore “datastore1“ (à changer au début du oneliner) et les enregistrer avec leur nom original (DisplayName dans le vmx) sur l’ESX.

Get-View -ViewType Datastore -Property Name,Browser -Filter @{"Name" = "^datastore1$"}|%{(Get-View $_.Browser).SearchDatastoreSubFolders($("[" + $_.Name + "]"),(New-Object VMware.Vim.HostDatastoreBrowserSearchSpec -Property @{matchPattern=("*.vmx")}))}|%{(Get-View -ViewType Folder -Property Name -Filter @{"Name" = "^vm"}).GetType().GetMethod("RegisterVM_Task").Invoke($(Get-View -ViewType Folder -Property Name -Filter @{"Name" = "^vm"}),@($($_.FolderPath + "/" + $_.File.Path),$null,$false,(Get-View -ViewType ResourcePool -Property Name -Filter @{"Name" = "Resources"}).MoRef,$null))}

1ere chose importante, ce onliner doit impérativement être exécuté depuis l’ESX et non le vcenter pour ne pas perde le MoRef des vm, si toute fois elles existent déjà dans le vCenter. Donc c’est un connect-viserver sur l’ESX qu’il convient d’exécuter dans votre console PowerCLI.

2eme chose, la difficulté de ce oneliner à été de faire passer un $null pour le paramètre “name” à la method RegisterVM_Task :

If this parameter is not set, the displayName configuration parameter of the virtual machine is used

Ca a l’air de rien mais en l’état c’est impossible et c’est grâce à un vieux post de Luc (encore lui !) qui retranscrit une solution provenant du support VMware :

VMware Support came up with a solution.
Big thanks to Jain

The problem was basically how to “not set” the name parameter from within PowerShell.

Nous avons donc pu intégrer ce bout de script au notre. Enjoy!

Nous avons ajouté la taille de la VM pour vous motiver à faire un VeeamZIP et à en finir définitivement avec ces VM qui risque d’être redémarrées après un crash d’ESX…

get-view -viewtype virtualmachine -property name,runtime,layoutex|?{$_.Runtime.PowerState -eq "poweredOff" -and $_.Runtime.ConnectionState -eq "connected" -and !$_.config.template}|?{$_.LayoutEx.File|?{$_.type -match "nvram"}}|%{$_|select Name, @{n="Modification";e={((get-view (get-view -viewtype datastore –filter @{"Name"=($_.LayoutEx.File|?{$_.type -eq "nvram"}).name.split("[]")[1]}).browser).SearchDatastore(($_.LayoutEx.File|?{$_.type -eq "nvram"}).name.split("/")[0],(New-Object VMware.Vim.HostDatastoreBrowserSearchSpec -property @{matchPattern=("*.nvram"); details=(New-Object VMware.Vim.FileQueryFlags -property @{modification=$true})}))|%{$_.file}).Modification}}, @{n="SizeGB";e={[math]::round(($_.LayoutEx.File|measure -Property size -sum).sum/1GB,1)}}}

C’est un honneur que nous devons en grande parti au travail effectué sur SexiGraf ainsi qu’à la communauté qui nous a largement soutenu dans notre démarche.

Merci à tous pour votre implication, vos retours et vos critique qui nous permettent de faire avancer cet outil dans la bonne direction!

In Virtual SAN 6.2, we introduced an advanced host setting called SwapThickProvisionDisabled, when enabled, removes the space reservation for .vswp files.

Une preuve de plus, s’il en fallait, que la bataille du SDS/HCI est rude jusqu’à en rogner ses best practices. En effet, nous rappelons à ceux qui auraient un trou de mémoire que placer le fichier de swap d’une VM sur un stockage “thin provisioné” va à l’encontre de toutes les bonnes règles de gestion et d’overcommit.

Do not store swap files on thin-provisioned LUNs. Running a virtual machine with a swap file that is stored on a thin-provisioned LUN can cause swap file growth failure, which can lead to termination of the virtual machine.

Regardless of the storage type or location used for the regular swap file, for the best performance, and to avoid the possibility of running out of space, swap files should not be placed on thin-provisioned storage.

Qu’importe, ca nous arrange bien aussi et pour l’occasion nous avons fait peter un petit oneliner pour fixer la bonne valeur :

Get-VMHost|%{(Get-EsxCli -VMHost $_).system.settings.advanced.set($null,"1","/VSAN/SwapThickProvisionDisabled",$null)}

Et un autre pour vérifier que c’est bien appliqué :

Get-VMHost|%{(Get-EsxCli -VMHost $_).system.settings.advanced.list($null,"/VSAN/SwapThickProvisionDisabled",$null)}

Avec un petit coup de SexiGraf pour monitorer le tout, on est bon :

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.

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

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!

Nous étions parti pour utiliser le script disponible sur VSANTeam.info mais il est malheureusement faux car il n’inclus pas l’objet VsanHostDecommissionModeObjectAction et donc le mode “ensureObjectAccessibility” est utilisé par défaut. Donc pour pouvoir utiliser le mode “evacuateAllData” ou “noAction” c’est comme ça qu’on fait :

Get-View -ViewType HostSystem -Filter @{"Name" = "esx.vmware.com" }|?{!$_.Runtime.InMaintenanceMode}|%{$_.EnterMaintenanceMode(0, $false, (new-object VMware.Vim.HostMaintenanceSpec -Property @{vsanMode=(new-object VMware.Vim.VsanHostDecommissionMode -Property @{objectAction=[VMware.Vim.VsanHostDecommissionModeObjectAction]::NoAction})}))}

Sinon vous pouvez aussi le faire avec Get-EsxCli en vous inspirant du post de William.

esxcli software vib remove -n vib1 -n vib2 -n vib3

Et pour ceux qui veulent du lourd sur esxcli, jetez un un oeil au Quick Tutorial de Steve Jin.

Historiquement, il était un peu complexe de générer ce genre d’interruption comme le détail William mais avec cette nouvelle API cela devient un jeu d’enfant en PowerCLI :

(Get-VM toto|Get-View).SendNMI()

Malheureusement, connecté au vCenter, on se mange une jolie erreur :

Exception calling “SendNMI” with “0″ argument(s): “The requested operation is not implemented by the server.”

Connecté en direct sur un ESX ça se passe nettement mieux :

En prime, on droit au nouvel événement VmGuestOSCrashedEvent :

<166>NoneZ visor04.lab.schitz.org Hostd: 2015-06-04T22:21:45.933Z info hostd[6DE83B70] [Originator@6876 sub=Vimsvc.ha-eventmgr] Event 894 : Win10 on visor04.lab.schitz.org: Guest operating system has crashed.

Sans autre tuning que le paramètre LPageAlwaysTryForNPT, TPS nous a permis de récupérer plus de 50% de RAM soit + de 12.5To sans impact sur le ressenti utilisateur (cliquez sur les graphs pour avoir le détail des compteurs) :

Merci qui ?

Et on a bien fait, parce qu’on a même réussi à créer une partition VMFS sur une clef de boot ESXi 6.0 :

Pour que ça ait de la gueule, nous avons utilisé ce qui se fait de mieux en la matière : une clef USB 3.0 MX-ES SLC NAND Ultimate Endurance capable d’encaisser 180Mo/s en écriture.

La procédure est la même que pour créer un datastore en cli avec partedUtil et vmkfstools :

Et pour le fun, on a aussi essayer sur une clef Kingston/VMware ESXi “special” :

Nous vous laissons imaginer les possibilités que cette nouvelle “unsupported“ feature pendant que nous préparons un post qui n’attendait que ça pour voir le jour…

]]> http://www.hypervisor.fr/?feed=rss2&p=5461 3