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!

Nach Migration auf neue Hardware: The CPU has been disabled

Hilfe bei Problemen mit der Installation oder Benutzung des VMware Server 2.

Moderatoren: irix, Dayworker

Member
Beiträge: 5
Registriert: 12.07.2013, 17:40

Nach Migration auf neue Hardware: The CPU has been disabled

Beitragvon brunni » 13.07.2013, 19:21

hi all

nach Migration von VMware-server-2.0.1-156745.i386 von einem Server mit
Xeon-Prozessoren auf einen Server mit Core i3-3220T erhalte ich beim Booten
von Kernel 3.2.47 auf dem Guest folgende Meldung:

The CPU has been disabled by the guest operating system. You will need to power off or reset the virtual machine at this point.

Auf der Konsole tut sich nach der Dekomprimierung des Kernels nichts mehr und
die Meldung erscheint im Log.

Mit Kernel 2.6.27.62 auf dem Guest funktioniert es! Ich habe Kernel 3.2.47
ausserdem bereits erfolgreich mit dieser VMware-Version eingesetzt - aber nur
zusammen mit Xeon-Prozessoren. Host-Kernel ist immer 2.6.27.62.

Ich habe ein bisschen mit der Kernel-Konfiguration für 3.2.47 des Guest
gespielt: CPU-Typ, HIGHMEM4G, PAE - bringt alles nichts.

Wer kann mir auf die Sprünge helfen ?

Ich wollte die Kernel-Konfiguration für den Guest als Attachment anhängen aber das darf ich offenbar nicht.

cu,
brunni

King of the Hill
Beiträge: 12942
Registriert: 02.08.2008, 15:06
Wohnort: Hannover/Wuerzburg
Kontaktdaten:

Beitragvon irix » 13.07.2013, 19:55

VMware Server 2.0 ist seit 2010 EOL und unterstuetzt neuere CPUs nicht mehr und es ist anzunehmen das es daran liegt. Du hast uns auch dein Host OS nicht veraten.

Gruss
Joerg

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

Beitragvon Dayworker » 13.07.2013, 21:24

Also ausgehend von meinen Erfahrungen beim VMserver1 liegt das Problem an deiner Einstellung des Gast-OS und fehlender Aktivierung von VT für den Gast.
Verlinke mal bitte das "vmware.log" der unwilligen VM auf einen Freehoster.

Member
Beiträge: 5
Registriert: 12.07.2013, 17:40

Beitragvon brunni » 15.07.2013, 15:00

Dayworker hat geschrieben:Also ausgehend von meinen Erfahrungen beim VMserver1 liegt das Problem an deiner Einstellung des Gast-OS und fehlender Aktivierung von VT für den Gast.
Verlinke mal bitte das "vmware.log" der unwilligen VM auf einen Freehoster.


Das vmware.log für den nicht funktionierenden Gast-Kernel 3.2.47 findet sich unter

http://www.netestate.de/vmware_fail/vmwarelog.txt

Die Kernel-Konfiguration für nicht funktionierenden den Gast-Kernel 3.2.47 findet sich unter

http://www.netestate.de/vmware_fail/kernelconfig.txt

Wie gesagt: 3.2.47 geht mit diesem Vmware aber unter älteren Xeon-Prozessoren
und das Gast-OS auf dem neuen Server bootet mit Kernel 2.6.27.62.

Der Kernel 3.2.47 auf dem Gast kommt mit der virtuellen Core i3 CPU irgendwie nicht klar und schaltet diese offenbar ab. Auf dem Bildschirm ist nur "Booting the kernel."
zu sehen.

cu,
brunni

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

Beitragvon Dayworker » 15.07.2013, 17:07

Jul 15 14:29:59.028: vmx| hostNumPerfCounters = 4
Jul 15 14:29:59.028: vmx| CPU0: PMC: IA32, Nehalem-C or later [c:0 f:1 e:0]
Jul 15 14:29:59.028: vmx| CPU1: PMC: IA32, Nehalem-C or later [c:0 f:1 e:0]
Jul 15 14:29:59.028: vmx| CPU2: PMC: IA32, Nehalem-C or later [c:0 f:1 e:0]
Jul 15 14:29:59.028: vmx| CPU3: PMC: IA32, Nehalem-C or later [c:0 f:1 e:0]
Jul 15 14:29:59.028: vmx| MONITOR MODE: allowed modes : BT HV HWMMU
Jul 15 14:29:59.028: vmx| MONITOR MODE: user requested modes : BT HV HWMMU
Jul 15 14:29:59.028: vmx| MONITOR MODE: guestOS preferred modes: HWMMU HV BT
Jul 15 14:29:59.028: vmx| MONITOR MODE: filtered list : HWMMU HV BT
Jul 15 14:29:59.028: vmx| HV Settings: virtual exec = 'hardware'; virtual mmu = 'hardware'

