in some scenarios, control domains (like dom0) can balloon

[djs55]

In a XenServer .iso configuration we keep domain 0 small and don't include it in DMC (ballooning/squeezed) calculations. We do this by setting VM.memory_dynamic_min = VM.memory_dynamic_max like this:

[root@st28 ~]# xe vm-list uuid=3a8b724e-8fb7-4679-921f-c404b27f7307 params=all | grep memory
             memory-static-max ( RW): 777256960
            memory-dynamic-max ( RW): 777256960
            memory-dynamic-min ( RW): 777256960
             memory-static-min ( RW): 307232768

In a typical xenserver-core configuration we give all (or at least lots of) host memory to domain 0, and use ballooning to make space for starting VMs. In this case domain 0 has memory settings like this:

[root@st20 ~]# xe vm-list uuid=a1fb665d-b0b0-d257-e3b2-ff36f3974106 params=all | grep memory
             memory-static-max ( RW): 8345174016
            memory-dynamic-max ( RW): 8345174016
            memory-dynamic-min ( RW): 1073741824
             memory-static-min ( RW): 1073741824

-- note that VM.memory_dynamic_min <> VM.memory_dynamic_max; this indicates that ballooning domain 0 is possible.

Everything seems to work fine in this second "xenserver-core" configuration except the new VM wizard warns that the host has not enough memory free. It arrives at this conclusion because the following property hard-wires domain 0 memory to static_max:

        /// <summary>
        /// The total of all the dynamic_minimum memories of all resident VMs ot
her than the control domain.
        /// For non-ballonable VMs, we use the static_maximum instead, because t
he dynamic_minimum has no effect.
        /// </summary>
        public long tot_dyn_min
        {
            get
            {
                long ans = 0;
                foreach (VM vm in Connection.ResolveAll(resident_VMs))
                {
                    if (!vm.is_control_domain)
                        ans += vm.has_ballooning ? vm.memory_dynamic_min : vm.memory_static_max;
                }
                return ans;
           }
        }

I think it would be better if the client always used the vm.memory_dynamic_min value, without overriding the value for the control domain. If there's a problem with the value provided for the control domain, then I think we should change it server-side.

[stephen-turner]

I don't think that's an example, because dom0 is explicitly not included in that calculation. However, I believe there may be other places where it is assumed that dom0 never balloons and that dynamic_m(in|ax) are ignored (which I think was the case when ballooning was first developed).