Configuring an IBM BladeCenter H with the HS22/HS22v for 6 Nics and 2 FC HBAs
Introduction
Configuring an IBM BladeCenter H chassis to accommodate six network cards and two fiber channel ports can be a little confusing with the amount of ports available for use at the rear of the H chassis.
The rear of the H Chassis looks like this.
IBM H Chassis Rear
There are a total of 10 interconnect bays. The vertical bays (Bays 1- 6) are normally referred to as Standard Switch Modules and the horizontal ones (Bays 7-10) are referred to as High Speed Switch Modules.
To utilise the horizontal bays, the Multi Switch Interconnect Module (MSIM) modules are required. What this does is it allows the vertical modules to be installed into bays 7-10. One MSIM modules occupies both bays 7 and 8, or both bays 9 and 10 simultaneously, allowing for two interconnect modules to be installed within a single MSIM module.
Configuring the HS22/HS22v
The IBM HS22/HS22v server supports two processors, 12 DIMM slots (18 slots for HS22v), two SAS drive bays (two SSD for HS22v), has two onboard network adapters, an internal USB port (for ESXi) and two daughtercard ports – CIOv and CFFh. Similar to how HP C Class blades terminate the network and fiber ports, the HS22/HS22v also has terminations set via the BladeSystem back-plane and this results in a set configuration of the location of the interconnect modules in the rear of the blade chassis.
The HS22/HS22v’s onboard network adapters, always terminate in bays 1 and 2 of the IBM BladeCenter H chassis.
The CIOv daughtercard will terminate in bays 3 and 4, as any CIOv card will always have a maximum of 2 ports. Some of the dual port CIOv cards available are:
CIOv Options
The CFFh card is different depending on the exact type of card that is selected. Any dual port CFFh port will terminate in bays 7 and 8, but any quad port CFFh card will terminate in bays 7, 8 and also 9 and 10.
Some of the CFFh cards available are:
CFFh Options
Of course as stated above, to utilise a CFFh daughtercard, the MSIM module will need to be installed first. One MSIM module in bays 7 and 8 for a dual port CFFh card and two MSIM in bays 7 and 8 and 9 and 10 for a quad port CFFh card.
For this configuration though I will use the “Ethernet Expansion Card (CIOv) for IBM BladeCenter – CIOv” and the “QLogic Ethernet and 8Gb Fibre Chanel Exp Card (CFFh) for IBM BladeCenter – CFFh”.
This allows us to meet our 6 NIC and 2 HBA requrements.
HS22/HS22v I/O to BladeCenter H I/O Port Mappings
The table below shows how the adapters within the HS22/HS22v terminate at the rear of the H Chassis.
| Adapter | Net/Fiber | H Chassis Bay |
| Onboard1 | Network | 1 |
| Onboard2 | Network | 2 |
| CIOv1 | Network | 3 |
| CIOv2 | Network | 4 |
| CFFh1 | Network | 7 |
| CFFh2 | Fiber | 8 |
| CFFh3 | Network | 9 |
| CFFh4 | Fiber | 10 |
This diagram also shows how the adapters within the HS22/HS22v terminate at the rear of the H Chassis.
HS22 IO Ports to BladeCenter H
So there you have it, the HS22/HS22v in a BladeSystem H simplified.
VMworld 2010 pre-registration is now open
Tech Tip: How to fix the dynamic disk problem after a P2V
The scenario:
- Boot the virtual machine, select F2 to go into the virtual machine’s BIOS and make sure that the VM is booting from the correct virtual disk.
- Boot the machine into a disk management software like Acronis Disk Director Suite or similar and convert the partitions from logical to primary partitions and then select the C: partition as the active partition.
Change Evolution is ‘The Way’
I’m working on a paper, document, anything, (probably just this post now since my schedule is so busy) on something that’s been in the back of my mind for a while now, and every time I speak to a new opportunity or a customer I always wished that I had something substantial to leave behind to show that yes, it is possible to achieve the desired future state without pain.
What I’m talking about is how to get from A to Z without pain, fear, risk, or increased cost and time.
‘A to Z’ is an expression that we all use, but in Lehmann’s terms it is getting to the desired future state from the current state.
What is the future state? For example a server migration project of 1000 Wintel servers into VMware infrastructure in 6 months.
So if A is the origin and Z is the destination, then the journey of getting from A to Z is the experience. It is the experience that is all too important. In a project’s lifecycle, the primary purpose of a project is to bring benefit to something (an organisation for example). But the experience can vary dramatically. Z can be achieved but at what cost? Z can be achieved but it could take a long time. Z can also be achieved but after how many mistakes, issues and actions that were required to achieve Z?
Is there a way to define the experience? To reduce the amount of risk and unplanned change, to limit the exposure to mistakes and unknowns. To cap the amount of time and cost to achieving Z. ‘The Way’ then is called a methodology. A methodology is a collection of processes and frameworks which are used to control the execution of change within a project.
So while I’m in a pessimistic mood, let’s go over why there are difficulties from having a comfortable journey:
• Lack of planning
• Lack of clear objectives
• Lack of support and acceptance (See Steve Chamber’s Barriers to Virtualisation)
• Lack of risk management
• Lack of a business case or project justification
• Lack of change control
Why is change so feared?
Let’s assume that your project justification and initiation are all good and that your project plans, objectives, business case and RAID are all up to scratch and now you are ready to embark on a project that changes your IT infrastructure. Have you considered how you will manage change? Are there push backs from the business or application owners who don’t really need or want anything to happen to their precious server due to changing the way a workload is run?
How can you alleviate their fears and introduce controlled change?
So let’s take the classic CIO/IT Director from a few years ago at a time when x86 consolidation using virtualisation was still in its infancy (there are those that still think transitioning to a virtual infrastructure is a risk too far). These CIOs had fears around change – change of management, change of skills, change of processes and changes with operations. These fears were prevalent then and are still prevalent now. In my view the main enablers for change are the frameworks that can be used to get from A to Z.
Without change, an IT organisation will never be able to evolve into an IT organisation that has more reliable infrastructure, more efficient processes and more streamlined operations. Those companies that do embrace change and evolve are considered to be the most high performing IT Organisations.
The consensus is basically this: change causes fear, therefore projects such as P2V take forever to do, and without the correct methodology your P2V project could fail before it has actually begun. But by introducing controlled change and then putting the processes and governance in place; the strategy controls, manages change and provides a framework for effective management and delivery of the project.
The barrier to evolution is due to a fear of change, we alleviate this fear by controlling change. Change then becomes the enabler for evolution: please welcome Change Evolution.
So what is Change Evolution?
Change Evolution is a framework that uses ITIL/Visible Ops methodologies to control migration to virtualisation projects. It expedites ROI due to enablement of change management as part of BAU/Operations.
Change Evolution is a framework for delivering projects with
- less Risk
- less Time
- less Cost
How is this accomplished?
- With baselined standard operating environments (SOE) which are standardised and adhere to strict change control.
- With Standard Operating Procedures (SOP) which are auditable, repeatable and measurable and are strictly controlled. Because these procedures are defined and controlled as part of the framework, it is possible for any member of the project to use these procedures to assist with the grunt work of the project. These procedures enable the ‘turning the handle’ method of migrations where the migrations are streamlined into the control processes.
- By working closely with the change control board (CCB). It is strategic to keep the CCB on your side, we are not re-inventing the wheel with change boards, we embrace them, but the amount of requests is submitted in a ‘turning the handle’ method in which P2V migrations are requested weeks in advance and each one follows the same migration methodology, processes and SOPs. Therefore these migrations can actually be integrated into operations quicker and with no risk.
By using a defined methodology that integrates with the change control processes it is possible for you to deliver record‐breaking project successes without risk and within strict time scales and budgets and above all with no pain.
Power CLI Quick Start Guide
1. INTRODUCTION
1.1 Overview
The VI Toolkit (for Windows) provides a powerful yet simple command line interface for task based management of the VMware Infrastructure platform. Windows Administrators can easily manage and deploy the VMware Infrastructure with a familiar, simple to use command line interface.
The VI Toolkit (for Windows) is a tool that system administrators and developers can use to automate the management of VMware Virtual Infrastructure. With the VI Toolkit (for Windows), many tedious and time-consuming tasks can be completely automated in as little as one line of code.
The VI Toolkit (for Windows) takes advantage of Windows PowerShell and .NET to bring unprecedented ease of management and automation to the Virtual Infrastructure platform. The VI Toolkit (for Windows) provides 125 PowerShell cmdlets that cover all aspects of Virtual Infrastructure management.
Some common tasks that the VI Toolkit (for Windows) can be used to perform include:
- Snapshoting all virtual machines.
- Disconnecting or removing all Floppy or CD-ROM drives from all Virtual Machines.
- Large-scale cloning of templates.
- Moving large numbers of Virtual Machines from one virtual switch to another.
- Migrating large numbers of Virtual Machines between ESX hosts.
- Reports and monitoring across the entire Virtual Infrastructure.
1.2 System Requirements
The following platforms are supported by the VI Toolkit (for Windows):
- Microsoft Windows Server 2003 R2 (32 or 64 bit)
- Microsoft Windows Server 2003 with Service Pack 2 (SP2) (32 or 64 bit)
- Microsoft Windows Server 2003 with Service Pack 1 (SP1) (32 or 64 bit)
- Microsoft Windows XP with Service Pack 2 (SP2) (32 or 64 bit)
- Microsoft Windows Vista (32 or 64 bit)
1.3 Virtual Infrastructure Platforms Supported
The following platform combinations are supported by the VI Toolkit (for Windows):
- Management of ESX 3.0.2 using Virtual Center 2.5
- Management of ESX 3.5 using Virtual Center 2.5
- Management of ESXi 3.5 using Virtual Center 2.5
- Direct management of ESX 3.0.2
- Direct management of ESX 3.5
- Direct management of ESXi 3.5
1.4 Pre-requisites
The following tables lists the software pre-requisites and the location to each installer. This guide focuses on the most recent releases as dated 05/02/2009, which are Windows PowerShell V2 CTP3, VI Toolkit (for Windows) version 1.5 and the VI Toolkit Community Extensions build 46896.
Windows PowerShell
VI Toolkit (for Windows)
VI Toolkit Community Extensions
Another pre-requisite that is also recommended for general administration is Notepad++. This is used to create and edit scripts that can be run with the VI Toolkit.
Notepad++ can be downloaded from here.
2. INSTALLATION
There are three installation tasks that need to be performed before you can start using the VI-Toolkit to manage a VMware Infrastructure.
Windows PowerShell. The VI Toolkit 1.5 (for Windows) requires Microsoft PowerShell V2 CTP 3.
Please download it from here.
VI Toolkit (for Windows). Can be downloaded from here.
VI Toolkit Community Extensions. Can be downloaded from here.
3. SETTING UP THE VI TOOLKIT
The procedures below go through in detail how to get the VI-Toolkit up and running after installation. Once installed the icon below will be available on the Windows Desktop.
DO NOT LAUNCH IT YET!
Before launching the VMware VI Toolkit application, you must first set up your PowerShell profile. The new desktop shortcut does two things for you: it starts powershell with the VI Toolkit snapin loaded and it runs a script which modifies the look of the Powershell window and adds some cool extra functions. If you want to have the same functionality in your normal Powershell window and your scripts, you have to copy some stuff to your Powershell profile.
3.1 First, set up your profile:
1. Start a normal PowerShell Window by navigating to Start | All Programs | Windows PowerShell V2 (CTP3) | Windows PowerShell V2 (CTP3), the following will be launched:
2. Run the following command:
Test-Path $profile
3. If it returned True then you already have a profile file. If it returned False, then proceed to the next step.
4. Create a profile file by running:
New-Item $profile –ItemType File
5. If an error is returned then create a WindowsPowerShell directory under your My Documents folder and then repeat step 4.
3.2 Adding the snap-in:
1. Open your profile by running:
Invoke-Item $profile
2. Add the following line to the profile file to load the snap-in:
Add-PSSnapIn VMware.VimAutomation.Core -ErrorAction SilentlyContinue
3.3 Adding undocumented functions
1. Open the file C:\Program Files\VMware\Infrastructure\VIToolkitForWindows\Scripts\Initialize-VIToolkitEnvironment.ps1
2. Copy the following Function Blocks to your profile file:
Get-VICommand, New-DatastoreDrive, New-VIInventoryDrive, Get-VIToolkitDocumentation, Get-VIToolkitCommunity
If the steps were performed successfully, then your profile will be present in the folder structure C:\Documents and Settings\Hugo Phan\My Documents\WindowsPowerShell/ Microsoft.PowerShell_profile.ps1
And its contents will look something like this:
3.4 Enabling the execution of scripts
The Set-ExecutionPolicy changes the user preference for the execution policy of the shell. The execution policy is part of the security strategy of Windows PowerShell. It determines whether you can load configuration files (including your Windows PowerShell profile) and run scripts, and it determines which scripts, if any, must be digitally signed before they will run.
You need to set the execution policy to unrestricted using the below cmdlet
set-executionpolicy unrestricted
get-executionpolicy will return the current execution policy.
The default ExecutionPolicy is Restricted. Unrestricted is unnecessarily risky.
Set-ExecutionPolicy RemoteSigned is more secure and works for VI Toolkit 1.5.
3.5 Loading the Community Extensions
The VI Toolkit for Windows Community Extensions is a PowerShell module designed to work with the VI Toolkit for Windows.
1. Download and extract the package and then copy the coreModule folder to the root of C:
2. Open up a Windows PowerShell session and then type in the following command
Import-Module “c:\coreModule\viToolkitExtensions.psm1”
Now you are ready to start using the VI Toolit by either logging into a vCenter environment or by launching scripts.
Upgrading to VMware vSphere using the vSphere Host Update Utility
There are three ways in which to upgrade to VMware vSphere, these are
- VMware Update Manager
- vSphere Host Update Utility 4.0, and
- a clean install of vSphere
This post goes through the upgrade process using the vSphere Host Update Utility 4.0. A 10 minute video is available here:
The vSphere Host Update Utility 4.0 is an application that is installed as part of the vSphere vCenter installation package.
- To start the upgrade process, launch the vSphere Host Update Utility.
- The vSphere Host Update Utility will request confirmation to connect to the VMware patch repository.
- Add the host to the update utility by clicking on Host | Add Host.
- Type in the FQDN or IP address of the host you wish to upgrade then click on Add.
- Now click on the Upgrade button to start the upgrade wizard.
- Next browse to the location of your vSphere ISO file then click on Next.
- Read and accept the license agreement to continue.
- Enter the root credentials then press Next.
- The Host compatibility check will perform some checks and will allow the upgrade to continue if the host meets the criteria.
- Next select a local datastore (recommended) to store the disk file for the Console OS and also select the disk size.
- Leave all other settings on default and finish the Wizard
- Once complete, reconnect the host in vCenter to install the new vCenter Agent.
My lab is bigger than your lab
Following on from vinternals post about what a terrabyte of RAM looked like. Here is what 2Tb of RAM looks like installed in 16 BL685c servers.
VMware has just launched vSphere
Heres a picture of the box…
Disaster Recovery just got "sESXi"
Notes on using vRanger Pro & ESXi for Disaster Recovery
Just succesffully proved vRanger Pro to restore backups taken from Production (ESX 3.5, vRanger Pro on physical with VCB) to infrastructure in DR (ESXi 3.5, vRanger Pro on a VM, non VCB). All this from provisioning DR Infrastructure (ESXi Servers, Storage, vCenter VM) within 1 hour. Silver tier recovery just got “sESXi”!
Infrastructure at Production
- ESX 3.5 Update 2 on BL460C
- Storage on 400Gb LUNs presented by IBM SVC
- VC 2.5 Update 2 VM
- vRanger 3.8.2.1 & VCB 1.5 & vRanger Pro VCB Plugin 3.0 on Physical DL380 G5 Server
- VM backups on TSM and replicated to DR
Infrastructure at DR
- ESXi Update 3 USB on DL360 G5
- Local Storage
- VC 2.5 Update 4 VM
- vRanger 3.2.9.7 & VCB 1.5 & vRanger Pro VCB Plugin 3.0 on W2K3 SP2 VM + .Net Framework 2.0 SP1
Important points to note
If you are running vRanger in a virtual machine to restore workloads backed up by vRanger installed on a physical host, with either traditional LAN based backup or VCB based backup. It is important that the software is installed in the correct order and all the necessary software is installed to enable vRanger to restore both types of backup. If the physical vRanger server performed a backup of a workload using the VCB framework, then you will not be able to restore that workload using another vRanger server unless the VCB framework is also installed. For example, you wish to perform a restore at a DR site.
The correct installation order is
- Microsoft .Net Framework 2.0 SP1
- vRanger Pro
- vRanger Pro VCB Integration module
- vRanger Pro file-level plugin
- VMware VCB Framework
Tips
- Install software in the correct order
- Create the same directory structure for the VM at the DR site as it is at Production. E.g, if the vRanger working directory is D:\vRanger_Backups at Production, then keep the same directory structure for the vRanger server at DR.
- This will enable you to first restore the vRanger database (esxRanger.mdb), which then populates the Restore table saving valuable time and effort because you will no longer need to use “Restore from Info”
- If restoring a vRanger backup that was taken using the VCB framework, then the vRanger server at DR will also need to have the VCB framework installed.
