VMware Security best practices are to not allow PermitRootLogin to an ESX host.

Enabling root SSH login on an ESX host.

I could not SSH into a newly provisioned host. The server would not allow root login (rightfully so), and my domain account could not log in either.

This is how I solved the issue.

1. Logged into the ESX host directly with the vSphere Client.
2. Created a new user with SSH access to the host.
3. Logged in to the host and found what the problem was time skew.
   
   Here is the error from /var/log/secure:
   
   Jan  9 09:52:36 ilesxdmz1 sshd[18263]: pam_krb5[18263]: authentication fails for 'msaidelk' (msaidelk@maishsk.local): Authentication failure (Clock skew too great)
4. Fixed the time issue.
5. Test SSH access with my domain account - Success.
6. Removed the temporary account.

The full how-to including video - is in the KB above.

And a bit of PowerCLI to create (and remove) the user, instead of having to open up the GUI.

New-VMHostAccount -Server esx1.maishsk.local -Id maish -Password "a:123456" -UserAccount -GrantShellAccess:$true -AssignGroups root

#And remove afterwards

Get-VMHostAccount -Server esx1.maishsk.local -Id maish | Remove-VMHostAccount -confirm:$false

I was battling with a piece of IBM hardware last week during the install of a new ESX host.

I had installed a new server, IBM x3650 M3 with 2 Intel Dual Port Server Adapters, and the damn thing would not recognize the cards in the system. I updated to the latest firmware. This was not the first time this model had been installed but up until now now problems had occurred.

After mucking about on the internet and calling support - apparently some of the NICS are not recognized properly in the UEFI settings (see full article for all the details).

Symptom

Upon power up, after the user installs one or more PRO/1000 PT Quad Port Server Adapters, Option 39Y6136, Field Replaceable Unit (replacement part number) 39Y6138, in one or more PCIe slot(s) in a System x Gen2 server, the adapters are not seen by the system.

 

Affected configurations

The system may be any of the following IBM servers:

• System x3550 M2, Type 4198, any model
• System x3550 M2, Type 7946, any model
• System x3550 M3, Type 4254, any model
• System x3550 M3, Type 7944, any model
• System x3650 M2, Type 4199, any model
• System x3650 M2, Type 7947, any model
• System x3650 M3, Type 4255, any model
• System x3650 M3, Type 7945, any model
• System x3850 X5, Type 7145, any model
• System x3850 X5, Type 7146, any model
• System x3950 X5, Type 7145, any model

Workaround

In the UEFI, change the setting for the PCIe slot(s) from "Gen2" to "Gen1" as follows:

To set the system PCIe bus/slots to Gen1 mode in the system UEFI:

1. In UEFI, go to Devices and I/O Ports and select Gen1.
2. Save the new setting and reboot the system.

The adapter(s) should now work fine with the system PCIe bus/slots set to Gen1 mode.

This is really stupid and ridiculous it should just work!!

Posted here so I do not have to look for it again, and perhaps is useful for you as well.

Ever since EMC released the the VNX I have been itching to get my hands on a simulator to try it out. Now seeing that Chad and Nick are not ones to leave us hanging for long, I started to ask for it straight after the launch. I was told that it would be out, in the not too distance future.

Yesterday, I saw that Nick Weaver had done it again. 

Just some things to note:

• NFS/CIFS only (at the moment)
• One datamover only

So here is my installation experience.

Download links can be found on Nick's post.

I will not go into how you import that into your ESX host - that should be pretty straight forward by now.

The appliance comes configured by default with:

• 1vCPU
• 2GB RAM
• 1 40GB IDE Hard disk
• 3 e1000 NICs

Thin provisioned this takes up 6.5 GB of disk space.

So let us Power on the appliance.

So first thing you will be asked to enter an IP for management for the device.
This will be the eth0 (Network Adapter 1)

Enter the following info:

