ESX3(i) unter VMware Server 2.0

[bla!zilla]

Hallo. Ist es möglich ESX unter VMware Server 2.0 zu betreiben? CPU mit Intel VT bzw. AMD-V sind vorhanden. Hatte einen ESX3i mal angetestet, der hat auch bis zu einem bestimmten Punkt gebootet, dann aber nicht mehr weiter gemacht.

[elgato319]

Mir ist nur bekannt das der esxi unter der VMware Workstation funktioniert:

http://schimana.net/2008/10/it/vmware-e ... en-lassen/

[Dayworker]

Hab auch immer noch das selbe Problem. "VMkernel loaded successfully" ist das letzte Lebenszeichen und die CPU steht unter Volllast. Die CPU ist ein VT-aktivierter E6600 mit W2k als Host-OS.
Scheint mir jedoch ein Problem von W2k zu sein, daß einige erweiterte CPU-Features brach liegen. Eine Suse64-10.2 läuft darauf zwar problemlos, jedoch auch nur mit angezogener Handbremse.

Hier mein letztes Log:

Code: Alles auswählen

Nov 28 16:32:00.507: vmx| Log for VMware Server pid=1076 version=2.0.0 build=build-122956 option=Release


[edit]
Log gelöscht.

[Dayworker]

Stutzig an dem Log macht mich folgendes:

Code: Alles auswählen

Nov 28 16:32:00.914: vmx| MONITOR MODE: allowed modes          : BT
Nov 28 16:32:00.914: vmx| MONITOR MODE: user requested modes   : HWMMU
Nov 28 16:32:00.914: vmx| MONITOR MODE: guestOS preferred modes: BT HWMMU HV
Nov 28 16:32:00.914: vmx| Msg_Hint: msg.cpuid.HVwithPV (sent)
Nov 28 16:32:00.914: vmx| Hardware virtualization is incompatible with paravirtualization. Using software virtualization instead.
Nov 28 16:32:00.914: vmx| ---------------------------------------
Nov 28 16:32:00.945: vmx| MONITOR MODE: filtered list          : BT
Nov 28 16:32:00.945: vmx| HV Settings: virtual exec = 'software'; virtual mmu = 'software'

Weshalb schaltet Server2 bei dem Host wieder auf SW um?
Ein ähnliches Problem habe ich auch mit meiner Suse10.2_64bit-VM. Dort ändert sich "virtual exec" immer in 'dynamic'.

[continuum]

Wenn sich der virtual.mmu parameter umstellt macht das nichts - nur die allerneuesten CPUs unterstuetzen das.

Poste mal deine vmx - der ethernet0.virtualDev = "e1000" Eintrag scheint zu fehlen.
Nimm doch einfach die VM die ich im sticky post ueber ESX3.5 als VM gepostet habe.

Auch der guestOS eintrag ist falsch - nimm "other-64"

[Dayworker]

Hier meine VMX:

Code: Alles auswählen

.encoding = "windows-1252"
config.version = "8"
virtualHW.version = "4"
floppy0.present = "true"
nvram = "ESXi.nvram"
virtualHW.productCompatibility = "hosted"
ft.secondary0.enabled = "true"
tools.upgrade.policy = "useGlobal"
powerType.powerOff = "soft"
powerType.powerOn = "hard"
powerType.suspend = "hard"
powerType.reset = "soft"

displayName = "ESXi"
extendedConfigFile = "ESXi.vmxf"

scsi0.present = "true"
scsi0.sharedBus = "none"
scsi0.virtualDev = "lsilogic"
memsize = "1024"
scsi0:0.present = "true"
scsi0:0.fileName = "ESXi.vmdk"
ide1:0.present = "true"
ide1:0.clientDevice = "FALSE"
ide1:0.deviceType = "cdrom-image"
ide1:0.startConnected = "true"
floppy0.startConnected = "false"
floppy0.clientDevice = "FALSE"
ethernet0.present = "true"
ethernet0.features = "1"
ethernet0.networkName = "HostOnly"
ethernet0.addressType = "generated"
guestOS = "other-64"
uuid.location = "56 4d 65 cc e2 bd 7c b8-9b 58 56 0d e5 d2 81 e3"
uuid.bios = "56 4d 7f 68 d9 b4 90 c1-62 60 aa ba f4 51 11 69"
vc.uuid = "52 f3 93 fa ec b5 93 9b-c4 25 5e 33 c9 3f 1c 0b"

