If you’re a Windows person, you probably don’t think much about Linux. The reality is that in the data center, Linux accounts for somewhere between 65% and 80% of all server deployments and growing. Among power users, developers, and security professionals, variations of Linux are making ever-increasing inroads as everyday operating systems. Even Microsoft has embraced this and included Linux as a full-fledged subsystem in Windows in the latest releases of Windows 10.

All this being said, one of the top questions asked by lab developers is “How do I create a great learning experience with Linux”? 

To understand why this is not as simple as just throwing Linux in a VM, we need to understand some of the limitations and challenges.

Distributions – There are literally dozens of distributions of Linux, based on different configurations and architectures. A comprehensive list is maintained on Wikipedia. The challenge is selecting the best distribution for your use case. Some distributions excel as administration tools. Some have quality desktop experiences, and others have rich console tools.  Availability of documentation, software, and updates all factor in.

Hypervisor Compatibility – Not all distributions of Linux work well as Virtual Machines. VMware and Hyper-V each maintain lists, with the list for VMware being maintained here and the list for Hyper-V here. Depending on your topic or technology, your selected distribution may not be on the list.

Cloud Compatibility – As with VMware and Hyper-V, Azure and AWS maintain a set list of Linux and Unix variations that they will deploy. For the most current list refer to Azure and AWS documentation. Azure documentation can be found here. AWS documentation can be found here.

Note: All Lab on Demand fabric choices support Debian 8+, including Ubuntu and Kali Linux, SUSE 11, Red Hat Enterprise Linux 6.4+, including CentOS.

Desktop Experience – This is perhaps the single biggest challenge for building labs that leverage Linux.  Both Hyper-V and VMware rely on console connections to present the desktop. While Windows-based VM’s excel in this configuration, Linux suffers. This is mainly due to Linux traditionally being a console based operating system, with the desktop experience being an add-on that most installations do not have. While VMware provides a reasonably good experience, this pain is particularly true on Hyper-V, where you can experience lag from typing, and moving a mouse in and out of the VM console is not 100% seamless. Finally, the experience can vary greatly from distribution to distribution. Where Windows VM’s can offer rich copy/paste, file transfer, and audio experience, this is lacking in Linux VM’s regardless of the platform.

Cloud Hosted – If you elect to deploy your Linux VM via AWS or Azure, the full desktop experience is not an option without much additional effort. Windows VM’s on these platforms offer an RDP and a one-click experience, however, Linux and its variations only offer console based Secure Shell (SSH). It is possible to add a desktop experience with additional steps, which we will discuss later. This leaves your default Linux experience as a shell only experience.

Optimizing Your Linux Learning

The good news is that with a little creativity, you can overcome many of the challenges and create some very rich experiences. These guidelines provided are suggestions based on things we have seen our customers do and experimented with ourselves. They are organized around the different types of learning experiences you may want to deliver, beginning with Cloud hosted Linux instances, and then moving to Learn on Demand Systems (LODS) data center-based experiences.

Linux on Azure with Console Access

This is the simplest configuration of Linux on Azure. You can deploy through the marketplace during the lab or deploy with an ARM template. Simply remember the following.

1.    A username will be assigned with Root access, that username must be all lowercase. “azureadmin” is a good example.

2.    Most templates and/or marketplace images will open port 22 for SSH access. If they do not you must remember to do this after your deployment or include the relevant instructions in your template.

3.    If deploying with a template, use a password instead of an SSH key. SSH keys are machine generated prior to deployment and must be included in the template, therefore they are not compatible with lab scenarios.

An example template which can be used as a reference can be found here.

Once deployed, to gain console access, you simply need an SSH client. There are several options for this. 

1.    In your lab, instruct users to navigate to https://shell.azure.com/bash to launch an instance of Azure Cloud Shell, which will contain a BASH console, which contains an SSH client.

2.    For Windows 10 users, instruct users to install the Windows subsystem for Linux. This includes an SSH client.

a.    Note that the Fall Creators updated includes a native OpenSSH client, which is accessible from the command line by typing SSH.

3.    Download any freeware SSH client such as PuTTY from www.putty.org.

4.    If your users are using Mac or Linux based operating systems, these include an SSH in the built-in console.

When your Linux instance is running on Azure, users will connect using these tools to the public DNS name of the instances Public IP. It is recommended you set this value using some variation of the lab instance ID.

