Starting with vCenter Server 8.0 Update 3, in the vSphere Client under Virtual Machine > Configure > Disabled Methods you can remove restrictions on virtual machine operations such as migration.

Malheureusement, il semble qu’il n’y ait pas d’api public pour cette feature…

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 :

Je sais qu’on ne vous offre plus autant de contenu qu’avant (même si on va faire en sorte que ça change), qu’on aurait du faire évoluer la charte graphique et refresh les section ZFS, Tools, Presse, etc… (même si on va faire en sorte que ça change) mais sachez qu’on est toujours là et pour vous le prouver, on vous offre la dernière version de SexiGraf avec plein de nouvelles feature sympa et un petit teasing de notre prochain projet (toujours avec vmdude) :

Merci à ceux qui se souviennent encore de nous et qui continue à nous soutenir !

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

Compte tenu de son implementation de l’époque (très bien décrite, en Francais, par nos amis d’x86-secret), il était souvent recommandé de désactiver l’HT. Au fil des évolutions des CPU mais aussi des versions d’ESX, la situation a fini par s’inverser et le grand débat de l’HT pouvait prendre fin…

Internal testing shows that the recent generation of HT processors displays a higher performance gain from utilizing both logical processors. This means that the potential performance loss by letting some hyper-threads idle for a fairness reason becomes non trivial.

[...]

On vSphere 5.x, such a benefit is recognized and more CPU time is charged when both logical processors are busy. The implication of this newer charging model on HT is that a vCPU which is lagging behind can catch up more quickly even on a partial core, making it less necessary to use only the whole core.

…Ou pas, car comme l’a décrit x86-secret il y a 16 ans (!) :

Avec l’HT, ce sont désormais deux flux d’instructions qui arrivent à l’entrée du pipeline. A noter que seule la partie en amont du pipeline est, d’une certaine façon, “consciente” de la présence de ces deux flux provenant de deux threads différents, et le reste du traitement s’effectue comme s’il s’agissait d’un unique flux d’instruction. Ainsi, les deux threads se partagent les unités de calcul et les mémoires caches.

Et guess what, une équipe d’un centre de recherche hollandais dit avoir été capable d’exploiter cette faiblesse connue depuis de années (mais c’était avant AWS & Co) maintenant baptisée TLBleed. En pleine “crise” Spectre/Meltdown, Intel semble ne pas avoir l’intention d’adresser cette faille mais les choses pourraient bien changer au moment de la publication d’ici le mois d’Août. Et oui, AMD est potentiellement impacté aussi

Et surprise, l’équipe des devs du projet OpenBSD (“As of February 2018, only two remote vulnerabilities have ever been found in the default install, in a period of almost 22 years“) a décidé de désactiver l’HT dans les nouvelles releases. Et c’est d’ailleurs pour ca que toute l’histoire est remonté à la surface.

On notera au passage que l’ANSSI recommandait déjà de désactiver l’HT depuis 2015 au moins, pour les mêmes raisons.

C’est donc le moment de sortir les popcorn’s. Quand on se souvient de l’affaire du salage de TPS pour des histoires de differences de latences de cache en environnement contrôlé, on se régale de la com VMware qui justifiera la désactivation d’HT dans ESX.

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)}}}

Donc encore merci à tous et stay tuned

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 :

Nous profitons du recent article de The Information qui décrit la volonté d’Apple de construire ses propres serveurs en raison d’une crise de paranoïa, pour partager avec vous une video découverte récemment traitant de Virtual Machine Introspection, une fonctionnalité de l’API Memory Inspection de l’Hyperviseur Xen (utilisé par Amazon pour AWS par exemple…).

Cette vidéo est présentée par Tamas K Lengyel, chercheur en sécurité et développeur actif sur les projets Xen Project Hypervisor, LibVMI et DRAKVUF (Dynamic Malware Analysis system). La description faites sur la home du site de ce dernier est particulièrement flipante :

