XEN Memory Ballooning

[Serow]

Hi,

wie der Titel vermuten lässt beschäftige ich mich gerade etwas eingehender mit XEN - speziell mit dem Balloon Driver.

Was ich bisher so gelesen habe ist, dass beim starten von XEN der komplette Speicher in dom0 zugeteilt wird. Wenn dann eine domU gestartet wird, wird dom0 solange Memory weggenommen bis die konfigurierte Memoryzuweisung für die domU befriedigt wurde. Wenn dom0 kein Speicher mehr weggenommen werden kann um die Memoryanforderung einer zu startenden domU zu erfüllen, kann die domU nicht gestartet werden. Wenn man jetzt eine domU ausschaltet wird der freigewordene RAM nicht wieder zurück in die dom0 "gepusht" sondern gammelt als nicht-ge-mappter RAM irgendwo rum. Richtig soweit?

1. Frage:
Wenn man nicht-gemappten RAM hat: Werden dann Memoryanforderungen einer neugestarteten domU zuerst aus diesem ungemappten RAM befriedigt und wenns nicht ausreicht per ballooning aus dom0?

2. Frage:
Warum macht man erst eine komplette Zuweisung des RAMs an dom0?

3. Frage:

workhorse:~# cat /proc/xen/balloon 
Current allocation:   524288 kB
Requested target:     524288 kB
Low-mem balloon:        4352 kB
High-mem balloon:          0 kB
Driver pages:           1024 kB
Xen hard limit:          ??? kB
workhorse:~#

Eigentlich verstehe ich keinen dieser Werte. Für einige habe ich Tests gemacht um eine Änderung verfolgen zu können, aber die gingen fast alle so aus, dass ich mit das ganze nicht erklären konnte. Soweit ich bisher gelesen habe wird von einer domain NICHT dynamisch Memory vom Hypervisor angefordert. Der Wert "Requested Memory" lässt aber eher darauf schließen, dass das doch so ist?!?!?! Wenn mir irgendjemand diese Anzeige sauber erklären könnte, wäre ich schon sehr dankbar!!

mfg
serow

 

[gelöscht]

Original von Serow
1. Frage:
Wenn man nicht-gemappten RAM hat: Werden dann Memoryanforderungen einer neugestarteten domU zuerst aus diesem ungemappten RAM befriedigt und wenns nicht ausreicht per ballooning aus dom0?

Soweit ich es jetzt weiß, müsste die DomU wieder neu gestartet werden, damit wieder dynamisch der RAM verteilt werden kann. So ist es zumindest der Doku zu entnehmen.

Um zu gucken wie die Verteilung gerade ist kannst du in der Konsole:

xm list

eingeben.

Damit siehst du, wie die dynamische Verteilung gerade ist und mit

xm  mem-set <Domain> <Memory>

kannst du die Zuordnung des RAM wieder neu setzen, dementsprechend müsste die Domain dann wieder neu gestartet werden.

Original von Serow
2. Frage:
Warum macht man erst eine komplette Zuweisung des RAMs an dom0?

Ganz einfach, weil die Dom0 immer den kompletten physikalischen RAM für sich in Anspruch nimmt, d.h. die DomU (unprivilegiert) keinen direkten Zugriff auf die Hardware hat, demzufolge wurde eben bei Xen das Balloon eingeführt.

Grüße

Zephyros

 

[Serow]

Ganz einfach, weil die Dom0 immer den kompletten physikalischen RAM für sich in Anspruch nimmt, d.h. die DomU (unprivilegiert) keinen direkten Zugriff auf die Hardware hat, demzufolge wurde eben bei Xen das Balloon eingeführt.

Ja - aber das ist doch keine Begründung. Warum gibt man dom0 nicht einen ebenfalls irgendwie konfigurierten Wert, lässt alles ungemappt, und wenn eine domU gestartet wird gibt man ihr was von dem ungemappten Memory. Wenn ne domU ausgeschalten wird, wird ihr RAM freigegeben aber nicht in die dom0 gepusht - dh er ist ungemappt. Wenn man sie wieder startet nehme ich mal an, dass der ungemappte RAM wieder benutzt werden kann. Warum alles zuerst in dom0 rein?
Wenn dom0 aber wirklich immer alles bekommt: Warum kann man dann per Kernel Parameter den RAM von dom0 begrenzen? Ich finde das irgendwie sehr verwirrend. Macht für mich gerade alles nicht sehr viel Sinn. Warum ist in dom0 gemappter Speicher "besser" als ungemappter?

Damit siehst du, wie die dynamische Verteilung gerade ist und mit

xm  mem-set <Domain> <Memory>

kannst du die Zuordnung des RAM wieder neu setzen, dementsprechend müsste die Domain dann wieder neu gestartet werden.

xenhost:~# xm list rtorrent
Name                                        ID   Mem VCPUs      State   Time(s)
rtorrent                                    11   128     1     -b----      1.4
xenhost:~# xm console rtorrent

rtorrent:~# cat /proc/xen/balloon 
Current allocation:   131072 kB
Requested target:     131072 kB
Low-mem balloon:        4352 kB
High-mem balloon:          0 kB
Driver pages:           1024 kB
Xen hard limit:          ??? kB
rtorrent:~#

Okay, wenn man mal so tut als wüsste man was die ganzen Zeilen bedeuten, sieht das eigentlich okay aus. Ich bekomme in xm list 128 MB angezeigt und das entspricht ja den 131072KB aus /proc/xen/balloon.

xenhost:~# xm mem-set rtorrent 200
Error: memory_dynamic_max must be less than or equal to memory_static_max
Usage: xm mem-set <Domain> <Mem>

