Die Foren-SW läuft ohne erkennbare Probleme. Sollte doch etwas nicht funktionieren, bitte gerne hier jederzeit melden und wir kümmern uns zeitnah darum. Danke!

ESXi 5.5: Booten von Windows Server 2003 nicht mehr möglich

Moderatoren: irix, Dayworker

Member
Beiträge: 34
Registriert: 07.01.2008, 13:23

ESXi 5.5: Booten von Windows Server 2003 nicht mehr möglich

Beitragvon TheExpert » 27.09.2013, 11:52

Hallo zusammen,

ich habe am Mittwoch meinen ESXi-Server von 5.1 auf 5.5 upgedatet, was soweit auch sehr gut funktioniert hat.

Leider stelle ich nun Boot-Probleme mit meinen beiden VMs mit Windows Server 2003 Standard (32 Bit, nicht R2) fest: Die VM lässt sich einschalten, ich komme auch ins BIOS, aber es kommt kein Startbildschirm von Windows. Der Bildschirm bleibt schwarz. Wenn ich eine neue VM erstelle und dort die SCSI-Platten des Windows Servers einbinde, tritt das gleiche Phänomen auf. Die CPU-Last der VM steht konstant auf 50% (bei einer vCPU von insgesamt 2).

Wenn ich diese VM z. B. mit einer ISO-Datei von GParted (basiert auf Linux) starte, fährt das System hoch und ich sehe auch die beiden SCSI-Platten, angebunden über LSI Logic Parallel. Wenn ich den gleichen Test mit der ISO-Datei der Installations-CD für Windows Server 2003 durchführe, dann komme ich bis zu dem Teil, bei dem das Setup die Hardware-Konfiguration untersucht.

Die beiden VMs liefen übrigens unter ESXi 5.1 mit dem allerneuesten Patchlevel ohne Probleme. Beide haben 2 vCPUs (2 vSockets mit einem vCore), Multiprozessor-Version 1.4. Eine Änderung auf Multiprozessor-Version 1.1 hat nichts gebracht.

Meine 3 Linux-VMs (Sophos UTM und UTM-Manager sowie eine Debian-VM) starten ohne Probleme. Das Gleiche gilt für meine Windows 2000 und Windows XP VMs. Nur meine Windows 3.11 VM startet nicht, der Bildschirm bleibt ebenfalls schwarz (habe dieses System noch aus nostalgischen Gründen ;) ).

Grundsätzlich stelle ich bei allen Windows-VMs fest, dass der Startvorgang unter ESXi 5.5 bis zum ersten Startbildschirm des Gastbetriebssystems sehr verzögert läuft. Das ist mir unter 5.1 so noch nicht aufgefallen. Ob auch die Linux-VMs nur verzögert starten, kann ich nicht sagen.

Hat jemand hier im Forum gleiche oder ähnliche Erfahrungen gemacht? Gibt es eine Erklärung, weshalb die 2003er-VMs nicht richtig hochfahren und warum grundsätzlich die Windows-VMs nur sehr verzögert starten?

Mein Host ist mit folgender HW ausgestattet:
    CPU: 2x Intel Xeon E5420, QuadCore, 2,5 GHz
    Board: Intel S5000VSA
    RAM: 16 GB
    RAID-Controller: 3ware 9650SE Hardware-SATA-RAID-Controller mit 8 SATA-Ports (wird mit einem zusätzlichen Treiber für ESXi eingebunden)
    Festplatten: 6x 500 GB WD SATA Server-Platten (4 Platten als RAID 10 für ESXi und VMs, 2 Platten als Einzelplatten für Daten des Windows Home Server v1, da eigener Replikationsmechanismus)
Und schließlich noch eine Frage bzgl. HW-Version der VM: Wie kann ich eine virtuelle HW der Version 10 wieder auf Version 8 oder 9 downgraden? Man kann mit dem vSphere Client keine 10er-VMs mehr anpassen und der Web Client funktioniert nur in Verbindung mit dem kostenpflichtigen vCenter Server.

Vielen Dank für Eure Unterstützung.

Experte
Beiträge: 1337
Registriert: 25.04.2009, 11:17
Wohnort: Thüringen

Beitragvon Supi » 27.09.2013, 12:49

Windows 3.1 wird wohl ab 5.5 nicht mehr supported.
Das ist dann aber schon sehr viel Nostalgie. Schon unter Windows 95/98/Me muss ich schwer überlegen, wo war jetzt noch mal dies oder jenes. Aber Windows 3.1(1)...

zum vHW downgrade: http://lmgtfy.com/?q=vmware+virtual+har ... +downgrade