• IP Address
• Subnet Mask
• Default Gateway
• Hostname
• Domain Suffix
• DNS server
• NTP server

A quick reboot and hup - Bob's your uncle, and for a simple setup you are all set to continue with the Web interface.

Default credentials are: nasadmin/nasadmin and here you have it

Now forget for a minute the error messages that are present - this is because of no access to the NTP servers.

You can see the new Unisphere interface

Let us go and create some NFS storage that we can use.

And now we have a new filesystem,

Next we create a network interface that will serve as NFS for this filesystem.

This device will use interface cge0 (Network Adapter 2) which in my specific case is not on the same network as the management network but - 192.168.166.x

And we now have a new interface on the network.

Now to export the storage to the correct subnet.

Just add in the correct values.

And Done.

Now to connect the ESX Hosts to the storage:

Get-VMHost esx*.maishsk.local  | % {
New-Datastore -vmhost $_ -Name nfs_1 -Nfs -NfsHost 192.168.166.5 -Path /nfs_1 -Confirm:$false
}

And we now have two Hosts connected to the shared storage.

I have to confess, to actually perform the procedure took less than 8 minutes (really) from power on till I had shared storage that I could access from an ESX host. The screenshots took over an hour.

My take on this as compared to the UBER VSA. The GUI is much more user friendly. I have not gone into how the snapshots and Data Protection work and how they are configured, but that will come.

Again my hats off to the EMC Crew for providing us a tool that is fully functional and working that allows us to get a fell of the new products and their features before actually buying the product.

The usual word of warning though.. This is not supported by EMC.
Support is through the Everything VMware at EMC community only.

Happy Uber'ing…

p.s. My apologies for not being so active lately - too much going on….

The new version of Xangati for ESX was designed specifically to make the installation process as simple as possible and provides VI administrators with the following benefits and features:

• A new and simplified GUI-based appliance set up – for getting the appliance addressed, powered-up and on the network – launched directly from the vCenter console tab;
• Standardization on one virtual appliance covering dynamic and static IP addressed data center segments;
• Streamlining of the steps required to enable Xangati to gather and summarize traffic traversing a vSwitch;
• Fifty percent reduction in the screens required to get to a working Xangati UI.

Available immediately – at absolutely no cost – Xangati for ESX gives VI administrators the ability to implement its real-time monitoring and troubleshooting capabilities for both server virtualization and virtual desktop infrastructure (VDI) environments.

A fully-functioning management tool, Xangati for ESX goes far beyond the capabilities of other free VMware or trial software tools by providing VI administrators with comprehensive and robust performance management that includes: continuous real-time insights into VMs and the ESX; a superior navigational drill-down user interface (UI) presentation; multiple data sources, including traffic traversing vSwitches and the VMware API; and Xangati’s unique and acclaimed DVR-recordings – allowing VI administrators to visually see and capture a problem through recordings triggered by VMware alerts.

Xangati for ESX works with VMware 3.5, 4.0, and 4.1 for ESX and ESXi. To download an enhanced version of the free Xangati for ESX tool and try it yourself, go to www.xangati.com/free-download. You can also watch a video describing the free Xangati for ESX for additional background.

About Xangati

Xangati, the emerging leader in Infrastructure Performance Management solutions, accelerates virtualization by providing critical VM visibility previously unavailable, enabling superior design, optimization and troubleshooting for the virtual infrastructure.

I will be posting my experience later of how the installation went.

I recently participated in writing a short piece on the question, "Is the Hypervisor a Commodity Nowadays?" on TechTarget. The consensus there was split 50/50.

I would like to explain a little more. What is a commodity?

A good or service whose wide availability typically leads to smaller profit margins and diminishes the importance of factors (as brand name) other than price.
[Source: Webster Dictionary].

So let us give two examples.

