vroem.co.za
Blog about VMware technical articles

VMware Workstation version 7.1 have been released today. Here is some of the new features:

1. Ubunto 10.04 support
2. 8 way SMP VM

The complete lists is here.

Kendrick Coleman from www.kendrickcoleman.com have created a very cool link with 10 free cool VMware tools.

Check it out here.

I had an incedent yesterday that had me thinking how long HA will try and attempt to start VM’s on other hosts. After some asking around I got to the answer.

HA will do by default 5 restarts in this order:

1. Attempt 1 – immediately
2. Attempt 2 – after 2 minutes
3. Attempt 3 – after 4 minutes
4. Attempt 4 – after 8 minutes
5. Attempt 5 – after 16 minutes

There is a undocumented setting (will be added to the doc shortly):

   das.maxvmrestartcount

You can set a value to unlimited by using -1.

Following on the Vblock1 config is a Vblock 2 configuration. This configuration scales more on storage and blade chassis than a Vblcok1.

Also note that these configuration MUST be exactly configured in this way otherwise it is not a Vblock supported configuration any more.

1. Min 4x UCS 5100 Blade Chassis with Max of 8x UCS 5100 Blade Chassis
2. 32-64 UCS B Blade Servers
3. Nexus 1000V
4. EMC Symmetrix V-Max Storage unit
5. 96-146Tb Storage capacity
6. EFD, FC and SATA drives are supported
7. Cisco MDS 9506
8. VMware vSphere 4 with Enterprise Plus Licenses (Must be “Plus”)
9. EMC Navisphere and PowerPath/VE
10. Cisco UCS and Fabric Manager

The one thing that is at an optional “extra cost” is UIM (Unified Infrastructure Manager).

So what is this VBlock all about?

Vblocks are pre-engineered, tested and validated units of IT infrastructure that have a defined performance, capacity and availability SLA.

Currently there are two types of Vblocks, Vblock1 and Vblock2. (I understand that Vblock0 is on its way..soon…). So more on Vblock1 configuration:

1. 2x Cisco UCS 5100 Blade Chassis (Minimum config, max 4)
2. 16-32 Cisco UCS B-series blades
3. 960Gb Memory (Max 1920Gb)
4. Nexus 1000V
5. 6100 Series fabric interconnects
6. EMC Clariion CX4-480 Storage unit
7. 38TB Storage (64TB Max)
8. Cisco MDS 9506
9. VMware vSphere 4 with Enterprise Plus Licenses (Must be “Plus”)
10. EMC Navisphere and PowerPath/VE
11. Cisco UCS and Fabric Manager

The above configuration can support from 512 up to 4096 VM’s. Yes 4096 does sound like a lot, but there is VM guidelines and vBlock1 configuration on the max Mem and CPU per VM.

Below is a high level topology overview of the design:

Link to reference document can be found here.

I did a Lab Manager implementation a few weeks ago. Here is some considerations that you need to know about:

1. Only ESX Standard, Enterprise and Enterprise Plus is supported
2. If you want to use Host Spanning you need Enterprise Plus
3. Mixed ESX versions inside a cluster is not supported
4. Hosts must belong to a single Datacenter
5. Don’t install Lab manager on vCenter Server
6. Lab Manager can be installed in a VM (Recommended)
7. Use static IP address for Lab Manager Server

Then understand how the client wants to use the networking, thus Fenced or not, do you create a DMZ like environment to fence the VM’s, private vLan’s and do some planning on this. Some systems might be on the Production network and need to be accessed from within a workspace.

Recently I have been involved in a SRM design and implementation using SRM on Hitachi storage.  Here is some of the design decisions we made on this project:

1. We used a VM for the SRM server. We installed the Hitachi Raid Manager CCI on this VM. Then we presented a “Command Device” from the storage unit to the VM as a raw device, physical passthru. (This is the device that the CCI will use to passthru the commands to the storage array) Do this on both SRM servers. The command device that is presented is only from the storage array that is on that site. We also decided to install SRM on a VM for this reason, so that we keep the vCenter installation clean and no raw devices, CCI or SRM was thus installed on vCenter VM.
2. Configure the HORCM file.This is the most important file. It has the config of the luns that is being replicated, controller serial numbers and IP address of both SRM servers in (The IP’s of the SRM servers is needed as the HORCM CCI starts as a service (if installed as a service) and during normal operation, when you do queries via the command line to the storage unit, the CCI will communicate to both HORCM instances.) I ask our local Hitachi specialist to help create this file. Once you get the hang of the format, it is not to difficult. Just remember that if this file does not have all your replicated luns information in the file, you will not see all the replicated luns in SRM.
3. Configure your luns on the correct storage ports.Give this some thought and do some testing. some of the replicated luns was presented over different storage ports and then in SRM we could not group the VM’s in one protection group and we had to create 2 protection groups. Not really a big problem, just had to include both Protections Groups into on Recovery Plan. But keep this in mind.
4. Timeout Setting for VM heartbeat. This we changed to 1200 sec as some VM’s took a while to start up.
5. Two Clusters was used.We used two clusters, one cluster had replicated Luns the other did not have. Thus all VM’s in cluster “SRM enabled” was being protected and VM’s in cluster “No SRM” was not.

The rest of SRM configuration was as per the manual. Hopes this helps.