There are definitely pros and cons to using the various PVS boot options. If you aren’t familiar or need a refresher, here they are:
- TFTP (with DHCP or PXE options)
- Create a Boot Device (BDM) using the included utility
- Let PVS XenDesktop Setup Wizard create a BDM partition/drive
For the purposes of this post, I will be talking about BDM. I’m going to differentiate option #2 with option #3 by referring to #2 as “BDM-TSB” and #3 as “BDM monolithic”.
The PVS Boot Process diagram outlines the process I great detail, and I highly suggest you read it. All options are limited to 4 potential “Login servers”. When using DNS, DNS based subnet affinity Here are some pro’s and cons of each option
TFTP (w/ PXE or DHCP)
- Relies on external load balancing (potential off-host communication)
- Relies on TFTP service or third party TFPT server UDP port 69
- Prone to outages
- Built-in TFTP control panel configuration does not work on 2012 R2. Multi-nic binding scenarios could be difficult
- Third-party TFTP servers often without support
- Multi-threaded TFTP servers traditionally don’t scale well
- Relies on either PXE or DHCP options for boot sever name
BDM-TSB
- Highly customizable
- DNS or Static IP Definitions
- Relies on Two-stage boot service (and proprietary protocol on port UDP 6969)
- Can “burn” ISO or partitions
- BDM Utility does not identify which SCSI ID or other unique identifier for disks. Prone to misconfiguration (BE CAREFUL! CAN OVERWRITE YOUR MBR!)
BDM-Monolithic
- Cannot customize
- Relies on “CONFIGURE BOOTSTRAP” settings for farm (more on this in a moment)
- Cannot use DNS
- Includes all components required for boot (No TFTP, load balancing, TSB needed)
- High degree of “Fault isolation”
- Can be cumbersome to replace/update
- Only available via XenDesktop setup wizard
- Newer (first release in 2013), not as widely used
In selecting the BDM-Monolithic option, I was hoping to be able to design a highly fault tolerant environment that does not rely on the network stack (TFTP load balancing) or rely on the two stage boot service on each PVS server. However at scale, we ran into some issues. The design calls for 2 servers per subnet, in a single farm. Since it is currently not possible to use DNS currently for the monolithic BDM and if there is a desire to not rely on DNS anyway (say, if another group in the organization owns it), my next thought was to configure bootstrap differently per-server then connect the PVS console to each server, hoping it would use it’s own BOOTSTRAP settings. Unfortunately, this seems to not be the case and it seems to select from the “top” PVS server in the farm (in my case, this was the second one added to the farm), as shown below.
Based on this, I started digging. What else could we do to make this a bit easier, without having to reconfigure BOOTSTRAP for the whole farm every time we spin up a subnet? I turned to DotPeek and saw something interesting.
If Login servers count = 0, we should hit that “else” statement and use DNS – which, we can’t modify the hostname, but I’ve confirmed is “ImageServer1” (the default) if you look in the BDM that gets “burned”.
However, once configured, you’ll be hard pressed to remove servers!
So while that is interesting, it would still be far more helpful that we simply use the BDM utility.
It seems that the simplest solution would be for Citrix to simply allow the BDM-monolithic to be created by the Boot Device Manager configuration utility – something that is long overdue given the age of the PVS 7.x code base.