jasonzio
commented
2 years ago Azure doesn't delete files on its own; if you want them deleted, you have to delete them. Azure doesn't manage the storage used by VM boot diagnostics; you do.
One potential limit on the number of VMs that can use the same storage account for boot diagnostics derives from the size limit on the storage account itself. The amount of storage required for serial console itself is quite small, far smaller than the storage occupied by the boot diagnostics for the associated VM. You're not going to hit that limit, even with 100k VMs.
The actual effective limit will derive from the maximum IOPs supported by the storage account. The published Azure documentation talks about the useful limits on the number of VMs that can write their boot diagnostics to the same storage account because of the IOP limit. The IOPs required by Serial Console are quite small (a handful of read/write operations when the session is established) and can practically be neglected.
tl;dr - follow published guidance for the number of VMs sharing a single boot diagnostic storage account; the space and IOPs required for Serial Console are vanishingly small next to that load. You're on the hook to clean up old diagnostic logs you no longer need.
mbifeld
I am unable to understand, how are the storage accounts managed in case of custom storage boot diagnostics. For example, if vm/vmss is deleted, will the files related to it be already present in the storage account/ or would those files be deleted? Also, is there any limit on the number of vms that can share a storage account for custom boot diagnostics?