Beiträge

Veröffentlicht am

ZeroClient: Problem bei Upgrade des Direct Service

Installation oder Update des Panologic DirectService unter Windows7 32Bit kann zu folgender Fehlermeldung führen:

 

 

“Please install Virtual Guest Service or Tools prior to installing Pano Direct Service”

Die VMware Tools waren zu diesem Zeitpunkt installiert und aktiv. Ein Neustart der VM oder eine Reaparaturinstallation der Tools brachte keine Besserung. Der angemeldete Nutzer hatte Domänen-Administrator Rechte.

Die Lösung ist recht einfach. Die Installer-MSI nicht über die GUI starten, sondern über die CLI im Kontext des Administrators: Start > suchen > cmd > “Als Administrator ausführen”

Dazu kopiert man die MSI praktischerweise ins TEMP Verzeichnis und startet sie über die CLI des Administrators. Danach läuft das Setup durch.

 

Veröffentlicht am

vSphere5: Lizenzmodell aktualisiert

In meinem letzten Artikel zum Thema vSphere5 Lizenzierung setzte ich mich mit dem neuen Preismodell und der Auswirkung auf Bestandskunden auseinander. Nach dem kräftigen Gegenwind aus Richtung der Anwendergemeinschaft hat VMware sein urprüngliches Lizenzmodell für vSphere5 nun nochmals überarbeitet. Insbesondere die vRAM Menge pro Sockel-Lizenz wurde deutlich erhöht.

Quelle: VMware

Mein Rechenbeispiel des ursprünglichen Posts sieht nun etwas verändert aus:

Ich ging aus von 3 ESX Hosts mit je 2 CPU und je 96GB RAM (Gesamt RAM: 288GB)

  • vSphere4 Standard: 6 Lizenzen (nutzbarer Gesamt RAM 288GB)
  • vSphere5 Standard: 6 Lizenzen mit je 32GB vRAM. Nutzbarer Gesamt RAM: 192GB (vorher 144GB)
  • vSphere5 Enterprise: 6 Lizenzen mit je 64GB vRAM. Nutzbarer Gesamt RAM: 384GB (vorher 192GB)
  • vSphere5 EnterprisePlus: 6 Lizenzen mit je 96GB vRAM. Nutzbarer Gesamt RAM: 576GB (vorher 288GB)

Damit sieht die Rechnung schon bedeutend besser aus. Selbst im Standard Modell muß der Kunde keine Lizenzen nachkaufen. Er hat zwar nicht genügend vRAM Lizenzen für seine physischen 288GB, jedoch darf man bei einem ESX Cluster nicht mit Vollauslastung rechnen. Es sollte grundsätzlich ein n-1 Modell gefahren werden. D.h. ein Knoten kann ausfallen und die restlichen übernehmen die Last. Für drei Knoten bedeutet das man darf jeden Knoten im Schnitt nur zu zwei Dritteln auslasten um nicht die Hochverfügbarkeit zu gefährden. Eine 2/3 Auslastung in Bezug auf RAM bedeutet die Anlage hat einen maximalbedarf von 192GB vRAM – und genau das ist durch die neue Lizenz abgedeckt. Im Fehlerfall wird das vRAM des ausgefallenen Hosts den verbleibenden Servern zur Verfügung gestellt. D.h. sie haben weiterhin 192GB vRAM, was ihrer physischen Kapazität entspricht.

Wer nicht mit Papier und Bleistift rechnen möchte, kann mit Hilfe eines Powershellskripts von Hugo Peeters den Lizenzbedarf einer bestehenden Anlage prüfen. Dieses Skript wurde bereits auf das neue Modell angepasst.

VMware hat ebenfalls reagiert und bietet Informationen und ein Berechnungstool (vSphere Licensing Advisor) an. Diese wichtige Info stammt von Yellow-Bricks.

Veröffentlicht am

Toten Pfad zum Target entfernen

Nach einem Infrastruktur Änderung änderten sich Pfade zu LUNs. Zuvor wurde ein Fibrechannel Point-to-point Verkabelung auf Fabric umgestellt. Der ESX Host sah dann sein Target auf einem neuen Pfad und markierte den alten als tot (rot). Ein Adapter rescan brachte zunächst keinen Erfolg. Man muß den HBA zwingen, tote Pfade zu entfernen. Das funktioniert mit einem Befehl der vSphereCLI.

esxcfg-rescan --server <VC> --username --vihost <ESX> -d vmhba1

Der Parameter -d bedeutet laut Manpage “Scan removing dead devices”.