Scenarios using the Claim capabilities in DevTest Lab


The Azure DevTest Lab service is useful in helping improve effectiveness  and efficiency of developers and testers.  There are advanced features available that move DevTest labs from a simple VM management tool to much more.  This post focuses on the ability to claim or un-claim virtual machines in Azure DevTest Labs and the various ways that this feature improves the user experience.  Before we dive into the different scenarios where this feature may be used, let’s look at what ‘claiming ’ is and how it works.

Claimable machines

A claimable machine is a virtual machine that is created in a lab without an owner.  Once the machine is claimed, the user has a full range of options for that VM.  When a user claims a machine a few changes are made, the VM is moved from the claimable VMs list into the 'My virtual machines' list in the UI.  The following capabilities are enabled for the user: to connect to the VM, customize artifacts, restart, stop, or un-claim the machine. There are a couple of ways to make a VM claimable, either by creating the machine and un-claiming it so that it moves to the claimable pool, or a VM can be created and placed in the shared pool using the advanced settings.

There are two cases where the claim/un-claim capabilities can be used effectively.  The first case requires more forethought and planning, to be designed and executed properly, the second is more situational.  The following are some examples of the different cases.

Designed use of claimable machines

  • Software development / testing: Allow developers or testers to be more productive by having configured machines ready and in an unclaimed state.   Having a set of VMs with different configurations, the necessary tools, and with the latest code allows users to claim a VM and begin work without having to spend the time to setup a machine.   Before the VMs have been claimed , the machines are provisioned but are shutdown minimizing the cost of having machines that are used less often, like specific languages.  When the VMs are needed the users simply claims the VM  which starts the machine.  The un-claim option isn't as useful in this case since creating a new VM is often easier and cheaper.
  • Classroom / Labs: Have VMs preconfigured for a class or lab, so that students can immediately connect to a machine using the Azure Portal.  Once a student claims a VM, the lab ensures that no one can claim the same machine.  Automating this process ensures that the required number of machines with the specified environment are available.  If not all of the students show up or are running late, the un-claimed machines can be kept available until the session is over with minimal cost.  The un-claim option isn’t as effective in this scenario since the VM is in an unknown state when the previous user is done.
  • Demonstrations: Use the machines for demonstrations, where the machines in the lab are setup with specific environments.  This capability is useful where multiple people may be giving a demonstration at the same time or at random times, such as at a conference.  The un-claim option may be useful in this situation as the demo shouldn’t change the state of the machine, allowing users to return a VM back to the claimable pool for the next demonstration.  With the unclaimed machine being deprovisioned and incurring minimal cost, the VMs can be left in the lab for longer time periods.
  • Temporary / Contract workers: Allow the users to use a machine, then when they leave they return the VM to the claimable pool without loss of data.  With the VM unclaimed, another user can claim the VM and continue or review the machine for additional information.
  • In General: The ability to have a sole source automatically configure and deploy VMs, on a specific cadence, is useful in many different situations.  There are several different situations where the 'claim' / 'un-claim' will help users be more efficient by having an automated process to build the DevTest Lab VMs in an unclaimed state with a set configuration.  The configuration(s) may include different operating systems, languages, disks, or other software (artifacts) depending on the different needed environments.  The ability to claim a VM or use the 'claim any'  from the lab allows the lab user to get a properly configured system without spending the time or effort in machine configuration.  The lab manager could use the claimed state of the VMs to improve the number of machines generated, clean up machines, and determine priority of configurations. The Image factory is a good example of an automated process to build VMs and images for multiple labs.  The scripts could be modified to execute any of the following situations with the appropriate changes or be used as a reference for creating a custom system.

Situational use of claimable machines

  • Use the claim/un-claim capability allows users to pass control of machines from one to another with minimal fuss and not having to know explicitly who will be picking up the machine next.
  • Development, testing and debugging of a scenario where a specific machine configuration can reproduce a bug then the machine can be unclaimed allowing another developer can claim the machine and continue the work.  This is especially useful as more people are working remotely in different areas of the world, being able to “pair” program from different time zones could be useful.
  • Being able to work with a single environment between multiple team members.  Examples of this situation could be manually setting up a complex environment that can’t be automated  or creating resources that can only handle modifications for a single input like images.  In the past this was dealt with by having a dedicated machine up and running and a process tothat would be handed off to different users.  The claimable feature is an improvement over the manual process by having built-in user access control, visual identification when available, and when un-claimed the VM is deprovisioned reducing costs.
  • Have a data disk attached to the VM, each disk up to ~ 1TB of data, allows  a large volume of data to be passed without having to copy or duplicate the data.  The VM would be  initially created with an attached disk that had  the large volume of data.  Any user could  then claim the machine and access the data.  When done un-claim the VM to allow other users to the machine.

There are some caveats to using the claimable machines, most commonly around gaining access to the machine.  If the machine is domain joined then the user claiming the machine will need to have already been granted access, usually this is done by granting access to a group that encompasses all users in the lab when the VM is created.  If the machine isn’t domain joined, the “Reset VM Password” artifact in the public repository will need to be run to add the user as an administrator.  Artifacts can be applied even after the machine has been started or claimed.

If you come across other situations where the claim\un-claim could be used, feel free to add them to the comments.

If you have any questions about DevTest Labs, please check out the MSDN forum.

Hope this helps.

Roger Best, Senior Software Engineer

Roger is part of the Visual Studio and .NET engineering team focused on Visual Studio and Azure customers.  He has been at Microsoft for 20 years, focusing on developer technologies for the past decade or so.  In his spare time, he watches too many movies, and tries to survive triathlons.

 


Comments (0)

Skip to main content