Member
Beiträge: 22
Registriert: 27.09.2013, 12:35

Beitragvon PBecker » 27.09.2013, 13:08

Also das Problem habe ich unabhängig von 5.5 mit einer XP VM.
Das Booten dauert unter voller Last auf einem Core 10-15 Minuten.
Danach funktioniert die VM ohne Probleme.
Wobei diese Machine per P2V erzeugt wurde und schon auf echter Hardware merkwürdig lange bootete.

Member
Beiträge: 34
Registriert: 07.01.2008, 13:23

Beitragvon TheExpert » 27.09.2013, 13:54

Hallo Supi,

danke für die Links. Die Option "Create a new virtual machine with required hardware version and attach the existing disk from the virtual machine" hatte ich mir auch schon überlegt, war mir aber unsicher, ob das funktioniert. Das teste ich jetz mal aus.

Bzgl. Windows 3.11: Das habe ich auch gesehen. Bis 5.1 war das kein Thema. Ich hänge irgendwie noch an meinem langjährigen, treuen und selten abgestürtzten Begleiter und möchte den zumindest noch am Leben halten. Dann werde ich diese Maschine eben auf einen ESXi 5.1 verschieben.

Member
Beiträge: 34
Registriert: 07.01.2008, 13:23

Beitragvon TheExpert » 27.09.2013, 14:08

Hallo Supi,

ich war jetzt mal erfinderisch: Ich habe in der VMX-Datei die Option "virtualHW.version" von Wert 10 auf Wert 9 heruntergesetzt. Ich wollte ja nicht glauben, dass das ausreicht, aber nun kann man wieder die Einstellungen der VM im vSphere-Client anpassen und die VM bootet problemlos (ebenfalls eine XP-VM).

Erstaunlich, wie einfach sich die Versionskontrolle von VMware hier austricksen lässt ;).

Benutzeravatar
UNSTERBLICH(R.I.P.)
Beiträge: 14759
Registriert: 09.08.2003, 05:41
Wohnort: sauerland
Kontaktdaten:

Beitragvon continuum » 27.09.2013, 14:59

Ich habe mit 2003 VMs unter den neusten Version beobachtet -dass die korrekte Einstellung des guestOS viel wichtiger ist als früher.
In älteren Versionen bootet eine 2003 VM fast mit jeder guestOS-Einstellung.

Seit einer Weile hängen 2003 VMs - jedenfalls solche mit E1000 nics - wenn das guestOS auch nur ein bisschen abweicht.

Member
Beiträge: 34
Registriert: 07.01.2008, 13:23

Beitragvon TheExpert » 27.09.2013, 15:40

Hallo continuum,

ja, auch daran habe ich schon geschraubt: Der eine Server war als "Microsoft Windows Server 2003 (32 Bit)" deklariert. Das habe ich dann auf "Microsoft Windows Server 2003 Standard (32 Bit)" geändert. Das hat aber keine Besserung gebracht.

Die Netzwerkkarte der VM ist als "E1000" eingestellt. Bei den LINUX-VMs ebenfalls. Unter Windows 2000 und XP habe ich auch einige mit "Flexibel" eingerichtet.

Mein Windows Home Server ist als "Microsoft Windows Server 2003 (32 Bit) Standard" deklariert und die Netzwerkkarte als "Flexibel" eingestellt. Und auch diese VM bootet nicht, der Konsolen-Bildschirm bleibt schwarz.

Welche NIC ist für Windows Server 2003 zu empfehlen bzw. mit welcher Karte hast Du die Hänger der VMs gelöst?

Member
Beiträge: 34
Registriert: 07.01.2008, 13:23

Beitragvon TheExpert » 29.09.2013, 02:40

Hallo zusammen,

es gibt Neuigkeiten bzgl. Startprobleme von einigen VMs unter ESXi 5.5, denn die Sache hat mir keine Ruhe gelassen.

Ich bin gerade dabei, einen neuen ESXi-Host aufzubauen, weil ich mehr Plattenkapazität benötige. Diesen Server habe ich ohne Update direkt mit ESXi 5.5 installiert und zum Testen eine der beiden Windows Server 2003 VMs sowie die Windows 3.11 VM dorthin kopiert. Diese beiden VMs lassen sich starten :grin: - bei Windows 3.11 zumindest im DOS-Modus, Windows scheint nicht zu starten!

Der neue Server hat folgende HW-Ausstattung:
    CPU: 1x AMD Opteron 2378, QuadCore, 2,4 GHz
    Board: Supermicro H8DM3-2
    RAM: 16 GB
    RAID-Controller: Adaptec 5805 Hardware-SATA-RAID-Controller mit 8 SATA-Ports
    Festplatten: 8x 1.000 GB Seagate Barracuda ES.2 SATA Server-Platten (4 Platten als RAID 10 für ESXi und VMs, restliche Platten sind noch nicht eingebunden)
