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