It’s been almost a year since DevTest Labs general availability announced at //Build last year! As a very self-motivated and agile team, we always keep exploring more opportunities to build solutions that solve our customers’ real problems in Dev/Test workloads management through a cost-controlled self-service sandbox. As Microsoft Build 2017 happening now in Seattle, I would like to take a moment to look back all the functionalities we’ve shipped since the Connect() conference last November, and explain how they can help you in various scenarios. To see a live demo of these features, please check out our video session at Build 2017: Azure DevTest Labs Updates.
Before we jump into any new features, please allow me to expand a little bit on the scenarios we are targeting with DevTest Labs:
- Developer machines
- Test environments
DevTest Labs makes it very easy for IT teams to enable a cost-controlled self-service environment for developer teams, including a set of out-of-the-box cost control policies, visibility to lab spending and projection, and various options to set up labs. Developers have the flexibility to quickly compose their own development machines on demand by using the reusable templates (such as Azure Marketplace images, custom images, formulas, and Azure Resource Manager templates) and artifacts under the policies defined by the IT team. The needs are satisfied from both IT teams and developers. The IT team gets the control, and developers are happy about the agility.
You can test the latest version of your application by quickly provisioning Windows and Linux environments using reusable templates and artifacts. DevTest Labs provides a rich set of REST APIs (including a .NET SDK), CLI commands and pre-made VSTS tasks that help you to easily integrate with your deployment pipeline to provision on-demand environments. You can also scale up your load testing by provisioning multiple test agents in the lab. Once the testing is done, you can also create your golden image from testing machines and make the image available immediately for all the lab users through a single step.
In addition to Dev/Test environments, you can also create pre-provisioned environments for training and education. In the classroom scenario, a set of identical VMs are created in a shared VM pool before the class starts. Students in the class simply click a button to get a VM as needed. All the VMs can be automatically cleaned up after the class. Check out this guidance for more details: Use labs for training.
Similarly, in the trial/hackathon/demo scenario, lab users pick a machine from the VM pool in DevTest Labs as needed. Once the event is over, the lab can automatically clean up all the VMs for the next event.
What’s new since last November
Now let’s go through the key new features, including:
- Managed disks support
- Claimable VMs
- Batch creation of identical VMs
- VM auto-expiration
- Shared public IP address
To see a live demo, please check out our Build 2017 video session: Azure DevTest Labs Updates.
The first big thing we’ve shipped recently is to support Managed Disks in the creation of VMs, custom images and data disks in DevTest Labs. As its name indicates, all managed-disk resources are automatically managed by Azure instead of your own storage accounts. It’s optimized scalable VM deployments and management.
Before this support, because of IOPS limits in a single storage account, for optimal performance, DevTest Labs create VM OS disks in additional storage accounts when there’re already many VMs using the same storage account. However, creating VM from a custom image VHD in a different storage account can take a long time, usually around 40-60 minutes. In order to optimize the VM creation performance, the same custom image VHD was replicated to all the new storage accounts.
With Managed Disks support, this flow is significantly simplified. The experience of creating VMs, custom images and data disks keeps the same; however, DevTest Labs no longer autoscale storage accounts for large-scale VM deployments as all the VMs are created from the same managed custom image.
Another key experience we’ve enabled in DevTest Labs is called “claimable VMs“. Lab admins can prepare VMs and put them in a shared VM pool. Lab users can then pick (aka. “claim”) a VM from the pool for them to use without spending any time to create it from scratch.
This is very helpful for a couple of different scenarios:
- In test scenarios, claimable VMs that are installed with the latest build for testing can be generated automatically from the release pipeline. Developers and testers can then claim VMs with their desired build from the pool for further testing or validation without waiting for VM provisioning.
- In training/education scenario, claimable VMs make it easier for trainers and teachers to get all VMs ready before a class. Because all the VMs for the same class are identical, students can ask the lab to pick a random VM from the pool for them at the beginning of the class.
To create a claimable VM, you select Yes under Claim options in the advanced settings when you’re creating a VM from the Azure portal. If you deploy lab VMs through Azure Resource Manager templates, you can create a claimable VM by setting the allowClaim property to true in the properties section.
After a claimable VM is created, it appears in the Claimable virtual machines list at the bottom of the lab’s Overview blade.
In order to save the cost of the VMs in the claimable pool (i.e. they are not in use yet), claimable VMs are automatically shutdown at creation. Once claimed, the VM will automatically start up and appear in the user’s My virtual machines list.
Batch creation of identical VMs
It’s very likely that you want to create multiple claimable VMs that are identical, so that different lab users can claim their own VMs with the same configuration (e.g. testing the same build, VMs for students in the same class, etc.). DevTest Labs supports creation of multiple identical VMs from the same VM image and artifacts all at once. The only additional thing you need to do is to provide the number of VM instances in the advanced settings when you create a VM. Of course, the VM quota policies set at the lab level still applies regardless how many VMs you are going to create.
In the case you want to automate VM retirement, e.g. claimable VMs should be thrown away after an amount of time, DevTest Labs also gets you covered. In order to make VM clean-up easier, now you can also set expiration date/time when you create a VM. At the specified expiration date/time, DevTest Labs automatically delete the VM. This capability enables you to fully focus on creating the right VM without taking any extra effort later to manage the VM retirement.
Shared public IP address
In the case that a lot of public-facing VMs need to be created in a lab, DevTest Labs provides a solution to share the same public IP address with those VMs. It can help you reduce cost and avoid exceeding the public IP address quota in your Azure subscription.
When creating a VM, what you need to do is simply choosing an IP configuration option to use a shared public IP address, and the Labs will do all the remaining work for you.
Once a VM uses a shared public IP in the lab, it will be automatically assigned to a unique port number, which will be used together with the shared public IP address when you connect to that VM. You can see which IP address and port number to use from the Essential section on the selected lab VM’s page. Or, for Windows VMs, just click the Connect button on top of the page to get a RDP file that contains all the required info directly.
For lab admins, in the case VMs in your organization shouldn’t be accessible through the Internet, DevTest Labs provides flexible settings to define which IP address configuration is allowed in the lab. In the lab’s Virtual networks settings, lab admins can select the virtual network and the subnet to change the options that lab users can use, including whether the subnet can be used in this lab for creating VMs, whether shared public IP is allowed, and whether each lab VM is allowed to be created with an exclusive public IP address.
In addition to the features highlighted above, there are also several small enhancements we’ve shipped to make your life easier, including the capability to set auto-shutdown for a single lab VM, export lab VM usage data for reporting, and an initial set of Azure CLI commands that allow you to manage your lab VMs.
In addition to all the things we’ve shipped, there are still many more things in our roadmap that we can’t wait to build and ship to our customers. Your opinions are valuable for us to deliver the right solutions for your problems. We welcome ideas and suggestions on what DevTest Labs should support, so please do not hesitate to create an idea at the DevTest Labs feedback forum, or vote on others’ ideas.
If you run into any problems when using the DevTest Labs or have any questions, we are ready at the MSDN forum to help you.