Introduction
Today, there are still many organisations running old/legacy unsupported operating systems. This is because there are still many critical Line of Business (LOB) apps stuck on the XP/Windows 7 or even older. In this post, I will explore some of the challenges associated with older applications and the pitfalls of running these applications on a type two hypervisor.
What is a Type Two Hypervisor
The critical difference between type one (1) and two (2) is that type two hypervisor uses the software layer (application), whereas type one runs at the hardware level. As type two is an application that sits on an underlining Operating System, you can expect potential issues relating to latency. There are also security concerns that you should consider in regards to the guest OS. If you are running older/legacy OS’s, there is still a risk. If the guest OS is compromised, it could, in turn, compromise the host OS itself. Some may suggest using a software Firewall to add protection; however, this does not resolve any exposed CVE’s for that particular old OS and may not fully solve the security conundrum. The following article eludes to the challenge of Host infection from a guest OS.
Application Challenges today
As the Operating System (OS) version changes, updates and new build versions are released, these can impact the applications that reside on the OS. When migrating applications to a newer operating system, you can experience errors like missing files on application launch, dynamic link libraries, gated installers or missing installation files. Some organisations are still using 16-bit applications today; these can be a mixture of 16bit only or 16/32bit hybrid apps using mixed instruction set components. A common question I get asked, is “can we use 16bit on Windows 10 ?”. The answer to this is yes, you can. The following link shows Foxpro, a 16-bit application running natively on Windows 10 Multi-Session in Windows Virtual Desktop (WVD).
Taking a look at Qemu using Azure Nested Virtualisation
I wanted to explore the possibilities of using an open-source type two Hypervisor and came across Qemu. I understand this is used in the developer communities for emulating mobile device operating systems, ARM etc.
To run nested virtualisation on Microsoft Azure, you need to ensure you choose the appropriate virtual machine size. You can find out more about the supported versions here.
Before we started taking a look at running Windows XP on Qemu as a virtual machine, I wanted to point out that you cannot use Intel’s hardware acceleration in nested virtualisation on Azure, also known as HAXM.
The following link to Kunal Chandratre’s blog provides a good insight into the challenges with Hardware acceleration within a nested virtualised environment.
There is also an MSDN article confirming this, and you can find the link here.
So performance could be poor when trying to run applications inside a containerised Windows XP machine as it’s suggested that there is limited support for hardware acceleration to ensure the smooth running of the VM.
Running Qemu on Windows Virtual Desktop
To test the experience and performance of Qemu in Windows Virtual Desktop. I compiled, installed and configured Qemu and created a virtual machine. This was a 3GB Windows XP OS. This test aimed to see if I could launch multiple instances of the same VM as read only. This was also to understand what the actual impact to the Session Host would be.
After I had built the VM and configured the VM to launch as read-only, I ran 7 copies of the VM and opened the task manager to see the CPU utilisation. It was useable when running one Qemu VM but took a good 4 minutes to boot up fully. When running multiple Qemu VMs to simulate multiple users launching within their session, I found that the performance was terrible.
As you can see from the screenshot above, resource utilisation is high. Each VM consumes 20/30% of the VM CPU on bootup. This means that you would be limited to the number of users you could have per session host using a Qemu VM. If you have a mass number of users wanting to run Windows XP for specific apps, then there is a risk of what I call a” VM Session Storm”.
"VM Session Storm" in the context of Nested virtualisation is when several nested Virtual Machines are booted up by a single user or multiple users within a Multi-session environment. This causes the host performance to degrade, impacting the user experience and possibly impacting the use and function of the Session Host itself. Furthermore, this could also impact the Host in the backend Azure datacentre requiring you to use “redeploy” in Microsoft Azure.
Einstein once said, “The definition of insanity is doing the same thing over and over again and expecting different results.” Adding containers upon containers to get native performance does relate to what Einstein stated, madness.
Polishing a Nested VM
So how can we get the user experience to look as seamless as much as possible. This can be achieved by enabling kiosk mode. Similar to libraries and clocking in machines. It does not matter however you dress this up, its still a virtual machine. Its recommended that you carefully consider how you access files between the VM and the user session as opening up communication between the Host and Guest creates security risks. see the link to the eternalblue hack.
Running Microsoft Office 2003 on Windows Virtual Desktop
Can you run Office 2003 on Windows Virtual Desktop natively. Yes you can.
However, due to how the application has been written and the licencing pain points associated that many of the IT pros have experienced over the years. It is recommended that you create low cost persistent desktops in Windows Virtual Desktop and deliver Office 2003 as a remote app to the required users.
Summary
In this article, I wanted to understand more about nested virtualisation’s use case within Windows Virtual Desktop. I also wanted to understand if I could use Qemu to deliver older applications to Windows Virtual Desktop users. From the research and the testing I completed, I found some security risks, high resource consumption as your running an OS, and the intended application, which creates complexity. It was evident to me that you would be much better where possible running the application natively. When looking at applications with complications and some of the older limitations, there is a minimal niche requirement to run apps inside a VM with an older operating system. I recommend where possible, you should consider delivering the apps natively.
It was clear in my mind that using nested virtualisation in Windows Virtual desktop to deliver applications is a bad idea. You would be better of using low-cost persistent desktops with “Start VM on Connect” taking full advantage of Microsoft Azure’s pay as you consume model.
Ryan Mangan's IT Blog 