SBS 2011 x64 auf dem ESXi 3.5

[blackwindow]

Hallo,

wir haben letztes Wochenende eine SBS 2003-2-2011 Migration gemacht. SBS 2011 haben wir auf dem ESXi Server 3.5 installiert. Alles läuft super, Exchange, GPOs, Druckerserver...
Allerdings schmiert ständig die Konsole ab...d.h. nach ein paar Anmelden geht irgendwann nichts mehr, ich meine die Umgebung läuft, alle können arbeiten, keiner beschwert sich, aber wir kommen nicht auf den Server, weder über RDB noch über VM Console, das Bild ist eingefroren.
Die VM hat 12 GB Speicher bekommen, aber 2 vCPUs. Waren es nicht 4? Mein Chef meint aber, da wir Lizenzierung nur für 2 CPUs haben, können wir leider nicht mehr geben..Oder denkt ihr hängt das Ganze nicht zusammen?
Hier ist noch ein Screenshot


Damit ich mich wieder anmelden kann, muss ich die VM neustarten. Das kann so nicht bleiben.

Habt ihr vielleicht Ideen?
Bin für jeden Hinweis sehr dankbar.

Grüße
Robert

[g0subaer]

komischer Lizenzierungsmist...
http://www.microsoft.com/de-de/server/w ... ungen.aspx

Habt Ihr die Migration nach Anleitung durchgeführt? Evtl. sind euch da Fehler unterlaufen.

[blackwindow]

alles nach der Anleitung, die ich teilweise persönlich sehr verwirrend fand...

Aber wie gesagt, da läuft alles gut, heute den ganzen Tag gab es keine Beschwerden von Nutzern, bis auf ein Paar Verknüpfungspfade, da der Servername sich geändert hat. Nur halt ich komme nicht mehr drauf...ganz doofe Situation...

[blackwindow]

alles nach der Anleitung, die ich teilweise persönlich sehr verwirrend fand...

Aber wie gesagt, da läuft alles gut, heute den ganzen Tag gab es keine Beschwerden von Nutzern, bis auf ein Paar Verknüpfungspfade, da der Servername sich geändert hat. Nur halt ich komme nicht mehr drauf...ganz doofe Situation...

Ich versuche heute den Arbeitspeicher auf 12288 zu korrigieren, denn 12 GB ist nicht wirklich 12000 MB, und die vCPUs auf 4 zu ändern...Ich hoffe, ist kein großer OS Fehler...

[Dayworker]

Wenn ich mir das Bild so ansehe, werden auf der rechten Seite Angaben für Host/Guest-Memory-Usage gemacht.
Host = 10.27GB
Guest = 1.52GB

Von meiner Warte aus werden vom Guest damit nur 1.5GB überhaupt genutzt und die 12000MB sind rechnerisch auch nur 11.72GB. Einen gewissen RAM-Bedarf schlägt VMware bei jedem seiner Produkte noch hinzu, um die PCI-Adress-Area und den GPU-Memory abzubilden.
So ganz genau haben die VMware-Anzeigen zum RAM zwar noch nie gestimmt, aber bitte sag jetzt nicht, daß der Host nur über die mageren 10.27GB RAM verfügt und die VM mit 12GB läuft.

Wenn dir die Console oder RDP abstürzt, hast du möglicherweise zu alte VMware-Tools eingespielt oder nutzt nicht den Workaround mit dem originalen M$-VGA-Treiber. Mit W2k8 bzw W7-SP1 und W2k8-R2 bzw dem darauf aufbauenden SBS-2k11 hatte bzw hat sich das Grafiksubsystem komplett geändert. Der Grafiktreiber in der VM muß etwas mit 3D bzw WDDM im Namen tragen und darf nicht mehr als "VMware SVGA II" gelistet sein.

[blackwindow]

Hallo Dayworker,

gibt es diesen WDDM Treiber auch bei ESXi 3.5? Ich habe in den Ordner reingeschaut, und da ist nur vmx_svga.inf Datei. Wenn ich das einzeln runterlade, kann ich das installieren?

Zu deiner Frage: der ESXi Host hat insgesamt 16GB, davon hat unser SBS 12000MB, auf dem Host läuft noch ein Win7 VM als FTP Server (2GB) , Sonst nichts. Aktuell benutzt der Host 14,25 GB, alles noch im grünen berech. ICh bin auch auf dem Server, keine Auffälligkeiten..

[Dayworker]

Keine Ahnung ob der schon bei den 3.5er VMware-Tools dabei ist, aber probier es doch aus.
Über den Link http://packages.vmware.com/tools/esx/index.html findest du alle VMware-Tools geordnet nach ESX(i)-Version.
Falls dabei kein WDDM-Treiber dabei ist, bleibt dir immer noch der Workaround. Dabei läßt du die Tools-Inst halt durchlaufen, deinstallierst im Nachgang nur den VMware-SVGA-Treiber und dann sollte der M$-Treiber wieder aktiviert werden.

[blackwindow]

Das war wohl nix,
Erkenntnis des Tages: die 3D WDDM Treiber für die VM auf dem 3.5 ESXi HOST sind nicht wirklich brauchbar



ODer hat jemand ein Vorschlag?

[irix]

Installier mal die VMware Tools aus dem ESXi 5 Packages sofern noch nicht geschehen.

Gruss
Joerg

[blackwindow]

Hallo Jörg,
Danke für den Tipp, wird dann die VM auf dem ESXi 3.5 Host die ganz neue VMWare Tools "fressen". Ich probiere es gleich...learning by kaputtmaking

[blackwindow]

diese Option hat leider auch nichts gebracht... Ich bin verzweifelt...doch ESXi 3.5 auf 5.0 Upgraden? Muahhhhaaa...

[Dayworker]

Verlinke mal bitte das "vmware.log" und dann sehen wir vielleicht das Problem.
Wenn ich mich recht entsinne, hatte der WDDM-Treiber entweder nur mehr Grafik-Speicher oder bei WS7/8 bzw vSphere4/5 mehr Grafik-Speicher + v.HW-Version 7 gebraucht.

[blackwindow]

Momentan läuft der Server stabil, wir vermeiden die ESXi KOnsole und den Zugriff über Teamviewer auf den Server- nur via VPN und RDP. Bis jetzt kein einziges Mal abgestürtzt...Liegt höchstwahrscheinlich an den NICHT wddm Treiber...Ich bin dabei rauszufinden, wie ich den ESXi 3.5 ohne Verlust der VMs bis auf 5.0 upgraden kann...Ok, das ist ein anderes Thema...
Danke aber erstmal für eure Tipps

[Dayworker]

Wenn du den originalen M$-Treiber installiert hast, friert dir weder die Console ein noch mußt du Abstürze erleiden.
Das Problem liegt einzig und allein an dem unpassenden Treiber, der noch auf dem alten WDM-Modell, also alles pre-Vista, basierte.


Ein Host-Upgrade ist eigentlich auch unkritisch, solange du den ESXi entweder vom USB-Stick oder einer separaten LUN startest. Da der ESXi zum Bootzeitpunkt alles komplett ins RAM einliest, bevorzugen wir den USB-Stick und dafür eignet sich bis auf wenige Ausnahmen jeder Stick mit 1 bis 2GB Platz. Eine separate LUN oder der Stick hatte bis zu vSphere4 auch den Vorteil, daß man den Server für die VMs gefahrlos updaten/upgraden konnte. Bis vSphere4 wird dabei immer der diesen beheimatende DS komplett überschrieben. Den ESX(i) also in denselben DS wie die VMs zu installieren, ist also keine gute Idee und verursachte schon viele Datenverluste oder war mit langwierigen Backup/Restore-Vorgängen vor dem Update verbunden.

Da sich die Blocksize beim ESX(i)3 im Vergleich zu vSphere4 oder vSphere5 zu sehr unterscheidet, wirst du wahrscheinlich auch nicht dein bisheriges VMFSv3-Dateisystem beibehalten können. Aber da müßtest du selbst nochmal in die Support-Matrix bei VMware schauen.