1.    If including the public DNS name in an ARM template, include the domianNameLabel in the dnsSettings of the publicIPAddress. Set it to a value such as vm@lab.labinstanceid. This allows you to provide a resolvable DNS name to SSH to in the lab instructions.

2.    If asking the user to set the value during the lab, use a similar method to instruct the user to set an appropriate name value.


Pre-deploy Linux using a template. Generally, Linux only takes a few minutes to provision. Include instructions to launch Azure Cloud Shell to SSH into your VM. This provides a browser-only experience that does not require any locally installed software or clients.

Linux Desktop Experience on Azure

If your lab calls for running your Linux instance on Azure, and you need a desktop experience, you have two viable choices – RDP or VNC.


RPD uses the same protocol as Windows VMs use, however the steps are a little more involved. Note that some of this work can be pre-done and included in the image or deployed automatically using an Azure custom script extension. The general process is as follows:

1.    Deploy your Linux image using any method you wish, as described above.

2.    Install and configure a desktop package.

3.    Install and configure the xRDP package.

4.    Configure xRDP for automatic startup.

5.    Create a rule to enable port 3389 (remote desktop).

6.    Connect with a standard RPD client.

Microsoft provides a good guide on how to do this in the Azure documentation.


VNC is similar to RDP in many respects and is configured using a similar process. Our recommendation for lab experiences is to use RDP, so we are not going to elaborate on the configuration for VNC. That being said, this website provides a reasonably good overview.


In both cases, as you can see, there is significant work to gain access to a desktop so we generally do not recommend this path. If you require a desktop experience in Azure, consider using a Hyper-V or VMware based VM instead, either instead of, or in conjunction with other resources deployed on Azure.

Linux on AWS

We are still evaluating our recommendation for AWS and will update this document when those recommendations are completed.

Linux in LODS Datacenters

There are many reasons to run Linux in our data centers instead of on a public cloud fabric. For assistance in making this decision, see our “Choosing a Lab Fabric” platform selection guide. The reasons can be summarized as follows.

1.    Better overall customization of the initial experience.

2.    True instance isolation.

3.    Faster startup times.

4.    More control over costs.

Once you choose to run Linux in a data center, the next choice is the platform. Again, “Choosing a Lab Fabric” can help you substantially in selecting Hyper-V or VMware. For simplicity, the key decision points are as follows:

1.    VMware provides a better overall experience.

2.    Hyper-V provides better overall startup times and greater disk-management flexibility.

Linux on VMware

Linux on VMware is a seamless UI experience in our data centers. Setup the virtual machine as you would a Windows virtual machine and install the Linux operating system. Install and configure the desktop experience or desktop environment, and you are set. The virtual machine will boot to the desktop normally, and you can perform whatever tasks are required. Note the following:

1.    Copy/Paste works well in VMware environments. It is easy to copy commands from instructions and paste directly in a VM terminal window.

2.    Screen Resize – When the VMware tools are installed in the VM, the console window will automatically resize the size of your lab client window, ensuring the best possible experience.

The most important point is to remember to install the VMware tools for Linux. Step-by-step instructions to install VMware Tools can be found here.

Linux on Hyper-V

Linux on Hyper-V does not have the same seamless UI interaction that it does when run in a console session on VMware. Additionally, actions such as copy-paste and IDLx commands such as Type Text do not work as well, if at all. If you require a Linux VM on Hyper-V, here are some simple solutions you can apply:[/vc_column_text][vc_single_image image=”2044″ img_size=”full”][vc_column_text]

Linux and Enhanced Session Mode

Preview releases of Windows Server include support for Hyper-V Enhanced Session Mode for Linux VM’s. This updated feature provides an experience that is on par with VMware. Once this feature is released and fully tested within Lab on Demand, we will update our guidance accordingly. Initial testing has been very promising, and we believe will make the user experience for Linux for Hyper-V and VMware equal.


For best experience on Linux, we recommend the following:

1.  On Azure, use Cloud Shell as a browser-based SSH client.

2.  For desktop experiences relying on GUI and mouse input, use VMware until such time that Hyper-V Enhanced Session Mode for Linux is released.

3.  For desktop experiences relying on console, use either Hyper-V or VMware.  If the console relies heavily on copy-paste of commands, either use VMware, or if using Hyper-V, include a document INSIDE the VM which can be copied from.