Ich will weiterhin mit dem XEON-System arbeiten und lediglich die Platten mit dem Adaptec-Controller aus dem AMD-Server dort anbinden, denn mit dem Intel-System habe ich mehr CPU-Leistung und weniger Stromverbrauch.

Allerdings ist mir schleierhaft, weshalb die VMs auf dem Intel-Server nicht starten, jedoch auf dem AMD-Server. Um zu sehen, ob die Windows 3.11 VM vielleicht wieder auf dem Intel-Server startet, habe ich die VM nochmals vom AMD-Server dorthin zurückkopiert. Das Ergebnis ist weiterhin eine nicht richtig startende VM auf dem Intel-Server. Nicht richtig startend bedeutet, dass ich jetzt immerhin den Startbildschirm von DOS sehe, aber beim Laden der Treiber usw. bleibt die VM hängen bzw. läuft die VM im Vergleich zum Start auf dem AMD-Server sehr träge. Könnt Ihr mir das erklären? Ist die AMD-Plattform seitens VMware unter ESXi 5.5 besser unterstützt als die Intel-Plattform? Das kann ich mir irgendwie nicht vorstellen!

Das Kopieren bedeutet für mich einen ziemlich großen Aufwand, denn es handelt sich um ca. 3 TB (!) Daten, die ich hin und her kopieren muss. Leider kommen weder Veeam FastSCP noch WinSCP über 4,5 MB/s in meinen Gigabit-Netz raus, so dass diese Aktion ziemlich lange dauern wird. Habt Ihr evtl. Tipps, wie ich das schneller bewerkstelligt bekomme?

King of the Hill
Beiträge: 13561
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Beitragvon Dayworker » 29.09.2013, 10:32

Es macht schon einen Unterschied, ob VT auf beiden Hosts eingeschaltet ist. Dazu kommt, daß dein Intel Core2Quad-Server noch auf FSB1333 setzt und dadurch zumindest RAM-anbindungs- und -durchsatztechnisch der AMD-CPU hinterherhechelt. Aktuelle SW wie vSphere5.5 will aber schon die aktuellen CPU-Features ausnutzen und wenn es die nicht vorfindet, wird es halt langsamer. Ob vSphere5.5 noch mit 16bit-OS umgehen kann, entzieht sich meiner Kenntnis. Win64 jedenfalls kann mit 16bittigen Anwendungen nichts mehr anfangen, aber ESXi ist ja weder Linux noch Windows.

Wenn du geschickt warst, hast du dir die jeweiligen "vmware.log" zu deinen Tests passend umbenannt und auf deinem Verwaltungsrechner gesichert. Mit etwas Glück finden sich darin die Ursachen. Falls du Hilfe beim Durchsehen brauchst, weißt du ja um die Verlinkung auf einen Freehoster, da bei uns keine Anhänge möglich sind.

Member
Beiträge: 34
Registriert: 07.01.2008, 13:23

Beitragvon TheExpert » 29.09.2013, 11:43

Hallo Dayworker,

sorry, aber in einigen Punkten muss ich Dir widersprechen. Zum einen sprechen die CPU-Benchmarks eine eindeutige Sprache für den Xeon, zum anderen würde sich ESXi nicht installieren lassen, wenn die mindestens erforderlichen Features der CPU nicht vorhanden oder deaktiviert sind.

Ich habe mich jetzt zu folgender Vorgehensweise entschieden:

1. Sicherung der Host-Konfiguration
2. Revert zur vorgehenden Version (5.1 mit Juli-Patch)
3. Einspielen der gesicherten Host-Konfiguration
4. Test der unter 5.5 nicht startenden VMs

Wenn das auch nicht funktioniert, dann teste ich auf dem Intel-Server mit jeweils frisch installiertem ESX 5.5 und 5.1.

Member
Beiträge: 34
Registriert: 07.01.2008, 13:23

Beitragvon TheExpert » 29.09.2013, 13:17

Hallo zusammen,

so, nun habe ich meinen Intel-Server auf ESXi 5.1 zurückgesetzt. Das Schöne an der ganzen Sache ist, dass sämtliche Einstellungen erhalten geblieben sind. Und die beiden Windows Server 2003 VMs starten wieder :grin:. Und auch die Windows 3.11 VM funktioniert.

