| title | description | services | documentationcenter | author | manager | editor | ms.assetid | ms.service | ms.workload | ms.tgt_pltfrm | ms.devlang | ms.topic | ms.date | ms.author |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Azure DevTest Labs FAQ | Microsoft Docs |
Find answers to common Azure DevTest Labs questions |
devtest-lab,virtual-machines |
na |
tomarcher |
douge |
afe83109-b89f-4f18-bddd-b8b4a30f11b4 |
devtest-lab |
na |
na |
na |
article |
09/13/2016 |
tarcher |
This article answers some of the most common questions about Azure DevTest Labs.
[!INCLUDE devtest-lab-try-it-out]
- What if my question isn't answered here?
- Why should I use Azure DevTest Labs?
- What does "worry-free, self-service" mean?
- How can I use Azure DevTest Labs?
- How am I billed for Azure DevTest Labs?
- What are the different security levels in Azure DevTest Labs?
- How do I create a role to allow users to perform a specific task?
- Why can't I see certain VMs in the Azure Virtual Machines blade that I see within Azure DevTest Labs?
- What is the difference between custom images and formulas?
- How do I create multiple VMs from the same template at once?
- How do I move my existing Azure VMs into my Azure DevTest Labs lab?
- Can I attach multiple disks to my VMs?
- How do I automate the process of uploading VHD files to create custom images?
- How can I automate the process of deleting all the VMs in my lab?
- How do I create a lab from an Azure Resource Manager template?
- Why are my VMs created in different resource groups with arbitrary names? Can I rename or modify these resource groups?
- How many labs can I create under the same subscription?
- How many VMs can I create per lab?
- How do I share a direct link to my lab?
- What is a Microsoft account?
- My artifact failed during VM creation. How do I troubleshoot it?
- Why isn't my existing virtual network saving properly?
If your question isn't listed here, let us know and we'll help you find an answer.
- Post a question in the Disqus thread at the end of this FAQ and engage with the Azure Cache team and other community members about this article.
- To reach a wider audience, post a question on the Azure DevTest Labs MSDN forum, and engage with the Azure DevTest Labs team and other members of the community.
- To make a feature request, submit your requests and ideas to the Azure DevTest Labs User Voice.
Azure DevTest Labs can save your team time and money. Developers can create their own environments using several different bases, and use artifacts to quickly deploy and configure applications. Using custom images and formulas, virtual machines can be saved as templates and easily reproduced. In addition, labs offer several configurable policies that allow lab administrators to reduce waste and manage a team's environments. These policies include auto-shutdown, cost threshold, maximum VMs per user, and maximum VM sizes. For a more in-depth explanation of Azure DevTest Labs, read the overview or check out the introductory video.
"Worry-free, self-service" means that developers and testers create their own environments as needed, and administrators have the security of knowing that Azure DevTest Labs helps minimize waste and control cost. Administrators can specify which VM sizes are allowed, the maximum number of VMs, and when VMs are started and shut down. Azure DevTest Labs also makes it easy to monitor costs and set alerts to stay aware of how resources in the lab are being used.
Azure DevTest Labs is useful anytime you require dev or test environments, and you want to reproduce them quickly and/or manage them with cost saving policies.
Here are some scenarios that our customers use Azure DevTest Labs for:
- Managing dev and test environments in one place, utilizing policies to reduce cost and custom images to share builds across the team.
- Developing an application using custom images to save the disk state throughout the development stages.
- Tracking the cost in relation to progress.
- Creating mass test environments for quality assurance testing.
- Using artifacts and formulas to easily configure and reproduce an application on various environments.
- Distributing VMs for hackathons (collaborative dev or test work), and then easily de-provisioning them when the event ends.
Azure DevTest Labs is a free service, meaning that creating labs and configuring the policies, templates, and artifacts is free. You pay only for the Azure resources used within your labs, such as virtual machines, storage accounts, and virtual networks. For more information on the cost of lab resources, read about Azure DevTest Labs pricing.
Security access is determined by Azure Role-Based Access Control (RBAC). To understand how access works, it helps to understand the differences between a permission, a role, and a scope as defined by RBAC.
- Permission - A permission is a defined access to a specific action. For example, a permission could be read-access to all virtual machines.
- Role - A role is a set of permissions that can be grouped and assigned to a user. For example, a "subscription owner" has access to all resources within a subscription.
- Scope - A scope is a level within the hierarchy of Azure resource. For example, a scope could be a resource group or a single lab or the entire subscription.
Within the scope of Azure DevTest Labs, there are two types of roles to define user permissions: lab owner and lab user.
- Lab owner - A lab owner has the access to any resources within the lab. Therefore, they can modify policies, read and write any VMs, change the virtual network, and so on.
- Lab user - A lab user can view all lab resources, such as VMs, policies, and virtual networks, but they cannot modify policies or any VMs created by other users. It is also possible to create custom roles in Azure DevTest Labs, and you can learn how to do in the article, Grant user permissions to specific lab policies.
Since scopes are hierarchical, when a user has permissions at a certain scope, they are automatically granted those permissions at every lower-level scope encompassed. For instance, if a user is assigned to the role of subscription owner, then they have access to all resources in a subscription. These resources include all virtual machines, all virtual networks, and all labs. Thus, a subscription owner automatically inherits the role of lab owner. However, the opposite is not true. A lab owner has access to a lab, which is a lower scope than the subscription level. Therefore, a lab owner is not able to see virtual machines or virtual networks or any resources that are outside of the lab.
A comprehensive article about how to create custom roles and assign permissions to that role can be found here. Here is an example of a script that creates the role "DevTest Labs Advanced User", which has permission to start and stop all VMs in the lab:
$policyRoleDef = Get-AzureRmRoleDefinition "DevTest Labs User"
$policyRoleDef.Actions.Remove('Microsoft.DevTestLab/Environments/*')
$policyRoleDef.Id = $null
$policyRoleDef.Name = "DevTest Labs Advance User"
$policyRoleDef.IsCustom = $true
$policyRoleDef.AssignableScopes.Clear()
$policyRoleDef.AssignableScopes.Add("subscriptions/<subscription Id>")
$policyRoleDef.Actions.Add("Microsoft.DevTestLab/labs/virtualMachines/Start/action")
$policyRoleDef.Actions.Add("Microsoft.DevTestLab/labs/virtualMachines/Stop/action")
$policyRoleDef = New-AzureRmRoleDefinition -Role $policyRoleDef
If you are using VSTS, there is an Azure DevTest Labs Tasks extension that allows you to automate your release pipeline in Azure DevTest Labs. Some of the uses of this extension include:
- Creating and deploying a VM automatically and configuring it with the latest build using Azure File Copy or PowerShell VSTS tasks.
- Automatically capturing the state of a VM after testing to reproduce a bug on the same VM for further investigation.
- Deleting the VM at the end of the release pipeline when it is no longer needed.
The following blog posts provide guidance and information about using the VSTS extension:
- Azure DevTest Labs – VSTS extension
- Deploying a new VM in an existing AzureDevTestLab from VSTS
- Using VSTS Release Management for Continuous Deployments to AzureDevTestLabs
For other CI/CD toolchains, all the previously mentioned scenarios that can be achieved through the VSTS tasks extension can be similarly achieved through deploying Azure Resource Manager templates using Azure PowerShell cmdlets and .NET SDKs. You can also use REST APIs for DevTest Labs to integrate with your toolchain.
Why can't I see certain VMs in the Azure Virtual Machines blade that I see within Azure DevTest Labs?
When a VM is created in Azure DevTest Labs, permission is given to access that VM. You are able to view it both in the labs blade and the Virtual Machines blade. Users in the DevTest Labs role can see all virtual machines created in the lab through the lab's All Virtual Machines blade. However, users in the DevTest Labs role are not automatically granted read-access to VM resources that others have created. Therefore, those VMs are not displayed in the Virtual Machines blade.
A custom image is a VHD (virtual hard disk), whereas a formula is an image that you can configure with additional settings that you can save and reproduce. A custom image may be preferable if you want to quickly create several environments with the same basic, immutable image. A formula may be better if you want to reproduce the configuration of your VM with the latest bits, a virtual network/subnet, or a specific size. For a more in-depth explanation, see the article, Comparing custom images and formulas in DevTest Labs.
You can use the VSTS tasks extension or generate an Azure Resource Manager template while creating a VM and deploy the Azure Resource Manager template from Windows PowerShell.
We are designing a solution to directly move VMs to Azure DevTest Labs, but currently you can copy your existing VMs to Azure DevTest Labs as follows:
- Copy the VHD file of your existing VM using this Windows PowerShell script
- Create the custom image inside your Azure DevTest Labs lab.
- Create a VM in the lab from your custom image
Attaching multiple disks to VMs is supported.
There are two options:
- Azure AzCopy can be used to copy or upload VHD files to the storage account associated with the lab.
- Microsoft Azure Storage Explorer is a standalone app that runs on Windows, OSX, and Linux.
To find the destination storage account associated with your lab, follow these steps:
- Sign in to the Azure portal.
- Select Resource Groups from the left panel.
- Locate and select the resource group associated with your lab.
- On the Overview blade, select one of the storage accounts.
- Select Blobs.
- Look for uploads in the list. If none exists, return to Step #4 and try another storage account.
- Use the URL as your destination in your AzCopy command.
In addition to deleting VMs from your lab in the Azure portal, you can delete all of the VMs in your lab using a PowerShell script. In the following example, simply modify the parameter values under the Values to change comment. You can retrieve the subscriptionId, labResourceGroup, and labName values from the lab blade in the Azure portal.
# Delete all the VMs in a lab
# Values to change
$subscriptionId = "<Enter Azure subscription ID here>"
$labResourceGroup = "<Enter lab's resource group here>"
$labName = "<Enter lab name here>"
# Login to your Azure account
Login-AzureRmAccount
# Select the Azure subscription that contains the lab. This step is optional
# if you have only one subscription.
Select-AzureRmSubscription -SubscriptionId $subscriptionId
# Get the lab that contains the VMs to delete.
$lab = Get-AzureRmResource -ResourceId ('subscriptions/' + $subscriptionId + '/resourceGroups/' + $labResourceGroup + '/providers/Microsoft.DevTestLab/labs/' + $labName)
# Get the VMs from that lab.
$labVMs = Get-AzureRmResource | Where-Object {
$_.ResourceType -eq 'microsoft.devtestlab/labs/virtualmachines' -and
$_.ResourceName -like "$($lab.ResourceName)/*"}
# Delete the VMs.
foreach($labVM in $labVMs)
{
Remove-AzureRmResource -ResourceId $labVM.ResourceId -Force
}
Artifacts are customizable elements that can be used to deploy your latest bits or your dev tools onto a VM. They are attached to your VM during creation with a few simple clicks, and once the VM is provisioned, the artifacts deploy and configure your VM. There are various pre-existing artifacts in our public Github repository, but you can also easily author your own artifacts.
We have provided a Github repository of lab Azure Resource Manager templates that you can deploy as-is or modify to create custom templates for your labs. Each of these templates has a link that you can click to deploy the lab as-is under your own Azure subscription, or you can customize the template and deploy using PowerShell or Azure CLI.
Why are my VMs created in different resource groups with arbitrary names? Can I rename or modify these resource groups?
Resource groups are created this way in order for Azure DevTest Labs to manage the user permissions and access to virtual machines. While you can move the VM to another resource group with your desired name, doing so is not recommended. We are working on improving this experience to allow more flexibility.
There is no specific limit on the number of labs that can be created per subscription. However, the resources used are limited per subscription. You can read about the limits and quotas imposed on Azure subscriptions and how to increase these limits.
There is no specific limit on the number of VMs that can be created per lab. However, currently the lab supports only about 40 VMs running at the same time in standard storage, and 25 VMs running concurrently in premium storage. We are currently working on increasing these limits.
To share a direct link to your lab users you can perform the following procedure.
- Browse to the lab in the Azure portal.
- Copy the lab URL from your browser and share it with your lab users.
Note
If your lab users are external users with a MSA account and they don’t belong to your company’s Active directory, they may receive an error when navigating to the provided link. If they receive an error, instruct them to click their name in the upper-right corner of the Azure portal and select the directory where the lab exists from the Directory section of the menu.
A Microsoft account is what you use for almost everything you do with Microsoft devices and services. It’s an email address and password that you use to sign in to Skype, Outlook.com, OneDrive, Windows Phone, and Xbox LIVE – and it means your files, photos, contacts and settings can follow you to any device.
Note
Microsoft account used to be called "Windows Live ID".
Refer to the blog post How to troubleshoot failing Artifacts in AzureDevTestLabs - written by one of our MVPs - to learn how to obtain logs regarding your failed artifact.
One possibility is that your virtual network name contains periods. If so, try removing the periods or replacing them with hyphens, and then try saving the virtual network again.