Copying VHDs locally to machines in Azure
This was from when RemoteApp didn’t support creating an image directly from VM.
- A1 Std machine, copying a 127GB VHD to a local drive (not temp D:\) via azcopy took 6.5 hours
- A4 Std machine, copying a 127GB VHD to D:\ via azcopy took 5 mins 20 secs
- A4 Std machine, copying a 127GB VHD to D:\ via save-azurevhd took 10 mins 39 secs
- A4 Std machine, copying a 127GB VHD to a local drive (not Temp) via azcopy took 25 mins 21 seconds
- A4 Std machine, copying a 127GB VHD to a local drive (not Temp) via save-azurevhd took 52 mins 11 seconds
Copying files into a VM via the two commands is very CPU intensive due to the threading it uses, so utilize a larger box no matter your method. And the hands down winner is to use Azcopy into the local temp D:\ (avoids an extra storage account hop). However, if you want a status bar, utilize save-azurevhd.
Copying VHDs between Storage Accounts
Due to a storage cluster issue in AU East, it has been advised to create new storage accounts and migrate VHDs to the new storage accounts. MSFT had provided us with a script, but it was taking hours/days to copy (and kept timing out).
Instead, we spun up a D4v2 machine in the AU East region, and I was able to have 6 azcopy sessions happening all at once with the /SyncCopy command. Each was running >100MB/sec whereas other async methods were running at <5MB/sec. You will see a ton of CPU utilzation during this, but the faster the machine, the better. Additionally, azcopy supports resume. To allow multiple instances of azcopy to run on a machine, utilize the /Z:<folderpath> switch for the journal file.
Stop Azure Blob with Copy Pending
Prior to getting all our copies going with the /SyncCopy, we had a few that were running async. Unfortunately, after stopping that with a CTRL-C and having azcopy stop, the blobs still had a copy pending action on them. This resulted in errors when attempting to re-run the copy with /SyncCopy on a separate machine: HTTP error 409, copy pending.
To fix this, you can force stop the copy. As these were new storage accounts with only these VHDs, we were able to run it against the full container. However, MSFT has an article on how you can do it against individual blobs.
Set-AzureStubscription -SubscriptionName <name> - CurrentStorageAccount <affectedStorageAccount> Get-AzureStorageBlob -Container <containerName> | Stop-AzureStorageBlobCopy -Force