Aber eine Erklärung habe ich immer noch nicht. Warum starten VMs mit Windows 2000, XP und 8 sowie mit Linux unter ESXi 5.5 auf dem Intel-System, wohingegen die Windows 2003 VMs das nur unter ESXi 5.1 tun - zumindest auf dem Intel-Server? Warum starten aber diese VMs unter ESXi 5.5 auf dem AMD-Server? Liegt das daran, dass der Intel-Server mit ESXi 5.5 upgedatet wurde, wohingegen der AMD-Server direkt mit ESXi 5.5 installiert wurde?

King of the Hill
Beiträge: 13561
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Beitragvon Dayworker » 29.09.2013, 13:43

Von der CPU-Leistung hatte ich nicht gesprochen, mir ging es um RAM-Anbindung und -Durchsatz. Beides ist beim AMD deutlich besser, da dort der Speichercontroller direkt in der CPU sitzt. AMD hatte dadurch sowohl die kürzeren Speicherlatenzen als auch den höheren RAM-Durchsatz.
Wenn es um die reine CPU-Leistung sowohl im Single- als auch Multicorebereich geht, hatte auch der damalige Opteron unbestritten keine Chance und das obwohl der Core2Quad kein nativer Quadcore sondern nur zwei auf einem Trägersubstrat zusammengepappte einzelne Core2Duos waren.

Zwischen CPU-Mindestanforderungen und optimalem Featureset liegen bekanntlich Welten. Wenn vSphere5.5 jetzt mehr Wert auf VT-x/EPT oder AMD-V/RVI legt, hilft dir das nur begrenzt weiter. Beides, Intels EPT (Extended Page Tables) als auch AMD RVI (Rapid Virtualization Indexing), wird für SLAT (Second Level Address Translation) gebraucht und beschleunigt die Speicherverwaltung für vSphere, da das Gast-RAM jetzt einfacher im Host-RAM abgebildet und bei Veränderungen auch zügiger ohne Mithilfe des Hypervisors auf den neuen Stand gebracht werden kann. Im Endeffekt steigt dadurch die Anzahl gleichzeitig laufender VMs oder die CPU-Belastung sinkt bei gleichzeitiger Zunahme der Ausführungsgeschwindigkeit der VM. Die VM läuft von der Gastseite betrachtet flüssiger.
EPT hat Intel aber erst mit dem Nehalem mit seinem in die CPU gewanderten Speicherkontroller und RVI wurde bei AMD auch erst mit der dritten Opteron-Generation mit dem Codenamen Barcelona eingeführt. Das könnte also der Grund sein, weshalb die W2k3-VM auf deiner Barcelona-CPU noch startet.


Für den VM-Start sollte das aber im Normalfall keine Auswirkungen haben. Es sei denn, daß es noch irgendwelche Einträge in die "config.ini" gegeben hat oder das in der VM noch prozessorspezifische Treiber installiert werden mußten. Das würde den Start auf der jeweils anderen CPU-Plattform verhindern, sobald dieser Treiber geladen wird.
Meine Hoffnung ist, daß dann auch das "vmware.log" entsprechende Einträge verzeichnet.



[add]
Beim Upgrade könnte auch etwas schief gelaufen sein und nur weil bestimmte bzw ältere HW mit einer ebenso älteren vSphere-Version lief, muß das nicht automatisch auch für neuere vSphere-Versionen gelten.
Um sicher zu sein, würde ich auch 5.5 auf dem Intel-System mal sauber aufsetzen. Wenn es dann läuft, bist du einen Schritt weiter.

Member
Beiträge: 34
Registriert: 07.01.2008, 13:23

Beitragvon TheExpert » 29.09.2013, 16:39

Hallo Dayworker,

danke für die ausführliche Erklärung. Das leuchtet mir soweit auch ein. Dennoch ist es sehr verwunderlich, dass eine XP-VM startet und eine Windows 2003 VM nicht. Denn XP und 2003 sind ja zumindest im Kern gleich, so dass beide starten müssten.

Und was einen prozessorspezifischen Treiber angeht, so habe ich nie etwas zusätzlich installiert und auch hier müsste das Verhalten doch gleich sein, wenn ein solcher Treiber installiert ist bzw. dürfte die Windows 2003 VM auch nicht auf dem AMD-System starten, denn es wurde auf einem Intel-System aufgesetzt, oder sehe ich das falsch? Aus den Logs bin ich nicht wirklich schlau geworden.

Wenn ich mal wieder etwas Zeit habe, dann versuche ich noch eine Neuinstallation von ESXi 5.5 auf dem Intel-System. Erst einmal bin ich froh, dass mit ESXi 5.1 alles weiterhin läuft.

