SDWAN 20.10 - DevNet Sandbox

[JoseBaldomar]

Hello community!

This is my first time typing here so I am hoping I do not mess this up, lol! I am testing some automation code to upgrade SDWAN controllers from code 20.10.1 to 20.12.2 on Sandbox, and the code works to stage the image and then activates it...

However, when the device comes back up (it pings back) and after 20minutes, the services for vManage 20.12.2 are not coming back up yet. I have checked the nms application-server status and gets stuck in "not started yet". I have restarted all the services, but still nothing changes and that is the only service that gets stuck after the upgrade. I am pretty sure is not my code, as I did the upgrade manually and also gets stuck there after coming back. I get to see the GUI image of the guy with glasses and the typical message "vManage Server is not ready or temporarily unavailable", so I am sure it is only that nms application-server that is stuck...

Do you happen to know if DevNet has a TAC Case for these scenarios? I am kind of lost on how to troubleshoot further as I cannot get access to the VM but only to CLI on this sandbox.

Any help is well appreciated!

[bigevilbeard]

Based on what you describe, its not your code - i would concur here. What i am going to suggest is that the backend of the sandbox does not permit this action in someway. The sandbox isnt meant for this type of operation sadly and as you mentioned you do not have access to the underlying VM/Infra. 

Since you have access to the CLI, look for vManage logs related to the nms application-server startup process. These logs might provide clues about why the service is failing to start. You can typically find them under /var/log/sdwan/vmanage. Look for errors or warnings around the time of the upgrade.

Only way to find known bugs for this is the bug tracker https://quickview.cloudapps.cisco.com/home or opening a tac case, devnet does not track bugs.

Hope this helps.