[libvirt] [Xen-devel] [PATCH RESENT 04/12] libxl: populate xenstore memory entries at startup
Marek Marczykowski
marmarek at invisiblethingslab.com
Thu Apr 11 10:53:00 UTC 2013
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 "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.
--
Best Regards / Pozdrawiam,
Marek Marczykowski
Invisible Things Lab
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 553 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20130411/d1cbb1ce/attachment-0001.sig>
More information about the libvir-list
mailing list