this severely limits us in what we can change without getting 10000 support cases the next morning.Ĭonsider the last part done, as I am the Vice President of Product Management, ultimately responsible for the feature set and behavior We are working on v8 product with the largest customer install base in the world as it comes to VMware backup, not some v1 version with a few beta users. I am just trying to show you the bigger picture, and what other things I need to consider. And the root cause for this issue is that this particular customer has never ever tested the backups, which is totally against standard data protection practices.Īgain, I am not saying I disagree that some customer with certain approaches to managing their backups will benefit from this feature. healing one symptom is okay (as long as this does not impact the user base), but this is still largely useless because instead, what you need to heal is the cause.
And if your customer don't test their backups, they won't find out about another hundreds of possible recovery issues until it's too late. Imagine the impact this will cause on 90000+ customer base who do these configurations on purpose. Now you are suggesting to change the current product behavior for based on single (sic!) request in 6 years that was caused by "inadvertent configuration" as you yourself put it. This is true! I can even try and find this topic There was one event that we accidentally moved back into the warning, and we had a 3 pages long topic in a matter of a few week with demands to fix this. We've spent last few years removing warnings from the product and reclassifying them into info events based on huge amounts of feedback, because people did not want to see the warning for irrelevant issues and known limitations.
0 kommentar(er)
