Once I unpacked the UCS Chassis from the box, it took me less than 10 mins to slot in 5 units of the B200M1 with 48GB Memory , 2x Intel 5540 and 2 x 146 SAS Local HDD each. At the same time, I did try to open up the casing for 1 of the blade,. it took me less than 1 min to do so. Came to the cabling part, usually we spent a lot of effort for cable management on Gigabits Ethernet and FC cabling, for Cisco UCS, maximum 8 cables per chassis for IO uplink. Of course, I do not require to over provision in this case, I managed to connect 4 FCoE connections from the chassis to the UCS 6120 Cluster for demo purpose and it is more than enough to handle the IO requirement for the showcase.

Well, when I move the box from my office to 2 different location in my country for event, it take me less than 1 hour to re-setup everything and boot up all the physical and virtual machine within the Cisco UCS.  It is really a great design to simplify a hardware setup and configuration. Guess what, I do have different engineer who are non server background that help me to re-setup and they were impressed with the design and took less than 5 mins to understand the architecture after my explanation.

Related posts:

1. Install Windows 7 on Cisco UCS blade with USB key
2. 1st hands on experience on Cisco UCS
3. Virtual KVM with Cisco UCS Manager

But I do want to point out some of weakness on the solutions proposed by the deployment team or vendors that suggest to start with 1 blade chassis to reduce the CAPEX require. To achieve the fully redundancy on the virtualization, we may require NIC teaming, redundant FC connection, redundant ISCSI HBA and etc. Some of the guys may had forgotten about the chassis issues on the blade today. If I would like to run the virtualization hosts or clustering servers on blade, I will not choose to go with only single blade chassis in this case. I will not believe there is 100 % guarantee of no failure on the chassis of the blade. I will definitely suggest to split the blade across to 2 different chassis as minimum to minimize the risk. But of course, we may still have a single point of failure on the SAN which require huge amount of capex investment to keep the production storage to be redundant. Imagine if you run 5 ESX hosts on single blade chassis today, you will easily achieve 15:1 per blade for consolidation, and if you are UNLUCKY enough and your chassis just burn or malfunction for any failure, you will have 75 VMs go down at 1 time and your HA and DRS is not worked at all. You will definitely screw and whack by your business or boss in this case. If we do not have enough capex to start with 2 blade chassis for HA in the virtualization, I will suggest to stick with 1U or 2U rack mount servers to minimize the risk of the business. I am impressed with the blade technology today, but just to start with 1 single chassis for HA and redundancy purpose, will not be my call.

Before you can use blade, you require higher power consumption per rack to support approximately 30 to 32 blades per racks on 42 servers rack. At the same time, the cooling unit design in you DC require to be customize to ensure your blade chassis is working in perfect condition. Once you have this, then you may able to start think about Blade.

ESX on Blade have been some idea I personally thought before. The products I specify looking is the latest DELL Blade M1000e. The power and cooling in my DC is not a big issue. When I do analyzed the possibilities, I found couple of show stopper to deny my decision to move forward on that. As the enterprise architect point of view, Blade will be more suitable to consolidate those machine which require to run on physical VS Virtualization. The reason of that, is not really the matter of CPU or Memory you can have in the single blade, is really about the redundancy and performance we focusing on our virtualization. The limited number of pass through, NIC, and FC per blade is really not able to meet the number of VM we tried to achieve per host. We require redundancy, teaming as well as performance through put in term of networking and storage with the ESX servers we have. When we do calculate in term of cost per VM, the number had not show up as significant saving as we expected.

In additional to that, the more ESX machine we have in our Virtualization farm, it always require additional efforts to manage it for long term basis. There are many cases that users had built the ESX server with only 2 gigabits NIC for VMnetwork, which end up facing the performance issue in term on the Networking as well as the single point of failure. Virtualization is not performance sacrification. If we do plan properly, we will gain performance in virtualization vs under utilization physical machine.

Here is those finding I have and I will say that the Blade will not fit the virtualization requirement to achieve High availability and performance requirement. If we will have enough money to be spent on Blade environment, I believe you should have sufficient budget to go for something more suitable like R900, R905 and others 4U servers which provide more memory and CPU you need.