ESX 3.5.0 Update 5 Change in Serivce Console Memory

December 30th, 2009 by jason No comments »

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

VMware Releases ESX(i) 3.5 Update 5; Critical Updates

December 5th, 2009 by jason No comments »

VMware apparently released ESX(i) 3.5 Update 5 dated 12/3/09, however it became available on Update Manager late this afternoon.  VMware is extremely poor at communicating anything but major releases, so to get the fastest notification possible about security patches and updates, I configure my VMware Update Manager servers to check for updates every 6 hours and provide me with email notification of anything it finds.  VMware doesn’t listen to me much when it comes to feature requests so I’ll shelve the ranting.

So what’s new in ESX 3.5 Update 5?  The major highlights are guest VM support for Windows 7 and Windows Server 2008 R2 (reminder, 64-bit only), as well as Ubuntu 9.04, and added hardware support for processors and NICs.  Before you get too excited about Windows 7, remember that it is not a supported guest operating system in VMware View.  Even in the new View 4 release, Windows 7 has “Technology Preview” support status only.

If you track the updates from VMware Update Manager, the 12/3 releases amount to 20 updates including Update 5, 16 updates of which are rated critical.  If you’re still a ways out on vSphere deployment, you’ll probably want to take a look at the critical updates for your 3.x environment.

Enablement of Intel Xeon Processor 3400 Series – Support for the Intel Xeon processor 3400 series has been added. Support includes Enhanced VMotion capabilities. For additional information on previous processor families supported by Enhanced VMotion, see Enhanced VMotion Compatibility (EVC) processor support (KB 1003212).

Driver Update for Broadcom bnx2 Network Controller – The driver for bnx2 controllers has been upgraded to version 1.6.9. This driver supports bootcode upgrade on bnx2 chipsets and requires bmapilnx and lnxfwnx2 tools upgrade from Broadcom. This driver also adds support for Network Controller – Sideband Interface (NC-SI) for SOL (serial over LAN) applicable to Broadcom NetXtreme 5709 and 5716 chipsets.

Driver Update for LSI SCSI and SAS Controllers – The driver for LSI SCSI and SAS controllers is updated to version 2.06.74. This version of the driver is required to provide a better support for shared SAS environments.

Newly Supported Guest Operating Systems – Support for the following guest operating systems has been added specifically for this release:

For more complete information about supported guests included in this release, see the VMware Compatibility Guide: http://www.vmware.com/resources/compatibility/search.php?deviceCategory=software.

•Windows 7 Enterprise (32-bit and 64-bit)
•Windows 7 Ultimate (32-bit and 64-bit)
•Windows 7 Professional (32-bit and 64-bit)
•Windows 7 Home Premium (32-bit and 64-bit)
•Windows 2008 R2 Standard Edition (64-bit)
•Windows 2008 R2 Enterprise Edition (64-bit)
•Windows 2008 R2 Datacenter Edition (64-bit)
•Windows 2008 R2 Web Server (64-bit)
•Ubuntu Desktop 9.04 (32-bit and 64-bit)
•Ubuntu Server 9.04 (32-bit and 64-bit)

Newly Supported Management Agents – See VMware ESX Server Supported Hardware Lifecycle Management Agents for current information on supported management agents.

Newly Supported Network Cards – This release of ESX Server supports HP NC375T (NetXen) PCI Express Quad Port Gigabit Server Adapter.

Newly Supported SATA Controllers – This release of ESX Server supports the Intel Ibex Peak SATA AHCI controller.

Note:

•Some limitations apply in terms of support for SATA controllers. For more information, see SATA Controller Support in ESX 3.5. (KB 1008673)

•Storing VMFS datastores on native SATA drives is not supported.

vSphere 4.0 Quick Start Guide Released on Amazon

November 23rd, 2009 by jason No comments »

What a great way to kick off the new week – The highly anticipated book, vSphere 4.0 Quick Start Guide: Shortcuts down the path of Virtualization, has arrived at Amazon.com! I look at this new release as the 2nd edition or vSphere edition of RapidApp’s Quick Start Guide to ESX 3.0 which is still available and was a huge success.

The vSphere 4.0 Quick Start Guide was written by a lineup of new authors who are well known rock stars in the virtualization community: Bernie Baker, Thomas Bryant, Duncan Epping, Dave Mischenko, Stewart Radnidge, and Alan Renouf. I obtained a preview copy of this book at VMworld 2009 in San Francisco and I can tell you that this it is absolutely amazing. Nowhere else will you find as much information in such a small and convenient footprint. Its small size allows you to put it in your pocket and take it virtually anywhere: On the plane, on the bus, into a meeting, or into the datacenter. As with the first edition, there are several blank pages in this book which allow you space to write down notes, command line information, configuration maximum changes, information about your environment, helpful URLs, etc. The authors did a great job on this book and considering the cumulative years of experience and combined expertise packed into this book, you can’t beat the price. I don’t think a better value exists. My copy has been traveling with me daily in my laptop bag. I give it two thumbs up.

Old vCenter Server Name Shown In Title Bar; Update Manager Plugin Fails

November 22nd, 2009 by jason No comments »

I recently rebuilt a vCenter Server on a new Windows host having a different name than the vCenter Server host used previously. Wanting to maintain my existing datacenter configuration and layout, I chose to connect to and preserve the existing SQL database back end.