@All: Wie transferiere ich denn am besten die ca. 3 TB auf die andere Hardware? Welche Tools könnt Ihr empfehlen? Ich habe keine Möglichkeit zur Zwischenablage der Daten auf einem Filer o. ä..

King of the Hill
Beiträge: 13561
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Beitragvon Dayworker » 29.09.2013, 17:36

XP und W2k3 sind je nach Ausführung (32 oder 64bit) doch zwei Paar Schuhe.

Bezüglich des Transfers stellt sich die Frage, ob du den vSphere Hypervisor oder einen bezahlten ESXi hast. Der vSphere Hypervisor hat nur eine Readonly-API und VMware hatte für seine Partner verfügt, daß diese ihre Produktunterstützung für dieses Produkt zurücknehmen. Im Endeffekt bleibt da nur noch Trilead VMexplorer über. Aber ob der auch schon mit 5.5 klarkommt oder ob du damit direkt zwischen zwei ESXi-Servern transferieren kannst, entzieht sich meiner Kenntnis. Sobald du den bezahlten ESXi hast, steht dir dafür ja neben dem VMware-vCenter auch jede Menge weiterer Software im VMware-Umfeld zur Verfügung.


An den Logs beider Systeme mit willigen und unwilligen VMs wäre ich trotzdem interessiert.
Speziell der Gast-Eintrag scheint inzwischen wesentlich wichtiger als noch in früheren ESX(i)-Versionen geworden zu sein und auch sonst läßt sich vielleicht noch mehr aus den Logs herauslesen.

Member
Beiträge: 34
Registriert: 07.01.2008, 13:23

Beitragvon TheExpert » 26.10.2013, 13:29

Hallo Dayworker,

heute bin ich endlich dazu gekommen, auf dem Intel-Server anstatt einem Upgrade von ESXi 5.1 auf 5.5 eine Neuinstallation von ESXi unter Beibehaltung der VMFS Datastores durchzuführen und einen der beiden Windows 2003 Server zu starten.

Der Konsolen-Bildschirm bleibt weiterhin schwarz. Damit ist m. E. widerlegt, dass beim Update von 5.1 nach 5.5 etwas schief gelaufen sein könnte.

Ich rede im Übrigen nicht von 64 Bit Systemen. Windows 2003 32 Bit und Windows XP 32 Bit sind sich sehr ähnlich.

King of the Hill
Beiträge: 13561
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Beitragvon Dayworker » 26.10.2013, 19:42

Verlinke bitte mal das(die) "vmware.log" der unwilligen Maschine(n). Mit etwas Glück schreibt VMware direkt sein Problem ins Log.

Member
Beiträge: 34
Registriert: 07.01.2008, 13:23

Beitragvon TheExpert » 26.10.2013, 20:09

Hallo Dayworker,

hier der Link zur Log-Datei: https://www.dropbox.com/s/ilvgcn1q23yiv87/vmware.log

Ich habe nun einen Test begonnen, eine neue Windows 2003 Maschine auf dem Host zu installieren. Die VM bootet von der ISO-Datei, bleibt aber dann bei dem Vorgang "Setup untersucht die Hardwarekonfiguration des Computers..." stehen.

King of the Hill
Beiträge: 13561
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Beitragvon Dayworker » 26.10.2013, 22:16

  • 2013-10-26T11:16:09.051Z| vmx| I120: hostCPUID name: Intel(R) Xeon(R) CPU E5420 @ 2.50GHz
  • 2013-10-26T11:16:09.388Z| vmx| I120: DICT displayName = Homeserver
  • 2013-10-26T11:16:09.388Z| vmx| I120: DICT numvcpus = 4
  • 2013-10-26T11:16:09.388Z| vmx| I120: DICT memsize = 4096
  • 2013-10-26T11:16:09.388Z| vmx| I120: DICT guestOS = winnetstandard
  • 2013-10-26T11:16:09.388Z| vmx| I120: DICT usb.present = TRUE
  • 2013-10-26T11:16:09.388Z| vmx| I120: DICT ide0:0.fileName = /vmfs/devices/cdrom/mpx.vmhba0:C0:T1:L0
  • 2013-10-26T11:16:09.388Z| vmx| I120: DICT ethernet0.virtualDev = vmxnet3
  • 2013-10-26T11:16:09.418Z| vmx| I120: HV Settings: virtual exec = 'hardware'; virtual mmu = 'software'
  • 2013-10-26T11:16:09.789Z| Worker#0| I120: DISKLIB-LINK : Opened '/vmfs/volumes/50fb29a6-deafa486-50f8-001517bed22a/Homeserver/Homeserver.vmdk' (0xa): vmfs, 625131520 sectors / 298.1 GB.
  • 2013-10-26T11:16:09.789Z| Worker#1| I120: DISKLIB-LINK : Opened '/vmfs/volumes/50f987e1-4a7debe5-8c41-001517bed22a/Homeserver/Homeserver_1.vmdk' (0xa): vmfs, 964689920 sectors / 460 GB.
  • 2013-10-26T11:16:09.790Z| Worker#2| I120: DISKLIB-LINK : Opened '/vmfs/volumes/50f98816-39fbe053-6d32-001517bed22a/Homeserver/Homeserver_2.vmdk' (0xa): vmfs, 964689920 sectors / 460 GB.
  • 2013-10-26T11:16:09.866Z| vmx| I120: SVGA: Truncated maximum resolution to VRAM size: 4194304 bytes VRAM, 1176x885 Max Resolution
  • 2013-10-26T11:16:10.135Z| vmx| I120: USB: Found device [name:TEAC\ FD-05PUW vid:0644 path:4/0 speed:full family:storage arbRuntimeKey:1 version:2] ==>Teac USB-Floppy
  • 2013-10-26T11:16:12.091Z| vcpu-0| I120: Unknown int 10h func 0x2000

