Subscribe

LUN serial NOT changed on a vol clone

Hi all.

 

I've just hit what I believe is a very serious bug in DOT 8.1.

On a vol clone operation on a LUN container, the cloned LUN kept the same serial number as the original one.

Of course that should never happen, since this basically means remote SAN initiators will see that LUN as just a bunch of new paths to the original LUN.

Experience shows it will make a VMFS datastore collapse.  :-(

 

DOT version used was Release 8.1.4P3 7-Mode.

No newer 8.1.4 patch release show such a bug as being fixed.

 

Has anyone experienced this before ?

 

 

Here are just a few commands exposing the problem.

The first clone operation is when everything goes alright. DOT properly identifies the new LUN as a duplicate, and takes appropriate action.

The second clone operation went bad : the LUN duplicate went unnoticed (seemingly the vol clone operation did not fully complete), and the resulting LUN has the same serial number as the original one...

 

netappb2*> lun serial /vol/vmfs_lan/vmfs_lan/vmfs_lan
Serial#: 2Fh5s+ClT/8T
netappb2*>
netappb2*> vol clone create vmfs_lan_20150517213001 -b vmfs_lan smvi__VMFS_LAN_20150517213001
Creation of clone volume 'vmfs_lan_20150517213001' has completed.
netappb2*> Tue May 19 01:19:50 CEST [netappb2:wafl.volume.clone.created:info]: Volume clone vmfs_lan_20150517213001 of volume vmfs_lan was created successfully.
Tue May 19 01:19:50 CEST [netappb2:lun.newLocation.offline:warning]: LUN /vol/vmfs_lan_20150517213001/vmfs_lan/vmfs_lan has been taken offline to prevent map conflicts after a copy or move operation.
netappb2*> lun serial /vol/vmfs_lan_20150517213001/vmfs_lan/vmfs_lan
Serial#: 2FhNd$GH-t35

netappb2*>
netappb2*> vol clone create vmfs_lan_20150309213324 -b vmfs_lan smvi__VMFS_LAN_20150309213324
Creation of clone volume 'vmfs_lan_20150309213324' has completed.
netappb2*> lun serial /vol/vmfs_lan_20150309213324/vmfs_lan/vmfs_lan
Serial#: 2Fh5s+ClT/8T