Zweite Frage ist einfach: JA! Dann teilen sich mehrere VMs halt eine phys. CPU (und der vmkernel schaut automatisch alle 20ms, welche vCPU auf welcher lCPU laufen soll). Die maximale Zahl der Virtuellen CPUs auf einem ESX ist aber beschränkt (Steht im max_config_guide auf der vmware-homepage)
Erste Frage ist etwas schwieriger:
Memory Overhead ist der Speicher, den der ESX pro VM braucht, für deren Verwaltung (abhängig von RAM-Größe der VM, Anzahl vCPUs und 64oder32-bit-Gast). Genauere Tabelle im Res.Mgmt.Guide, auch auf der VMware-Homepage... Der Overhead wird übrigens immer auf die Memory Reservation einer VM dazuaddiert, und vom Start weg reserviert (drum auch die "ungeraden" Werte im "Ressource Allocation"-Tab eines Ressource-Pools/Hosts). Bleibt "stabil" während der gesamten Laufzeit einer VM.
Guest Memory usage ist der Speicher, den das Gast-OS gerade "benutzt", also drauf zugreift. unabhängig von der Physik.
Host Memory letztendlich ist der Speicher, den der ESX gerade für diese VM wirklich im physikalischen Speicher verwendet (inkl. overhead, und abzügl. Transparent Page Sharing, wenn ich mich nich irre
).
Es macht nix, wenn die beiden Werte auseinander liegen. Sobald physikalischer Speicher auf dem ESX knapp wird, sollten sich beide Werte annähren, weil dann der vmkernel effizienter mit dem physikal. Speicher "haushalten" muss. Wenns überschlägt, d.h. Guest Memory größer Host Memory usage, dann ist das normalerweise ein Zeichen für Swapping-Aktivität.
Wenn der Guest-Memory-Usage nahe an den Wert kommt, den die VM als Speicher "eingebaut" hat, bekommt man einen Guest Memory Usage-Alarm.
Physikalisch "benötigt" wird also der Overhead aller VMs, plus der Guest Memory Usage (der wechselst natürlich ständig), abzgl. Einsparungen durch Transparent Page Sharing. (In der knappsten Kalkulation). Bei weniger physik. RAM gibts swapping => schlecht für die performance.
Was min. benötigt wird, um eine VM zu starten, ist die Summe aller Reservations der VMs plus den Overhead aller VMs.
Service Console ist dabei übrigens außen vor, bei diesen Betrachtungen, also defaultmäßig immer noch die 272M dazuzählen, und das für den VMkernel selber.
Nähere Infos dazu gibts auch im sehr empfehlenswerten Resource Management Guide (nicht nur die Overhead-Tabelle).
Viele Grüße,
Jörg
ps, gerne rumexperimentieren, außer schlechterer performance zwischendrin kann nix passieren
