Auto Deploy Deep Dive, Part 3: PowerCLI, Image Builder, and PXE Boot

Auto Deploy Deep Dive Series, Part Three focuses on PowerCLI and Image Builder, puts the wrap on DHCP, and brings the first auto-deployed VMhost to life!

PowerCLI and Image Builder

We are going to use some PowerCLI next. You can find plenty of PowerCLI primers elsewhere (I suggest Alan Renouf and Luc Dekens sites for the novice. I’ve also done a few articles on Power CLI…), so I’m going to assume some familiarity with it. Connect to your vCenter server with “Connect-VIServer <hostname>” and provide your credentials. The rule we are about to create relies on a host profile and a cluster name , so first we grab that information:

PS C:> Get-Cluster

Name                           HAEnabled  HAFailover DrsEnabled DrsAutomationLevel  
----                           ---------  ---------- ---------- ------------------  
HomeLab                        False      1          True       FullyAutomated      

PS C:> Get-VMHostProfile

Name                           Description                   
----                           -----------                   

PS C:> $HostRangePattern = "ipv4="

In the example above, the cluster is called HomeLab and the Host Profile is called stateful. We also defined a small IPv4 range for the AutoDeploy hosts. Replace those values with something appropriate for your environment.

We then have to create an ESXi Image Profile and Auto Deploy rules. The rules tell the host which Image Profile to use, a cluster to join, and a host profile to apply. Here is a PowerCLI script (which includes the $HostRangePattern var, so it’s easy to change) which does this for us:

#New-EsxImageProfile -CloneProfile ESXi-5.5.0-20131201001s-standard -Name Lab-5.5-Standard -Vendor Nelson
# Add VIBs here with Add-EsxSoftwarePackage
# Export to a bundle or an ISO if necessary, make sure you have write access to the destination.
#Export-EsxImageProfile -ImageProfile Lab-5.5-Standard -ExportToBundle
#Export-EsxImageProfile -ImageProfile Lab-5.5-Standard -ExportToISO C:lab-5.5-standard.iso
$HostRangePattern = "ipv4="
$Profile = Get-EsxImageProfile -Name "*standard*" # replace with "Lab-5.5-Standard" if you modified it
New-DeployRule -Name ProductionDeploy -Item LabHostProfile,$Profile,HomeLab -Pattern $HostRangePattern
Set-DeployRuleSet -DeployRule ProductionDeploy

The first line adds the VMware online software depot. If we need to add VIBs to the image, we would do it in the commented lines by cloning VMware’s 5.5.0 profile to a new profile and adding additional VIBs (an excellent example of this can be found at Chris Wahl’s site, specifically Step 3 of the PowerCLI script). We could then export the image as a zip bundle or an ISO image, perhaps to load on a host with a DVD drive or attach to a nested ESXi VM’s optical drive.

Two global variables, $HostRangePattern and $Profile, are then set for use later. You will need to modify $HostRangePattern. $Profile is based on the software depot, if you are using a vendor depot the name may vary. As with all automation, it doesn’t hurt to run it once manually to verify.

The last two lines create a single rule that applies the host profile, image, and cluster all at once. By using Set-DeployRuleSet, any existing rules are removed and replaced with the specified rule; if you have existing rules to preserve, use Add-DeployRule. This rule applies a set of objects to a new host. The Image object is used to install the OS, the Host Profile applies it to the new host (but does not check compliance!), and the Cluster object adds the host to the cluster. Auto Deploy simply auto-magically determines the action to take according to the object type.

One important thing to note: We used an online repository. You can also use an offline depot, or make your own via the ‘Export-EsxImageProfile -ExportToBundle’ command. I made this decision because it’s simply easier than finding the right file on VMware’s site. However, when you apply your first rule, you’ll notice that a lot of downloading begins, as shown below. All of the VIBs in the ImageProfile you chose need to be downloaded. This probably isn’t an issue in your lab environment, but if your production setup does not have direct internet access, the offline depot may be the better solution.

PS C:> $HostRangePattern = "ipv4="

PS C:> New-DeployRule -Name ProductionDeploy -Item LabHostProfile,Lab-5.5-Standard,HomeLab -Pattern $HostRangePattern
Downloading misc-cnic-register 1.72.1.v50.1i-1vmw.550.0.0.1331820
Downloaded 0 bytes...Downloaded 0 bytes...Downloaded 0 bytes...Downloaded 10,904 bytes...Download finished, uploading to AutoDeploy...
Upload finished.
Downloading scsi-lpfc820
Downloaded 0 bytes...Downloaded 0 bytes...Downloaded 0 bytes...Downloaded 0 bytes...Downloaded 163,840 bytes...Downloaded 410,516 bytes...Download finished, uploading to AutoDeploy...
Upload finished.
Downloading scsi-aacraid
Downloaded 0 bytes...Downloaded 0 bytes...Downloaded 55,068 bytes...Download finished, uploading to AutoDeploy...
Upload finished.

Downloading net-mlx4-en
Downloaded 0 bytes...Downloaded 0 bytes...Downloaded 0 bytes...Downloaded 49,152 bytes...Downloaded 69,782 bytes...Download finished, uploading to AutoDeploy...
Upload finished.

Name        : ProductionDeploy
PatternList : {ipv4=}
ItemList    : {Lab-5.5-Standard, HomeLab, LabHostProfile}

PS C:> Set-DeployRuleSet -DeployRule ProductionDeploy

Name        : ProductionDeploy
PatternList : {ipv4=}
ItemList    : {Lab-5.5-Standard, HomeLab, LabHostProfile}
PS C:>

One last thing to note: The Image Builder commands (*-EsxSoftwareDepot and *-EsxImageProfile) exist per-session. If you close your PowerCLI session and decide to tweak your deploy rule, you may need to re-apply all those rules if your changes a custom ImageProfile such as Lab-5.5-Standard. Even though vCenter has stored the ImageProfile for use with new hosts, PowerCLI won’t see it and will generate errors. Save your Auto Deploy script so you can modify it on future iterations. As an alternative, you can export the image to a bundle, which you can import in the next session.

DHCP Reservations

We have one last step: DHCP reservations. We add one reservation for the new host. Obviously, use your MAC, not mine. Here is the reservation for esxi02, the new PowerEdge T320.

    host esxi02 {
        hardware ethernet 74:86:7a:e5:27:ce;

Again, ensure the entry is added to the correct scope. Restart dhcpd and ensure it is handing out addresses and renewals before proceeding.

Power On

Now, we are all set! Power on my server, force a PXE boot (F12 on my Dell), and come back in 30 minutes to a server running ESXi 5.5 and joined to your cluster. Take it out of maintenance mode and it is ready to host VMs!

Auto Deploy Complete

By following these articles, you should have a working host in your cluster on which you can deploy VMs. Now that you’ve completed the basic setup of Auto Deploy, there’s a lot of fine tuning you can do on your own – pre-populate DNS, assign DHCP based on CIM details like make and model, use a more specific Host Profile to attach a vDS and shared storage, tie it into a vCO workflow, etc. Auto Deploy is a really powerful tool, regardless of whether you’re running 2 or 3 hosts in your home lab or hundreds in a production network – or studying for a certification! I can confirm that there’s not a lot that’s more fun than unpacking a gigantic Christmas present, plugging it into the network, hitting F12, and doubling the size of your vSphere lab!

This series isn’t over yet! In these last three articles, we made the assumption that everything we did went well. But what if we had an issue? Next week, in Auto Deploy Deep Dive Series Part Four, we will cover some troubleshooting steps to address some common, and some uncommon, problems with Auto Deploy.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s