The following forum(s) are migrating to a new home on Microsoft Q&A (Preview): Azure DevTest Labs!

Ask new questions on Microsoft Q&A (Preview).
Interact with existing posts until December 13, 2019, after which content will be closed to all new and existing posts.

Learn More

 sticky
How to RRS feed

  • General discussion

  • I thought I would post a sticky thread with several "how to" posts to inform ways of fixing common issues I see. In some cases, we may have a bug fix or a feature change coming which will alleviate a problem. Given that it often takes days and sometimes weeks for a change to get to all production regions, I want to equip customers with tools to mitigate.

    Also, some issues are so uncommon that it is unlikely we'll put time into providing a more elegant solution. For those issues, knowing how resolve a problem is very important to some people.

    Each "how to" will appear as a reply to this sticky thread. When mitigation steps become obsolete, I'll delete the replies.

    Regards,


    David R. Williamson - MSFT

    Friday, April 14, 2017 8:47 PM

All replies

  • How to delete a VM schedule

    You may know that a VM can be created in a lab, and as such, inherits a lab auto-shutdown schedule.

    VMs not in a lab can also get an auto-shutdown schedule. You'll find this in the Compute Azure portal blade menu, under SCHEDULES | Auto-shutdown.

    This schedule can be enabled/disabled, but the UI does not provide a mechanism to delete. This can be done with a little PowerShell.

    Note: if you don't have the Azure PowerShell modules, you can get them by downloading it via the Web Platform Installer.

    1. In the Azure Portal, find the resource group in which the VM exists and find the shutdown schedule (usually easiest by clicking on the resource group name link in the Essentials part of the VM blade). The type will be "Microsoft.DevTestLab/schedules" and the name will start with "shutdown-computevm-".
    2. Copy the Resource Id to the clipboard
    3. Open PowerShell
    4. Login to Azure with "Login-AzureRmAccount"
    5. Select the subscription in which the VM and schedule exist with "Select-AzureRmSubscription -SubscriptionId <GUID>" where <GUID> is the subscription Id
    6. Run the command "Remove-AzureRmResource -ResourceId <RESOURCEID>" where <RESOURCEID> is the copied Resource Id from the properties blade in step 2.

    If you have any problems with this, let us know.

    Regards,


    David R. Williamson - MSFT

    Friday, April 14, 2017 8:56 PM
  • How to accelerate migration to a fully managed (storage) lab

    Until recently, DevTest Labs created 3 storage accounts with each new lab:

    1.        Standard storage for private artifacts and ARM templates caching (name prefixed with ‘a’)
    2.        Standard storage for VM OS disks, data disks, and custom images (name prefixed with ‘d’)
    3.        Premium storage for VM OS disks, data disks, and custom images – only used if the lab was configured to use premium storage (name prefixed with ‘p’)

    We knew early on that storage accounts were a potential limit for the number of VM OS disks that could be hosted on them due to IOPs limitations. Once too many VMs were running on the same storage account, the user experience on the virtual machines would degrade due to OS disk performance.

    So at one point we started seeing labs with enough VMs that we needed to start scaling up the storage accounts hosting OS disks. When your lab resource group ends up with more than the 3 storage accounts listed, that is because scaling logic came into play when a VM was created. All of these scale storage accounts are prefixed with ‘aas’.

    The Compute team realized this was a problem for many customers and planned a feature called Managed Disk. With it, you ask for managed storage to store a VHD and behind the scenes they do all the scaling, without the need for a customer-deployed and accessible storage account. We updated the lab to take advantage of this feature starting with new labs and later rolling out to all labs.

    New labs now only get 1 storage account created: the one listed above for artifacts, ARM templates caching, and non-sysprepped custom images.

    For classic labs, they still have all the storage accounts but we have implemented eventual migration. How this works:

    • New VMs are created with managed disk instead of in storage accounts
    • New sysprepped (aka for Linux deprovisioned) custom images are created using a Managed Image
    • New data disks are created using Managed Disk
    • When a new VM is created referencing a sysprepped custom image in a storage account, that custom image is first converted to Managed Image
      • The original VHD not be deleted. We decided to leave it in case of error and because some customer scenarios depend on keeping the VHD.
    • When a data disk is attached to a VM using Managed Disk, and that data disk was a blob in the storage account, it is first updated to Managed Disk

    This enables an eventual migration off of storage accounts for classic labs. However, for now at least, this still means the storage accounts will remain.

    One can check inside the storage account to see what VHDs remain, and if empty delete it. Lab will still have a record of that storage account, but should continue to work fine.

    Caveats:

    • If you delete the storage account that the lab still needs, it will disable the lab. You can identify this special storage account by the prefix. You’ve probably noticed that storage accounts take the name of the lab, but also have a 1-3 letter prefix. So if your lab name is ‘Foo’, do not delete the storage account whose name starts with ‘afoo’.
    • If you have non-sysprepped custom images, you will need to consolidate the VHDs to the artifacts storage account. The easiest way to do this is to re-upload the VHD as a new custom image (it will end up in the right place) and then delete the source custom image (which will also delete the source VHD).

    I know this has the potential to be quite a mess depending a few factors. This is still a work in progress for us. We wanted to deliver the new value to customers ASAP. I know some people may want to clean up storage accounts before we can get to the remaining user stories, so I thought I’d share the manual steps that would help one achieve that.

    Of course, if it is easiest for you to create a new lab and move all resources to it, then that works too.


    David R. Williamson - MSFT

    Thursday, April 27, 2017 1:38 AM
  • DevTest Labs .NET SDK

    We recently updated our .NET SDK, which is helpful if you wish to automate lab operations. You can find it at https://www.nuget.org/packages/Microsoft.Azure.Management.DevTestLabs/.


    David R. Williamson - MSFT

    Wednesday, May 17, 2017 6:07 PM
  • We have also uploaded a SDK Samples solution using the DTL SDK to our samples Azure DevTest Labs GitHub repo.

    Leo Vildosola [MSFT]
    Microsoft Azure DevTest Labs

    Friday, May 19, 2017 4:26 PM
  • How to use BYOA to create a virtual machine from a generalized (sysprepped/deprovisioned) Custom Image.

    1) Create a custom image in your DevTest lab.

    2) Copy the generated Managed Image id from the portal for the custom image

    3) Use the following settings in the deployment template for the 'storageProfile':

     "storageProfile": {
                        "imageReference": {
                            "id":  "managedImageId"
                        },
                        "osDisk": {
                            "createOption": "FromImage"
                        }
                    },

    Note: The managed image id copied should be used in the 'id' section above. It is of the format -"/subscriptions/<subId>/resourceGroups/<rg>/providers/Microsoft.Compute/images/<imagename>"


    Sindhu Nagesh


    Thursday, November 2, 2017 9:33 PM