locked
ASDK depoly alerts critical RRS feed

  • Question

  • when i depoly asdk,version is 1805.1.47,an when  depoly success,but on the admin portal,there is a critical alerts,the alerts description like this:

     
    The node WIN-4H448CUME1O in the scale unit is inaccessible. There is less capacity available for tenant workloads. A process has been started to move tenant workloads from this node to other nodes. If there is no available capacity, some workloads may not restart.

    • What effect does this alarm have and how does it solve it

    Wednesday, June 20, 2018 1:11 AM

Answers

  • On all ASDK deployments for the 1805 release you can expect to see this alert falsely report a capacity issue.  It is listed in the known issues for 1805.  The alert works correctly on Integrated System deployments.  Checkout this document Azure Stack 1805 update for more details on this topic. The issue causing the alert to fire in the ASDK will be resolved in a future release. Reference thread.

    ----------------------------------------------------------------------------------------------------

    If this answer was helpful, click “Mark as Answer” or Up-Vote. To provide additional feedback on your forum experience, click here.

    Wednesday, June 20, 2018 1:24 PM

All replies

  • On all ASDK deployments for the 1805 release you can expect to see this alert falsely report a capacity issue.  It is listed in the known issues for 1805.  The alert works correctly on Integrated System deployments.  Checkout this document Azure Stack 1805 update for more details on this topic. The issue causing the alert to fire in the ASDK will be resolved in a future release. Reference thread.

    ----------------------------------------------------------------------------------------------------

    If this answer was helpful, click “Mark as Answer” or Up-Vote. To provide additional feedback on your forum experience, click here.

    Wednesday, June 20, 2018 1:24 PM
  • Hi Ajay, 

    Thanks for kindly quick response. So according to your feedback, it means we can ignore this alert for ASDK deployment as it is a wrong alert, which does not indicate the deployment failure, right? If yes, we can continue the following deployments. Thanks again!

    BR,

    Devin

    Thursday, June 21, 2018 2:42 AM
  • Yes, you can ignore the alert.
    Just ensure that your system meets the recommended hardware requirement as outlined in this document Azure Stack deployment planning considerations, and that you follow the deployment process/steps as highlighted in the documentations: Prepare the ASDK host computer. In case, you have any issues with this operation do let us know for further assistance.

    Thursday, June 21, 2018 8:05 AM
  • Hi,Ajay.

         
    •      Our installation steps are documented  https://docs.microsoft.com/en-us/azure/azure-stack/asdk/asdk-prepare-host  ,and our hardware is meeting the requirements.

    •     I now have the following error messages when deploying the VM

    • {"code":"DeploymentFailed","message":"At least one resource deployment operation failed. Please list deployment operations for details. Please see https://aka.ms/arm-debug for usage details.","details":[{"code":"Conflict","message":"{\r\n \"status\": \"Failed\",\r\n \"error\": {\r\n \"code\": \"ResourceDeploymentFailure\",\r\n \"message\": \"The resource operation completed with terminal provisioning state 'Failed'.\",\r\n \"details\": [\r\n {\r\n \"code\": \"VmProvisioningTimeout\",\r\n \"message\": \"VM 'test' failed to provision with timeout.\"\r\n }\r\n ]\r\n }\r\n}"}]}

    I have tried to deploy the fileshare server through the template, the sqlserver in the iaas mode, and an empty 2016 directly, all of which were reported above

    •    


    Friday, June 22, 2018 12:25 AM
  • Could you provide the following information for a better insight?

     

    Build/Version:  

    Get-Content "C:\CloudDeployment\Configuration\Version\version.xml"

     

    Directory type: 

    Azure AD or ADFS

     

    Hardware: 

    How many CPU Cores, RAM, Get-Disk output

     

    Network: 

    Static or DHCP.

      

    BareMetal or Nested Hyper-V:

     

    Deployment parameters used:

     

    Also, could you running the following script to validate the health of your ASDK stamp?

    If there is an issue, Test-AzureStack should point to the root cause.

     

    $CloudAdminCredential = Get-Credential -Credential AzureStack\CloudAdmin

    $psSession = New-PSSession -ComputerName AzS-ERCS01 -ConfigurationName ` PrivilegedEndpoint -Credential $CloudAdminCredential

    Invoke-Command $psSession {Test-AzureStack} 

    Wednesday, July 4, 2018 10:43 AM