1. Gasoline. Your car needs gasoline to run. But what qualifies gasoline as a commodity? the fact that you can go to any gas station, be it Shell, BP, Paz, Texco - what ever you want.. and fill in the same gasoline into you car and it will continue to take you to where you want to go. You don't have to worry about if your car will be compatible with the gasoline you just put in - since it is the correct octane - it is guaranteed to go. Now mind you - there are certain requirements that need to be considered (octane is one of them). And of course - each company will have their small "extras" that will make their offering more appealing to the customers.
   The main thing here is that you can put in the gas and your car will drive.
2. Water. You are thirsty and you go and buy a bottle of water in the store. This helps you wuench your thirst, stops you from dehydrating, and gives the ability to keep on going. Does it make a difference which company the water is from? To serve the purpose of satisfying the need to quench your thirst - no. Will it taste nicer if it is cooled, or has a slight addition of lemon, or peach or bubbles, to each his own preference.
   And again the main thing, no matter what kind of water you buy, it quenches your thirst.

So that is how I would define a commodity. So back to the question raised before.

Is the Hypervisor a commodity?

Microsoft has one, VMware has one, Xen has one, Redhat has one and who knows what the future will hold. They each have their benefits and their flaws, their ups and their downs, the good and the bad. But the main thing is that - today - you cannot run a Hyper-V virtual machine on ESX, and you cannot run a Xen VM on Hyper-V. It simply is not possible. What the vendors are starting to do is provide you ways to convert a VM from one hypervisor to another. VMware just release a Fling called XVP that will allow you to connect to a Hyper-V server and if you to control certain parts of the Hypervisor, perform certain tasks on the Hosts and the virtual machines themselves. Microsoft SCVMM has boasted support for vCenter for quite a while now.

The point to note here is that in order to run a VM from one vendor on another vendor's hypervisor is not a done deal. There is a decent amount of tinkering around that needs to get this work.

So what does this have to do with the cloud in few years from now?

Let us play what-if for a second.

What if you there was some magic that could provide a translator and act as a buffer between the hypervisor and the VM? Something like the graphic below.

We all know what the problem is with having a non-standard format for virtual machine. Each vendor has their "tools" and optimizations for their own hypervisors and they are completely not compatible with their competitors.

Now I am not holding my breath for any of the vendors to come up with a industry standard that will allow you to run your VM on any hypervisor. That is actually quite counter-productive to what they are trying to achieve by getting their vendor lock-in for their solution.

If there was an additional layer that you could install on your hypervisor, that knew how to make these translations between the VM and the hypervisor below, allowing you to run a Hyper-V vhd on an ESX hypervisor or a ESX vmx on a Hyper-V Host. Granted this layer will have to be very clever and very fast in order to provide the performance that is close to native to that you would have on the hypervisor itself.

Call it a "hypervisor for hypervisors" if you will.

And what does this have to with cloud though? The way I see cloud vision is having your pool of resources from which you can provision your applications and vApps to your end users. At the moment this is limited to a cloud for each Hypervisor. I cannot have a VMware vCloud that has Hypervisors that are not ESX. I cannot have a Microsoft Cloud with Hypervisors that are not Hyper-V and so on.. Yes, there are some products that will allow you to manage the multiple clouds under one "umbrella" and place the VM in your Hyper-V cluster or ESX Cluster or RHV Cluster according to different criteria. But today they still need to be separate clusters. Utilizing such an idea will make my infrastructure completely vendor agnostic - and I (the customer) could pick and choose whichever hypervisor suits me.

This something which is not available but I do think it is only a matter of time until this technology becomes available. The first one to do this will have a great thing going for them.

Perhaps a good idea for a startup….

What do you all think? Please feel free to leave a comment below.

Thanks to a tweet from vConsult I learned that a new vCenter and vSphere update was released.

As always test before deployment!!

What's New

The following information describes some of the enhancements available in this release of VMware ESXi:

