VMware Workstation und Player – Bios Boot Verzögerung

Jeder der schon mal auf schnellen Platten bzw. auf einer SSD eine VMware gestartet hat kennt das Problem. Das Bios zischt an einem vorbei das man nur so schaut.

Das ist auch prinzipell gut, jeder ist begeistert von performanten Systemen. Jedoch wenn man zB in das Boot Menü möchte bekommt man definitiv Stress, den man hat nur noch eine gefühlte 1/10s Zeit zum Escape drücken.

VMware hat sich da auch was einfallen lassen, ein Bios Boot delay.

Dies ist keine Einstellung in den VM Settings, das wäre auch zu einfach 🙂 , zumindest bei VMware Player und Workstation.

Am ESX wurde diese Funktion bereits in die GUI verbaut.

Stört uns aber nicht weiter da es sehr einfach ist dies in einer VM-Maschine einzustellen.

 

1. gehe zu dem Pfad an dem deine Maschine liegt.

2. Öffne mit Hilfe von einem Notepad das „.vmx“ File deiner VMware Maschine.

3.Suche dir einer leere Zeile und füge bios.bootdelay = 5000 ein.

4. Speichern und Datei schließen danach die VMware wieder starten und danach habt ihr 5 zusätzliche Sekunden. Ihr seht in der Ecke rechts unten die Zeit ablaufen bis der Boot weiter geht. Ihr könnt natürlich den Wert anpassen. 5000 = 5s ,sprich es handelt sich um Millisekunden.

Wunderbar einfache Lösung, würde ich sagen und funktioniert immer und ohne Probleme zu machen.

Getestet hab ich die Funktion in der Workstation Versionen 8,9,10 und Player 3.X , 5 und 6.

 

Take a Cup of Coffee 😛

Microsoft Cluster auf VMware vSphere 5.1

Der Fluch der VMware hat wieder mal zugeschlagen vor einiger Zeit.

Es kam die Anforderung das meherere virtuelle Microsoft Cluster betrieben werden müssen.

Nachfolgend ein paar kurze Tipps für den Betrieb:

Bei der Erstellung des Clusters umbedingt folgendes Whitepaper befolgen:
http://pubs.vmware.com/vsphere-51/topic/com.vmware.ICbase/PDF/vsphere-esxi-vcenter-server-51-setup-mscs.pdf

Diskkonfiguration

vmsettings_clusternodeBesonderes Augenmerk auf die Konfiguration der Clusterdisken richten. Hier können keine vmdk’s verwendet werden. Es müssen zwingend RDM LUN’s physical verwendet werden (pro Clusterdisk eine LUN).

Weiters die Clusterdisken auf einen eigenen SCSI Controller hängen der ebenfalls im physical Mode ist. Aber vorsicht: wie man den Screenshot entnehmen kann, dann könnt ihr die Einstellung nur verändern wenn die VM powered off ist. Anders sieht es aus wenn ihr eine neue RDM LUN mit neuen SCSI Controller hinzufügt: Hier kann die Einstellung gleich geändert werden -> nicht machen -> die VM verabschiedet sich dann mit einen schönen Bluescreen.

latencyBesonders wichtig ist die Einstellung „perennially reserved“ . Diese Einstellung wird auf jeden Host für jede RDM LUN gesetzt. Ich versuche es mal zu erklären: Da ja die LUN 2 VM’s zugeteilt ist und der Hypervisior nicht weiß das die Clusterressource mit der Disk gerade auf der anderen VM aktiv ist versucht der Host der den passive MSCS Node hat sich alle paar Sekunden die Disk zu nehmen. Geht aber nicht da diese von den anderen Host gelockt ist. Auch die Bootzeit des Hosts verändert sich ins negative. Bei einen MSCS wird euch das nicht wirklich auffallen. In meinen Fall aber werden in einen VMware Cluster 3 MSCS mit je über 15 Disken betrieben, also in Summe ca. 45 RDM LUN’s. Fazit wenn diese Einstellung nicht gesetzt ist: Bootzeit einen Hosts beträgt ca. 3-4 Stunden und die Disklatency könnt ihr dem Screenshot entnehmen.