DRAKVUF is an agentless dynamic malware analysis system built on Xen, LibVMI, Volatility and Rekall. It allows for in-depth execution tracing of malware samples and extracting deleted files from memory, all without having to install any special software within the virtual machine used for analysis.

Un peu avant la 3eme minute de la présentation, vous aller voir Tamas lancer la calculatrice de Windows 7 dans une VM, depuis l’hyperviseur, en “hijackant” la mémoire du GuestOS à l’aide de l’API VMI de Xen. Si si.

Ce projet est loin d’être recent puisqu’il date de 2011 et a bien été amélioré depuis :

In Xen 4.6 a number of significant improvements to Xen’s Virtual Machine Introspection (VMI) subsystems make it the best hypervisor for security applications. Hardware support for VM Functions (VMFunc) available on Intel’s 4th generation Haswell CPUs and Atom Silvermont CPUs decreases overheads. Support for Virtualization Exceptions is now available on Intel’s 5th generation Broadwell CPUs and Atom Goldmont CPUs has significantly reduced latency. VMI support for ARM CPUs has also been added.

On vous laisse méditer sur les fonctions clefs du projets pendant que votre DSI se félicite d’avoir migré tout son système d’information sur Azure…

• Agentless start of malware execution.
• Agentless monitoring of Windows internal kernel functions.
• Guest multi-vCPU support.
• Tracing heap allocations.
• Tracing files being accessed.
• Extracting files from memory before they are deleted.
• Cloning of analysis VMs via copy-on-write memory and disk.

Dell EMC has retired ftp.dell.com and transitioned exclusively to a global downloads site with regional hosted repositories .Feb 21, 2021

MAJ 27/07/2016 : Il semblerait que la valeur “/catalog” pour la Catalog Location offre des versions nettement plus up2date.

Parmi les nombreuses méthodes pour upgrader les firmware des composants d’un serveur Dell, il y en une qui nous intéressait beaucoup mais que nous n’arrivions pas à faire fonctionner : la méthode ftp.dell.com

The repository could either be ftp.dell.com or a user generated repository on the local network share.

Sur les serveurs Dell relativement récents, il est en effet possible de “stager” et “scheduler” toutes les updates matérielles possibles directement depuis l’iDRAC en live depuis le ftp Dell. Et depuis la version v.2.21.21.21 les firmwares des HDD/SSD sont complètement supportés même sur un contrôleur en mode HBA (passthrough).

Malheureusement impossible de trouver dans les docs Dell les informations nécessaires pour y arriver :

Mais ça c’était avant de connaitre Lionel, Onsite System Engineer chez Dell, qui nous a donné le trick :

FTP Address : ftp.dell.com
User Name : anonymous
Password : user@domain.com
Catalog Location : /
Catalog Filename : Catalog.xml.gz

D’après le serveur ftp de Dell, le password doit etre un e-mail : “Anonymous access allowed, send identity (e-mail name) as password.“

Ensuite vous rebootez quand vous voulez et les patchs sont appliqués (rapidement) par le Lifecycle Controler :

Merci Lionel

Du coup, on a bêtement essayé mais évidement ça aurait été trop beau :

C’est dans une autre kb VMware que nous trouvons la solution :

Deleting the /etc/vmware/locker.conf file is not a supported method of removing the link to the scratch location. To remove the scratch location reference, empty the file rather than deleting it.

En vidant le fichier /etc/vmware/locker.conf c’est effectivement beaucoup plus efficace et on fini par un petit “flush firmware configuration” pour forcer un backup de la conf :

#vim-cmd hostsvc/advopt/view ScratchConfig.ConfiguredScratchLocation
#cat /etc/vmware/locker.conf
#cat /dev/null > /etc/vmware/locker.conf
#cat /etc/vmware/locker.conf
#vim-cmd hostsvc/advopt/update ScratchConfig.ConfiguredScratchLocation string ""
#vim-cmd hostsvc/advopt/view ScratchConfig.ConfiguredScratchLocation
#vim-cmd hostsvc/firmware/sync_config