Our journey to VDI continues. This week, we had several more milestones on our road to delivering this solution into the far reaching corners of our area. Among those accomplishments were implementing the DHCP options successfully, setting up several pools of linked-clone virtual desktops and a wider testing of the Pano devices and their capabilites. (This is only an incremental update – see my prior post.)
Mike, one of our senior sysadmins, has successfully implemented the Pano DHCP options on Cisco Network Registrar (CNR) which we use for DHCP. We initially had trouble getting the scope options working with CNR. We failed back and used a more standard Linux DHCP server for our proof of concept. But rolling this out to our company, we knew we’d either have to abandon CNR or make it work. And, with a little persistence, he was able to get the options included usign CNR. If anywhere in Pano Logic’s documentation is lacking, its with configuring the DHCP part of their solution. Granted, they offer other ways, but DHCP is pretty much the standard way. The documentation I saw was strickly for Windows DHCP, though we got it working quickly on Linux DHCP. The scope options are now deployed across the entire enterprise, so we can fire up a Pano anywhere in our corporate infrastructure now and it should work.
I’ve had some more hand-on time with the Pano devices this week. I’ve begun testing the solution at my desk and I’m very impressed at the performance I’m getting using the new Console Direct technology from Pano Logic. The improvements in performance are noticable and I’m extremely happy with the overall experience.
Jason is continuing to work out kinks in our VDI templates. Right now, we have two – one for our group to use and one for the central offices – and we’re continuing to customize and redeploy these templates. We’re utilizing VMware View, and there are a few things we’ve learned about View with Pano.
Unlike using Pano Manager against an ESX farm directly, when using VMware View you have an option for adding VDM pool(s) to your Pano Manager. Using Pano Manager against ESX directly means you use Pano to spin up new VM’s as needed and set all permissions and entitlements in that console. But with View, you may simply create a VMware VDM collection (one for all) and assign all your AD users to it. From this point on, all administration for the VDI can be accomplished in View Manager. This is the route we have chosen to go to gain some of the features included with View.
We are using View to leverage the thin-provisioning technology and hopefully save us some very expensive space on our disk arrays. Keep in mind, you don’t need View when running Panos, however we felt that the VMware View was more adventageous to use now from a licensing cost perspective.
As best we can tell, the Pano Manager will only be needed to make changes against the Pano devices in our environment – changes like making login screen preference changes or assigning a second Pano to serve as a dual monitor pair. It turns out that using View as our backend, we won’t be using Pano Manager to spin up VM’s, create pools, etc.
Jason and I are doing some additional testing with View’s capabilities to seemlessly separate user data (profiles) from the linked-clone OS image. We are testing some of the caveots of using the profile change disks and what survives after a re-compose process. I’ll be posting more on this once we’ve run it through the ringers a little more thoroughly.
