Open neanderson opened 3 years ago
@neanderson , local PowerShell and CloudShell are using different authentication. In CloudShell, Azure PowerShell uses system assigned MSI. If MSI doesn't work, all Azure PowerShell cmdlets cannot work in CloudShell. Could you try other cmdlet in CloudShell such as get-AzSubscription
?
In addition, the result of Get-AzResource -ResourceGroupName nate -Name Test14
is empty. It means VM is not accessible in your environment.
In parallel, we will do further test to check which area have problem.
Hi @dingmeng-xue , I did notice the different authentication methods, but if I wait some time, the Get-AzResource command starts working in Cloud Shell without restarting the session, so I figured authentication was not the problem. And I don't think it would explain why the Get-AzVM command returns a result for Test 14 at the same time. Right now the Get-AzResource command is working fine for Test14 in Cloud Shell.
Is it expected that there will be noticeable delay from when a VM is deployed to when the Az.Resource commands work?
PS /home/nate> Get-AzSubscription
Name Id TenantId State
---- -- -------- -----
Microsoft Azure bab6f0ef-6aca-4894-9942-2e50f7cc2b43 b124ed85-f72c-46ff-b40d-edafa5f708f4 Enabled
PS /home/nate> Get-AzResource -ResourceGroupName nate -Name Test14
Name : Test14
ResourceGroupName : nate
ResourceType : Microsoft.Compute/virtualMachines
Location : westus2
ResourceId : /subscriptions/bab6f0ef-6aca-4894-9942-2e50f7cc2b43/resourceGroups/nate/providers/Microsoft.Compute/virtualMachines/Test14
Tags :
Name Value
========= =====================
Started 12/4/2020 12:00:36 AM
MaxUptime 24
PS /home/nate> Get-AzVM -ResourceGroupName nate -Name Test14 -Status
ResourceGroupName : nate
Name : Test14
ComputerName : Test14
OsName : ubuntu
OsVersion : 18.04
HyperVGeneration : V1
BootDiagnostics :
Disks[0] :
Name : Test14_disk1_d37b395fe91b4eb69c4fcdd40b047436
Statuses[0] :
Code : ProvisioningState/succeeded
Level : Info
DisplayStatus : Provisioning succeeded
Time : 12/3/2020 11:16:03 PM
VMAgent :
VmAgentVersion : 2.2.52
Statuses[0] :
Code : ProvisioningState/succeeded
Level : Info
DisplayStatus : Ready
Message : Guest Agent is running
Time : 12/4/2020 1:12:19 AM
Statuses[0] :
Code : ProvisioningState/succeeded
Level : Info
DisplayStatus : Provisioning succeeded
Time : 12/4/2020 12:01:01 AM
Statuses[1] :
Code : PowerState/running
Level : Info
DisplayStatus : VM running
I opened a ticket with Azure Support and found out why this is happening. It's because Azure commands only run in a single region, and no matter where the VM is deployed, the VM's info must replicate to the region in which the command is run before it is successful. Right now it's taking a very long time for this info to replicate. This is a known issue and ARM PG is supposedly working on fixing it.
From Azure support:
"I got the confirmation once again from our ARM PG that they will address these kind of delays within the next months (we have quite a big project going on in this regard). The major change will be a move from Azure Storage Queues to Azure CosmosDB in order to store underlying replication data. That should then work much faster than the current design."
Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @Drewm3, @avirishuv.
Author: | neanderson |
---|---|
Assignees: | - |
Labels: | `Compute - VM`, `Service Attention`, `customer-reported`, `question` |
Milestone: | - |
Adding compute team
Compute team, do you know whether there is latency?
@avirishuv, @jaylabell, can you please look into this issue?
Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @armleads-azure.
Author: | neanderson |
---|---|
Assignees: | - |
Labels: | `ARM - Core`, `Service Attention`, `customer-reported`, `question` |
Milestone: | - |
Correcting the label on this to ARM. As @neanderson mentioned this is an issue with replication in Azure Resource Manager, and is above the Azure Compute layer.
Description
After a new VM is deployed, there is a large delay before the Get-AzResource and New-AzTag commands start working with the VM when executed in Cloud Shell or an Azure function. This is causing a function that automatically adds tags to VMs following deployment to fail. A resource not found error is returned when the function is triggered by an operation write success event and the New-AzTag command is executed.
The Get-AzVM command run in Cloud Shell shows that provisioning is successful and that the VM is running, but the Get-AzResource command doesn't return the VM and the New-AzTag command fails.
Even when the commands are failing in Cloud Shell, they work when run from a local PowerShell session.
The delay before the Get-AzResource and New-AzTag commands start working in Cloud Shell varies. In testing I've doing over the past several weeks, some days the delay is non-existent and other days it's 20+ minutes.
Example using Cloud Shell:
Steps to reproduce
Environment data
Module versions
Debug output
Error output