Windows Home-Server wird meines Wissens nach im Gegensatz zum SBS2003 immer noch nicht unterstützt und bei einer Quadcore-CPU einer VM 4 Kerne zu geben, läßt die VM etwas ruckeln und für den ESXi bleibt nix übrig.
Was läuft als Gast-OS wirklich in der VM? Der 5.5er macht zwischen den einzelnen GastOS-Typen eine wesentlich feinere Unterscheidung auch hinsichtlich der CPU-Features. Zwischen W2k3 Enterprise und Standard sollte es CPU-featuretechnisch keine Unterschiede geben. Um da aber alles auszuschließen, wähle den richtigen GastOS-Typ aus.

Die Meldung Unknown int 10h func sehe ich bei fast jedem VM-Produkt. VMware sollte da dringend mal die Grafik-Routinen bei VM-Start überarbeiten. Solange dort keine Meldungen mit X86Fault_Warning: vmcore/vmm32/bt/btpriv.c auftauchen, scheint das aber alles unkritisch zu sein.


Schalte bitte mal trotzdem unnötige vHW wie USB ab und installiere das Gast-OS vom ISO und nicht vom CD/DVD-Laufwerk. Für den LSI- bzw Buslogic- oder LSISAS-Controller gibt es auf der VMware-Seite http://download3.vmware.com/software/vmscsi-1.2.0.4.flp extra ein Floppy-Image, damit man zur Inst nicht extra irgendwelche reale HW in eine VM durchreichen muß. Je nach GastOS-Typ steht dann der richtige sprich performanteste Treiber zur Verfügung.

Member
Beiträge: 34
Registriert: 07.01.2008, 13:23

Beitragvon TheExpert » 27.10.2013, 18:21

Hallo Dayworker,

danke fürs Durchgehen. Windows Home Server v1 entspricht Windows 2003 Standard Edition (nicht R2) mit 32 Bit. Und genau so ist die VM auch konfiguriert.

Diese VM läuft übrigens seit Monaten einwand- und ruckelfrei auf ESXi 5.1 und auch 5.5 - letzteres auf meinem AMD-Server - mit genau dieser HW-Konfiguration. Die LSI-Treiber habe ich natürlich schon lange eingebunden, denn sonst würde die VM gar nicht funktionieren. Und natürlich habe ich 2 QC CPUs im Server, denn sonst wären die 4 vCPUs sinnfrei ;).

Und beachte bitte auch noch meinen Hinweis aus meinem letzten Post: Ich kann auf dem Intel-Server nicht einmal eine Windows 2003 VM neu installieren.

King of the Hill
Beiträge: 13561
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Beitragvon Dayworker » 27.10.2013, 19:23

