A big thank you goes to Michael Zimmerman for the contribution:
By default with the Setup PXE Boot task in UCSD, there are a certain set of default variables that are found and replaced with values in the ks.cfg file for a PXE request. These variables correspond to the default inputs that you enter inside the Setup PXE boot tasks…for example in a sample ks.cfg file there might be a line like the following…
network --bootproto=static --device=eth0 --ip=$PXE_IP --netmask=$PXE_NETMASK --gateway=$PXE_GATEWAY --vlanid=$PXE_MGMTVLAN --hostname=$PXE_NAME --onboot=on
Everything I highlighted in the line above is a default variable that is replaced by the value you provide in the Setup PXE boot task of your workflow.
Now, where the additional parameters come into play is if you want to define your own user defined variables and pass them to the BMA and have them be replaced with dynamic values. So lets say I wanted to pass an IP address for another interface or something…in the additional parameters table I might add something like..
What this does is forces the BMA to look in your ks.cfg file and if it finds the phrase “$SecondIP” (without quotes) from the “Name” column, then it will replace it with the value in the “Value” column. In this example, I’ve set the “Value” column to “192.168.20.20. So anywhere in my template ks.cfg file where I have entered $SecondIP, it will be replaced by “192.168.20.20. You can also instead of putting a static value in the “Value’ column, you can also put a dynamic variable. So lets say in my workflow I prompt the user for the second IP so I have a workflow input called “Second_IP_Address” that I want the user to provide. I could set it up like this…
Now whatever the value that is provided for the workflow input “Second_IP_Address” will be replaced and inserted in to the template ks.cfg file wherever the phrase “$SecondIP” (from the “Name” column in additional parameters) is found.
So it’s really just a way to create user defined variables that can be used in the template ks.cfg file and then pass data from the Setup PXE Boot task to the ks.cfg file…
For your example above…your additional parameters might look something like this..
Then the lines in your template ks.cfg file might look like this…
esxcli storage nfs add -H $SERVERNAME -s /pathtoshare -v esx_logs
esxcli system syslog config set —logdir=$PATH_TO_VMFS_DIRECTORY —loghost=$REMOTE_HOSTNAME --logdir-unique=$LOGDIR_UNIQUE --default-rotate=$DEFAULT_ROTATE --default-size=$DEFAULT_SIZE
Again I’m using workflow inputs in the “Value” column in this example as noted by the "${}”, so you’d have to set those up as workflow inputs in your workflow…
Depending in the connectivity of the BMA to UCSD one may have to swap out these variables:
${PXE_WEBSERVER} vs ${PXE_WEBSERVER_MGMT_VLAN_IP}
This is is important for the notifications task in the work flow to be alerted that the PXE process is done.
Here is the content of the attached word document:
Sample BAM configuration:
Sample PXE boot task inputs:
Sample PXE workflow execute information:
- Service Request ID = 924
- PXE Request ID = 2
Sample Windows BMA configuration:
Sample setup windows PXE boot task
Sample workflow execution:
- Service Request ID = 925
- PXE Request ID = 3
Sample outputs:
Side notes:
For RHEL 7
The issue was solved by adding the VLAN to the PXE task on the workflow --- (which was not required for RHEL 6.5)
