ESXi TPS Status ermitteln

Tranparent Page Sharing (TPS) ist eine Technik zur gemeinsamen Verwendung von Speicherinhalten, indem identische Pages nur einmalig abgelegt werden.

Seit Update 2b wurde TPS von VMware per Default deaktiviert, da es in seltenen Fällen zu Sicherheitsverletzungen zwischen VMs kommen konnte. Wie es sich zeigte, ist aber bei ESXi Servern mit höherer Build Nummer unter Umständen TPS noch aktiv. Das liegt daran, daß VMware TPS offensichtlich nur bei Neuinstallation abschaltet.

TPS Status

Wie kann man nun ermitteln, welchen TPS Status die ESX Server eines Clusters haben?

Hierfür kann man mittels PowerCLI einen oneliner ausführen.

# Connect-VIServer <myVC>
# Get-VMHost –State Connected | Get-AdvancedSetting –Name Mem.ShareScanGHz | Format-Table –Property Entity,Name,Value -AutoSize
# Disconnect-VIServer

Werte >0 deuten auf ein aktiviertes TPS.

TPS deaktivieren

# Connect-VIServer <YourvCenter>
# Get-VMHost –State Connected | Get-AdvancedSetting –Name Mem.ShareScanGHz | Set-AdvancedSetting –Value 0

Status erneut testen

# Get-VMHost –State Connected | Get-AdvancedSetting –Name Mem.ShareScanGHz | Format-Table –Property Entity,Name,Value -AutoSize
# Disconnect-VIServer

Links

Veeam Endpoint Backup 1.5

Veeam hat heute Version 1.5 der kostenlosen Backup Lösung Veeam Endpoint veröffentlicht. Hinzugekommen sind einige neue Funktionen wie z.B. Schutz des USB Backup Mediums vor Cryptolocker Angriffen, oder die Email Benachrichtigung.

VMware patcht glibc Lücke in mehreren Produkten

Die glibc Bibliothek ist in Linux Systemen weit verbreitet. Mitte Februar 2016 wurde vor einer kritischen Lücke in dieser gewarnt. VMware patcht nun eine Reihe seiner Produkte, die auf Linux basieren und die betroffene glibc Library verwenden. Windows Komponenten sind hiervon logischerweise nicht betroffen.

Was ist betroffen?

Betroffen sind die Hypervisoren ESXi 5.5 und 6.0. Frühere Versionen wie 5.1 oder 5.0 enthalten keine verwundbare Version von glibc.

Virtuelle Appliances auf Linux basis sind betroffen. VMware hat hierzu  KB 2144032 veröffentlicht.

Links

golem.de – Sicherheitslücke gefährdet fast alle Linux-Systeme
VMware Scurity Advisories – VMSA-2016-0002.1

ESXi – Zuordnung vmnic zu physischem Adapter testen

who is who?

Dieses Problem kennt jeder, der ESXi Server auf neuer Hardware ausrollt: Welcher physische LAN-Adapter entspricht welchem vmnic?
Eine pragmatische, aber mühsame Prozedur besteht darin, zunächst nur einen LAN-Adapter zu verbinden und dann in der DCUI den Linkstatus aller vmnics zu kontrollieren. Das Verfahren wird so lange wiederholt, bis alle Adapter mit dem Switch verbunden sind. Dumm nur, dass sich die LAN-Adapter auf der Server Rückseite und die Konsole bestenfalls auf der Server Vorderseite, oder gar in einem anderen Raum befinden. Das heißt Teamwork und Telefon ist gefragt…. Wer schon einmal versucht hat, hinter einem Server zu telefonieren, wird bestätigen dass dies kein gutes Verfahren ist.
Bei laufenden Systemen kann es aber auch sein, dass ein Entfernen der Patchkabel nicht möglich ist. Was also tun?

Ethtool

Hier kommt ein praktisches Bordmittel des ESXi zum Einsatz. Mit dem ethtool kann man physische NICs zum blinken bringen.

ethtool -p <device> <t in sec>

Um beispielsweise vmnic1 für 30 Sekunden blinken zu lassen, gibt man folgenden Befehl ein:

ethtool -p vmnic1 30

Eine Liste der im System vorhandenen vmnics und der korrespondierenden Hardware erhält man mit den Befehl

esxcfg-nics -l

Dies ist nur eine von vielen Möglichkeiten, die uns das ethtool an die Hand gibt. So kann man beispielsweise auch die Firmware eines physischen NICs abfragen.