vmx Datei Parameter monitor.phys_bits_used = "40"

[pirx]

Hallo,

kann mir jemand sagen, für was der Parameter monitor.phys_bits_used zuständig wird? Der Support sagt ich soll die Zeile in der vmx Datei entfernen. Dokumentiert ist der Parameter nicht und der L1 kann mir auch nicht sagen was er macht und _warum_ ich ihn entfernen soll (L2 sagt das muss so sein). Er ist in jeder vmx Datei bei mir enthalten, mit unterschiedlichen Werten (36, 40, 42...).

[Dayworker]

Der Wert gibt ausgehend von seiner Bezeichnung an, wieviel pRAM die CPU ansprechen/addressieren kann. Die Wertangabe erfolgt in Bytes:

2^32 = 4,294,967,296B = 4194304KB = 4096MB = 4GB
2^36 = 68,719,476,736B = 67108864KB = 65536MB = 64GB
2^40 = 1,099,511,627,776B = 1073741824KB = 1048576MB = 1024GB = 1TB
...
2^64 = 18,446,744,073,709,551,616 = 16 Exabytes

Dieser Wert ist auch ein Hinweis des VMM, wieviel pRAM er in den 64bittigen Adressraum heutiger CPUs einzublenden gedenkt und wie der Hypervisor den Speicher in seinen Adressraum per Address Space Layout Randomization (ASLR) abbildet. Im Grunde ist das eigentlich nur interessant, wenn man laufende VMs per vMotion zwischen verschiedenen Hosts migrieren will. Als weiteres Stichwort sei dazu auch Enhanced vMotion Compatibility (EVC) processor support (1003212) genannt, denn laufende VMs lassen sich meines Wissens nur zwischen CPUs gleichen Featurelevels migrieren.

Da der VMware-Support die Entfernung anweist, kann das eigentlich nur bedeuten, daß der entsprechende Eintrag nicht mehr aktualisiert wird, sobald er einmal gesetzt wurde. Denn der Wert wird beim ersten Start einer VM gesetzt und ändert sich, solange die VM auf demselben CPU-Typ ausgeführt wird, auch nicht mehr. Solange der Parameter unterhalb des realen Ansprechbereiches eingestellt ist, verringert man vielleicht nur die ansprechbare pRAM-Menge oder die Adressbereiche überschneiden sich im Hypervisor, was fatale Folgen bis zum Absturz haben kann.


Welche Probleme treten denn bei dir auf?
Vielleicht läßt sich ja daraus auf genaueres schliessen...

[pirx]

Das Problem ist eigentlich mehr auf der VM, bzw. Applikationsseite zu finden. Seit dem Update eines Clusters von 5.5 auf 6.0U1b crashen Applikationen und schreiben Minidumps (das ist erst seit kurzem klar). Das Eventlog der W2Kx VMs ist voller Fehlermeldungen. Die Analyse von MS geht Richtung Memory in Verbindung mit ESXi. Nach der Rollback von 2 Hosts auf 5.5 treten die Probleme bei den VMs nicht mehr auf.

Der Windows Kollege meint aber, dass nun auch die Probleme bei den VMs auf den verbliebenen 6er Hosts nicht mehr auftreten. Auffällig ist das sich die BIOS Version der VMs geändert hat. Bisher weiß ich nicht was für das Update der BIOS Version einer VM verantwortlich ist (Tools, vHW, ESXi Version). Auch der Support konnte das nicht beantworten.

Das Problem ist nicht so einfach zu greifen. Sowohl MS als auch VMware haben Full Dumps von VMs.

[Dayworker]

Die vBIOS-Version kann sich meiner Erfahrung nach mit den VMware-Produkten VMserver1/2, WS/Player mit jeder Produktversion ändern und dürfte daher auch für den ESXi zutreffen. Ob dazu auch Updates gehören, habe ich nicht verfolgt, halte es jedoch für möglich.

Kannst du bitte 1 oder 2 "vmware.log" betreffender VMs verlinken?
Würde mich echt interessieren, wie, was und ob etwas in den Logs vermerkt wird.

[Dayworker]

Hier mal die Logeinträge meiner CPU aus der Signatur unter zwei verschiedenen VMware-Produkten:

vmx| CPUID[0] vendor: GenuntelineI
vmx| CPUID[0] name: Intel(R) Xeon(R) CPU E3-1220 V2 @ 3.10GHz
...
vmx| CPUID Maximum Physical Address Bits supported across all CPUs: 36

vmx| I120: hostCPUID vendor: GenuineIntel
vmx| I120: hostCPUID family: 0x6 model: 0x3a stepping: 0x9
vmx| I120: hostCPUID codename: Ivy Bridge E3
vmx| I120: hostCPUID name: Intel(R) Xeon(R) CPU E3-1220 V2 @ 3.10GHz
...
vmx| I120: CPUID Maximum Physical Address Bits supported across all CPUs: 36

Die dort vermerkten 64GB sind aber die doppelte Menge, der im Intel-ARK für den Intel Xeon-Processor E3-1220v2 gelisteten 32GB. Eventuell ist das auch ein Sicherheitsbereich, damit Addressierungskonflikte vermieden werden. Sicher bin ich mir damit aber nicht, dazu müßte man sich mal eingehender mit dieser Materie befassen.