You may know that the Red Hat Enterprise Linux 3 Update 6 based ESX 3.x Service Console default memory allocation has been 272MB since its first release. VMware Infrastructure 3 Advanced Technical Design Guide authors Ron Oglesby and Scott Herold discuss in their book about how Service Console memory requirements in ESX 3.x have become less of a factor in 3.x compared to 2.x since the Service Console has been stripped of some of its resonsibilities including 
VMM and hardware management. They go so far as to say the default value of 272MB should be enough memory for most environments. I generally accept this theory, but for the record I have been on plenty of support calls where VMware recommends increasing Service Console memory to its maximum value of 800MB. Many subscribe to maxing out Service Console memory as a best practice to avoid problems down the road and if nothing else, avoid a reboot for the memory change or rebuild to resize Service Console swap. Service Console memory utilization will vary between environments and will influenced by 3rd party software which is installed in the Service Console such as anti-virus, hardware agents, backup agents, etc. The number of vSwitch ports will also impact Service Console memory use.
Left to their own discretion, many have established their own build standards with respect to Service Console memory allocation. Some will increase it. Some will leave it at the factory default of 272MB. I haven’t heard of anyone reducing Service Console memory usage but it can be lowered slightly down to 256MB. Whatever you decide, be sure you adjust your Service Console swap accordingly. While we’re on the subject, the assignable range of Service Console memory in ESX 4.0 is the same as 3.x (256MB – 800MB), however, the default Service Console memory assignment in ESX 4.0 is 400MB whereas it is 272MB in ESX 3.x.
While working in the lab on my VCDX design, I discovered that VMware has increased the default Service Console memory assignment to 512MB as of ESX 3.5.0 Update 5. For those who configure and tune their ESX hosts manually, this is a non issue for you. Continue to manually configure your ESX hosts. Those with automated post build scripts using sed to change Service Console memory allocation, you’ve got a few changes to make to your scripts. Basically, whereas sed used to look for 272MB values to replace, it must now search for 512MB values. For example:
An ESX 3.5.0u4 post build script which increases COS memory from 272MB to 800MB:
cp /etc/vmware/esx.conf /etc/vmware/esx.conf.old
cp /boot/grub/grub.conf /boot/grub/grub.conf.old
/bin/sed -i -e ‘s/272/800/’ /etc/vmware/esx.conf
/bin/sed -i -e ‘s/272M/800M/’ /boot/grub/grub.conf
/bin/sed -i -e ‘s/277504/818176/’ /boot/grub/grub.conf
Will become an ESX 3.5.0u5 post build script which increases COS memory from 512MB to 800MB:
cp /etc/vmware/esx.conf /etc/vmware/esx.conf.old
cp /boot/grub/grub.conf /boot/grub/grub.conf.old
/bin/sed -i -e ‘s/512/800/’ /etc/vmware/esx.conf
/bin/sed -i -e ‘s/512M/800M/’ /boot/grub/grub.conf
/bin/sed -i -e ‘s/523264/818176/’ /boot/grub/grub.conf
If you’ve got a mix of 3.5u4 and 3.5u5 hosts and you wish to use the same centralized post configuration script on each, the following script should cover both:
cp /etc/vmware/esx.conf /etc/vmware/esx.conf.old
cp /boot/grub/grub.conf /boot/grub/grub.conf.old
/bin/sed -i -e ‘s/272/800/’ /etc/vmware/esx.conf
/bin/sed -i -e ‘s/512/800/’ /etc/vmware/esx.conf
/bin/sed -i -e ‘s/272M/800M/’ /boot/grub/grub.conf
/bin/sed -i -e ‘s/512M/800M/’ /boot/grub/grub.conf
/bin/sed -i -e ‘s/277504/818176/’ /boot/grub/grub.conf
/bin/sed -i -e ‘s/523264/818176/’ /boot/grub/grub.conf
I looked in the ESX 3.5.0 Update 5 release notes and did not see anything about a Service Console memory allocation increase. My hunch is VMware realized they can reduce their volume of support calls and ultimately increase support revenue margin by granting the Service Console more memory out of the box.
The lab has once again fulfilled its purpose. You test releases in your lab or development environment, right? Right? 🙂
Happy Holidays
your sed scripts are dangerous. I don’t have the file syntax handy, but I’m pretty sure it’s “keyword=value” so your script must be written so that action is taken ONLY on the matching “keyword=” line.
sed ‘/keyword=/ s/value1/value2’
I agree that the listed sed commands are dangerous. You are changing any instance of 272 & 500 to 800 in esx.conf. There are hundreds of lines in esx.conf. I think you should be doing a more thorough search.
Like this. sed -e ‘s/boot\/memSize = \”272\”/boot\/memSize = \”512\”/g’
and sed -e ‘s/uppermem 277504/uppermem 523264/g’ -e ‘s/mem=272M/mem=512M/g’
Or even better is to use vmware-vim-cmd. I am still fully testing this, but it should work on both 3.5 and 4.0. /usr/bin/vmware-vim-cmd /hostsvc/memoryinfo 838860800
I agree that adding more explicitness to the search string will more easily depict what the script is doing to unfamiliar eyes plus it will protect future builds of ESX should additional matching strings be introduced which are not related to memory.
That aside, future builds should be tested in a LAB or DEV environment. The scripts work correctly with current builds of ESX and there are not additional matching strings which would taint either configuration file with unintended settings.
Following are “out-of-the-box” conf files from ESX 3.5 Update 5. Use the “find” function and you will see there are no additional string matches other than what we intend to change.
http://www.boche.net/dropbox/esx.conf
http://www.boche.net/dropbox/grub.conf
Thank you for the comments!
Well spotted!
Making it future proof and working on both u4 and u5 builds, the sed syntax can be changed into this:
sed -i ‘s/memSize = “[0-9][0-9][0-9]”/memSize = “800”/’ /etc/vmware/esx.conf
Alternatively you can issue a single vimsh cmd:
vimsh -n -e “/hostsvc/memoryinfo 838860800”
(Requires reboot)