• Enablement of Trusted Execution Technology (TXT) — ESXi 4.1 Update 1 can be configured to boot with Intel Trusted Execution Technology (TXT). This boot option can protect ESXi in some cases where system binaries are corrupted or have been tampered with. TXT is currently available on Intel Xeon processor 5600 series servers. For more information, see KB 1033811.
• Improvement in scalability — ESXi 4.1 Update 1 supports up to 160 logical processors.
• Support for additional guest operating systems — ESXi 4.1 Update 1 provides support for RHEL 6, RHEL 5.6, SLES 11 SP1 for VMware, Ubuntu 10.10, and Solaris 10 Update 9 guest operating systems. For a complete list of guest operating systems supported in this release, see the VMware Compatibility Guide.
• Inclusion of additional drivers — ESXi 4.1 Update 1 includes the 3ware SCSI 2.26.08.036vm40 and Neterion vxge 2.0.28.21239-p3.0.1.2 drivers. For earlier releases, these drivers are only available as separate downloads.

Resolved Issues – In addition, this release delivers a number of bug fixes that are documented in the Resolved Issues section.

What's New

This release of VMware vCenter Server 4.1 Update 1 offers the following improvements:

• Additional Guest Operating System Customization Support: vCenter Server now supports customization of the following guest operating systems:
  • Windows 7 SP1 (x32 and x64)
  • Windows Server 2008 R2 SP1 (x32 and x64)
  • RHEL 6.0 (x32 and x64)
  • RHEL5.5 (x32 and x64)
• Additional vCenter Server Database Support: vCenter Server now supports the following databases:
  • Microsoft SQL Server 2008 R2
  • Microsoft SQL Server 2005 SP3
  • Oracle 11g Standard/Enterprise Release 2, 11.2.0.1.0 or later,  (x32 and x64)
  • IBM DB2 9.7.2 Express C (x32 and x64)
  • IBM DB2 9.7.2 Enterprise (x32 and x64)
    For more information about using IBM DB2 - 9.7.2 database with vCenter Server 4.1 Update 1, see KB 1033201.
• Resolved Issues: In addition, this release delivers a number of bug fixes that have been documented in the Resolved Issues section.

I was presented with an issue yesterday regarding a VM that I was not able to start

I went through KB Article 10051, step by step, until I got to:

I did not want to reboot the host, seriously… just because there was one VM that would not power on?

What I did not tell you was that a few hours before there was a power failure that took out the Fiber Channel switches (yeah… you always find out that someone plugged something into the wrong power strip after things like this) which in turn caused the all the ESX Hosts in the cluster to lose the LUNs and HA tried to failover the machines.

This I saw in the logs of the VM.

As you can see the machine tried to failover to another host, but was not successful because the other hosts also had not access to the LUN.

I could not clone the VM. I could not remove the VM from the inventory either.

Did you notice that the machine was no longer on esxdmz2 (where it originally was located before the power failure)?

I confirmed this within the Events of the VM. the machine had been moved and changes were made on the new host.

I figured I would try to power it back up on the original host esxdm2.

That worked! I then moved it back esxdmz3 and powered it on on and as you can see the machine powered on with out an issue.

Sometimes all it needs is a bit of putting things back the way they were - before it hit the fan - and things go back to working the way they were.

*****Update June 11, 2012******

The new version is available here

*****************************

• Updated to the latest PowerPoint Icons and Images - 3Q10
• Added new items to Stencils (30+)
• All graphics now have connection points - which will make work easier.

Box Shots	Icons	Products

A few days ago, I was presented with a situation that I had a failed ESX Server which needed to be re-installed. How and what happened is another tory for another time though.

I wanted to get some information off of the ESX host, namely the configuration and the whole /var/log partition for the purposes of opening an SR with VMware to analyze the issue.

In this particular case I could only get into single mode on the ESX host, so I did not have any network connectivity to the outside.

So I thought that I might as well use a USB stick. Well life is not so simple. The only one I had on me was a 16GB Sandisk Cruzer. Now this USB stick was formatted in Windows, and of course because of the partition size - it was NTFS.

