Seite 1 von 1

Dell T110 II (11.Gen) mit Ivy Bridge und der VMserver1.010

Verfasst: 04.05.2013, 00:34
von Dayworker
Die Konstellation spielt erstmal teilweise zusammen. Win-VMs machen keine Probleme, nur bei Linux hakts gewaltig...

May 02 02:34:53: vcpu-0| Unknown int 10h func 0x0000
May 02 02:34:53: vcpu-0| Unknown int 10h func 0x0000
May 02 02:34:53: vcpu-0| X86Fault_Warning: vmcore/vmm32/bt/btpriv.c:1353: cs:eip=0x60:0xc022b420 fault=13
May 02 02:36:06: vmx| VMXVmdbCbVmVmxExecState: Exec state change requested to state poweredOff with reset
Das Problem ist, daß sich eine Linux-VM reproduzierbar nach der X86Fault_Warning-Meldung weghängt und nur noch per Reset- oder Shutdown-Schaltfläche zu beenden ist. Das Problem wurde auch von unserem Ronny aka "e-e-e" im Thread Installation eines Tiny Core Linux startet nicht bereits 2010 beschrieben.
Mit Ubuntu sieht die Fehlermeldung aber auch nicht besser aus:
May 04 00:48:44: vcpu-0| Unknown int 10h func 0x0000
May 04 00:48:44: vcpu-0| Unknown int 10h func 0x0000
May 04 00:48:44: mks| VNCENCODE 1 encoding mode change: (640x480x24depth,32bpp)
May 04 00:48:48: mks| VNCENCODE 1 encoding mode change: (1024x768x8depth,8bpp)
May 04 00:48:48: vcpu-0| X86Fault_Warning: vmcore/vmm32/bt/btpriv.c:1353: cs:eip=0x60:0xc10373a3 fault=13
May 04 00:48:48: vcpu-0| Msg_Hint: msg.monitorevent.halt (not shown)
VM-seitig äußert sich dieses Problem darin, daß GRUB noch erscheint und man den gewünschten Eintrag zwar auswählen kann, der VM-Bildschirm dann aber schwarz bleibt und die CPU bei ca 75% Last verbleibt.

Hier die Ausgangslage VMX-technisch gesehen:
guestOS = "ubuntu"
Erfolg = :evil:


Ulli hatte in einem WS-Thread geschrieben, mal Auflösung und Video-RAM genauer einzustellen:
guestOS = "ubuntu"
svga.maxWidth = "1024"
svga.maxHeight = "768"
svga.vramSize = "8388608"
Erfolg = :evil:


In irgendeinem von gefühlten 1000 Threads im Kraken stand dann, daß man einfach mal als Gast-OS "winnt" einträgt. Gesagt und getan:
guestOS = "winnt"
svga.maxWidth = "1024"
svga.maxHeight = "768"
svga.vramSize = "8388608"
Erfolg = :evil:


Da die Meldung immer wieder auf X86Fault_Warning: vmcore/vmm32/bt/btpriv.c lautet, scheint es ein Problem mit X86 (Grafik) und BT (Binary Translation) zu geben. Die Angabe von Auflösung und Video-RAM hat sich als wenig hilfreich erwiesen und fliegt daher wieder raus. Also probieren wir:
guestOS = "ubuntu"
monitor_control.vt32 = "TRUE"
Erfolg = :evil:


In einer letzten Verzweifelung der Versuch mit:
guestOS = "winnt"
monitor_control.vt32 = "TRUE"
Erfolg = :D
Ähem, was'n das. Ich hab eine 32bittige Ubuntu-VM und die startet nur, wenn man (a) die Virtualisierung in HW einschaltet und (b) das Gast-OS auf "winnt" setzt :?::?::!:

Okay, das könnte auch Zufall sein. Also geschwind die letzten beiden Einstellungen mit der Zabbix-Appliance und Suse12.3 ausprobiert und die VM bleibt nicht wieder nach der Bootauswahl hängen. Da mir der voreingestellte GRUB-Schirm zu klein ist, hab ich als Startoption mal "VGA = 0x341" (1024x768x32) eingetragen und die VM startet weiterhin.

Verfasst: 18.02.2014, 09:37
von Dayworker
Linux wird anscheinend immer mehr zum Problem, wenn eine aktuellere Kernel-Version eingesetzt werden soll. Für das häufig verwendete Ubuntu bis Version 12.10 und Ubuntu-Kernel 3.5.X läßt sich sagen, daß sich solche VMs nur mit aktivierter Virtualisierung und Änderung des Gast-Types auf WinNT4 starten lassen und dies aber bereits mit der Ubuntu-Version 13.04 und dem Ubuntu-Kernel 3.8.X nicht mehr möglich ist. Die VM hängt sich dann reproduzierbar auf. Den von mir angenommenen Kernel-Oops sieht man schon nicht mehr.

Inzwischen hat Ubuntu 13.04 das Ende seiner kürzeren Supportzeit erreicht und zumindest in den Version mit anderem Desktop wie Lubuntu mit LXDE-Desktop wird direkt das Upgrade auf die noch aktuelle Version 13.10 angeboten. Dessen Ubuntu-Kernel 3.11.X kommt noch weniger damit zurecht. Die VM geht damit entweder direkt in eine Reboot-Schleife oder verbleibt bei 100% Last auf den maximal zwei konfigurierbaren Kernen. Da ich dazu vor geraumer Zeit und bis zum Morgengrauen gefrickelt hatte, ist die Erinnerung schwach ob es Reboot oder Volllast war.

Verfasst: 18.02.2014, 09:42
von Dayworker
Falls jemand mit VMserver1 mal gea's Napp-IT mit OmniOS oder allgemein einem Solaris-basiertem OS ausprobieren will, hat ebenfalls Pech. Die VM geht direkt nach der vBIOS-Anzeige in eine Reboot-Schleife.