vmi.present = "false"
scsi0:0.mode = "independent-persistent"
ide1:0.fileName = "C:\Virtual Machines\|23 iso\VMware-VMvisor-InstallerCD-3.5.0_Update_3-123629.i386.iso"
floppy0.fileType = "file"
floppy0.fileName = "C:\Virtual Machines\|23 iso\floppy.flp"
chipset.onlineStandby = "false"
bios.forceSetupOnce = "false"

vmware.tools.requiredversion = "7396"
monitor_control.restrict_backdoor = "true"
monitor.virtual_exec = "hardware"
monitor.virtual_mmu = "hardware"

ethernet0.generatedAddress = "00:0c:29:51:11:69"
scsi0:0.redo = ""
vmotion.checkpointFBSize = "16777216"
ethernet0.generatedAddressOffset = "0"


[Dayworker]

Mit diesen Einstellungen aus dem Sticky-Posting von Continuum aus dem ESX-Bereich kann ich den ESXi lokal auf dem Server2 installieren
Einziger markanter Unterschied zu dieser Tageszeit oder eher Nachtzeit ist die HW-Version 6.

Code: Alles auswählen

.encoding = "windows-1252"
config.version = "8"
virtualHW.version = "6"
displayName = "esx35i_continuum"
ethernet0.present = "TRUE"
ethernet0.virtualdev = "e1000"
ethernet1.present = "TRUE"
ethernet1.virtualdev = "e1000"
floppy0.present = "FALSE"
guestOS = "other-64"
ide1:0.autodetect = "TRUE"
ide1:0.deviceType = "cdrom-image"
ide1:0.fileName = "C:\Virtual Machines\|23 iso\VMware-VMvisor-InstallerCD-3.5.0_Update_3-123629.i386.iso"
ide1:0.present = "TRUE"
memsize = "1024"
monitor.virtual_exec = "hardware"
monitor_control.restrict_backdoor = "true"
numvcpus = "1"
scsi0.present = "TRUE"
scsi0.virtualDev = "lsilogic"
scsi0:0.fileName = "esx35i_continuum.vmdk"
scsi0:0.present = "TRUE"
sound.present = "FALSE"

extendedConfigFile = "esxi_continuum.vmxf"
virtualHW.productCompatibility = "hosted"
tools.upgrade.policy = "manual"

ethernet0.features = "1"
ethernet0.networkName = "HostOnly"

ethernet1.features = "1"
ethernet1.networkName = "HostOnly"

ide1:0.allowGuestConnectionControl = "FALSE"

scsi0.sharedBus = "none"
scsi0:0.writeThrough = "TRUE"
scsi0:0.mode = "independent-persistent"

ethernet0.addressType = "generated"
ethernet1.addressType = "generated"
uuid.location = "56 4d c6 e7 42 18 37 ed-0a a3 ed 21 f6 a2 e5 83"
uuid.bios = "56 4d c6 e7 42 18 37 ed-0a a3 ed 21 f6 a2 e5 83"
scsi0:0.redo = ""
vmotion.checkpointFBSize = "16777216"
scsi0.pciSlotNumber = "16"
ethernet0.pciSlotNumber = "17"
ethernet1.pciSlotNumber = "18"
ethernet0.generatedAddress = "00:0c:29:a2:e5:83"
ethernet0.generatedAddressOffset = "0"
ethernet1.generatedAddress = "00:0c:29:a2:e5:8d"
ethernet1.generatedAddressOffset = "10"


[continuum]

Hier noch mal der direkte download - link
http://sanbarrow.com/moa24/files/esxi_35.zip

[Dayworker]

Ich könnt mir in den A**** treten. Ich hab meinen Knackpunkt in den Konfigurationen gefunden!
Die Virtuelle HW-Version ist auf meinem Intel E6600 egal, ich habs an 3 VMs ausprobiert.
V4 in meiner Suse64-VM, V6 mit der Seite1-Konfig von continuum aus dem ESXi_in_WS6.5-Thread im ESX-Bereich und mit V7 über den Download-Link.

Code: Alles auswählen

monitor_control.restrict_backdoor = "TRUE"
monitor.virtual_exec = "hardware"

waren ja klar,

aber

Code: Alles auswählen

monitor.virtual_mmu = "automatic" oder "software"

oder

Virtual_MMU einfach komplett aus der Konfig zu nehmen darauf muß man erstmal kommen. Ich glaube mittlererweile, daß die Einstellung "Hardware" nur für eine AMD-CPU geeignet ist bzw überhaupt Sinn macht. Allerdings könnte das auf einem Nehalem-System schon wieder anders aussehen!