Wie man die Einstellung setzt ist in folgenden KB Artikel gut erklärt:
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1016106

Wenn ihr die Einstellung das erste mal setzt so wie bei mir (45 Disken auf je 4 Hosts) wird mal alt bis dies erledigt ist. Beim ersten Mal hilft euch folgendes Script weiter:

Dieses Script liest alle Hosts in den Cluster aus -> sucht nach RDM LUN’s -> verbindet sich auf jeden Host mit root und ändert es über die ESXCli. Dauert ein paar Minuten bis er fertig ist. Danach idealerweiße jeden Host rebooten.  Gestartet wird das Script von der PowerCLI aus mit z.B.  „.\rdm_luns.ps1 vmware_cluster_name“

DRS/HA

Idealerweise auch eine DRS Regel für die Clusternode erstellen damit sie in meinen Fall RZ getrennt laufen.
MSCS Node von HA ausnehmen.

Weitere Einschränkungen

Ein MSCS Clusternode kann nicht im Betrieb migriert werden -> also kein vMotion/SvMotion.
Keine Snpashots
Wenn ein Host offline gehen muss dann muss auch die VM ausgeschalten werden -> Zuerst MSCS Ressourcen moven, dann VM ausschalten und dann kann mit dem Host weitergemacht werden.
Am besten für die MSCS einen eigenen VMware Cluster mit dedizieren Hosts erstellen.

Multipathing Policy via PowerCLI ändern

Hiobsbotschft vom Storageadmin:
Auf allen LUN’s in den verschiedenen VMware Clustern muss die Multipathing Policy auf Roundrobin eingestellt werden.

Bei knapp 90 LUN’s mit 26 Hosts in der GUI eine mittelschwere Katastrophe.
Jede LUN auf jeden Host angreifen, Properties öffnen, Roundrobin auswählen und speichern.
Dauert geschätzte Monate bis die händisch durch sind, in der PowerCLI nur Minuten.

Um die Multipathing Policy via PowerCLI zu ändern geht einfach folgendermaßen vor:

Seht euch zuerst mal die LUN’s auf einen Host an:

Bei den nachfolgenden 2 Befehlen folgendes beachten:

  • „naa.600* “ durch euren CanonicalName ersetzen
  • Der erste Befehl ändert es nur auf einen Host, ESXHOST durch den Hostnamen ersetzen
  • Der zweite Befehl ändert es auf allen Hosts im angegebenen Cluster
  • Änderung wurde online mit aktiven Guests durchgefüht. Kein Ausfall
  • Getestet unter ESXi 5.0 mit PowerCLI 5.1
  • Ein Wechsel von Fixed auf MRU wird nicht supportet
  • Bei keiner RDM LUN auf Roundrobin stellen die in einen Microsoft Cluster als Clustered Disk hängt.

Als kleine Lektüre:

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1011340

 

SSH aktivieren via PowerCLI

Wer kennt es nicht? Es stehen Arbeiten auf den ESXi Hosts an welche nur über SSH erledigt werden können.

Bei wenigen oder vielleicht sogar nur 1 Host kein Problem in der GUI.  In meinen Fall sind es aber 26 Stück. Viel Zeit – Viel geklicke in der GUI -> kurzum eine nervige Arbeit.

Um dieses Problem zu lösen gibt es 2 Wege.

1. SSH aktiviert lassen und den Alarm ausstellen (Kategorie Quick&Dirty, unsicher, nicht zu empfehlen)

oder die elegante Nummer 2:
Wir aktivieren und deaktivieren SSH via PowerCLI.

Nach dem Öffnen der PowerCLI und einen erfolgreichen Login in das VC führen wir diesen Befehl aus:

Und voila, auf alles Host die in diesen VC hängen wird SSH aktiviert. Nach erfolgreichen Arbeiten deaktivieren wir das Service wieder mit: