vSphere 5 Lizenzierung
VMware hat leider beschlossen mit Version 5 das Konzept der bisherigen "Per Socket" Lizenzen aufzuweichen, und zusätzlich noch nach vergebenen Arbeitsspeicher (Arbeitspeicher der einer VM max. zur Verfügung gestellt wurde) zu lizenzieren.
Folgende Staffelung ist aktuell vorgesehen (Je Lizenz)
- Essentials, Essentials Plus oder Standard = 1 x Socket + 24 GB vRAM
- Enterprise: 1 x Socket + 32 GB vRAM
- Enterprise Plus: 1 x Socket + 48 GB vRAM
Wenn man ein vCenter verwendet werden die vRAM Kapazitäten der gesamten Infrastruktur zur Verfügung gestellt, d.h. es wird ein vRAM Pool gebildet.
Howto: ESXi 4.1 auf USB Stick installieren
Aktuelles ISO File herunterladen
Aktuelles VMware ESXi DVD Image von VMware oder dem Serverhersteller herunterladen:
http://downloads.vmware.com/d/info/datacenter_downloads/vmware_vsphere_4/4_0
Für HP,Fujitsu, Hitachi und Dell Server gibt es hier vom Hersteller mit Custom CIM Providern angepasste ISO Files:
http://downloads.vmware.com/d/details/esxi41u1/ZHcqYnRlQEBiZCpwaA==#drivers_tools
VMware ESXi 4.1 verliert Management Network Verbindung
An einem unserer Standorte habe ich ab und zu das Problem das alle drei ESXi 4.1 Hosts gleichzeitig die Verbindung zum vCenter in der Zentrale verlieren. Alle Server sind von meinem Standort aus nicht per Ping erreichbar, vom lokalen Standort aus aber schon. Hier vermute ich ein Problem im Zusammenspiel mit unserem Nortel Switch vor Ort. Ein Neustarten des Mmnt. Networks über die Consolen GUI half nur bei einem der Server.
Als ich mir die Konfiguration der Hosts angeguckt habe ist mir folgendes aufgefallen:
ESX1
vmk0: Management Network
ESX 2 und 3
vmk0: vMotion Network
d.h. ein Neustart über die GUI startet bei 2/3 nicht das Management Network sondern die vMotion Network neu (Lt. VMware wohl ein bereits bekanntes Problem). Um die Maschinen ohne neustart wieder ans Netz zu bekommen habe ich folgende Aktionen durchgeführt:
- Per Remote Consolen Mngmt Software auf den Server schalten (ILO oder ähnliches)
- Den Local Tech Support Mode aktivieren
- Über die Console das bestehende Management Network löschen
-
esxcfg-vmknic -d "<Name des Management Network>"
-
- und neu erstellen:
-
esxcfg-vmknic -a "<Name des Management Network>" -i <IP Adresse> -n <Netzwerkmaske>
-
Sofort danach waren die Maschinen wieder ansprechbar. Jetzt muss ich nur noch raus finden woran genau der Connection Lost herkommt.
Snow Leopard in VMware Workstation 7.1
Voraussetzungen
- CPU mit erweiterten Virtualisierungs-Funktionen
Intel: Intel VT
AMD: AMD-V
Diese sind u. A. notwendig um unter VMware ein 64Bit Betriebssystem zu betreiben. Ob man eine kompatible CPU hat kann meistens einfach im BIOS herausgefunden werden, denn da kann man die entsprechende Funktion ein- und ausschalten. Wenn nicht, einfach danach googeln. Die Core2Duo/Quad können es z.B. fast alle. Mit AMD habe ich leider zu wenig Erfahrung um hier vernünftige aussagen treffen zu können.
- Mindestens 2 GB RAM, besser sind 4-8GB
- Eine Snow Leopard Installations-DVD
- VMware Workstation 7.1.1
Eine voll Funktionstüchtige Demo Version kann man sich bei http://www.vmware.com herunterladen. Nach dem Testzeitraum steht nur noch der VMware Player zur Verfügung. Dieser reicht aber vollkommen aus um das OSx System weiter zu verwenden.
- Ein Boot CD-Image (nach darwin_snow.iso googeln)
Das ISO File kann man mittlerweile an vielen Stellen im Netz herunterladen. Da ich leider nicht weiß, ob man bzw. wessen Rechte man damit verletzt lass ich das direkte verlinken.
- Entsprechend Festplattenplatz
Anmerkung: Solange nichts anderes dabeisteht, einfach mit "Next", "Weiter", "Fortfahren", "Beenden" oder ähnlichem fortsetzen. Das jedesmal zu schreiben ist mir zu umständlich.
vMotion Fehler auf HP Servern und HP NC375x Network Adapter
Beim Testlauf meiner beiden neuen vSphere 4.1 Hosts habe ich festgestellt das bei Servern mit >1 GB RAM der vMotion vorgang mit folgender Fehlermeldung abbricht:
A general system error occurred: Migration failed while copying
data. Already disconnected.
Mit folgenden Fehlerdetails
Migration to host <<unknown>> failed with error Already disconnected (195887150).
vMotion migration [-1407644152:1291646678441186] write function failed.
vMotion migration [-1407644152:1291646678441186] failed to flush channel: Already disconnected
vMotion migration [-1407644152:1291646678441186] socket connected returned: Already disconnected
Die behebung dieses Problems ist ein wenig aufwendig. Zuerst scheint der mit 4.1 eingesetzte nx_nic Treiber in Version 4.0.550 Probleme mit NC375x Quadport Karten zu haben.
KB 1027206: Determining NIC firmware and driver version in ESX/ESXi 4.x
Nach dem Update der nx_nic Treiber auf Version 4.0.570 ist das Problem gelöst.
Aktuelle VMware Treiber für die QLogic Netzwerkkarte gibt es hier. Installationsanleitung liegt bei (Bei ESXi einfach das vSphere CLI verwenden)
Das gesamte Problem ist auch hier beschrieben: KB 1026021: vMotion fails on ESX/ESXi 3.5 and 4.0 with some versions of nx_nic and unm_nic drivers
Tipps für VMware Data Recovery 1.1
Nachdem ich jetzt die Data Recovery Appliance ein paar Wochen im Betrieb habe konnte ich folgende Verbesserungen bzw. Workarrounds durchführen:
Nach Arbeitsspeichererhöhung der Appliance von 2 auf 4 GB hat sich die Performances meines Erachtens merklich verbessert. Der Service stürzt jetzt auch nicht mehr so oft ab.
Eine CPU Erhöhung von 2 auf 4 hat leider nicht so viel gebracht.
Wenn man nicht auf ein VMDK oder Raw Device schreibt sondern über Netzwerk auf eine CIFs Share sollte man unbedingt die IP Adresse des Servers und nicht den Namen verwenden. Hat bei mir einige der "Task terminated enexpectedly, possibly due to a power failure or system crash." Fehler behoben.
Die Reports kann man nicht löschen und sie werden scheinbar in Version 1.1 nicht automatisch bereinigt. Falls man die Einträge unbedingt loswerden möchte kann man folgendes tun:
Die beiden Dateien Config10.dat und Config10.bak im Verzeichnis /var/vmware/datarecovery/ beinhalten sowohl Backup-Konfiguration als auch alle Reports. Die Dateien können nachdem man den Dienst mit "service datarecovery stop" beendet hat gelöscht werden.
Allerdings muss man dann die Appliance neu konfigurieren. D.h. alle Backupjobs und Backupziele sind erstmal nicht mehr vorhanden. Die Restorepoints werden wieder angezeigt sobald man das Backupziel wieder korrekt konfiguriert hat.
Sehr umständlich aber es funktioniert, ich hoffe VMware baut in die nächste Version eine Logfile Verwaltung mit ein.
p.s. die standard Zugangsdaten zur Appliance sind root // vmw@re
Edit: Mit Version 1.2 ist's besser geworden 
Snapshot vergessen?
Hm, was passiert wenn man bei einem Testsystem (MS Forefront + WSUS) nach der Grundinstallation vergisst den Snapshot zu entfernen muss ich gerade leidvoll erfahren.
1. Der Host geht auf Status rot da wärend des Snapshot entfernen keine automatische Lastverteilung funktioniert.
DRS-Ressourceneinstellungen können nicht auf dem Host 'xyz' in 'Datacenter' angewendet werden (Ursache: Ein allgemeiner Systemfehler ist aufgetreten: Invalid fault). Dies kann die Effektivität von DRS erheblich beeinträchtigen.
2. Das Snapshot entfernen dauert zu lange fürs Virtual Center, d.h. es gibt eine Fehlermeldung sowie einen Timeout.
Tipp: Um zu sehen was los ist, direkt auf den entsprechenden ESX Host gucken, denn da läuft das entfernen weiter.
3. Das Entfernen dauert eine halbe Ewigkeit, aber da muss ich jetzt wohl durch. Ich brauch ein schnelleres Storage, blödes Ding
So ein Snapshot entfernen kann schonmal ne Stunde dauern, ich darfs wohl nicht mehr vergessen. ^^
World of Warcraft in einer VM
Endlich hinbekommen. 
WoW Version: 3.1.1
FPS: 8-20
Jetzt brauch ich irgendwann nur noch viel zeit und einen Account dem eine Sperrung nichts ausmacht ^^
Telnet für ESX 3.5u3
Wenn mans mal braucht, einfach Installations-CD rein, mounten und RPM Paket installieren
rpm -i /mnt/cdrom/VMware/RPMS/telnet-0.17-26.EL3.3.i386.rpm
und danach mit
rpm -e telnet-0.17-26.EL3.3
wieder runterwerfen.