vm create: expose --boot-diagnostics-storage to capture boot log#6302
Conversation
|
View a preview at https://prompt.ws/r/Azure/azure-cli/6302 |
|
edit: Never mind, I see what this does the PUT, I can do this from resources.azure.com for now. |
| c.argument('write_accelerator', nargs='*', min_api='2017-12-01', arg_group='Storage', | ||
| help="enable/disable disk write accelerator. Use singular value 'true/false' to apply across, or specify individual disks, e.g.'os=true 1=true 2=true' for os disk and data disks with lun of 1 & 2") | ||
| c.argument('boot_diagnostics_storage', | ||
| help='pre-existing storage account name or its blob uri to capture boot diagnostics. Its sku should be one of Standard_GRS, Standard_LRS and Standard_RAGRS') |
There was a problem hiding this comment.
Does the service need permission to the storage account?
There was a problem hiding this comment.
No extra permission configuration is needed. I believe CRP just accesses the storage under VM creator's identity captured through the original token from the VM PUT
|
When are you folks going to release this feature? |
|
@dsboulder, the release date will be around May 22, based on the milestone page https://github.com/Azure/azure-cli/milestones |
|
I have a question about the --boot-diagnostics-storage option. Other options like subnet allow the full path to a resource (/subscriptions/id/ResourceGroup/...) is there a reason why this just accepts the name? |
|
storage name has to be unique across groups and subscriptions, so accepting a name is enough |
|
Hi Team, How do you specify a "Microsoft Managed Storage Account" for boot diagnostics during As per this azure article, if we don't specify storage account, then it should automatically pick up azure managed storage account, however based on azure cli command, it requires an argument - Azure Article |
Fix #5634
Related command flows will be
1. az storage account create -g yg -n ygstor --sku standard_lrs 2. az vm create -g yg -n yg-1 --image ubuntults --boot-diagnostics-storage ygstorFor VM with unmanaged disk, I thought about defaulting the storage account to the os disk's but it turns out not very worthy for 2 reasons:
unmanaged diskwithstandard_lrswill be pretty minority, hence could become confusingThe PR has modified HISTORY.rst describing any customer-facing, functional changes. Note that this does not include changes only to help content. (see Modifying change log).
I adhere to the Command Guidelines.