We have a few AppStacks that have become un-provisioned. Could this have happened as a result of Storage DRS since they reside on a storage cluster?
Just to follow on here as I work with Ken, the AppStack in question hasn't been moved so the path is still valid but the application has suddenly become 'Unprovisioned'. SDRS may not be involved at all though the LUN is part of a storage cluster with SDRS enabled.
Quite perplexing as this is the 2nd app to have this mysteriously happen. We are wondering what might trigger this for a working AppStack.
Any clues or ideas would be enormously helpful and greatly appreciated,
Tim
You mean the status is unprovisoned?? And you were able to attach it previously??
In my understanding the appstack can only be unprovisioned if you make a copy of the original file using the "Update" option in the Appvolumes Manager. This would create a new writable appstack were you can install application in and after you stop the provisiong it is then sealed, never to be changed again .
Noone accidentally clicked update on the appstack??
Yep...unprovisioned and yep, we were able to attach and use the application previously. This has happened with two different AppStacks.
This all happened without anyone touching the Update button. Nothing useful in the activity log.Even if you do touch the Update button you still have to consciously update the appstack.
We have a case open with VMware now and they have the logs. More info as it becomes available.
Windows 2008 R2 and 2012
Location: C:\Program Files(x86)\CloudVolumes\Manager\Log
Log files:
You can access the Production.log through the web at http://cloudvolumesserver:port/log. Substitute App Volumes Server for IP or FQDN or simple name of your App Volumes Manager Server. This requires a login to the App Volumes Manager portal.
Note: Only the ADMIN group configured to access App Volumes Manager can access this page.
Is the AppStack Metadata file still in the same location as the AppStack itself?
Was this issue ever resolved? If so, would you mind sharing the resolution. @We are facing a similar issue