On Thu, 2013-04-11 at 11:53 +0100, Marek Marczykowski wrote:
On 11.04.2013 09:52, Ian Campbell wrote:
> On Thu, 2013-04-11 at 05:09 +0100, Jim Fehlig wrote:
>>> + /* This will fill xenstore info about free and dom0 memory - if
missing,
>>> + * should be called before starting first domain */
>>> + if (libxl_get_free_memory(libxl_driver->ctx, &free_mem)) {
>>> + VIR_ERROR(_("cannot get free memory info"));
>>> + goto error;
>>> + }
>>>
>>
>> Should failure of libxl_get_free_memory() really be fatal and prevent
>> the driver from loading?
>
> I'm not sure it is intended to be called like this...
>
> I think it is intended to be called as part of starting every domain, to
> check if there is enough free memory for that domain, rather than
> calling it once at start of day.
>
> In that context if it fails or returns less than the required amount of
> memory then that would be fatal for starting that domain.
>
> In xl we use this as part of the auto balloon of dom0, see
> xl_cmdimplg.c:freemem. Does libvirt do autoballooning or does it require
> dom0_mem? Perhaps this is handled at a higher level?
The problem is how libxl set initial value for freemem-slack. If, for any
reason, dom0 hasn't (almost) all memory assigned before creating first domain,
15% of host memory will no longer be used at all.
This is probably one for Stefano who understands this aspect best, I
think. (He's back next week, so this may need to wait). IanJ also knows
this stuff better than I, I've added both of them to the CC.
Note that whatever problem you are envisaging is also true if /creating
first domain/starting libvirtd/ (or whatever the relevant daemon is
called).
This "any reason" can be
dom0_mem, which is covered by "auto" value for autoballoon in xen-unstable
(actually only for xl, not libxl in general). But this can also happen if
somebody calls xl set-mem 0 <some value>. The later case doesn't mean the user
want to disable autoballoon completely.
And to answer you question - libvirt rely on libxl autoballoon.
AIUI autoballoon and dom0_mem (and I think mem-set at start of day too)
are mutually exclusive, which means that as it stands the libvirt
backend is incompatible with dom0_mem -- obviously this is something
which should be addressed. I don't think this patch is the right way to
do that but I'm not sure what is, hopefully Stefano or IanJ have some
ideas...
Ian.