SnapCenter 4.4 - Issue with Cloning, Custom Plug-in for MySQL Server

[TveUA]

Hello,

We're backing up a MySQL database on iscsi storage (on Ontap 9.7) via SnapCenter 4.4 using the Custom Plugin for MySQL 2.0.
This seems to work great, but when we try to clone via SnapCenter we get stuck on:

"Mount Filesystem"=>"Building clone for data file systems and associated entities" and following log entry:

Internal error: Attribute (uuid) does not pass the type constraint because: Validation failed for 'Str' with value undef at accessor SCU::Model::Device::uuid (defined at /opt/NetApp/snapcenter/spl/lib/../plugins/scu/scucore/bin/../modules/SCU/Model/Device.pm line 26) line 4
SCU::Model::Device::uuid('SCU::Model::Device=HASH(0x3ce8730)', undef) called at /opt/NetApp/snapcenter/spl/lib/../plugins/scu/scucore/bin/../modules/SCU/Metadata/FSMetadataBuilder.pm line 105

If you look on the host right before it fails you can see that the LUNS are visible via sanlun lun show.
If we take a look at the BuildHostStackCloneInput json file, fsMetadataInfo=>"path"=>deviceInfo=>uuid = null. Wich explains why the error happens. If we, for testing purposes, edit the FSMetadataBuilder.pm file to use "" instead of null the clone works, but we don't want to edit those files ofcourse.

We have no idea why that value is null to begin with, we've tried on both SLES and Oracle Linux, same result.

Does anybody have any ideas?

[stanton]

Do you have UDEV rules in place for the source filesystem?  Is there a UUID for the source?

[RobinR1]

What UDEV rules should be set up? We don't have any custom udev rules in place. And during the  clone process we see the filesystems get successfully discovered and (with devicemapper and multipath) mapped to /dev/dm-0, /dev/dm-1, etc..

The filesystems on those devices do have a uuid that can be viewed with the blkid command, if that is the uuid you mean?

The devices are also found in /dev/mapper/<id> where <id> seems to be some unique id, different from the blkid

After discovery takes place and those lun's are mapped to multipath devices, the cloning process fails with the above-mentioned error and the lun's are removed again.. (without actually removing the DM devices on the OS first so multipath/dm start complaining about all the paths)

[stanton]

This looks like a deep enough problem that a support case should be opened as it is going to require NetApp to look deeper into the data than can safely be gathered in a forum setting.  Please open a case with NetApp support.