This has been requested in other forms, but now that you have Managed Disks you're most of the way there. I would like to be able to say "I want a Managed Disk using standard storage, 1TB in size, with 2500 IOPS." Then you figure out how to configure storage to deliver those IOPS without me having to stripe disks, or whatever.
Or perhaps "I want a 1TB Managed Disk using premium storage with 15000 IOPS." Again, you figure out how to configure and provision that, so I don't have to. That would be awesome!73 votes
Thanks for your feedback! This ask will be discussed amongst our team to determine if we plan to do this and when.
Currently the smallest premium disk size when creating a VM is 128 GB. We have many VM's that are used solely for computation intensive workload and large amounts of data are not stored to the operating system drive. A 64 GB option would be sufficient for the space we are using and help to reduce some of the premium storage costs.22 votes
Azure Storage is actively working on features that would address this concern.
I have some complaints from users that they can not specify Diagnostics settings On / Off at the time they create a storage account.
When users create a new storage account, the storage account diagnostics is enabled by default and billing for storage analytics tables occurs because those tables are created automatically. Moreover users can’t notice those table storage being charged during usage if they are not familiar. Please add a feature to allow users to specify storage diagnostics On / Off when creating a storage account.14 votes
Please allow attaching more disks per core, or increase the max size of disk (1TB by default) without forcing upgrading the VM instance.
For my project I use A1 Standard VM instance and CPU/memory is sufficient for my project, but it needs more storage (up to 10TB).
I can't attach more disks without spending more on CPU/memory that my project doesn't require.
I think, we should be charged for capacities/storage we really use and not for what we're forced to use!
Please support it!13 votes
Azure Storage is actively working on features that could address this request.
Please provide the capability of using Customer Managed Keys for Storage Service Encryption (SSE). This is required for customers who need the ability to manage keys but seek to leverage the scalability and manageability advantages of Managed Disk.9 votes
We have database linux vm with multiple premium managed disks. We have software raid on top of these disks inside the Linux guest vm. We need a way to take snapshots of these multiple managed disks at the same point in time coordinated at Azure storage level so all the writes are captured at the exact same point in time across all disks.6 votes
Is there a way to create an automated snapshot of an existing managed disk on a schedule? I want the option to choose a fixed rate to create
Automate the managed disk snapshot schedule frequency4 votes
Please backup and copy OS disk only by schedule with portal (not AzCopy Command). I would like to back up OS disk only. Currently Azure image capture and back up service take snapshot and backup by VM unit. AzCopy makes it to copy OS disk only. For me, AzCopy takes much time. Please make it much easier, I mean operation from management portal would be much preferred.4 votes
We have managed disks encrypted at rest with SSE, but the backups to recovery vault of those VMs are not encrypted at rest. This is a security issue for us.
A native feature for this would be great to get rid of the workaround to encrypt those with external tools (BitLocker, dm-crypt,..)3 votes
Currently, the only way to create an OS Disk from a generalized image is by creating it at the same time as a VM shell.
The ability to spin up Managed Disks without attaching them to a VM from a generalized image would be incredibly useful and allow for dynamic resizing of disks via ARM templates without affecting the VM itself.2 votes
It is not yet supported to directly migrate a managed VM from one subscription to another.
It would be nice to have export directly to a storage account instead of creating an URL.
It will just make migration so much easier and more secure, than having an URL, that is public accessable..
- Don't see your idea?