posted

2 Comments

In the previous post Configure DHCP and TFTP for Auto Deploy, we discussed how to setup your DHCP and TFTP servers to allow your ESX hosts to PXE boot. However, once an ESX host boots, it will need directions to know what to boot. This is where Auto Deploy Rules come in.

Download an ESXi Offline Bundle

You will need at least one offline ESXi bundle, which will allow you to attach ESXi to an Auto Deploy rule (we’ll talk about this later on)

Go to www.vmware.com and click on the version of ESXi you wish to use. You will see an ‘ESXi Offline Bundle’ ZIP file. Download the file and remember the location where you placed it.

Screenshot 2015-05-19 14.24.16

Do not unzip this file as you will need the full ZIP file for Auto Deploy.

Screenshot 2015-04-07 10.01.55

Add ESXi to the Software Depot

Once you have the ESXi Offline Bundle, you will need to add it to the Software Depot.

To add the Offline Bundle to the Software Depot, you will use the ‘Add-EsxSoftwareDepot’ cmdlet along with the location of the bundle:

Add-EsxSoftwareDepot C:REPOVMware-ESXi-6.0.0-2494585-depot.zip

Screenshot 2015-04-07 10.02.06

Once this file has been loaded successfully, you will see the Depot URL:

Screenshot 2015-04-07 10.02.10

You can then use the ‘Get-EsxImageProfile’ cmdlet to see the versions of ESXi available to you from the bundle that was just uploaded. In the image below, you can see that there are two versions of ESXi 6.0.0; standard, and no-tools:

Screenshot 2015-05-19 15.14.01

Save the desired version in a variable:

$os = Get-EsxImageProfile -Name “ESXi-6.0.0-2494585-standard”

Screenshot 2015-04-07 10.07.04

 

Create Deploy Rules

A Deploy rule is used to determine which hosts boot a specific version of ESXi. There are two important pieces of information needed to create the deploy rule; items and patterns. The items determine what object to associate to the ESXi host and the patterns determine which ESXi hosts are a part of the specific rule.

The following are patterns that can be specified:

  • Asset – The host’s asset tag
  • Domain – Domain name
  • Hostname – The Machine’s hostname
  • IPv4 – IP address of the host. This can be a specific IP Address or a range
  • MAC – MAC address of the NIC used in PXE boot
  • Model – Host’s model name
  • OEMstring – OEM string from the BIOS
  • Serial – Serial number of the host
  • Vendor – Host’s vendor name

To get a better idea of what is needed, I’ve added two screenshots of a host booting via DHCP and iPXE from the previous blog post. The first shows the host successfully receiving an IP Address and receiving files via TFTP.

Screenshot 2015-04-07 10.10.51

This screenshot below shows the attributes of the host that is being booted, which is a major help when determining the patterns used for the auto-deploy rule. In this case, the host being booted is a virtual ESXi host. Machine attributes will be determined mostly by the model and vendor of the host being used.

Screenshot 2015-04-07 10.10.55

We will use the information from the screenshot above to create a pattern for our auto-deploy rule. We will give the new rule a name and attach the ESXi Image profile from the previous step to it. In this scenario we will create our pattern off of the vendor name “VMware,  Inc.” and the IP range that we specified in the DHCP scope, meaning that any host between 192.168.109.21-.30 that has VMware as the vendor will be accepted.

In the example below we use the following command:

$deployrule = New-DeployRule -Name “Default” -Item $os -Pattern “ipv4=192.168.109.21-192.168.109.30″,”vendor==VMware,  Inc.”

Screenshot 2015-05-19 15.59.52

The rule will then get created and you will see a number of files being uploaded to AutoDeploy:

Screenshot 2015-04-07 10.14.53

These files are being uploaded to the vCenter Server AutoDeploy Repo. The repo will house each of the ESXi bundles. The default depot size is 2GB but can be modified if 2GB is not sufficient.

Screenshot 2015-04-07 10.19.08

Once the upload finishes, you can see your DeployRules using Get-DeployRule. This will show you the Name of the rule, the patterns used to identify the hosts, and the version of ESXi that will be attached to said host.