Der Nachteil der ganzen Geschichte sei dabei aber auch nicht verschwiegen. Die Tools lassen sich zumindest unter Suse64 nicht mehr installieren und brechen mit der Fehlermeldung, daß dieses Prog nur für die Installation in einer VM bestimmt sei, ab!

[continuum]

???

monitor.virtual_mmu = "hardware"
wird automatisch angepasst - falls kein Hardware support moeglich ist.
Die "hardware" Einstellung funktioniert nur mit allerneuesten AMD-CPUs

Die Tools lassen sich zumindest unter Suse64 nicht mehr installieren und brechen mit der Fehlermeldung, daß dieses Prog nur für die Installation in einer VM bestimmt sei, ab!

???????

[continuum]

Ach ja - in einer nested VM im ESX 3.5 oder ESX 3.5.i laufen keine 64bit VMs

[Dayworker]

Der Nachteil der ganzen Geschichte sei dabei aber auch nicht verschwiegen. Die Tools lassen sich zumindest unter Suse64 nicht mehr installieren und brechen mit der Fehlermeldung, daß dieses Prog nur für die Installation in einer VM bestimmt sei, ab!

Kleiner Verdreher meinerseits und sollte eigentlich etwas anderes aussagen.
Ich habe meine Suse64-VM zum testen auf die Einstellungen:

Code: Alles auswählen

monitor_control.restrict_backdoor = "true"
monitor.virtual_exec = "hardware"

gesetzt und konnte dann die Tools weder zum Laufen (Maus hängt im VM-Fenster fest und läßt sich nur mit STRG+ALT befreien) noch zum neu installieren in dieser VM animieren. Statt dessen teilt mir das Tools-Script mit, daß man zur Inst eine virtuelle Maschine bräuchte. Mit anderen Worten findet das VMware-Tools-Script selbst keine Hinweise darauf, daß es bereits innerhalb einer VM gestartet wurden.

???
monitor.virtual_mmu = "hardware"
wird automatisch angepasst - falls kein Hardware support moeglich ist.
Die "hardware" Einstellung funktioniert nur mit allerneuesten AMD-CPUs

Ja stimmt. ABER mit dieser Einstellung wird bei mir automatisch auch "monitor.virtual_exec" entweder auf "dynamic" bei meiner Suse64-VM oder "software" bei meiner ESXi-VM umgestellt. Die ESXi-VM ist dann dauerhaft (nach 2h immer noch keine Veränderung und dann von mir abgebrochen) unter Volllast bei "Loading vmkernel" und spuckt Meldungen ala

Code: Alles auswählen

Dec 07 03:03:36.271: vcpu-0| SEG_SS 1254 count=9999

im Log raus.

[Dayworker]

In der VMware-Community habe ich grad noch eine Antwort erhalten, welche gleichzeitig auch das von mir festgestellte Umschalten erklärt.

The pair of configuration settings, monitor.virtual_exec and monitor.virtual_mmu, are not independent. They are used together to specify one of three execution modes: BT, HV, or HWMMU. Since the execution mode you requested (HWMMU) is not supported by your hardware, it was ignored. The fallback was the default execution mode for this guest OS. In VMware Server, the default execution mode for other-64 is BT. That default has been changed to HV for Workstation 6.5.1, and should probably be changed for any future releases of VMware Server as well.

I agree that it would be better if only the monitor.virtual_mmu setting was ignored. I'll file a bug report.

[continuum]

Interessant - wusste gar nicht das VMserver sich da anders verhaelt wie die Workstation 6.5.1

Ronald - am besten mache ich zwei downloads - einen fuer VMserver 2 und einen fuer WS 6.5.1 - was meinst du ?

[Dayworker]

Also prinzipiell sollte es ausreichen, eine Version für beides zu haben. Ich würd vielleicht in einer Readme-Datei die empfohlene Einstellung für AMD's K10 & Intel's Core i7 auf der einen Seite und auf der anderen Seite die nötige Einstellung für die ältere Core2-Generation nennen.
Es werden ja sicher noch einige Server2-Versionen das Licht der Welt erblicken und in der Annahme, daß der Bug auch bearbeitet wird, zieht der Server2 mit der WS6.5.1 wieder gleich.

[Dayworker]

Hat eigentlich schon jemand mal die Einstellungen unter Server1 ausprobiert?