Azure Storage Explorer and upload of VHD RRS feed

  • Question

  • When I download and then upload a managed OS disk, using ASE, without making any changes locally, and then attempt to swap the OS disk on the VM the disk originally came from, to the uploaded disk, I get an incorrect Hypervisor Generation error. Is it possible, that on the upload, that ASE is not creating a Generation 2 managed disk? Is the only work around to use Powershell to upload the VHD?


    Monday, April 6, 2020 12:06 PM


All replies

  • Use AzCopy v10 to upload your local VHD file to a managed disk by specifying the SAS URI you generated. You may also refer to the suggesstion mentioned in this article: https://docs.microsoft.com/en-us/azure/virtual-machines/windows/disks-upload-vhd-to-managed-disk-powershell 

    Powershell script is the best option to upload to Azure.

    Upload VHD file to lab's storage account using Microsoft Azure Storage Explorer

    Hope this helps! 

    Kindly let us know if the above helps or you need further assistance on this issue. 

    Do click on "Mark as Answer" and Upvote on the post that helps you, this can be beneficial to other community members.
    Monday, April 6, 2020 2:16 PM
  • Thanks Sumanth. I appreciate your help.

    Is the posting of links to labs, the circa 2020 version of RTFM? 😊

    As always with Microsoft products, and particularly with Azure, there are many ways to achieve the same result. Searching always returns a number of different approaches, some unfortunately using deprecated or archived methods, for example AzureRM.

    The Powershell lab example does not mention the -HyperVGeneration switch on New-AzDiskConfig. You have to go here Support for generation 2 VMs on Azure FAQ.

    I believe that Azure Storage Explorer has not implemented this either, hence my problem. If I have time I will look at the code on GitHub.

    I am going to use ASE to upload the VHD to a storage account, and then the steps in the link regarding Gen 2, and hopefully that will see the problem resolved.



    Tuesday, April 7, 2020 10:53 AM
  • Okay!

    After many attempts, I was able to use ASE (AZCopy) to upload the VHD, create a managed disk from the blob using PowerShell, and swap to it for the VM. The VM started and I was able to logon to it.

    These were the changes I  made to get it to work:

    1. Upgraded the storage account to gen 2. 
    2. Ensured the VHD file name was all lowercase.

    I used New-AzDiskConfig with -HyperVGeneration "V2".

    I am uncertain if I can now delete the blob? It is not leased so presumably New-AzDisk has copied it?



    Wednesday, April 8, 2020 11:42 PM
  • @JonBeets Firstly, apologies for the delay in responding here and any inconvenience this issue may have caused

    Thanks for the update! and Azcopy solution helped in uploading the vhd file and able login

    Let me explain What is Azure Lease Blob? Is it just a mechanism which provides an exclusive lock to the blob storage?

    Your understanding is correct. When you lease a blob, you acquire an exclusive lock on that blob. As long as the blob is leased, no one other than lease holder can modify or delete the blob. You can either acquire a temporary lease, duration of which could be anywhere between 15 to 60 seconds or an infinite lease.

    Where can I use it?

    Most commonly this functionality is used by Azure Virtual Machines. As you know Azure VMs are backed by Azure Page Blobs. So when a VM is created, an infinite lease is acquired on the blob holding the VHD for that Azure VM so that no other process can modify or delete that blob.

    Yet another place where you would want to use lease blob functionality is when you want to implement Leader Election pattern.

    For example, consider a scenario where you would want to process a file stored in blob storage through a background Worker Role. Further assume that there are multiple instances of that Worker Role running where each instance wakes up after 30 seconds and checks for blobs in a container and if any blob is found that instance processes it.

    Since Azure Worker Roles are stateless in nature, without locking that blob each instance will process that blob (not something you would want). To avoid this situation what you could do is have each instance try to acquire a lease on that blob. Only one instance will succeed (and hence elected as leader). Other instances will fail to acquire the lock on that blob. The leader instance will process the blob.

    Another example would be where you want to distribute work in Competing Consumers where you would want to distribute work among them. In one of our products, we are using this pattern with Leader Election pattern. Through blob lease functionality, we find a leader (consumer which was able to acquire blob lease) and then this leader distributes work amongst other consumers.

    Hope this helps! 

    Kindly let us know if the above helps or you need further assistance on this issue. 

    Do click on "Mark as Answer" and Upvote on the post that helps you, this can be beneficial to other community members.
    Monday, April 13, 2020 11:51 AM
  •  Just checking in to see if the above answer helped. If this answers your query, do click “Mark as Answer” and Up-Vote for the same, which might be beneficial to other community members reading this thread. And, if you have any further query do let us know.
    Wednesday, April 22, 2020 5:24 AM