2013-10-26T11:16:09.416Z| vmx| I120: CPU0: PMC: Patch Level 0xa0b, smmFrz (hw): (1)
2013-10-26T11:16:09.416Z| vmx| I120: PMC: IA32, Penryn [c:0 f:1 e:0]
2013-10-26T11:16:09.416Z| vmx| I120: CPU1: PMC: Patch Level 0xa0b, smmFrz (hw): (1)
2013-10-26T11:16:09.416Z| vmx| I120: PMC: IA32, Penryn [c:0 f:1 e:0]
2013-10-26T11:16:09.416Z| vmx| I120: CPU2: PMC: Patch Level 0xa0b, smmFrz (hw): (1)
2013-10-26T11:16:09.416Z| vmx| I120: PMC: IA32, Penryn [c:0 f:1 e:0]
2013-10-26T11:16:09.416Z| vmx| I120: CPU3: PMC: Patch Level 0xa0b, smmFrz (hw): (1)
2013-10-26T11:16:09.416Z| vmx| I120: PMC: IA32, Penryn [c:0 f:1 e:0]
2013-10-26T11:16:09.416Z| vmx| I120: CPU4: PMC: Patch Level 0xa0b, smmFrz (hw): (1)
2013-10-26T11:16:09.416Z| vmx| I120: PMC: IA32, Penryn [c:0 f:1 e:0]
2013-10-26T11:16:09.416Z| vmx| I120: CPU5: PMC: Patch Level 0xa0b, smmFrz (hw): (1)
2013-10-26T11:16:09.416Z| vmx| I120: PMC: IA32, Penryn [c:0 f:1 e:0]
2013-10-26T11:16:09.416Z| vmx| I120: CPU6: PMC: Patch Level 0xa0b, smmFrz (hw): (1)
2013-10-26T11:16:09.416Z| vmx| I120: PMC: IA32, Penryn [c:0 f:1 e:0]
2013-10-26T11:16:09.416Z| vmx| I120: CPU7: PMC: Patch Level 0xa0b, smmFrz (hw): (1)
2013-10-26T11:16:09.416Z| vmx| I120: PMC: IA32, Penryn [c:0 f:1 e:0]
Ups, du hast recht. :oops:
8 CPUs und wegen E5420 auch kein HT können nur 2 Sockel mit Quadcore bedeuten.


Der AMD ist eine andere Baustelle. Was passiert eigentlich, wenn du die Meldung "Setup untersucht die Hardwarekonfiguration des Computers..." noch länger stehen läßt?
Meine Hoffnung ist, daß der ESXi dann noch eine hilfreiche Meldung ins Log schickt.

Falls das nichts bringt, würde ich der Homeserver-VM testweise mal nur 1 vCPU mit 1 GB vRAM gönnen und wenn das nichts bringt, würde ich testweise die HW-VT nur für diese VM ausschalten. Die Syntax aus anderen VMware-Produkten sollte auch unter 5.5 weiterhin funktionieren, wobei bei dir der Parameter "software" in beiden VMX-Einstellungen das gewünschte Ergebnis sprich erfolgreicher VM-Start bringen sollte:

Code: Alles auswählen

monitor.virtual_mmu = "software"
monitor.virtual_exec = "software"


Bei VMX-Einstellungen "monitor.virtual_mmu" und "monitor.virtual_exec" kennen als Parameter:
  • hardware
  • software
  • dynamic



Wenn das alles nichts bringen sollte, würde ich direkt im VMTN mal einen Thread aufmachen. "jmattson" springt eigentlich auf solche Fragen direkt an und liefert irgendeine Einstellung, damit es trotzdem geht.



[add]
Ausgehend vom VMTN-Thread E1000 virtual nic on Win 2003 R2 causing PSOD on ESXi 5.1 (PF Exception 14) solltest du in jedem Fall beim vNIC-Typ "vmxnet3" bleiben, denn eine Lösung dafür wird erst im Q1/2014 erwartet...

Member
Beiträge: 34
Registriert: 07.01.2008, 13:23

Beitragvon TheExpert » 28.10.2013, 08:34

Dayworker hat geschrieben:
Was passiert eigentlich, wenn du die Meldung "Setup untersucht die Hardwarekonfiguration des Computers..." noch länger stehen läßt?
Meine Hoffnung ist, daß der ESXi dann noch eine hilfreiche Meldung ins Log schickt.

Falls das nichts bringt, würde ich der Homeserver-VM testweise mal nur 1 vCPU mit 1 GB vRAM gönnen und wenn das nichts bringt, würde ich testweise die HW-VT nur für diese VM ausschalten. Die Syntax aus anderen VMware-Produkten sollte auch unter 5.5 weiterhin funktionieren, wobei bei dir der Parameter "software" in beiden VMX-Einstellungen das gewünschte Ergebnis sprich erfolgreicher VM-Start bringen sollte:

Code: Alles auswählen

monitor.virtual_mmu = "software"
monitor.virtual_exec = "software"


Bei VMX-Einstellungen "monitor.virtual_mmu" und "monitor.virtual_exec" kennen als Parameter:
  • hardware
  • software
  • dynamic

Ausgehend vom VMTN-Thread E1000 virtual nic on Win 2003 R2 causing PSOD on ESXi 5.1 (PF Exception 14) solltest du in jedem Fall beim vNIC-Typ "vmxnet3" bleiben, denn eine Lösung dafür wird erst im Q1/2014 erwartet...


