I have some questions regarding Azure Managed Disks.
To my understanding, when a VM with managed disks is created the disks are in a Storage Account found suitable by Azure. The chosen Storage Account might not even be inside the same resource group as the VM.
What happens when I try to delete a Storage Account which has VHDs of managed disks inside it?
What happens when I try to delete a Resources Group with Storage Accounts which has VHDs of managed disks?
Our flow, of dev/test, requires many Resource Groups and many Storage accounts. We need a way to both work with Managed Disks and be able to delete old Resource Groups with their Storage Account. Is this possible?
I'm posting the the response I've got from Azure support, in case this helps someone in the future:
Managed disks are a managed service provided by Azure so that customers do not have to concern themselves with certain performance considerations, such as the amount of IOPS coming into a standard storage account or how many VHDs are being stored in one. When a managed disk is created, it is stored in an Azure storage account on the backend that is not accessible by the customer. The customer never receives the name of the storage account or the disk URI of where the underlying VHD is housed. A managed disk should be created into a resource group of your choosing, however, and can be deleted just like any other resource in it. To answer your questions, I will list them out:
What happens when I try to delete a Storage Account which has VHDs of managed disks inside it?
Managed disks are not stored in storage accounts managed by customers, so this will not be a scenario a customer must consider. This is only for unmanaged disks. All of your storage accounts will only house unmanaged disks.
What happens when I try to delete a Resources Group with Storage Accounts which has VHDs of managed disks?
Managed disks will delete just as any other resource would in a resource group. When they are deleted, the underlying VHD is simply removed from the backend storage account in Azure.
Our flow, of dev/test, requires many Resource Groups and many Storage accounts. We need a way to both work with Managed Disks and be able to delete old Resource Groups with their Storage Account. Is this possible?
You can definitely make this work with managed disks, I believe. Just treat the managed disks as their own entity and don’t worry about the underlying storage accounts on the backend. No storage accounts are needed on your end to have managed disks. Managed disks were created to simplify the management of the VHDs and storage accounts for virtual machines. If the managed disk exists, know it is being housed and managed on the backend appropriately. Delete managed disks as needed with resource groups, just like any other resource.
What happens when I try to delete a Storage Account which has VHDs of
managed disks inside it?
The storage account that Azure uses to place VHDs for the managed disks is transparent to you. In fact, you can't even see it using the portal or Storage Explorer, so you would not be able to delete a storage account that has your VHDs for managed disks.
What happens when I try to delete a Resources Group with Storage
Accounts which has VHDs of managed disks?
They are removed.
We need a way to both work with Managed Disks and be able to delete
old Resource Groups with their Storage Account
Yes.
Related
According to Microsoft documentation. there are managed disks and unmanaged disks. Managed disks are something managed by microsoft. All the VHDs are stored as page blob in storage account.
Question: When I create a linux VM with additional disk I don't see storage account created in resources list. I dont see storage account created when VMs are created for both OS disk and Data disk. I really appreciate if some one answer this.
Storage account and VM Disks are 2 separate things ?
There's a Storage Account and Page Blob behind the scenes but they are kind of hidden from you. When the disks are managed, the necessary infrastructure is created and managed by Microsoft so that you don't have to worry about them.
This is the reason you don't see any Storage Account and Page Blobs in your Azure Subscription for managed disks. You will see them only when your disks are unmanaged as then you are responsible for the management of these resources.
Please see this link for a nice comparison between managed and unmanaged disks: https://learn.microsoft.com/en-us/answers/questions/3619/what-is-the-difference-between-managed-disk-and-un.html.
I have create more than 3 storage account and 3 VM and 3 Clusters.
Storage Accounts:
Storage Account 1
Storage Account 2
Storage Account 3
I want to know Storage Account 1 is associated with how many VM and Clusters. How can I find it via Azure Portal ?
A storage account isn't an "owned" or "dedicated" resource. That is, even if you use a storage account for a given app or service, there's no tight coupling between the two. Any service / app that has your account credentials (or a SAS link to a specific container/queue/table within your storage account) will be able to use that storage account.
However, if you look at the settings for a given app or service (in your case, your VM or HDInsight), you can see which storage accounts it's using, with a bit of digging. For example, your VM might have both OS and Data disks, with each disk using potentially a different storage account - you'd need to enumerate the OS+attached disks to see which storage accounts are in use for each.
Further, if you create all resources at once (again, imagine creating a new VM with new storage), all of your resources will be bundled together within the same Resource Group.
You can via the new Azure portal to find the Azure Storage Account, in the storage account, you will find the Container. The vhds container used for Azure VM by default, select the vhds, you will find the VMs' VHD files there. About the HDInsight, the default Container name is the HDInsight name, so we can find the result manually.
I'm using Azure VM (Ubuntu 16.04) as web server. For some reason at my resource group for VM there are two storages.
First - GRS Standart and second LRS Premium.
How to determine which storage is necessary for my web server and which I can safely delete?
You can check the storage account holding the disks (OS and Data disks) by clicking on Disks option and then clicking on individual disks. You will see the URL of the page blob holding the disk and that should tell you about the storage account.
However before deleting the other storage account, please check if it is not used for collecting diagnostics data for the VM.
Making an assumption, I believe your LRS Premium account is holding the disks and the other one is for storing diagnostics data.
I created a virtual machine in Azure and then deleted it.
However, the associated storage account still exists.
I can't delete the storage account because it contains a container with a blob in it that has an indefinite lease.
Nothing else is using this storage account.
How can I delete this blob?
You need to delete the disk objects that are associated with the abandoned vhd's. You can do this easily in either the classic or new portal. Once you dispose of these (along with associated leases), you should be able to get rid of your storage account
In the Classic portal (manage.windowsazure.com), you just visit Virtual Machines, then Disks. Select a disk to delete, and click the trash can at the bottom of the screen.
In the new portal (portal.azure.com) you'll find the disks under OS Disks (classic) :
From there, you can select and delete the disks from the VM's you deleted.
You can Use Azure Cloud Explorer tool on Codeplex Open the Storage Account Delete all files inside that container,
Then you Can Delete the Container and the Storage Account Easily
One solution is to delete the container, whether through a GUI like a cloud explorer, tooling like Azure Storage Powershell, or using the rest API with an Azure Storage Client Library.
You don't need the blob lease to delete the container, which would also delete any blobs present in the container.
Azure has Storage accounts and Storage accounts (classic) in the Azure Portal.
What are the differences between them? Is there any reason to migrate from a classic storage account to a new storage account?
Classic storage accounts are created using existing Service Management API's (the REST API stack that's been available for the past several years). The newer storage accounts are created with the new Azure Resource Manager (ARM) API's (which are also wrapped in PowerShell and CLI now). Ultimately they provide the same resources to your apps, but they're created/managed differently, and there are a few nuanced differences (such as the ability to tag resources that are created via ARM scripts).
You can't convert a classic storage account (or any classic resource) to a newer type. You don't really need to anyway, unless you're trying to mix resources from classic and new, such as adding ARM-based virtual machines to a classic-based virtual network, or spin up an ARM-based VM from a vhd image sitting in a classic storage account (and for that example, you could always just copy the vhd to a new storage account). Note that, for general storage usage (blobs/tables/queues), you just need the URI and the primary (or secondary) key. With those, you can access your storage resources from anywhere, from any VM/website/etc, regardless if you're accessing storage from classic or new virtual machines, for example.
Check out this link for a general list of differences between classic and new resources.
One advantage of the new over the classic storage accounts is Storage Service Encryption (SSE):
Q: I have an existing classic storage account. Can I enable SSE on it?
A: No, SSE is only supported on Resource Manager storage accounts.
Q: How can I encrypt data in my classic storage account?
A: You can create a new Resource Manager storage account and copy your
data using AzCopy from your existing classic storage account to your
newly created Resource Manager storage account.
There is now a way to migrate Classic resources to the new ARM model. I've done a few myself and it worked as expected. Here's a guide from Microsoft:
https://learn.microsoft.com/en-us/azure/virtual-machines/virtual-machines-windows-ps-migration-classic-resource-manager
In addition to #David Makogon's answer, the new Azure Storage offers reselling resources to sub-subscriptions.
This means that you are able to buy storage from Azure and sell it to your customers.
You can now migrate Classic Storage Accounts to ARM from within Azure.
Settings --> Migrate to ARM
With Azure
With Powershell