Today I have helped a customer with ther vCenter database and the rollup jobs that was not present..

Yesterday i noticed that they had missed to update the stat jobs when moving their database to another server (I gave them the KB 7960893 link so they could move the db. allthough they missed step 5 in that list.). This was leading to an growing database and that the performance stats where not being updated. ultimately if the database grows to much and fills the disk the vCenter server will stop. I showed them the KB 1004382 that descripbes how you update or create new stat rollup scripts for your vCenter database, this was not successfull because they did not select the right database for the creation of the jobs..

Again i used the wonderful tool Teamviewer and connected to the customer and helped them to correctly create the jobs.

One important thing is to select the right database when running the script or it will not work when it is going to run.

As you can see on the screendump, for one that is not to familiar with SQL management studioi you must select the database beside the ! Execute before executing, the script will run and create a stat rollup job but it will not work because it is looking for stored procedures that are in the vCenter database..

If you not have logged on as the owner of the database (your vcenter service account) you should edit the jobs to be run as that account!

I have now tested the script that Hugo Peeters has made for checking what licensing needed with a vSphere platform when upgrading to V,

Of course this is a small platform and we do not have so much machines running, but the point is that it is a cool script that gives you a hint where you are and what your platform need in amount of licensing.

One thing my colleagues has missed and i wanted to touch and highlight is the vRAM and the pooling, i think it is well documented in the vSphere licensing, pricing and packaging document

The new licensing model is as follows

• No more restrictions on cores
• No max physical RAM limit
• You still need one license/pCPU
• Not allowed to mix different vSphere editions in the same vRAM pool, if using more than one edition managed with vCenter it will create different vRAM pools

for each license model there is a vRAM entitlement 24 GB for standard, 36 GB for Enterprise and 48 GB for Enterprise+, these are shared when connected to a vCenter so if you have a virtual machine on a host with 2 pCPU 192 GB physical RAM (with E+ you have 96 GB vRAM) and this VM has been configured with 128 GB vRAM and in your vmware vSphere cluster that this host resides have 3 other hosts with same setup and that will give you 384 GB vRAM in the pool, 384 – 128 equals 256 GB left to use for other VMs before bying more licenses.  Also if you have a linked vCenter and hosts with vRAM that is also included in the pool to be used. What i am trying to say is that although you have used more vRAM than assigned for one host you are still compliant as it is part of a pool.

As in all virtualization design you must calculate for host failures and its vRAM can be used when one host is down for maintenance or failure.

In the above example you can add more licenses for getting more vRAM, these licenses can later be used for adding a new host and for that physical CPUs.

Hope this gives some more light in the jungle

I have been investigating some things that need to be considered when deploying a Microsoft Cluster on a VMware platform.

As you can see on the graph, there are some different supported configurations. The kb 1037959 shows more information, i will try to highlight some things below.

Why i started this was because i was looking at the Multipathing polices for a customer and we discussed in the office that we preferred the Round-Robin policy, This is as you also can read on the KB not supported for the RDM shared disk, so if you already have  Round Robin as default on your hosts you have to set another policy on that specific LUN.

This can be done by powerCLI or by the vClient GUI, and as i am a big fan of powerCLI i will show you the command for it

VMHost hostname.test.local | Get-ScsiLun -CanonicalName "naa.60054242555" | '
Set-ScsiLun -MultipathPolicy "fixed"

If your default multipathing policy is set to one you do not want you can edit the default both with VMware CLI and powerCLI, as for the last there is a script that Stephen has made and can be found on the VMware Communities forum. otherwise you will have to change policy on every new datastore you add manually.

If you have a iSCSI SAN you will use in-guest iSCSI connection to the shared storage, then there is no need to change multipathing polices, what i do not understand and have not got any good information about is when i use in-guest shared storage, why do VMware have a limit of two cluster nodes that they support? As I see it the limit should be what MSCS has as a limit and that is 16 nodes, maybe there is no need for such a big cluster as you already have HA in your virtualization platform. If the setup as you can se in the graph is a cluster without shared storage it is not any limits set on number of nodes.

You will also need to edit your VMs scsi controller, for the Win 2008 you must have the LSI SAS controller installed, there is a KB 1002149 for that where the steps are outlined. The shared disk must reside on a dedicated scsi controller.

You will also have to setup Anti-Affinity rules in DRS to keep your cluster nodes apart, if you have for some reason decided to setup a CIB (Cluster in a Box) then you will need to setup an affinity to keep them together on the same host. For the VMs that are used for clustering you should set the DRS to partially automated.

For more information how to setup look at the VMware documentation on setup of failover clusters pdf