Now the process of mounting a USB stick on an ESX host is really very simple.

1. Plug it in
2. dmesg to get the identity of the drive that was just inserted (for example /dev/sda)
3. mkdir /tmp/usb
4. mount /dev/sda /tmp/usb

It is that simple.

I needed to copy off the files before I wiped and re-installed the host.

I thought - where else do I have an available USB stick? And Bling! Light bulb!! My phone!!!

1. Plugged it into the host.
2. Found the identity from dmesg
3. Created the directory, mounted the device
4. Copied off my files
5. umount /tmp/usb

I now had the necessary files on my phone - which I could thereafter forward to the relevant people.

Handy to have a phone wherever you go, don't you think?

This was just released. KB 1027027 (ESX) and KB 1027753 (ESXi)

I wanted to point out that is should deal with several issues that include a patch to solve this Host crash because of ESX Active Directory Integration.

Here is the info from the KB 1027021

When an user who is a member of more than 32 groups attempts to log into an ESXi host by using KVM, any one of the following issues might occur:

• ESX/i host restarts

• ESX/i host becomes unresponsive

Note: With this patch, a user who is a member of more than 128 groups can access the console, but loses any group information beyond the 128th group.

And also the 8 character password issue that William Lam posted about here

If passwords of more than eight characters are set for ESXi 4.1 system users, the set password is truncated to eight characters, and the system evaluates only the first 8 characters of the password submitted for authentication.
Note: To implement this fix, reset the password of the existing ESXi 4.1 system users after applying the patch.

As always - Test before deployment

I was contacted the other day with an issue where someone was trying to create a cluster in a box, and they were running into an issue. When trying to power on the VM with the shared, eager-zeroed-thick disk that was created they were running into an error message, saying that they did not have permission to access the disk.

I checked to see if the VM settings were correct and that the SCSI adapter was set to a different controller with the correct disk sharing options. It was.

I enquired how was the eager zeroed disk created, and that was also done correctly. The admin logged into the ESX host and created the disk with the following command on the datastore.

sudo vmkfstools -c 60G -d eagerzeroedthick /vmfs/volumes/IT_DBM_QT/shared/shared.vmdk

I logged into the host and noticed something weird. The disk was created in a folder called shared but the permissions on the folder and the files were not correct. they were set with owner:group which was not root:root the way it should have been.

From the ESX host

drwxrwxrwx 1 root root 4096 Nov 1 14:43 .
drwxr-xr-x 1 root root 512 Nov 1 15:23 ..
drwxr-xr-x 1 65534 65534 4096 Sep 20 14:31 md1
drwxr-xr-x 1 65534 65534 4096 Oct 27 11:23 md2
drwxr-xr-x 1 65534 65534 4096 Sep 19 16:21 mich_bi
drwxr-xr-x 1 65534 65534 4096 Oct 14 18:04 oem11
drwxr-xr-x 1 65534 65534 4096 Sep 16 10:20 orabi11
drwxr-xr-x 1 65534 65534 4096 Oct 3 12:09 rh5.5-m2.kickstart
drwxr-xr-x 1 65534 65534 4096 Sep 12 12:36 rh5-dg1
drwxr-xr-x 1 65534 65534 4096 Oct 14 16:53 rh5-dg1_1
drwxr-xr-x 1 65534 65534 4096 Sep 12 15:46 rh5-dg1_2
drwxr-xr-x 1 65534 65534 4096 Sep 13 11:05 rh5-dg2
drwxr-xr-x 1 65534 65534 4096 Sep 12 15:08 rh5-dg2_1
drwxr-xr-x 1 65534 65534 4096 Nov 1 15:07 rh5-rac1
drwxr-xr-x 1 65534 65534 4096 Nov 1 15:09 rh5-rac2
drwxrwxr-x 1 admin admin 4096 Nov 1 14:43 shared
drwxrwxrwx 1 root root 4096 Nov 1 12:00 .snapshot