Die VM bleibt an der Stelle hängen, ich kann die VM dann nur ausschalten. Möchtest Du mal in das Log schauen?

Wo kann ich denn diese Einstellungen anpassen (nicht vRAM und vCPU)? Ist das in der VMX-Datei oder macht man das im vSphere Client?

Einen PSOD mit der virtuellen E1000 hatte ich unter 5.1 nicht. Ich habe aber auch kein Windows 2003 R2. Unter 5.5 habe ich zwischenzeitlich auf vmxnet3 migriert, da ich einige Tests bzgl. Netzwerkperformance durchgeführt habe.

King of the Hill
Beiträge: 13561
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Beitragvon Dayworker » 28.10.2013, 10:58

Immer her mit dem Log. Die Auswertung kann allerdings heute etwas dauern.
Im Hinterkopf behalten sollte man aber auch, daß der Homeserver nicht unterstützt ist und da VMware beim 5.5er ebenfall viele HW-Zöpfe abgeschnitten hat, könnte dies auch für nichtunterstützte Gast-OS gelten.

Member
Beiträge: 34
Registriert: 07.01.2008, 13:23

Beitragvon TheExpert » 28.10.2013, 11:51

Hallo Dayworker,

ich kann das Log auch erst heute Abend liefern, da der Intel-Server derzeit ausgeschaltet ist.

Wie schon mehrfach erwähnt, funktioniert der Windows Home Server (basierend auf Windows 2003 Standard, 32 Bit - nicht R2) auf dem AMD-Server unter ESXi 5.5 (Free Hypervisor) tadellos. Damit ist Deine These widerlegt, dass der Home Server nicht unterstützt wird, weil VMware hier die supporteten Gastbetriebssysteme reduziert hat.

Im Übrigen bist Du mir noch die Antwort schuldig, wo ich die von Dir genannten Einstellungen vornehmen kann: Per Editor in der VNX-Datei oder über die GUI des vSphere Client?

King of the Hill
Beiträge: 13561
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Beitragvon Dayworker » 28.10.2013, 12:22

Der Homeserver wird laut HCL nicht offiziell supportet. Daran führt kein Weg vorbei. Das kann bedeuten, daß dieser nicht oder nicht zuverlässig läuft und manchmal hat das auch überhaupt nichts bedeuten. Bei VMware ist manchmal alles möglich. Da der 5.5er aber noch bedeutend mehr Macken als der 5.1er hat, würde ich vorerst noch beim 5.5er bleiben. Das der 5.5er anscheinend auch 4GB RAM-Minimum als Inst-Voraussetzung hat, scheint in meinen Augen der wahre Grund hinter der Aufgabe der künstlichen 32GB-Arbeitsspeichergrenze beim vSphere Hypervisor zu sein...


Bezüglich der Einstellungen entweder in der VMX-Datei selbst oder in den erweiterten VM-Einstellungen in vSphere- bzw Web-Client. Beim Client gibt es irgendwo die Möglichkeit, eigene Einstellungen hinzuzufügen.



[add]
Das irgendwo ist im KB-Eintrag Modifying advanced virtual machine settings using vSphere Client (1016098) beschrieben.

Member
Beiträge: 34
Registriert: 07.01.2008, 13:23

Beitragvon TheExpert » 28.10.2013, 12:53

Hallo Dayworker,

OK, lassen wir den Home Server mal außen vor. In der Support Matrix ist aber Windows 2003 Server (nicht R2) noch enthalten. Und das lässt sich ja im Moment noch nicht mal installieren (auf dem Intel-Server)! Auf dem AMD-Server ist auch das kein Thema: Dort habe ich einen "normalen" Windows 2003 Server Standard Edition, 32 Bit laufen - ohne irgendwelche besonderen Einstellungen.

Ich werde heute Abend mal mit den von Dir vorgeschlagenen Optionen in der VMX-Datei testen und dann berichten. Dann stelle ich auch das Logfile von der nicht installierbaren Windows 2003 VM zur Verfügung.

Welche Macken sind denn beim ESXi 5.5 bekannt? Gibt es irgendwo eine Sammlung dieser Macken? Ich kämpfe nämlich parallel noch mit hohen Netzwerk-Latenzen auf meiner virtuellen Sophos UTM, seit diese auf ESXi 5.5 läuft - und das ist sogar innerhalb des ESXi-Hosts nachstellbar (also per Ping von einer VM zur UTM).


Zurück zu „vSphere 5.5 / ESXi 5.5“

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 8 Gäste