d.lansinklesscher wrote:I can fully understand that you don’t want to break integration with existing linux-based storage devices. Therefore why don’t you create an extra option in the “Add server Screen” to add the a Nas that uses a different Veeam_soap that addresses the issues?
The reason is pretty simple: because it adds yet another option for us to test and support, multiplying the test cases accordingly, and reducing the quality of testing for other options correspondingly. For this reason, I always prefer to follow Occam's razor principle. Adding a separate option for each small storage vendor who decides to do "his own thing" and break what was working for years is just wrong.
Besides, I believe that with over 120'000 of paying customers, and over half a million of free edition users, Veeam is in position where most storage vendors out there want to ensure that they maintain compatibility from their side, if they want to stay competitive with other vendors. For example, look what ExaGrid did in their recent firmware (they are one of the leaders in enterprise-scale deduplication appliances). Basically, they have built a "sandbox" environment to allow our data movers to run on their storage without affecting main data processing engine. This is so much bigger effort than to just "not brake" things which have been working for years.