Posted by: MikeLaverick
This week I spent some (not all) of my time playing about with a Panologic Device.
[Oh, and contrary to popular belief - they didn't pay me to do this, and I didn't ask for any money. I all asked for was a the device and software so I could play. Remember, after years of documenting VMware technologies - mainly for free - VMware has never given me a penny. He who pays the piper calls the tune - does NOT apply on RTFM. Got that?]
It’s not a PC and its not a dumb-terminal. It’s something else all together – its what’s called a zero-client. What that means is essentially the device is truly stateless. It boots over the network to what’s called the Pano Manager, which then acts as a broker to your virtual desktops. I’ve been writing a guide to VMware View 4.5 (which is currently in beta), and thought it was about time that I looked at dumb-terminals and zero-clients. If first came across Panologic at the North Carolina User Summit in 2008, and then again when they presented at the London User Group. Panologic is not alone in creating a zero-client, there are others on the market – and I’d be happy to evaluate them if the respective vendors can setup me up with a device and necessary software. It’s important to really understand what zero-client really means – it means literally there is no software or firmware on the device. You plug it, and so long as the appropriate system services are in place (DHCP, the zero-client manager/broker, vCenter and Virtual Desktops) – then the client simply boots, presents a logon screen and the user gets their desktop. I’m going to experiment with my Pano over the next couple of weeks, hopefully using my partner as a guinea-pig (I’m sure she wouldn’t not like being compared to furry rodent, despite her feline qualities!). She’s working in London, and wants to leave her laptop down there, but she will still need to browse the web and stuff when she gets home for the Le Weekend. Rather than letting her “borrow” my Mac Book Pro, and have complain about where the DEL key is – I thought I would take her keyboard, screen and mouse – and plug them into the Pano. She’s always complaining about her old Jurassic Windows XP laptop being to slow – so perhaps she will find the virtual desktop experience a better one.
I won’t bore you with a details step-by-step setup of the system – but will give you here an overview how to get started and what I felt about the overall system. Remember I’ve only been using a zero-client for about a week so my experiences will be quite narrow and partial. I’m not doing (yet) a bake-off between various zero-clients.
First, I download and imported the Pano Manager. This is a pretty straightforward job – as it ships in a .OVF format which means so long as your on vSphere4, it just gets imported into the cluster. It’s a pretty straightforward post configuration to from the vSphere Console – you just need to assign a static IP address to the Pano Manager (in my case 192.168.3.130), and set your passwords up! The real post configuration is in the administrative web-pages of the Pano Manager itself which is based on this nice, new Adobe Air environment – its seems like every vendor who has a web-page based admin tool is adopting – including VMware…
There’s two mandatory and seven optional components that need to be setup. Firstly, you need to tell the Pano Manager about your Active Directory configuration and then your vCenter configuration. Of course, being a lab environment I just cheated and used the built-in administrator accounts – but best practice would be to use dedicated accounts for this stuff. The Pano Manager needs your AD environment for authentication – and the vCenter to locate the desktops – it also needs these if you chose to use the Pano Manager to provision desktops. This isn’t mandatory – unless you have no other provisioning method already in place. If you have VMware View for example, you could let View handle the provisioning processes, and then just point the Pano Manager to the desktops already created.
Notice how in the second screen grab – you need the HTTPS reference to the SDK running on the vCenter server… One interesting anomaly of this is that exposes even the hidden VM folders created by the VMware Composer Service for linked clones.
I also filled in the back location, and completed the VMware View location as well – as I wanted to evaluate Panologic with & without VMware’s broker:
The next thing I did was look at creating some virtual desktops for the Panologic Devices. NOW. A word of warning, inside the virtual desktop you install what is essentially an agent called Pano Direct. The Pano Direct also installs a virtual graphic driver into the virtual desktop – which is used to re-direct all the graphics of the virtual machine to the Pano Device.
This Pano Direct Controller is incompatible with the VMware SVGA 3D (WDDM) driver. In fact if its installed, you cannot install the Pano Direct software. This can and will cause problems for existing pools of desktop, say created using VMware View (if you have them). Whilst its relatively simple process to replace the driver and roll-back to Standard VGA Driver its is bit of PITA. This gave me some hassles becausethe instructions on the Panologic website seemed geared around Windows XP, and couldn’t follow their instructions to the letter on Windows 7. It’s something I brought to their attention this week, so hopefully they will update that portion of the site soon… To make own life simple I end-up making a new Windows 7 VM, installing VMware Tools in a custom mode, and just not installing the SVGA Driver. This makes graphics not very altogether fantastic in a vSphere Client “Console” window, so I resorted to RDP rather than struggling with the VMware Remote Console.
What this blog post misses out is the hours I spent trying to rollback, uninstall, and install the VMware SVGA II driver on Windows 7. It’s a strange and terrible saga too torturous to going to into now. In the end just using the Standard VGA Driver seemed the least painful process!
NEW: Sometime after getting the Panologic Device and Pano Manager working – I did a VMware Update Manager update of my ESX hosts (I didn’t do anything the way of virtual machine patching. After doing the VUM Update, I discovered I couldn’t connect to the virtual desktop via Pano Manager. I discover that Carmel’s virtual desktop – suddenly had the VMware SVG 3D driver (despite the fact I had never installed it!). This was very weird. VUM also updates the .ISO images that are mounted during a VMware Tools installation, all I can assume is that the driver got installed that way. The interesting thing is that normally when ESX is on build X, and VMware Tool is build Y – you get the option to update VMware Tools – in the affected VM this wasn’t the case. Perhaps VUM, does update VMware Tools for you in the guest – but I think that’s very strange behaviour given that an automatic update of VMware Tools on Windows usually means a reboot. Anyway, I’ve raised this issue with Panologic in the hope they can reproduce the issue, and offer advice on how to manage it… The really odd thing, is I checked out my other virtual desktops – and they had the SAME build number of VMware Tools, and had not picked up the VMware SVGA 3D driver. Stranger and Stranger. Who DID install the driver. It weren’t me Gov, and if it weren’t VUM – have a got a hacker in my midst who likes to install drivers?
Strictly speaking there’s no need to enable RDP or install any other agents such as VMware’s View Agent – but I did. I want the virtual desktop to be accessible to my partner when she’s using the Pano Device, but also have access to it (if she wants it) from her laptop using the VMware PCoIP protocol. I figure the more ways she has of connecting to her virtual desktop (either home or away) the more likely she will use thing! Once you have resolve the display driver issue the Pano Direct software installs in a next-next fashion – there a couple of pop-ups to do with drivers but nothing too funky… Of course, all the usual suspects that affect virtual desktops needed to be dealt with as well – before I could consider giving the Pano Device access such as:
- Turning off hibernation and sleep settings in Windows 7 and other optimizations to improve security or performance (the list is literally endless!) fortunately some of this handled by GPOs…
- Enabling RDP (Optional) for Windows 7 and handling the RDP Security issues
- Joining it to the domain
- Testing I could access it for RDP and VMware View (Optional)
Next thing, I needed to do was to get my DHCP sorted. I was hindered by having to switch off my wifi routers DHCP functionality, and having to crank-up a Microsoft DHCP on Windows 2008 R2 for the purpose of the eval. Incidentally, your not limited to using Microsoft DHCP – and reasonable DHCP (i.e not one from some crappy domestic Wifi unit!) will do. On the Panologic help pages they have blow-by-blow instructions on different DHCP’s and how to set them up including:
- Linux DHCP server
- Netware DHCP server
- Cisco DHCP server
- Alcatel/Lucent VitalQIP
- Infoblox DHCP server
I followed parrot fashion the Microsoft instructions. Basically, you add in one of those “Vendor Class” definitions to the DHCP – so when the Pano Device crys out for its Pano Manager the DHCP server recognizes it – and passes the IP address of the Pano Manager. This then gets added as a scope option in the DHCP
It took a couple of reboots of the Panologic to clear the old DHCP IP address it had picked up from my Sky Router, to get the new DHCP address from the Microsoft DHCP. But nothing that would trouble a half decent engineer. But remember on a zero-client all there is a reset button, forget about ipconfig /release and renew!
- Linux DHCP server
- Netware DHCP server
- Cisco DHCP server
- Alcatel/Lucent VitalQIP
- Infoblox DHCP server
When you power on the Panologic Device it should default to login screen, and you can see connected Panologic Devices from the “Setup” tab in the Pano Manager. So below you can see the Pano received an IP address of 192.168.3.16, and distinguished on the network by a concatenation of Pano-plus it the devices MAC address. The “Settings” button allows to modify the logon preferences. The locale default to US, so I changed this the British Flag and English. That made me feel very patriotic! A little bit later on I adjusted the Power Save Delay because the Pano was sat a logon screen for long times whilst I did the server side stuff.
Once these were checked off my list I could start to look at giving my Pano Device access to the virtual desktop….
As with VMware View, I started of with a very basic setup – where I can just test that an ordinary user can connect without errors to the “base” image. Once I’m happy they can, I blow away this temporary “publish” of the desktop – and then convert the virtual desktop into a template or a linked clone (in the case of VMware View). There’s no point in creating a gizzlion VMs without first checking you can connect.
The Pano Manager has the concept of DVM (Desktop Virtual Machine) Collections – this just fancy word for a group of VMs in a virtual machine folder or datastore in the vCenter. The Pano Manager can be pointed at existing VMs and create VMs (using your templates and guest customizations). You basically click the DVM Collections Tab, and click the Add button. The General Tab you set what type of DVM you want, a friendly name, and browse to a folder or resource pool where your virtual desktop(s) reside. The Access Tab allows you handle the ACL issues – so you can allocate the virtual desktop(s) to the user(s). I think some planning on how you lay out your folders/datastore would be VERY important if you were wanting to use Panologic in production – in fairness I would say this about ALL VDI solutions including VMware View (in fact especially for VMware View as it hates having many aspects of vCenter being changed!)
By far the most interesting aspect of this – is the “Type” option as this will give you some idea of what Pano Manger is capable of brokering:
As you can see I used the template was creating as the source held in the folder /NYC DataCenter/vm/_Templates – called Administrator’s Desktop and allocated (guess who!) the Administrator to the desktop. This worked just dandy from the Panologic Device. Once a user is connected you can see them in the DVM tab, it tells you the status of the session and who’s connected.
If there is serious network problem (I yanked the UTP cable out of the back of the Pano Device) the users device will flash-red in the bottom right-hand corner, and after a short while the screen will go blank. Just like RDP the session is kept open until the network outage is resolved and the client’s tab will show the Pano Device as “unreachable”.
Once the UTP is reconnected the LED will blink orange, and then go solid blue. The solid blue indicates the Pano Device is connected to the Pano Manager. The user is returned to logon screen with a pop-up message indicating there session was disconnect, all they need to do then is re-login and carry on working. Additionally, by default the screen resolution settings defaults to 16-colours, using the Pano Control Panel you (as the administrator) can change this to be 24-bits. It does require a disconnect to take affect – on top of this are some use-experience controls on the properties of the DVM Collection.
Panologic does have a protocol of its own for remote screen delivery – but don’t expect a PCoIP/HDX/RemoteFX experience. The Panologic solution also contains firewall traversal system which piggy-backs of a Microsoft RDP Gateway for external users – this is compatible with both the Panologic Device, additionally you can use a client for Windows, so someone from a PC can remotely connect to the virtual desktop. Its for this reason that I see Panologic and zero-client like it as ideal for call-center, factory floor or high-security environment where you want a stateless VM, however it seems clear that the rest of industry is pursuing a high-octane graphic experience for remote users. I think a lot depends on the applications your delivering to end-users – I think PCoIP, HDX and RemoteFX are brilliant – but should your call-center users be really browsing youtube.com when they should be working? YES. I know there are usage cases where high-graphics rendering is needed, but does that represent the “dilbert” style user who uses standard applications?
The other thing worth mentioning is that because the Pano Device doesn’t use RDP to make the primary connection some of the restrictions you see in RDP (shutdown options are limited for example) – don’t apply. So you WILL need the right GPOs to stop users shutting down or hibernating their virtual desktops. Try to see it like you have just cranked up the VMware Console, and logged in as ordinary user. Chances are though – is that you probably have these GPO’s in place already…
Anyway, once I was happy with the basic functionality – I converted my Panologic virtual desktop to template in vCenter, and set about looking at the deployment options for creating pools of desktops, and I also removed the test DVM Collection that I had created as part of my test. Pano Manager’s own deployment options are very similar to VMware View without the Linked Clone feature. You basically set what type of desktop you want – do you want pool where the user always returns to the same desktop, or one where they grab a desktop from the pool and hand it back after logout. VMware called this persistent/non-persistent or dedicated/floating desktops. Additionally, like View without Linked Clones, Pano Manager use your templates together with your “Guest Customization Settings” to start creating new virtual desktops and joining them to your respective domain(s). These settings are held in the “Deployment” Tab:
NEW: This above dialog box is VERY important – especially the “Advanced Options”. You really have to expand this option otherwise the Pano Manager will put your virtual desktops in any old storage location in any other resource pool! I think the Pano Logic guys really need this part of the process mandatory – I was surprised you could get away with just specifying the other fields above “Advanced Options” without specifying the rest.
The “Capacity” Tab then allows you to set the quantity of virtual desktops you want to create.
As you can see this is going to create 10 virtual desktops right off the bat, keeping only two powered on initially – ready for clients to connect – and virtual desktop not in use after period of time, will be powered off. That’s all well and good, but not especially sophisticated. If you running on vSphere4 you can keep the disk cost of this down by using thin virtual disk, and deduplication if you have on your storage layer. The deployment process is only as fast as you storage and pipe on the ESX host, as it pulls down the template, and pushes it to the datastore. One nice touch of the Pano Manager, is that it gives a status on the progress of the creation of these VMs, something that VMware View doesn’t bother to do:
So where next for Panologic. Well, I think they will be looking to be virtualization vendor neutral – so I wouldn’t be surprised to see their next version will support Citrix XenDesktop and Microsoft Virtual Desktops. Also I would like to see much close integration to VMware View (and others). I would like a situation where when you create a desktop pool in VMware View, these are somehow “imported” into the Pano Manager – together with the permissions rights which you could later modify. Right-now if you create a desktop pool in VMware View, you then have to define a DVM Collection to allow your Panologic users access.
Anyway, I’m hoping to have the Panologic guys on a chinwag sometime soon – so I can learn more – and I will let you know what the girlfriend thinks once her 3 month trial period is over!