This probably could be a much more scientific approach to a review or analysis of the accessibility of a Windows guest running on the ESXI hypervisor however, I don’t really have the time to write such a document at the moment. However, this will serve as verification to some that access to this environment is possible all be it in a limited way.
For the less technical people out there, basically what I’m talking about here is running a Windows computer inside a virtual machine.
You need a more basic description? No problem. Try this. Let’s say you have one large computer. Virtual machines are machines that run inside this big computer. Think about it as if it was a building. This building might have ten different companies. True, each company could probably have its own building but there’s no need. It only needs a certain amount of space. An entire building would be over kill. So, the one building hosts all of these guest companies. Just like one large server can host dozens or hundreds of virtual machines be those workstations that users work with or servers that run the companies IT systems. Having one building hosting all these smaller companies cut down on the space required the cost of maintenance and the cost of power. When you hear the word hypervisor, I am basically talking about the building or the large server that hosts all the virtual machines or companies. When I talk about a guest, I am talking about the companies in the building i.e, the virtual machines. Get it?
- Building = Server / Hypervisor
- Company = Guest or virtual machine
Ok. I’m glad we have all of that cleared up. You can take a break for a few seconds before I move on to the next part because it’s going to get a little technical again. Don’t worry. You’ll understand it now that you have a grip of the basics.
For one reason or another, I spent some time yesterday tackling the problem of how a blind person can independently and efficiently access a Windows 7 PC that has been virtualized using a thin client. A thin client for those of you who aren’t aware of the term is a basic PC. It has very limited storage, limited RAM and a low power processor. The idea of this machine is to give a user a platform from where they can access a virtual computer. All it does is start a cut down version of Windows and provide the user with a log in box to start their virtual system.
There is one barrier to accessibility when using thin clients. No additional software can be installed ordinarily as there isn’t enough space to facilitate it. This means installing a screen reader isn’t an option. Even a pen drive version of Jaws won’t work because it requires the installation of a mirror driver. Fortunately, NVDA will work very well. Just download the portable version and run it. If I was to make one suggestion it would be to put NVDA to sleep automatically when the PC over IP or the RDP client started as it can get a little confusing when modifier keys such as caps lock are pressed. I know this can be done using scripts though and it is something I would look at doing if I was using this as my workstation every day.
So, you can now use the thin client to log into your workstation. That’s the first hurdle out of the way. Now what?
With VMware you can log onto virtual machines using two protocols. RDP which is Microsoft’s remote desktop protocol or PC over IP which is the protocol used by VMware. PC over IP is more efficient for a number of reasons but in later versions of RDP Microsoft have gained some ground. I won’t explain the benefits over PC over IP in this post but very quickly, PC over IP is less bandwidth intensive so the experience of remotely using a virtual machine is a little smoother.
You’ll be happy to know that relaying sound back to the thin client is supported by both of these protocols however you won’t get instant feedback like you would if sitting at your own PC. The delay is in the realm of about fraction of a second but if like me you expect instant responses from a screen reader this fraction of a second may as well be an eternity.
Relaying sound back to the thin client is very important. Jaws, my preferred screen reader crashes every time it is started in a virtual machine using the PC over IP protocol. Without fail, it refuses to run. NVDA on the other hand runs very nicely in a virtual machine using the PC over IP protocol. Of course, using NVDA sound mapping to your thin client is vital which is why I made the point earlier.
Unfortunately, there you have it. What I’m saying in a very long winded way is, yes, you can access a virtual machine using a thin client if you’re stuck but I wouldn’t think it’s usable every day. The sound lag is just too pronounced. NVDA’s ability to work in this environment should however be recognised and commended. Jaws, a leader in screen reading software seems to fail badly.
Please don’t’ take this as an endorsement or a criticism of any screen reader. I am simply stating what I have found to be the reality here. I have written this post to highlight this area and to show that improvement is required. More and more organizations and companies are moving to virtual desktops to replace physical machines as they provide significant cost savings. I have a genuine fear that assistive technology companies are not aware of this trend and blind computer users such as me will be left clambering to keep up with my sighted colleagues. I strongly believe that it is vital that companies such as Freedom Scientific, NV Access and GW Micro listen to users and when possible, utilize their experience and expertise. I for one offer it freely.
Systems used are:
- ESXI 5.0
- VMWare view 5.0
- Windows 7 X64 and 32 bit.
- Thin client running a cut down version of Windows XP.
- 1GB network connection.
- Virtual machine had two processors and 4GB of RAM.
- Thin client had 1GB of RAM and 1 processor at 1.5GHZ.
I should finally note that I do not see RDP as a viable solution for accessing virtual machines using a thin client. Especially for screen reader users. If by some stroke of luck you get Jaws running on your thin client, you would then use Jaws on your virtual machine to tunnel the data back to your locally running instance of Jaws on the thin client. That’s fine, however, what if like me your a system administrator and you will need to establish connections to other remote systems from your virtual machine. You will not be able to use Jaws to establish a second or third connection as you are already using jaws through one RDP session. Drawing on an article from IBM this seems to be a viable solution for some researchers however from the perspective of someone who both administers and uses a virtual environment every day, I would not be able to depend on RDP due to this limitations. PC over IP is a protocol designed and optomized for he VMware virtual platform. We should be able to use it.