Also die CPU und ihre 4 Kerne werden erkannt. Es wird sogar die Virtualisierung komplett in HW abgewickelt.

Änder mal bitte guestOS = "other26xlinux" in guestOS = "winnt" in deiner syngenta.vmx-Datei.

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

Beitragvon continuum » 15.07.2013, 18:22

Dazu gibt es einen post im VMTN im Betaforum.

AFAIK muss man bei NT 4 und WS ab #7 einfach damit leben.

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

Beitragvon Dayworker » 15.07.2013, 18:25

Hast du einen Link parat?

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

Beitragvon continuum » 15.07.2013, 18:51


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

Beitragvon Dayworker » 15.07.2013, 18:55

Das Problem von "brunni" ist aber, daß die Meldung "CPU disabled" bei Linux-VMs und/oder durch das Virtualisierungsprodukt bisher noch nicht unterstützte CPUs auftaucht.

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

Beitragvon Dayworker » 15.07.2013, 19:18

Spielst du darauf an, daß WinNT laut dem Thread mit deinem Posting kein ACPI unterstützt und über die Einstellung guest.OS = "winnt" dann möglicherweise ACPI lahmgelegt wird?
Das Linux im Gegensatz zu Windows mit "unausgereiften" ACPI-Tabellen weit weniger gut umzugehen weiß, ist mir nicht neu. Linux verläßt sich halt auf die vom MB generierten Tabellen und fällt deswegen besonders gerne auf NBs auf die Nase.
Interessant an der Linux-Geschichte finde ich allerdings Einträge der Art "Unknown int 10h func 0x0000" oder "X86Fault_Warning: vmcore/vmm32/bt/btpriv.c:1353".

Member
Beiträge: 5
Registriert: 12.07.2013, 17:40

Beitragvon brunni » 15.07.2013, 19:27

Dayworker hat geschrieben:Änder mal bitte guestOS = "other26xlinux" in guestOS = "winnt" in deiner syngenta.vmx-Datei.


mit guestOS = "winnt" geht es! :-) Das ist dann die Lösung ? Kann man irgendwo die Hintergründe nachlesen ?

Wenn es an ACPI liegt, hilft dann alternativ die Kerneloption acpi=off ?

Auf jeden Fall schonmal vielen lieben Dank!

cu,
brunni

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

Beitragvon Dayworker » 15.07.2013, 19:36

Wenn ich mit meiner ACPI-Schätzung richtig liege, sollte acpi=off auf dem Linux-Bootprompt die gleiche Wirkung haben.

Hattest du dir mal die ACPI-Tabelle in der VM mit der alten CPU abgespeichert oder kannst du das irgendwie noch gedeichselt bekommen?
Ich kanns leider nicht mehr, da mein alter Rechner den Weg zum örtlichen Recycler abgeschlossen hat.

Member
Beiträge: 5
Registriert: 12.07.2013, 17:40

Beitragvon brunni » 15.07.2013, 20:21

Dayworker hat geschrieben:Wenn ich mit meiner ACPI-Schätzung richtig liege, sollte acpi=off auf dem Linux-Bootprompt die gleiche Wirkung haben.

Hattest du dir mal die ACPI-Tabelle in der VM mit der alten CPU abgespeichert oder kannst du das irgendwie noch gedeichselt bekommen?
Ich kanns leider nicht mehr, da mein alter Rechner den Weg zum örtlichen Recycler abgeschlossen hat.


Also acpi=off in den Kerneloptionen und guestOS = "other26xlinux" funktioniert nicht.

Die alte Kiste läuft noch. Wie soll ich die ACPI-Tabelle auslesen ? /proc/acpi/dsdt auf dem alten Host ? Auf dem alten Guest gibt es unter /proc/acpi nur ac_adapter, alarm, battery, event und wakeup.

cu,
brunni

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

Beitragvon Dayworker » 15.07.2013, 20:57

Gute Frage wie man das ausliest, könnte je nach Distro geringfügig anders aussehen.

Member
Beiträge: 5
Registriert: 12.07.2013, 17:40

Beitragvon brunni » 15.07.2013, 21:01

Dayworker hat geschrieben:Gute Frage wie man das ausliest, könnte je nach Distro geringfügig anders aussehen.


Ich verwende ein selbstgebautes Linux auf Host und Gast. Wenn Du mir sagst, welches Tool ich verwenden soll, kann ich es bei Bedarf kompilieren und installieren. Vielleicht acpidump ?

cu,
brunni

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

Beitragvon Dayworker » 15.07.2013, 21:16

Was selbstgebrautes hatte ich schon fast befürchtet, nachdem du deine Kernelconfig verlinkt hast.
Versuch mal DSDT auszulesen oder verlinke mal die Ausgabe von "/var/log/dmesg". Vermutlich hilft uns aber beides nicht weiter, da ich auch nicht weiß, wie man die Ausgabe auf Plausibilität prüfen kann.


Zurück zu „VMserver 2“

Wer ist online?

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