Now the listing above shows that the owner was 65534:65534 which was not right.

Now who is user 65534? I tried to cat /etc/passwd | grep 65534 but did not find anything there.

I have the NFS datastore mounted outside of the ESX host, for administrative purposes, so I decided to check from there. And low and behold this is what I saw.

drwxrwxrwx 17 root   root    4096 2010-11-01 14:43 .
drwxr-xr-x 20 root   root    4096 2010-11-01 15:21 ..
drwxr-xr-x  2 nobody nogroup 4096 2010-09-20 14:31 md1
drwxr-xr-x  2 nobody nogroup 4096 2010-10-27 11:23 md2
drwxr-xr-x  2 nobody nogroup 4096 2010-09-19 16:21 mich_bi
drwxr-xr-x  2 nobody nogroup 4096 2010-10-14 18:04 oem11
drwxr-xr-x  2 nobody nogroup 4096 2010-09-16 10:20 orabi11
drwxr-xr-x  2 nobody nogroup 4096 2010-10-03 12:09 rh5.5-m2.kickstart
drwxr-xr-x  2 nobody nogroup 4096 2010-09-12 12:36 rh5-dg1
drwxr-xr-x  2 nobody nogroup 4096 2010-10-14 16:53 rh5-dg1_1
drwxr-xr-x  2 nobody nogroup 4096 2010-09-12 15:46 rh5-dg1_2
drwxr-xr-x  2 nobody nogroup 4096 2010-09-13 11:05 rh5-dg2
drwxr-xr-x  2 nobody nogroup 4096 2010-09-12 15:08 rh5-dg2_1
drwxr-xr-x  2 nobody nogroup 4096 2010-11-01 15:07 rh5-rac1
drwxr-xr-x  2 nobody nogroup 4096 2010-11-01 15:09 rh5-rac2
drwxrwxr-x  2 admin  admin   4096 2010-11-01 14:43 shared
drwxrwxrwx 10 root   root    4096 2010-11-01 12:00 .snapshot

The owner was nobody:nogroup.

I then asked the storage admin to please check the export on the NetApp filer was defined and got this back

/vol/DBM/DBM_QT        -sec=sys,rw

I remembered from a while back in my first VCP course that ESX hosts have to have root access to the NFS mount in order to work.

Changed the export to:

/vol/DBM/DBM_QT        -sec=sys,rw,root=1.1.2.0/24:1.1.3.0/24

I now tested the creation of a new VM from the vSphere client and verified that the permissions were now created with root:root.

Strangely enough the ESX host was able to mount the datastore, machines were working as well.

I did however still have to change the permissions on the folders and files that were already created on this datastore while the mount was not correct. This I did in order to prevent further problems and rectify the incorrect permissions

