In the last post we got a VM to auto deploy.  In this post, we’ll wrap up that config (clean it up) and talk about host profiles.  But first, lets talk about use case.  Auto deploy is a neat feature, but I think there’s some misconceptions about how it works.  For instance, when I first read about it, I assumed that you could PXE boot a host right into a new cluster and instantly add capacity.  As it turns out, not so much.  Auto deploy is really just a way to boot machines over the network with a centralized configuration and policy.  Here’s a quick run down of how this process works.

-Configure Auto Deploy to get a new machine to PXE boot
-Configure an Auto Deploy policy to tell the machine what host profile and what cluster you want the host in
-PXE boot a VMware depot image to load ESXi
-The machine loads into vCenter but is in maintenance mode
-Configure that machines answer file for unique machine information
-Reboot the machine again
-The machine should load, vCenter reconnect, and the machine load directly into the cluster

So that’s a super quick run down of how it should work.  Obviously there are a few pieces missing but I’ll run through those in the actual config below.  To start off, lets undo some of the config we did yesterday in VMware power CLI to make the configuration more generic. 

So let’s take a look at what’s already configured first.

Log into the vCenter instance…

 
Now let’s take a look at the existing deployment rules…

 
We see the ‘NormalBoot’ rule we created yesterday.  Now, let’s remove that rule entirely from the configuration…

 
So wait…  We just deleted it and it’s still there?  Yep.  See when you remove the deploy rule, you are essentially just taking it out of the active deployment policy.  If you want to actually remove the policy, you need to add the ‘-delete’ flag to the command.  Since that’s what we want to do, let’s try again.

 
That’s better.  Now, let’s make our new generic deploy policy.  Im going to run this command to create it…

New-DeployRule –Name “WindowsServerCluster” –Item “ESXi-5.0.0-469512-standard”, “WindowsServer”, “AutoDeploy” –Pattern “ipv4=10.20.30.1-10.20.30.10”

So the first part is just like the last one we did however we are specifying a couple of other items here.
"WindowsServer" – The name of the cluster I want the host join.  You need to create this ahead of time
"AutoDeploy" – The name of the Host Profile I want the host to use. 
-Pattern “ipv4=10.20.30.1-10.20.30.10” – Here I specify what servers I want this policy to apply for.  So I’m saying, any server with an IP between 10.20.30.1 and .10 should match this policy.  I’m actually using MAC address reservations on my switch to make sure that the server get’s an IP in that part of the DHCP scope. 

So let’s plug that in and see what happens…

 
It didn’t like the command claiming that it cant find the ESXi image I specified.  This is another weird one.  Each time you load PowerCLI to configure a new policy, you need to reload the depot.  So let’s do that and try again…

 
Last we need to actually activate this policy…

Bingo.  New policy loaded.  So now let’s talk about host profiles a little bit.  Host profiles essentially allow you to create a default configuration for ESXi hosts.  When the profile is applied to a host, the host can either be compliant or non-compliant.  In addition, since not each host can be totally identical, the host profiles have something called answer files.  The answer files get associated with particular hosts and provide specific information that’s unique on each host.  I think the easiest way to explain them is to just jump into the config, I’m sure you’ll pick it up quick. 

Start off by going into ‘Hosts and Clusters’ view in vCenter….

 
Now since I have my vCenter server virtualized I already have a ESXi host loaded and configured the way I want it.  Let’s use that host’s configuration as our baseline (or host profile).  Right click on the host, go to Host Profile, and click Create Profile from host.

Give the profile a name click Next, and then Finish.

 
Now go back to the home page in vCenter, and select the Hosts Profiles link.

 
You should now be in the Host Profile menu…

 
Right click your new profile, and select ‘Edit Profile’…

 
This view allows you to tweak all of the settings associated with the profile.  If you pop into network configuration, you can see that the network configuration is present from the host we created the profile off of…

 
We want to make a couple of quick changes to the profile for future hosts.  First’ despite using DHCP and MAC reservations for the management vmKernel interface, I still prefer to hard set the IP of the host just incase.  So let’s tell the profile to hard set that IP as part of the answer file. 

  
Then let’s tell it to prompt for the storage (iSCSI) IP address as part of the answer file configuration. 

 
Quick note.  It is incredibly important that the Management Network be the first item defined under Host port groups!  If it isn’t the host will boot using a different IP as the management interface.  I lucked out and mine were in the right order, but if yours aren’t, then you’ll need to remove any of the other other policies and recreate them underneath the management interface.

 
So let’s close this profile, and PXE boot our new host.  The host should boot into the range you defined in your auto deploy rule and with any luck, you should see it load into vCenter.  Note that the host will load in maintenance mode.  This is because we need to finish it’s configuration with an answer file. 

 
At this point, let’s go back to the host profile view in vCenter. Select Home, Host Profiles, then click your AutoDeploy policy on the far left.  Once the policy loads, select the ‘Hosts and Clusters’ tab on the right hand pane.  

 
Now right click on the host and click ‘Check Answer file’.  When the process has finished your host should look like this…
 

Now, right click on the host again and choose ‘Update answer file’.

 
This is essentially a wizard that walks you through all of the items that vCenter needs before it can apply the host profile to the new auto deploy host.  Walk through each item and fill out the information required hitting the ‘Next’ button at the bottom to go to the next item.  When you are done with all of the items, click update to close the screen.  

Couple of quick notes.  Make sure that your iSCSI storage initiator name is configured on your SAN so that the box can load the appropriate data stores on the first reboot.  Also, make sure that the IP’s you specify are valid for the iSCSI connectivity. 

Once the update has finished, right click the host again and click ‘Check Answer File’.  The status should change to complete as shown below…

 
Now for fun, I’m going to add the new host to the DRS cluster that the 10.20.30.5 host is already a part of.  With any luck, the new host (10.20.30.6) should boot, have the host profile applied, exit maintainence mode, and DRS should move at least one of my other running Vms onto 10.20.30.6.

 
Now reboot the host and let’s see what happens!

After a few minutes, the host comes back online, vCenter reconnects the server, and DRS vMotions a VM over to it!

 
So there you have it a successful auto deploy scenario.  I learned a lot about host profiles and the auto deploy technology in these last two posts but I’m interested to hear if anyone is running this in production.  If so, how does your configuration differ?