Set the current memory usage for a domain.
xenhost:~#

Okay, ich hab in der Konfigurationsdatei 128 als Memory gesetzt, dh das ist das maximum und kann auch durch xm mem-set erstmal nicht überschritten werden.

xenhost:~# xm mem-set rtorrent 100
xenhost:~# xm console rtorrent

rtorrent:~# cat /proc/xen/balloon 
Current allocation:   102400 kB
Requested target:     102400 kB
Low-mem balloon:       33024 kB
High-mem balloon:          0 kB
Driver pages:           1024 kB
Xen hard limit:          ??? kB
rtorrent:~#

Unterschritten werden kann das Maximum indem ich den RAM mit xm mem-set wegnehme. Wenn ich vorher mit xm mem-max ein anderes Maximum setze, kann ich mit xm mem-set das alte Maximum bis zum neuen hin überschreiten:

xenhost:~# xm mem-max rtorrent 200
xenhost:~# xm list rtorrent
Name                                        ID   Mem VCPUs      State   Time(s)
rtorrent                                    11   100     1     -b----      1.5
xenhost:~# xm mem-set rtorrent 200
xenhost:~# xm list rtorrent
Name                                        ID   Mem VCPUs      State   Time(s)
rtorrent                                    11   200     1     -b----      1.5
xenhost:~# xm console rtorrent

rtorrent:~# cat /proc/xen/balloon 
Current allocation:   130668 kB
Requested target:     204800 kB
Low-mem balloon:        4756 kB
High-mem balloon:          0 kB
Driver pages:           1024 kB
Xen hard limit:       130668 kB
rtorrent:~#

Neugestarten werden muss die VM also scheinbar nicht. Ich nehme jetzt einfach mal an, dass "Requested Target" das ist, was der Balloon Driver vom Hypervisor angefordert hat. Gut momentan wird halt weniger verwendet.
Bleiben noch die Fragen nach den restlichen Werten. "Low-mem balloon" ist jetzt scheinbar gestiegen und plötzlich kennt er auch sein "Xen hard limit". Allerdings entspricht der Wert von 130668KB ja nicht den 200MB die ich als Maximum gesetzt habe - 200MB würde ich hier erwarten. Scheinbar ist "Xen hard limit" was ganz anderes!?!?!
Was "Driver pages" sein soll ist mir auch ein Rätsel ... Ich hätte vermutet, das sind die Memory Pages, die der Balloon Driver alloziert hat. Aber 1024KB als Wert?? Kann ja nicht sein irgendwie oder?

 

[gelöscht]

Ich muss gestehen ich bin kein Xen - Experte, von daher kann ich dir leider auch nicht alles beantworten, sondern eben nur teile, wie im 1. Post von mir.

Original von Serow
Ja - aber das ist doch keine Begründung. Warum gibt man dom0 nicht einen ebenfalls irgendwie konfigurierten Wert, lässt alles ungemappt, und wenn eine domU gestartet wird gibt man ihr was von dem ungemappten Memory. Wenn ne domU ausgeschalten wird, wird ihr RAM freigegeben aber nicht in die dom0 gepusht - dh er ist ungemappt. Wenn man sie wieder startet nehme ich mal an, dass der ungemappte RAM wieder benutzt werden kann. Warum alles zuerst in dom0 rein?

Weil Dom0 der eigentliche "Wirt" ist, der (wie oben erwähnt), die einzige Domäne ist die mit der physikalischen Hardware kommuniziert, die DomU ist auch nur eine aufgesetzte Domäne auf Dom0. Sozusagen ist Dom0 die Schnittstelle zw. Hardware und den virtuellen Hosts.

Original von Serow
Wenn dom0 aber wirklich immer alles bekommt: Warum kann man dann per Kernel Parameter den RAM von dom0 begrenzen? Ich finde das irgendwie sehr verwirrend. Macht für mich gerade alles nicht sehr viel Sinn. Warum ist in dom0 gemappter Speicher "besser" als ungemappter?

Kann mich nur wiederholen, Dom0 ist die einzige Domäne die mit der physikalischen Hardware kommunizieren kann. Ob es Sinn macht oder nicht, müsstest du Xen fragen, ein wenig sinnfrei klingt es ja, aber die werden schon ihre Gründe haben.

Das ist mit anderen VM's nicht groß anders, der "Wirt" kommuniziert und regelt alles zw. Hardware und Gastssystemen. Bei Xen ist es eben noch besonders, genau wie beim Hyper-V und VMWare ESX, als z.b. bei VirtualBox oder VirtualPC.

Virtualisierung ist eben auch nicht so ganz einfach, aber sicherlich steckt dort seine logische Struktur drin. Xen hat allerdings eine sehr gute Doku und auch ein sehr gutes Wiki.

Grüße

Zephyros

 

[Serow]

Naja, dass dom0 für die Hardwareresourcen zuständig ist, ist so nicht ganz korrekt. Für jeglichen I/O stimmt das (Event Channel), aber für Scheduling und Memory ist der Hypervisor direkt verantwortlich.

Weil Dom0 der eigentliche "Wirt" ist, der (wie oben erwähnt), die einzige Domäne ist die mit der physikalischen Hardware kommuniziert,

dom0 ist nicht der Wirt für die Gäste - sonst hätten wir ja architekturtechnisch eine Situation wie in VMware Workstation oder VirtualBox. XEN ist aber was das angeht eher mit VMware ESX vergleichbar und dom0 mit der Service Console vom ESX. Ein "bare-metal" Hypervisor, wie VMware so schön sagt.

cu
serow