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…

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 !

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 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.

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

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.

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.

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.

Pour ce test nous nous sommes procuré des SSD Intel 530 afin de vérifier que le design du PCB ne représente pas un frein aux performances et la faible latence des puces NAND. Nous nous sommes également amusé à démonter le backplane pour étudier la construction générale du produit.

Contrairement à ce que nous avions imaginé, vous pouvez constater sur les photos qu’il reste encore un peu de place entre les SSD ce qui peut laisser envisager une version 10 slots (SSD only par contre) ! Compte tenu de l’usage cible nous avons retiré les 2 ventilateurs 40 mm ce qui facilite le câblage et nous précisons au passage qu’une seule prise d’alimentation peut suffire même si nous craignons que ce ne soit pas idéal pour le PCB. Comme pour les autres produit de la gamme, la finition est très bonne et le coté “full metal” offre clairement une impression semblable aux produits des gammes professionnels chez les grands constructeurs.

Pour le benchmark, nous avons installé le rack dans un HP ML 110 G6 équipé d’un Xeon  x3430 et d’une carte LSI 9240-8i. C’est sur FreeNAS 9.3 que nous avons lancé iozone afin d’obtenir un résultat un peu plus réaliste qu’avec un simple dd :

180 µs de latence à 2.5 Go/s c’est quand même pas mal du tout

Durant le test de “reread”, nous avons pris une capture d’iostat pour avoir une idée de l’état des SSD et on remarque qu’ils ne sont même pas au maximum de leur capacité à en croire le %b :

Et pour le fun, on s’est dit que ce serait la classe dans mettre ça dans un N40L même si le processeur est loin de pouvoir suivre :

]]> http://www.hypervisor.fr/?feed=rss2&p=5492 2 http://www.hypervisor.fr/?p=5447 http://www.hypervisor.fr/?p=5447#comments Wed, 25 Mar 2015 21:50:54 +0000 NiTRo http://www.hypervisor.fr/?p=5447 Puisque l’autre cofondateur de SexiLog s’est fendu d’un post plutôt joufflu, nous ne ferons que compléter l’argumentaire En l’occurrence, notre recherche de solution de gestion de logs pour ESXi remonte à bien avant Graylog2 avec le fameux php-syslog-ng (devenu le très payant LogZilla), puis LogAnalyzer. Ensuite il y a eu la tentative raté de Partylog2. Et on ne vous parle pas du misérable vSphere Syslog Collector ni du coûteux Log Insight… Pour finir par le faire nous même :

Nous vous recommandons donc vivement de vous rendre sur sexilog.fr pour y télécharger la dernière version de l’appliance et la déployer sur votre infra, envoyer vos logs ESXi dessus et profitez des dashboards intégrés

Rock n’ Log!

Ah tiens, on a oublié de parler de Splunk.

Que ce soit pour créer de nouvelles alarmes dans le vCenter ou parce que certains messages d’alerte ne sont visible que dans les logs d’ESXi, nous avions autrefois recours à la page vCenter Events de Veeam pour trouver l’inspiration. Cette page n’étant plus mise à jour depuis fin 2011, nous avons chercher à produire un page similaire pour nos propres besoins et l’avons, depuis quelques temps, mise à dispo dans la rubrique “Links”. Voici la commande PowerCLI qui vous permettra de générer la votre depuis votre vCenter (et plugins) :

(Get-View EventManager).Description.EventInfo|select @{n="event";e={if ($_.key -match "^EventEx$|^ExtendedEvent$") {$_.FullFormat.split("|")[0]} else {$_.key}}},category,description,FullFormat|Out-GridView

Nous nous sommes très largement inspiré d’un post de Luc pour ce oneliner

Récemment, William à posté une liste similaire issue d’un fichier disponible en clair dans les librairies d’ESXi mais nous avons remarqué qu’il ne contenait pas les événements vob.* que nous pouvions trouver dans les logs. Après quelques recherches, nous avons fini par faire un coup de strings sur le binaire /usr/lib/vmware/vob/bin/vobd (issue d’un ESXi 5.5 1331820) pour en extraire les précieux messages. Nous avons ensuite “dédoublonné” la liste obtenue (vob.vmfs.heartbeat.timedout == esx.problem.vmfs.heartbeat.timedout par exemple) pour ne garder que le différentiel :

