IBM Storwize support is really basic

[aceit]

Hello.
am I wrong or the integration with IBM Storwize SAN arrays (i.e. V50xx / V70xx etc.) is so extremely basic that call it "integrated" is quite an overstrech ?
For example there is apparently no pool awareness (basic and foundational concept in storwize).
Also the error handling (snapshot failure) and the overall awareness is really basic.

For example I have a very simple setup in one fibrechannel storage unit (IBM V5030):
- two pools, pool1 with flash disks and pool2 with nearline disks
- pool1 is fully committed (no space free)
- pool2 is free and used for backup and snapshot purposes (nearline disks with plenty of space free)
- our VMFS production volume lives in pool1

Basically when Veeam issue a snapshot command, it assumes that the snapshot should be created in the same pool as the source volume (despite no space, in my case, also).
The default pool to use by Veeam should be selectable and configurable when registering the storage in B&R console.

In my case veeam tries to snapshot our volume in pool1 to pool1, despite no space, it fails, and I think this also leave veeam in inconsistent state toward the storage.



I've logged on the matter also an "improvement" support Case # 04740889 leading to the enhancement request.

IMHO, it is a basic thing to ask (pool selection, pools are essential to partition the storage in physical fault domain and I/O characteristics), and without pool selection veeam cannot be really considered integrated with IBM storwize.

[ronnmartin61]

Duly noted. Yes a selectable pool target for snapshots has surfaced as an enhancement request in the past however I do not believe we've seen enough demand to justify the engineering effort (though I will defer to @foggy if I'm mistaken here). Our more recent engineering efforts for FlashSystem (formerly StorWize) have been around supporting complex HyperSwap deployment scenarios.

[aceit]

thanks for the feedback, but, IMHO, you should plan (despite demand) such functionality.
It is such basic concept in Flashsystems/Storwize, that one almost expect it to be present in a backup software. And the integration possibilities are kind of impaired without such (little) grade of automation.

Also a really basic input field and logic with "specify default pool name used for snapshots" would be more and way better than the (pretty static and rigid) situation we have today.

thanks for the collaboration

[Andreas Neufert]

Hello aceit,
thanks again for the input. Based on feedback from the last years with the IBM integration we have planned additional functionality enhancements but this one didn´t made it to the next planned enhancements.

[foggy]

Right, that wasn't a frequent request at all since the most common scenario is to create a snapshot in the same pool, otherwise, it would have shown up more frequently. That said, our integration cannot be called basic or 'overstretched' as it is basically working with the storage on the native API level, which provides the capabilities of using storage snapshots as a backup source. While it may be lacking some more advanced options, it is a pretty close cooperation with the storage firmware. Thanks for the feedback, anyway, we will look closer and track the demand for this functionality.

[Gostev]

you should plan (despite demand)

That would be a terrible way to prioritize missing features it would get me fired from Veeam in no time! Just saying...

[Zew]

One question to back up the OP here a bit. One would assume that if there's an option to pick a pool, that option would be a required parameter in the API calls?

Something smells fishy here.

[foggy]

Without actually checking - it could be optional with the default value to create snapshots in the same pool in case the parameter is not explicitly specified (like the majority of Veeam B&R registry values that you need to create only in case you need to alter the default behavior).

[aceit]

That would be a terrible way to prioritize missing features it would get me fired from Veeam in no time! Just saying...

Sure I completely understand... but really, my original view was that, being the "pool" concept so integral of the IBM system, that one almost take it for granted (ok, naive on my part).
It's like say, having a backup software where you can't specify a target directory for the repo, it justs uses say "c:\backuprepo" because the source data is in c: (comparison just to pass the concept. Of course demand will quickly "drive" this feature immediately, but would have been more efficient and natural to have it there in the first place. IBM Storwize users are a small subsample of the overall veeam users of course, so the a demand bias is natural).

That said, it would be nice to include and clearly state in the documentation any kind of limitations / caveats of the integration with IBM Spectrum/Storewize software, i.e. "Veeam doesn't have pool awareness. Snapshots would be targeted to the same pool of the source volume.".

To go into details, basically Veeam issue this command line, when instructed via GUI to take a volume snapshot
---
4/8/2021 12:59 veeam svctask rmvdisk -force 3
4/8/2021 12:59 veeam svctask rmfcmap -force 1
4/8/2021 12:58 veeam svctask startfcmap -prep 1
4/8/2021 12:58 veeam svctask mkvdisk -name v5030V1_SSTEST -mdiskgrp 0 -vtype striped -size 44519225808896 -unit b -rsize 0% -autoexpand -iogrp 0 -node 2 -grainsize 32
4/8/2021 12:58 veeam svctask mkfcmap -cleanrate 0 -copyrate 0 -source 0 -target 3 -name v5030V1_SSTEST_fc_map
---

The desired pool (mdiskgrp) should be selectable, that would be nice, i.e.

svctask mkvdisk -autoexpand -grainsize 256 -iogrp io_grp0 -mdiskgrp v5030P2 -name v5030V1_01 -node node2 -rsize 2% -size 44519225808896 -unit b -warning 80%
svctask mkfcmap -cleanrate 0 -copyrate 0 -source v5030V1 -target v5030V1_01


thanks

[foggy]

If all the IBM Storwize users required this functionality, then it would definitely have raised the demand even though they are "a small subsample of the overall veeam users". We will consider adding a note describing this limitation to the user guide.