Hello everyone,

I hava problem with two VDM on a VNX array.

We received it a few weeks ago for file usage. 

The person who installed it created several raid groups, then allocated them to file storage, creating the system-generated storage pools for files "clarata_r6" and "xxx_archive".

A VDM also has been created on this VNX array, replicated to another VNX. And another VDM has been created as well to serve as the replication destination of a VDM from the other VNX.

Nothing being in production yet, we decided to change the raid group and storage pool organisation.  We should have stayed at home this day, because doing this, we created our problem.

We deleted the LUN's on the raid groups.  Then deleted the raid groups themselves, the goal being to recreate afterward a storage pool with several disks, and to allocate this pool to file storage.

But we didn't notice that the VDM filesystems were on the clarata_r6 storage pool.  We though it would be on some system disks...

So, be destroying the LUN's and RG's, we destroyed the FS from the VDM.  We told ourselves "that's not that bad, we are in the process to reconfiguring our system to go later on production, we'll just delete the VDM and recreate a new one".

Unfortunately :

[nasadmin@EXPVNX ~]$ nas_server -delete EXPVDM

Error 12066: root_fs_vdm_EXPVDM is the source or destination object of a file system replication session and cannot be unmounted or is the source or destination object of a VDM replication session and cannot be unloaded.

Ok, let's delete the replication first then...  But it doesn't find any!

[nasadmin@EXPVNX ~]$ nas_replicate -l

Name                      Type       Local Mover               Interconnect         Celerra      Status

Same problem with the other VDM (which is the destination of a replication).

Some information that could be useful :

[nasadmin@EXPVNX ~]$ nas_fs -list

id      inuse type acl   volume    name                server

1         n    1   0     10        root_fs_1

2         y    1   0     40        root_fs_common      2,1

3         n    5   0     73        root_fs_ufslog

4         n    5   0     76        root_panic_reserve

5         n    5   0     93        root_fs_d3

6         n    5   0     94        root_fs_d4

7         n    5   0     95        root_fs_d5

8         n    5   0     96        root_fs_d6

9         y    1   0     12        root_fs_2           1

10        y    1   0     14        root_fs_3           2

11        y    1   0     108       root_fs_vdm_EXPVDM  1

13        y    1   0     111       root_fs_vdm_JBXVDM_ 1

==> The 11 and 13 are the ones that do not exist anymore...

[nasadmin@EXPVNX ~]$ nas_disk -list

id   inuse  sizeMB    storageID-devID   type  name          servers

1     y      11260  CKM00123602675-2007 CLSTD root_disk     1,2

2     y      11260  CKM00123602675-2008 CLSTD root_ldisk    1,2

3     y       2038  CKM00123602675-2009 CLSTD d3            1,2

4     y       2038  CKM00123602675-200A CLSTD d4            1,2

5     y       2044  CKM00123602675-200B CLSTD d5            1,2

6     y      65526  CKM00123602675-200C CLSTD d6            1,2

7     y    8446309  CKM00123602675-0010 CLATA d7            1,2

8     y    8446309  CKM00123602675-0011 CLATA d8            1,2

==> disks 7 and 8 are not there anymore.

[nasadmin@EXPVNX ~]$ nas_pool -list

id      inuse   acl     name                      storage system

18      y       0       clarata_r6                CKM00123602675

==> This pool is the one that contained the VDM information.  It doesn't know yet that disks 7 and 8 are not there anymore.  I do not dare deleting these disks with the command "nas_disk -delete", because I fear the storage pool clarata_r6 will then disappear, and the VDM's will then be even more difficult to delete.  Or maybe that would solve the problem.  If the storage pool containing the VDM FS is destroyed, the VDM willl be removed from config....

Any advice would be appreciated.  And yes, I know we made a mistake in the first place (we should have deleted the VDM's first).

Thanks in advance for your help!

Johan.