vob.net.fence.port.fail
vob.net.pg.uplink.transition.down
vob.net.pg.uplink.transition.up
vob.net.dvport.uplink.transition.down
vob.net.dvport.uplink.transition.up
vob.net.uplink.watchdog.timeout
vob.net.migrate.bindtovmk.failed
vob.net.portset.port.connect.fail
vob.net.lacp.uplink.peer.noresponse
vob.scsi.scsipath.add
vob.scsi.scsipath.remove
vob.scsi.scsipath.por
vob.scsi.scsipath.badpath.unsafepe
vob.scsi.scsipath.badpath.unreachpe
vob.scsi.scsipath.pathstate.dead
vob.scsi.scsipath.pathstate.off
vob.scsi.scsipath.pathstate.on
vob.scsi.scsipath.pathstate.standby
vob.iscsi.connection.started
vob.iscsi.connection.stopped
vob.iscsi.connection.error
vob.iscsi.target.async.event
vob.iscsi.session.recovery.timeout
vob.iscsi.target.permanently.removed
vob.iscsi.isns.discovery.error
vob.vmfs.lock.corruptondisk.v2
vob.user.dcui.factory.network.restored
vob.user.dcui.restarting.hostagents
vob.user.dcui.restore.factory.defaults
vob.user.dhclient.lease.offered.noexpiry
vob.user.coredump.unconfigured2
vob.user.coredump.capacity.insufficient
vob.user.scratch.partition.size.small
vob.user.scratch.partition.unconfigured
vob.user.dcui.reboot.host
vob.user.dcui.shutdown.host
vob.user.esxcli.host.reboot
vob.user.coredump.configured2
vob.cpu.mce.log
vob.cpu.nmi.ipi.vmkcs
vob.cpu.nmi.ipi.unknowncs
vob.cpu.nmi.ipi.halt
vob.cpu.nmi.ipi.savebt
vob.uw.core.dumped
vob.external.warning
vob.external.error
vob.external.info
vob.user.external.warning
vob.user.external.error
vob.user.external.info
vob.visorfs.tardisk.readonlyfile
vob.vsan.pdl.offline
vob.vsan.pdl.online
vob.vsan.net.gotip
vob.vsan.net.noip
vob.vsan.rdt.noip
vob.vsan.net.no.connectivity
vob.vsan.net.created
vob.vsan.net.reconfigured
vob.vsan.cmmds.disabled
vob.vsan.cmmds.unloaded
vob.vsan.cmmds.enabled
vob.vsan.lsom.diskerror

Pour les curieux, voici la liste originale.

La solution la plus “connue”, même si c’est la moins pratique à notre avis, est le boot from SAN. En plus d’être longue à mettre en place, cette solution impose une dépendance forte au SAN qui peut poser de sérieux problèmes en cas d’incident sur la baie ou la fabric. A notre avis, le seul avantage de cette solution est la redondance liée au multipathing scsi.

La deuxième solution est évidemment le boot PXE, connue depuis qu’Autodeploy fait partie officiellement de l’arsenal de déploiement d’ESXi. Bien que pensé à la base pour du PXE, l’idée de dépendre du réseau pour booter ESXi ne fait pas encore l’unanimité. Il est possible de booter en PXE en repoussant un backup de la configuration (comme le faisait PXE Manager) mais la solution officielle de VMware est Autodeploy qui boot des ESXi vierges et repousse un host profile dessus. Pour peu que l’infrastructure DHCP/TFTP/vCenter soit hébergée sur les ESX managés par cette même infra, vous avez l’interdiction de couper le courant à vie.

La troisième solution est le boot from USB flash ou SD flash qui fut la solution “de lancement” d’ESX 3i en 2007 :

[...] Veso has thrown out hard disks in favor of embedding VMware’s new 32MB ESX 3i hypervisor in flash memory.

Cette solution à l’avantage d’être peut coûteuse, facile à mettre en place et indépendante. ESXi étant stateless, le nombre d’écritures sur la mémoire flash est très faible et réduit par conséquent les risques d’usure prématurée du support. C’est selon nous la solution la plus élégante et efficace, c’est donc celle ci que nous avons choisi pour libérer les 2 slots disques de nos blades.

Suite à de nombreux problèmes de contrôleurs, le cartes SD et micro SD ont pris le dessus sur les clefs USB en entreprise mais le principe reste identique donc nous testerons notre méthode de migration sur une clef kingston. Le principe est de restaurer un backup du bundle d’un ESXi visor-thin sur une nouvelle installation visor-usb.

visor-thin indicates an installable deployment
visor-usb indicates an embedded deployment
visor-pxe indicates a PXE deployment

