Scott,
I know this is a bit late for a response but I recently had to review a mixxed class upgrade procedure as well, just wanted to add some input to this one, it may not be the exact answer to the question you asked but it may help someone else out down the road..
Any devices in a different class need to be on the same build before they will join the IAP VC. When they were in different firmware versions, I would see PAPI traffic communicating via the "datapath sessions" command (cli), and I would see the mac address populate for the allowed-ap(cil).
Once you have differnet classes in a single IAP VC, you will have a different URL upgrade paths for each class (ex orion or cassiopeia). If for some reason one of the upgrade fails and you didn't reboot any of the IAP's you will lose the devices in that class that failed. You can confirm the upgrade process in the cli by running this command "show upgrade info". This command will only show you the devices that are active in the IAP VC, so if there is a failed attempt somewhere you may not see those devices when running the command.
The issue I came into was when the IAP was on different firmware, it thought it was part of the cluster but wasn't fully synced. If you grabged the IP of the IAP in the other class that you are trying to join the VC with, I noticed it would redirect you to the IAP Master. I attempted to SSH but received a reject message.
Only way I was able to get around this was by putting that IAP on a different vlan / segment so it couldn't communicate with the VC via broadcast and then was able to get into mgmt. If you have more the one IAP in that other class they should create their own VC, and it should be fairly straight forward for the upgrade process.
Once the IAP's in that other class are upgraded you can put them back on the vlan / segment with the other IAP VC, and they will join back in wihtout any issues.
As to using the URL upgrade procedures its pretty straight forward, TFTP was pretty slow for me, and I have yet tried HTTP. Just put any images on your tftp / http server, and enter the following firmware codes in this format.
tftp://x.x.x.x/ArubaInstant_Cassiopeia_6.2.1.0-3.4.0.5_41337
tftp://x.x.x.x/ArubaInstant_Orion_6.2.1.0-3.4.0.5_41337
To confirm the upgrade process you would go into the CLI, and run the following command.
- show upgrade info
I have provided an example below with 2 different classes "Cassiopeia & Orion"
AP-1# show upgrade info
Image Upgrade Progress
----------------------
Mac IP Address AP Class Status Image Info Error Detail
--- ---------- -------- ------ ---------- ------------
6c:f3:7f:xx:xx:xx 172.16.1.20 Cassiopeia upgrading tftp://172.16.1.10/ArubaInstant_Cassiopeia_6.2.1.0-3.4.0.5_41337 none
6c:f3:7f:xx:xx:xx 172.16.1.21 Cassiopeia upgrade-done tftp://172.16.1.10/ArubaInstant_Cassiopeia_6.2.1.0-3.4.0.5_41337 none
00:0b:86:xx:xx:xx 172.16.1.22 Orion downloading tftp://172.16.1.10/ArubaInstant_Orion_6.2.1.0-3.4.0.5_41337 none
Auto reboot :disable
Use external URL :enable