Configuration (vCentre)

From vWiki
Jump to navigation Jump to search

Architecture Suggestions

The following are some suggestions on how set-up your VI management infrastructure, take all of the below with a large amount of consideration for your specific requirements. For example, even if you've a small number of ESX's, if you're always performing lots of tasks you may want to consider beefing up your management infrastructure.

  • Install on Virtual machines (rather than physical)
    • VI management is resilient to hardware failures/maintenance through HA and vMotion
    • Besides, you can hardly expect service owners to be comfortable with virtualisation if you're not confident enough to locate your own systems on the platform!
  • Install both vCentre and SQL on the same VM
    • Installing on separate machines is of little benefit, and if they're always together the VC service becomes impervious to network and other problems (it readily fails if it has trouble access the SQL database).
  • Join the VM to the domain
    • Makes user management so much easier (and its more secure that way)
  • Install vCentre to run using a Local System account
    • If a domain service account, you can't start vCentre without the domain, which might be a big problem if you're DC's are virtual and your starting up following a power-down
    • If a local admin/service account, you can't browse/add domain users/groups to your vCentre permissions
  • Virtual hardware
    • 2 - 4 vCPU's (2 is fine for small installations)
    • 4 - 6 GB RAM (2 for OS, SQL, and vCentre respectively, 4GB total fine for small installations)
    • Large installations >100 ESX's or >1000 VMs will require more than the above

Sysprep Setup

If you're only deploying Windows 2008 and above you don't need to install sysprep files on your vCentre.

The following Sysprep support directories were created during Virtual Center installation, these need to be populated in order for the VC to be able to sysprep VM's as they are deployed using Guest Customisation:

  • Windows 2003 vCentre
    • %ALLUSERSPROFILE%\Application Data\Vmware\VMware VirtualCenter\sysprep\
    • C:\ProgramData\VMware\VMware VirtualCenter\sysprep\
  • Windows 2008 vCentre
    • %ALLUSERSPROFILE%\VMware\VMware VirtualCenter\sysprep\
    • C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter\sysprep\
...\1.1\
...\2k\
...\xp\
...\svr2003\
...\xp-64\
...\svr2003-64\

Windows 2008 (and Vista) and above don’t need sysprep files as the function is built into the OS.

Download the System Preparation Tool or Deployment Tools package that contains sysprep from the Microsoft download centre. Make sure that you download the correct version for the guest operating system and Service Pack that you want to customise.

1.1: In the case of the generic version 1.1 simply run the downloaded executable to extract the files then copy the contents of the Tools directory into the appropriate directory (see below).

Windows 2000: In the case of Windows 2000 simply run the downloaded executable to extract the files into the appropriate directory (see below).

Win XP: In the case of XP run the downloaded executable to create deploy.cab then use something like WinZip to extract the files into the appropriate directory (see below).

Windows 2003: In the case of Windows 2003 the downloaded executable is a Hot Fix which must be run (Installed) on a matching OS to create deploy.cab then use something like WinZip to extract the files into the appropriate directory (see below).

TomCat Memory Throttle

None of the changes in this section are suitable for production environments

vSphere 4

The Tomcat webserver (used to provide VC Web-services), can be very memory hungry (up to 1GB) in comparison to when it ran on VC v2.5 (normally around 50MB). This can be throttled down, though this is only recommended for small, non-production installations (<10 ESX's). Bear in mind that things like API access (inc PowerCLI) are serviced by the VMware vCentre WebServices, so if these become sluggish you may need to increase. For home lab, single ESX installations you can reduce down to 64 MB.

  1. Edit the registry to put a ceiling on the Java VM's memory usage
    • Append --JvmMx=256 (MB) to end of HKLM\SYSTEM\CurrentControlSet\Services\vctomcat\ImagePath
  2. Restart the service
    • VMware VirtualCenter Management Webservices

vSphere 5

Java is now used for the following...

  • VirtualCenter Management Webservices
  • Inventory Service
  • Profile-Driven Storage Service
  • Single Sign On

...and in their default configuration makes vCentre a bit memory hungry for a small test/home environment. Throttle down by the following procedure (not to be used for production installations).

  1. Edit .\VMware\Infrastructure\tomcat\conf\wrapper.conf
    • Update the line wrapper.java.additional.9="-Xmx512M"
  2. Edit .\VMware\Infrastructure\SSOServer\conf\wrapper.conf
    • Update the line wrapper.java.additional.9="-Xmx512M"
  3. Edit .VMware\Infrastructure\Inventory Service\conf\wrapper.conf
    • Update the line wrapper.java.initmemory=128
    • Update the line wrapper.java.maxmemory=512
  4. Edit .\Infrastructure\Profile-Driven Storage\conf\wrapper.conf
    • Update the line wrapper.java.initmemory=128
    • Update the line wrapper.java.maxmemory=512
  5. Restart the server to apply the changes

Start Notepad as an administrator if you have trouble saving changes

The above was adapted from http://defaultreasoning.com/2012/09/27/tweaking-java-exe-memory-usage-on-vcenter-server-5-1/

ESX Poll Time-out

An ESX send a UDP poll to its controlling vCentre, once every 10 secs. This times-out after 20 secs, and the vCentre will mark the ESX as disconnected. If you've got ESX's in a remote site or at the far end of a dodgy/overloaded network connection it won't uncommon for the UDP polls to get lost and your ESX's appear disconnected. To increase the time-out...

Within %APP_DATA%/VMware/VMware VirtualCenter/vpxd.cfg , edit the following section

<heartbeat>
  <notRespondingTimeout>60</notRespondingTimeout>
</heartbeat>

and restart the VMware Server Service