Screenshot 2015-05-19 16.04.42

Remove Deploy Rules

If you create a Deploy Rule that either doesn’t work, or you need to remove it for any other reason, You can do so by retrieving the Deploy Rule, and then using the Remove-DeployRule -Delete command. You will need to make sure that you use the -Delete parameter otherwise, the rule will not be deleted.

In the example below, there are two Deploy Rules: ESX Default, and ESX Hosts. If I wanted to delete the ESX Hosts rule, I would type:

Get-DeployRule “ESX Hosts” | Remove-DeployRule -Delete

Screenshot 2015-04-07 10.24.58

Add Rule to the Deploy Rule Set (Active Deploy Rules)

When you are satisfied with your Deploy Rule, you then need to use the Add-DeployRule cmdlet, which will activate the specified rule and allow your hosts that match the pattern, to boot via autodeploy.

Screenshot 2015-05-19 16.17.12

To see which rules are active, run ‘Get-DeployRuleSet’. This will return all active rules. In our example, we only have one.

Screenshot 2015-05-19 16.18.21

***Note*** You will most likely end up having more than one rule in your active ruleset. The order of rules in the ruleset DOES MATTER. The rules are ordered so that the first rule is Rule 0. The next being Rule 1 and so on. The topmost rule will attempt to apply first. If the patternlist does not match, it will move on to the next rule and continue until it finds a rule where the patternlist matches the host. If you need to place a rule above or behind another, you can use the -At parameter during the Add-deployRule command:

Add-DeployRule -DeployRule “HP Hosts” -At 0

Remove Rule from Deploy Rule Set (move from Active-Set to Working-Set)

Rules that are in the Deploy Rule Set are active. If you decide to remove a rule from the Active rules and place it into the Working-Set (Created rules that are not currently being applied), you would use the Remove-DeployRule cmdlet. This will drop it out of the Active-Set and allow you to edit/tweak any part of the rule needed before placing it back in the Active-Set. Remember, if you add the -Delete parameter on the end of the command, you will completely delete the rule, rather than pull it out of the Deploy Rule Set.

Get-DeployRule “Default” | Remove-DeployRule

Boot the Hosts

Once you have a valid Deploy Rule in the Deploy Rule Set, you should see your hosts start to boot. Power On your hosts and watch them start to load ESXi. You have now booted a baremetal host into stateless ESXi!

Screenshot 2015-04-07 10.37.25

 

Conclusion

Hopefully you have found this helpful. Although there are a number of steps to complete initially, this lays the groundwork for all future hosts to be able to stateless boot, without the need of manually installing and configuring every single ESX host. We will discuss Host Profiles in our next post.

Auto Deploy Command Quick Reference

For those of you who already understand the process and what the commands do, but need to refer back to the cmdlets used, this is for you:

  • Add-EsxSoftwareDepot <path to zip>
  • Get-EsxImageProfile
  • $img = Get-EsxImageProfile -Name “<Name of Image Profile>”
  • $Deployrule = New-DeployRule -Name <Name of rule> -Item $img -Pattern “<pattern sequences here>”
  • Get-DeployRule
  • Get-DeployRule -Name <Rule Name> | Remove-DeployRule -Delete
  • Get-DeployRule -Name <Rule Name> | Add-DeployRule
  • Get-DeployRuleSet
  • Get-DeployRule -Name <Rule Name> | Remove-DeployRule

About the Author

Brian Graf

Brian Graf is a well-known VMware evangelist in the IT community. Over the past 5 years, Brian has done Technical Marketing for PowerCLI Automation and ESXi Lifecycle, Product Management of vCenter Distributed Resource Management features (DRS & HA), and is currently working as a Technical Marketing Manager for VMware Cloud on AWS. Brian is a co-author of the PowerCLI Deep Dive 2nd edition book. He has helped develop VMware certification courses and exams and presents around the world at VMware User Conferences, AWS Summits, Interop, as well as other industry Conferences. Brian is also a Microsoft MVP.