Attaching New ESX Host to Celerra Fiber Drives

We finally got back to the optimization/ best practices of which the next task was to connect the esx host to our SAN. Orginally the first 3 hosts were connected for us by EMC during the install, and when we added them it looked pretty easy. Ultimately we were missing 1 important step, the zoning of the fiber switches.

We used the following infrastructure:

1. Brocade 4424 Fiber Switches

2. Dell M1000e chassis with Dell M710 Blade Servers

3. Celerra with Navisphere

Step 1. Go to the Dell Chassis Management, Click on the server you are trying to add and find the WWN/MAC address you are looking for. Pay attention to which location or fabric module each one is assigned to.

Step 2. Go to the IO Modules and Launch the GUI of the Fiber switch you are working on. Login and click manage the Zone Admin.

Step 3. Click on the zone tab, under that should be a drop down for the Zone Name. Verify what you want isn't already made then click New Zone.

Step 4. You will need to find WWN id of the host in the fabric you are in. Add this as a member for that zone. Then add both Clarion devices as members, this allows the esx host to see both emc's we currently have.

Step 5. Go to the Zone Config tab and add the zones you created as Zone Config members.

Step 6. Click enable config to Save and enable it. We did this during downtime, because there is a chance of temporary I/O interruption.

Step 7. Open Navisphere. On the hosts tab, Navisphere should now be able to see the new ESX hosts

Step 8. Go to the Storage tab, Navigate to Storage Groups as shown below and find the group you need. Right click and select connect hosts. Choose the new hosts and add them.

Step 9. You can now check Vsphere and the ESX hosts should be able to see the storage.

Consistent Network Configuration across ESX hosts

One of the key settings from our VMware health check that needed adjusted was the network setup. The goal is to make all connections redundant and constitant across the configuration so I am going to post the recommended config for our particular ESX hosts which are Dell M710's. They have the capability to have 2 sets of Mezzanine cards, however we only have 1 set filled. Of those we are only using the onboard ethernet or A fabric and the ethernet mezzanine or B fabric.

Therefore per the healthcheck tool, here are the recommendations.

----------------

Minimize differences in the network configuration across all hosts in a cluster. Consistent networking configuration across all hosts in a cluster easies administration and troubleshooting. Also, since services like VMotion require portgroups to be named consistently in order for VMotion to work, it is important to have a consistent nnnnnzz

Also, use a consistent naming convention for virtual switches, portgroups, and uplink groups

Product/Version: vSphere 4

VMware vSphere 4 introduces VMware vNetwork Distributed Switches (vDS) and Cisco Nexus 1000V distributed switches which reduce administration time and ensure consistency across the virtual datacenter. Changes to the distributed virtual portgroup are consistently and automatically applied to all hosts that are connected to the distributed switch. Check the licensing requirements in order to determine if distributed switches can be used in the environment.

Consider using distributed switches if possible.

Network Design

Blade Module	VMNIC#	Connection Type
A0	VMNIC0	Service Console
A1	VMNIC1	VMotion
A0	VMNIC2	Fault Tolerance
A1	VMNIC3	VM Production
B0	VMNIC4	Mgmt Spare
B1	VMNIC5	VM Production

------------------------------

In order to accomplish this, here is how we setup it in VMware.

1. We created 2 Distributed Virtual Switches - a production one, and a Service Console One.

2.Under the Service Console switch create a port group for Fault Tolerance, this should be a very limited vlan or for administrative purposes only.

3. Under the Service Console switch create a port group for the Service Console, this should be a very limited vlan or for administrative purposes only.

4.Under the Service Console switch create a port group for Vmotion, this needs to only be on the virtual switch or across any switch ports that Vmotion would be used across. It is something the ESX hosts handle internal to VMware so it doesn't even need to be routable.

5. On the production Switch current port groups as needed for your environment.

Teaming and Failover Setup

1. You need to setup Teaming and Failover to make the uplinks redundant which can be done after you have added the vmnics to the uplinks.

2. Once that is completed edit the settings of each port group. Go to the Teaming and Failover section under policy.

3. Change the links based on the Chart at the top so the uplink that matches the vmnic above is the Active Uplink. Move the rest of the uplink to standby. See the screen shot below for an example.