Après avoir vérifié qu’aucune trace du “mode” d’installation n’était présente dans le fichier esx.conf du bundle, nous avons tout simplement utilisé vmplayer pour tester la migration sur un ESXi nested. Et pour ceux qui se demande comment nous avons booté sur une clef usb avec vmplayer, allez faire un tour chez Plop :

Comme vous pouvez le constater, la migration vers une clef usb se déroule sans accrocs et si VMware vous dit que ce n’est pas une méthode supportée, demandez leur de vous prouver que vous l’avez utilisé…

Premier constat, le temps de compute des valeurs moyennes de cpu et ram est très important et c’est évidement proportionnel au nombre de nœuds. Pour optimiser ce script, nous nous somme rabattu sur les quickstats du resource pool “racine” du cluster (aka “resources”). Ces valeurs étant basé sur les 5 dernières minutes d’activité (et non sur les 24 dernières heures comme le script original), il faut l’exécuter au moment de la journée où l’activité du cluster est la plus importante pour avoir des valeurs vraiment représentatives du workload. Le gros avantage de ces valeurs est qu’il n’est pas nécessaire de faire une requête dans les statistiques, elles sont pré-computées et disponibles sous forme de propriétés, on passe donc d’une exécution pouvant aller jusqu’à plusieurs minutes à 2 secondes par cluster. Comme dirait Mozinor, “tu peux pas test”.

Deuxième constat, le mode “slot size” d’admition control ne tiens pas compte de l’overcommit. Duncan et Frank l’explique en détail dans leur bouquin mais voici un exemple encore plus parlant :

3 hosts sur 12 (25%) en mode “slot size” contre 67% en mode “resources”. Dans ce dernier mode, HA tiens compte de la consommation réelle du cluster pour déterminer ce qu’il reste.

With the resources failover policy in place, vSphere HA uses the following calculations to control virtual machine migration in the cluster
1. Calculate the total resource requirements for all powered-on virtual machines in the cluster.
[...]

Il est donc clair que sur des gros cluster avec de l’overcommit, le mode “slot size” est totalement inutilisable.

En attendant de déguster la dinde farcie aux marrons de tante Yolande, voici le oneliner powershell à deguster en amuse-bouche :

foreach ($cluster in (Get-View -ViewType ClusterComputeResource|?{$_.ConfigurationEx.DasConfig.Enabled})) {,($cluster|?{$_.host}|select @{n="mem";e={(($_|%{(Get-View $cluster.ResourcePool|?{$_.Parent -eq $cluster.Moref}).Summary.QuickStats.HostMemoryUsage/(Get-View -ViewType virtualmachine -SearchRoot $cluster.moref -Property Runtime.PowerState|?{$_.Runtime.PowerState -eq "poweredOn"}).count}))}}, @{n="cpu";e={(($_|%{((Get-View $cluster.ResourcePool|?{$_.Parent -eq $cluster.Moref}).Summary.QuickStats.OverallCpuUsage)/(Get-View -ViewType virtualmachine -SearchRoot $cluster.moref -Property Runtime.PowerState|?{$_.Runtime.PowerState -eq "poweredOn"}).count}))}}, @{n="vcpu";e={(Get-View -ViewType virtualmachine -SearchRoot $cluster.moref -Property Runtime.PowerState,Config.Hardware.NumCpu|?{$_.Runtime.PowerState -eq "poweredOn"}|Select @{n="vcpu";e={$_.Config.Hardware.NumCPU}}|Measure-Object -Average -Property vcpu).average}}|measure -average -property mem,cpu,vcpu|%{[math]::round($_.average,0)})|%{if (($_|measure -Sum).sum -ne ($cluster.ConfigurationEx.DasConfig.Option|?{$_.key -match "das.slotCpuInMhz|das.slotMemInMB"}|measure -Sum -Property value).sum -and ($_|measure -Sum).sum -gt "64") {$cluster.ReconfigureComputeResource((New-Object VMware.Vim.ClusterConfigSpecEx -property @{dasConfig=(New-Object VMware.Vim.ClusterDasConfigInfo -property @{option=@((New-Object VMware.Vim.OptionValue -property @{key="das.vmMemoryMinMB";value=$_[0].tostring()});(New-Object VMware.Vim.OptionValue -property @{key="das.vmCpuMinMHz";value=$_[1].tostring()});(New-Object VMware.Vim.OptionValue -property @{key="das.slotMemInMB";value=$_[0].tostring()});(New-Object VMware.Vim.OptionValue -property @{key="das.slotCpuInMhz";value=$_[1].tostring()}))})}),$true)}}}

Joyeux Noël à tous !