The installation went well and my existing datacenter configuration was in tact, however, I noticed one anomaly having two symptoms. After establishing a vSphere Client connection to the new vCenter Server named vc40.boche.mcse, the vSphere Client title bar showed jarjar.boche.mcse which was the old vCenter Server name.

Furthermore, the Update Manager plugin was failing to load because it could not establish a connection to jarjar.boche.mcse. I wasn’t surprised a connection could not be made since jarjar was retired and no longer on the network. But why was the legacy vCenter Server name persisting in my new installation?

At first, I thought there was some funky DNS reverse lookup going on but I was able to quickly rule that out when I remembered that I had assigned a new IP address to the new vCenter Server host.

I quickly came to the conclusion that there was a row in the SQL database tattooed with the old vCenter Server name which was showing up in the vSphere Client. With that thought in mind, I used the vSphere Client to access the Administration|vCenter Server Settings menu option.

There it was, under Runtime Settings, the old name of the vCenter Server from the original installation. I was able to simply change the Name from jarjar.boche.mcse to vc40.boche.mcse

Afterwards, the vSphere Client title bar was updated with the correct name of the vCenter Server vc40.boche.mcse. No reboot or recycling of any services needed. The Update Manager plugin had also followed suit, making its connection to the correct vCenter Server name instead of the old one which no longer existed.

Simple stuff but I thought I’d write it up in case anyone else ran into this and was pulling their hair out.

Create a 32-bit vCenter DSN on a 64-bit Operating System

November 21st, 2009 by jason No comments »

As I had pointed out in this blog post, VMware hints that 64-bit may be the future for vCenter Server. I decided that for my upgrade to vCenter 4.0 Update 1 this weekend, I would take the opportunity to rebuild my vCenter server from Windows Server 2003 32-bit to Windows Server 2008 64-bit.

Once the 64-bit base operating system build was complete, I installed the 64-bit Microsoft SQL Server Native Client drivers (downloadable here) since my back end database is Microsoft SQL Server 2005 on a remote server. A key thing to remember about this installation is that it installs both 64-bit and 32-bit DSN drivers.

The next step is to create the vCenter ODBC DSNs. Although vCenter Server runs on 64-bit operating systems, it currently requires a 32-bit ODBC DSN. This is important to remember because the Windows Start Menu launches the 64-bit ODBC DSN tool, not the 32-bit version I needed.  The vCenter Server (and Update Manager) installation will not complete without a 32-bit DSN.

To create a 32-bit DSN on a 64-bit operating system, run the following executable:

[WindowsDir]\SysWOW64\odbcad32.exe

Once the utility opens, you’ll be greeted by all the legacy 32-bit ODBC DSNs you’ve likely seen for years working with tiered Windows platforms. If using Microsoft SQL Server 2005 like me, be sure to select the SQL Native Client driver towards the bottom of the list, and not Driver da Microsoft para arquivos texto highlighted below:

Proceed with the creation of the vCenter Server and Update Manager ODBC DSNs and complete the vCenter Server and Update Manager installations.

This information and much more can be found in the ESX and vCenter Server Installation Guide, page 73.

64-bit vCenter Server Coming? VMFS-2 Support Going Away?

November 20th, 2009 by jason No comments »

Looking at the VMware vCenter 4.0 Update 1 Release Notes, it appears we may be looking at 64-bit only versions of vCenter Server in the future:

“Future releases of VMware vCenter Server might not support installation on 32-bit Windows operating systems. VMware recommends installing vCenter Server on a 64-bit Windows operating system. If you have VirtualCenter 2.x installed, see the vSphere Upgrade Guide for instructions on installing vCenter Server on a 64-bit operating system and preserving your VirtualCenter database.”

I’m hoping this won’t be a deal breaker for anyone as we should all have 64-bit hardware in the datacenter by now. However, we may be temporarily inconvenienced with Windows Server platform upgrades from 32 to 64-bit.

In the same document, I also noticed verbiage about VMFS-2 support going away in future vSphere releases. If you’re not completely rid of ESX2 and VMFS-2 in your environment by now, I’d start planning on it soon.

vSphere 4 Update 1 Released

November 19th, 2009 by jason No comments »

While the Dutch and UK bloggers sleep, VMware has released Update 1 for ESXi 4, ESX 4, and vCenter 4.

Notable improvements include:

  • View 4 support
  • Windows 7 and Windows Server 2008 R2 support (Support for Windows 7 was timed nicely for View 4)
  • DB2 database back end support (Who requested this? Sound off, I’d like to hear your comments)
  • HA cluster hosts can now support 160 VMs each in a cluster of 8 hosts or less. 9 or more hosts in an HA cluster are still limited to 40 VMs per host (This still bugs me a little. Anyone loading up a host with near 160 or more VMs?)
  • Paravirtualized SCSI support has been extended to Windows 2003 and 2008 boot drives
  • vDS performance improvement (Important if creating VMkernel portgroups on vDS for NAS storage)
  • vCPUs per core limit increased from 20 to 25 (“Lorraine – You are my density…”)
  • Intel Xeon 3400 series CPU support
  • Improved support for Microsoft Clustering (Yes, more changes to the wonderful MS clustering document)
  • Rumors of comma separators in report/graph numbers (This could be my favorite new feature)
  • Many resolved issues

Last but not least, we can still reboot our ESX 4 hosts with CTRL + ALT + DEL at the console 🙂