Aaron Delp’s BladeVault

This afternoon I attempted to load VMWare ESX 3.5 in a VMWare Workstation 6.02 Virtual Machine. I downloaded the latest version of the white paper from xtravirt.com and followed the directions. The ESX VM boots fine and everything looks great. I then created a VM inside the ESX server and tried to power it on, and….. BOOM! Hard crash on the ESX VM.

I asked one of my co-workers, Tim, who has this running with ESX 3.02 in VMs. After some digging it turns out that 3.5 in a VM doesn’t seem to work right now. A number of people are having the same issue. Here and Here are links to some threads about it.

For now, I’m going to punt and go back to 3.02 to set up my VMotion environment and play with it another time. To Be Continued…

Thanks to Tim for your help!

UPDATE: It looks like in the few hours since I checked this out VMWare has stated that this will be fixed in Workstation 6.5!

It appears we have found a possible bug in the Deploy from Template Command in ESX 3.5. When you create a Windows Server based template and then try to deploy directly into an Active Directory with customization, the new system will get an error that a service failed to start when the machine is launched. This is because the VMWare BootRun service is not removing itself properly after deployment. This does not happen with deployments into a workgroup.

If you aren’t familiar with the BootRun service, this service will make all of the customizations after the sysprep work is complete during the deployment. You usually never see it because it runs on the first boot, makes the changes, and then removes itself from the machine.

In this case, the files are removed but the service entry is still there, hence the error that it can’t start up. VMWare has confirmed this to be a problem and they are investigating.

If you have a need for a quad port NIC on the HP c-Class Blades on ESX, make sure it is the NC325m and not the NC364m. The NC325m is certified for VMWare ESX and the NC364m isn’t. The NC325m is Broadcom based (I believe) and the NC364m is Intel based.

Link to the Quick specs for the cards and the VI3 Compat Guide:

• NC325m Quick Specs
• NC364m Quick Specs
• VI3 Compatibility Guides

A big thanks to Don at my company for helping out with this one!

I was recently asked by a customer if you can mix the IBM CFFh (Compact Form Factor, Horizontal) blade cards with the “legacy” expansion cards. The only expansion cards that will co-exist physically on a blade are the CFFv (Compact Form Factor, Vertical) cards. The legacy cards will not physically attach on the blade at the same time. If you have a customer that has legacy expansion cards already in place, they will have to be replaced. Also, please note that if the legacy card is an iSCSI card, you will not be able to move to the CFFv form factor.

Please see the IBM Redbook on the Blade Products for more information.

UPDATE #2: This article has been updated here.

UPDATE: This article has been updated here.

I have been asked this question a number of times by customers here in the Triangle area. The new family of HP Blades, the c-Class Blades, do not iSCSI boot at this time. The IBM Blades will boot with the Q-Logic iSCSI expansion card but there is not an equivalent HP Product at this time. This fact can be a key differentiator in some accounts and is a good bit of knowledge to keep in your back pocket when positioning IBM vs. HP Blades.

This article has been updated here. 

This one is a little dated but I wanted to share in case you are seeing this problem in the field. Back in November IBM released version 1.07 BIOS for the HS21 Blades. With certain types of processors, you would see a 199 (Processor Mismatch) error on the next boot if two processors were installed in the machine. This would happen even if the stepping levels were matched. I brought this to IBM’s attention and BIOS 1.07b was released on Dec 21, 2007.

This BIOS fixes the problem but we have found an instance where loading Redhat Workstation 4, Update 3 (SeverProven OS by the way) will cause a kernel panic during installation if the stepping levels of the OS are mismatched and the highest stepping level is in CPU slot 0. I don’t know if other versions of Red Hat are affected. The work around for now is to swap the lowest stepping level into slot 0 and reinstall the OS. It has been years since we’ve had to worry about stepping levels so hopefully IBM is working on a fix. I spoke to support a few days ago and they were passing this along to the BIOS team. I’ll post here with updates.