chown -R root:root /vmfs/volumes/IT_DBM_QT/*

Of course this was all done with the VM's powered off!

I started reading Eric Siebert's book this afternoon - Maximum vSphere: Tips, How-Tos, and Best Practices for Working with VMware vSphere 4 (which is a great book - highly recommended!!), and for some reason during the part that he was speaking about licensing and the features, a thought crossed my mind.

I put out a feeler this evening on Twitter with this question:

All the answers I received all pointed to the same conclusion.

The constraint that almost everyone hits first is RAM, not CPU. Some admins cannot expand on the amount of RAM in their server, because the cost of the bigger DIMM's are too high, and there are not enough slots left in the server. Which leaves them with servers that are nearing memory capacity, but not not anywhere close on utilizing the CPU power of the server.

Many people are purchasing dual-socket servers for redundancy or because of the fear of not having the server perform well enough.

From my own environment I can say that my hosts are utilizing around 30% of their CPU, with 2 Quad Core CPU's. And from the answers I got tonight on my question above - the results are pretty much the same.

Now perhaps a sacrilegious thought. What would happen if we only used one physical processor in a server?

Today we are talking about a six or eight core processors and this number is rising. The amount of cores available are more or less the same,  as what the majority of people are using today, 8 cores - 2 x Quad-core processors.

Now you might ask, but here I lose the redundancy. This could be true, but how many of you have actually lost a CPU due to malfunction in a server? I personally have not. Ever. I would also suppose - that if a physical CPU barfs on you during a production workload - then it will not be pretty. The VM's that were running from that Processor will obviously kill over and die, but I suppose the rest of the host will not be happy either. From my experience with faulty memory, you are more likely to crash the whole host with a PSOD than having the host function with one DIMM less. I guess that with a CPU - it will probably be the same. So having redundant CPU's does not really cover it. I could be wrong here, and if so I would appreciate your feedback with more information.

Now I am sure there are other implications here, regarding the spread of memory and load over the two channels from both processors, and I am also sure that there are other internal ESX performance implications as well. So it is not a simple matter.

How will this change the game though? Well it will cut costs - in two ways.

1. Licensing. ESX licenses are now counted per processor, and not per sets of 2. Removing one processor, will lower ESX host licensing costs by half.
2. Server hardware. With one processor less, you are able to cut costs on each server.

So are we destined to run only a 1 Socket ESX host? I would interested in hearing your thoughts and insights on this one.

I was subscribed to this thread and received an update today that I must have missed previously, with an issue much more serious than the one that the thread was originally started with.

Previously, I posted an article to explain how to Integrate ESXi into Active Directory. After the integration logging onto a host with your domain credentials can cause the host to crash. The issue occurs when the user logging into the ESX host with their Active Directory credentials is a member of more than 30 Security Groups.

The issue has been confirmed with happening with the user being a member of as little as 23 security groups as well.

The ESX Host throws an error and reboots (PSOD) and reboots. The thread owner has a ticket open with VMware and according to the information there engineering are working on the issue.

Below are Screenshots taken from the thread

I ran a quick check to how many groups my AD account is a member of (Powershell of course)

Get-QADUser msaidelk | Get-QADMemberOf -ErrorAction Continue | where {$_.GroupType -eq "Security" } | Measure-Object | Select-Object -Property Count | Format-List

Count : 45

I have tried to re-create this on my standalone host but have not experienced this problem.

Has anyone else encountered this issue?

I was entrusted with the deployment of a new HP DL380 G7 as a new ESX Host.

I have my build process down very well. I use the UDA:

• create a new sub-template
• enter the information that I need in for the hostname and IP
• Boot the server.
• Choose the server name from the menu
• Come back 20 minutes later and add the ESX host to my vCenter.

All fine and dandy. So.. I prepared to do the same with the new G7.

I booted the server and started the process. And BAM! it failed - complaining that is could not find the disks. I was intrigued to say the least because this is a proven working process - which never, ever fails!

As always - I use Google as part of my right-brain - and this brought me to the following post that shed some light on the issue.

During the kickstart operation you define where you are going to install your partitions.
Historically this was /dev/cciss/c0d0 as you can see from part of the kickstart configuration below

# Clear Partitions
clearpart --drives=/dev/cciss/c0d0 --overwritevmfs

If once upon a time it was

esxcfg-module -l | grep -iE "cciss|hpsa"
cciss 0x8ae000 0x7000 0x290d140 0x2000 3 Yes

It was now

hpsa 0x961000 0xa000 0x2956da0 0x10000 4 Yes

Ken Cline also pointed me in right direction. With this new adapter the devices are now recognized as /dev/sda and not /dev/cciss/c0d0.

Well all in all this is a good change - I think. If you were using different Vendors IBM, Dell, HP you needed to keep one template for HP and another for all the rest.

Even the UDA specifically was built this way

Now I will not have to keep a template specifically for HP hardware

Judging from the post mentioned above this is not only a G7 issue but also a G6 blades as well.

Hope you can make use of the info.