This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] Re: [Xen-users] Max. PV and HVM Guests

Thanks for the information!  Looks like I'll be adjusting some boot-time 
options on my Xen servers.  I have seen a couple of issues now and then with 
either migration or starting a domU, but it happens once every few months at 
the most, and usually I blame the migration issues on a fault network 
connection or something like that.  I'll have to try out limiting my dom0s to 1 
or 2 GB of RAM and see if those issues go away!


>>> On 2009/11/09 at 08:18, Keir Fraser <keir.fraser@xxxxxxxxxxxxx> wrote: 
> On 09/11/2009 15:06, "Nick Couchman" <Nick.Couchman@xxxxxxxxx> wrote:
>> Really?  I thought current conventional wisdom was to allow Xen to
>> self-manage memory in both dom0 and domUs, and not to manually adjust
>> this?  I run several Xen systems with anywhere from 8 to 24 GB of RAM
>> and 20 to 30 domUs on some of these systems and have *never* specified
>> the dom0 memory at boot time - the Xen ballooning has always functioned
>> perfectly fine, and never crashed my dom0.  Furthermore, while I'm not
>> Linux developer and so not familiar with how Linux calculates buffering
>> and caching, I do know that my Linux systems dynamically manage buffers
>> and caches, and when memory is reduced or some application requires a
>> larger amount of physical memory, Linux reduces the amount of data in
>> buffers and caches.
> If you are not using dom0 as a general-purpose OS then it is a very good
> idea to specify dom0's memory allowance via dom0_mem= and disable
> auto-ballooning in the xend-config.sxp. There are a few reasons for this,
> the most compelling being that Linux will have a metadata overhead for
> tracking memory usage, and this will be a fraction (say a percent or so) of
> its initial memory allocation. So, that overhead may be just 2% of 24GB,
> say, but then if dom0 gets ballooned down to 1GB it'll be more like 50%!
> Clearly you are limited in how far you can balloon down without risking the
> OOM killer in dom0.
> Apart from that, the auto-ballooner has been implicated in various quirky
> bugs in the past -- failing domain creations and migrations for the most
> part -- so it's nice to turn it off if you can, as that's one less thing to
> fail. And if dom0 is single-purpose you should be able to work out how much
> memory it needs for that purpose and statically allocate it. Using
> auto-ballooner is actually perverse in this scenario, in that dom0 gets the
> least memory when it needs it the most (because it presumably has highest
> load when servicing the most VMs, but in that case auto-ballooner has stolen
> lots of memory from dom0).
> My 2c!
>  -- Keir

This e-mail may contain confidential and privileged material for the sole use 
of the intended recipient.  If this email is not intended for you, or you are 
not responsible for the delivery of this message to the intended recipient, 
please note that this message may contain SEAKR Engineering (SEAKR) 
Privileged/Proprietary Information.  In such a case, you are strictly 
prohibited from downloading, photocopying, distributing or otherwise using this 
message, its contents or attachments in any way.  If you have received this 
message in error, please notify us immediately by replying to this e-mail and 
delete the message from your mailbox.  Information contained in this message 
that does not relate to the business of SEAKR is neither endorsed by nor 
attributable to SEAKR.

Xen-devel mailing list