I got a call the other day advising that AppVolumes was “broken” when trying to update an existing AppStack. I quickly hopped onto the environment and noticed the Activity Log showed the error “Update Appstack xxx – Failed 5 times” as can be seen in the image below.
Knowing my way around the log files pretty well, I took at a look at the Server logs and noticed the following error:-
P7136DJ449121 INFO RvSphere: Searching datastore “[pdesxappv_gen2_ssd] cloudvolumes/apps” non-recursively
[2017-01-06 11:49:04 UTC] P7136DJ449121 INFO Cvo: Application volumes datastore folder already exists: [pdesxappv_gen2_ssd] cloudvolumes/apps/
[2017-01-06 11:49:04 UTC] P7136DJ449121 ERROR Cvo: Unable to create AppStack because a volume at “[pdesxappv_gen2_ssd] cloudvolumes/apps/Core!20!Applications!20!(Enterprise!20!Trust)!20!-Live_30112016-update.vmdk” already exists
[2017-01-06 11:49:04 UTC] P7136DJ449121 ERROR Cvo: Job error: Update AppStack #<Thread:0x9d5390> Unable to create AppStack because a volume at “[pdesxappv_gen2_ssd] cloudvolumes/apps/Core!20!Applications!20!(Enterprise!20!Trust)!20!-Live_30112016-update.vmdk” already exists
What this came down to was that the AppStack that was trying to be updated was trying to use a filename that already existed on the underlying datastore, based upon a previous updated version. So, to fix this, I changed the name of the Appstack as part of the update process and as soon as the AppStack name was changed, the error message was no longer presented and the updated became available to be provisioned for use.
I’m going to raise a Feature Request with VMware and ask them to include a level of error checking to ensure that duplicate file names cannot be entered and at least produce an error message when trying to commit an updated stack rather than waiting for the process to fail and having to trawl through the Server logs.