----- On Feb 12, 2020, at 8:34 AM, Peter Krempa pkre...@redhat.com wrote: > to briefly summarize what those three knobs do: > > 1) memory - this is the initial memory size for a VM. qemu grants this > amount of memory to the VM on start. This is also the memory the guest > is able to use if the balloon driver is not loaded as the balloon driver > voluntarily gives up memory from the guest OS to the host. > > 2) currentmemory - in case the guest is using the balloon driver this is > the actual memory size it's using. This field is dynamically updated to > reflect the size reported by the balloon driver > > 3) maxMemory - This knob controls the maximum size of the memory when > memory hotplug is used. This basically sets the amount of address space > and memory slots the VM has so that new memory can be plugged in later.
Aaaah. > The above can also be added during runtime e.g. using virsh > attach-device. Hence hotplug. It can also be unplugged during runtime > but that requires guest cooperation and there are a few caveats of this. > Namely to successfully unplug the memory the guest must not write any > non-movable pages into it so that it can give up the memory later. On > linux that means that no memory-mapped I/O regions can be created there > which may lead to weird guest behaviour if the memory is onlined as > movable. I'm not sure how windows behaves in this regard though, but > AFAIK it supports memory hotplug just fine. > >> What i find concerning ballooning is that it doesn't work automatically but >> has >> to be adjusted >> manually. Is that right ? > > No, unfortunately none of this works automatically. > >> Is my idea right, does that work basically ? If yes how do i have to set the >> parameters ? >> Is the memory released after the guest has e.g. finished his calculation ? >> Does that work automatically or do i have to adjust that manually ? > > When using the balloon driver you can set the 'currentMemory' size down > to some reasonable value and the balloon driver will then return the > memory to the host. There were some attempts to make this automatic, but > I don't remember how they went. One other caveat is that any memory > returned by the balloon driver to the host may be available to the guest > again e.g. on reboot when the balloon driver is removed. > > For a 1 NUMA node guest the memory hotplug an balloon can theoretically > be combined but unplugging of the memory might not work while the ballon > is inflated. > > I hope this clarified it somehwat. Yes it did.Thanks. Ballon and Memeory hotplug are two different things, right ? Which is better, where are the advantages and disadvantages ? I played a bit around with ballooning and it went like a charm. If i try to use Hotplugging and inserts "maxMemory" and "memory model='dimm'" in the config, libvirt complains i have to add a "numa" entry. I don't know much about Numa, so maybe it's better not to use hotplugging. While reading in the internet i stumbled across KSM for Linux, which is recommended for the host if you have several guests of the same OS. What do you think about it ? Btw: is it also possible to add cpu's to guests during runtime ? Thanks. Bernd Helmholtz Zentrum München Helmholtz Zentrum Muenchen Deutsches Forschungszentrum fuer Gesundheit und Umwelt (GmbH) Ingolstaedter Landstr. 1 85764 Neuherberg www.helmholtz-muenchen.de Aufsichtsratsvorsitzende: MinDir.in Prof. Dr. Veronika von Messling Geschaeftsfuehrung: Prof. Dr. med. Dr. h.c. Matthias Tschoep, Kerstin Guenther Registergericht: Amtsgericht Muenchen HRB 6466 USt-IdNr: DE 129521671