When all this is done, the ESX host specific configuration, should look like the image below. If your switching configuration is setup correctly then VMware should be now be setup redundant and according to the Health Check best practices.

Vmware ESX Host Drive Space Best Practice

We recently had Vmware technicians come in to analyze our environment we had configured and tell us what needed changed and give us best practices for VMware in our environment. It was through Dell and ultimately there is a Virtualization Healthcheck tool that will go through and tell you the majority of this. That tool runs as a Guest OS host in your VMware enviroment.

This particular post lays out what optimum settings for virtual disk size when setting up and ESX 4.0 host. This is one setting that needs to be done before you go much further since changing it pretty much requires a rebuild of the ESX host.

Here are the settings we ended up using.

• /boot - ext3 1100MB (PreConfigured Space for upgrades)
• - swap 1600+MB (Change for maximum services console swap)
• / - ext3 16384 MB (Change for additional space in root)
• /var - ext3 8192 MB (Create this partition to avoid overfilling root with log files)
• /tmp - ext3 8192 MB (Create this partition to avoid overfilling root with temp files)
• /opt - ext3 8192 MB (Create this partition to avoid overfilling root with VMware HA log files)
• - vmkcore 100MB (Memory Dump for PSOD - Note I didn't have this option)
• Leave all remaining space on the local volume unpartitioned

That is the first major setup best practice that isn't immediately obvious by going through the steps, more to follow including network setup and reasoning since that is one of the toughest ones in our experience.

Printer Deployment with Group Policy Step by Step

Here at Mount in the past we have done our printer deployment to all the various computers across campus with vb scripts that run at user logon. For a while, this worked well and delivered the printers people need to computer according to where they were placed in an OU structure that matched printer associations. Recently however certain sections of computers have simply stopped receiving the printers, so we went about finding a new way to deploy them without using vb scripts.

As a background about our infrastructure, our public computers are all running Windows XP which makes the deployment of printers slightly more complicated.

To accomplish this we followed the Microsoft article here.

1. Open the Group Policy Management Console and browse to a policy you want to use to deploy the file PushPrinterConnections.exe this allows the XP machines to accept printers deploy via the deploy printers option in the Management Console.

2. We chose to push the file out during the computer startup which seems to help save time during the user logging on. Copy a x86 version of the file to the folder for the GPO, then add file as in the image below.

3. At this point we went to the GPO that was assigned to the computers we have been having difficulty with, ie. the Mezzanine section of the library. You can add the printer to the deployed printers under Computer Configuration > Policies > Windows Settings.

Note: The one weakness of this setup is not being able to currently specify a default printer. For now we will just have the default added. There are 2 possible remedies to this problem, the first is creating another vb script to assign the default printer. The 2nd, is to upgrade your AD to Windows Server 2008 R2 and take advantage of the Group Policy Client Side Extensions. We are not at the level of AD yet, but our plan is to upgrade to it in the near future. So for now we will live with only having one printer installed in those couple areas where problems occurred with the vb scripts.

Reconnecting VMhost after losing connections due to config problems

In trying to figure out our VMware setup, configure the switches and virtual switches many times I ended up losing connectivity to the vmhosts. The majority of the time this was caused by moving the vmnics into and out of the different switches or switch groups.

When ever this occurs the only way I have found to correct it is by going to the host console, for us this is accomplished via the remote console. When using the remote console I have found the following commands to be a great deal of help.

Many of these were taken from various VM sites including here, here or here.

To view the current configuration you can use

esxcfg-vswitch -l

which will create an output like.

For a virtual switch you can use commands like

esxcfg-vswitch -U {$vmnicid#} {$virtualSwitchName} this will remove or unlink the vmnic from the switch.

To link or add a vmnic to a virtual switch use the command

esxcfg-vswitch -L {$vmnicid#} {$virtualSwitchName}

To link or add a vmnic to a Distributed virtual switch or DVP use the command

esxcfg-vswitch -P {$vmnicid#} -V {$dvportId} {$dvswitchName}

To unlink or remove a vmnic from a Distributed virtual switch or DVP use the command

esxcfg-vswitch -Q {$vmnicid#} -V {$dvportId} {$dvswitchName}