Video Screencast Help

Appliance Disk Shelf Cannot Be Added

Created: 28 Jan 2013 • Updated: 29 Jan 2013 | 6 comments
Mark_Solutions's picture
This issue has been solved. See solution.

Due to issues with a new appliance Master it was re-imaged (along with three others!)

All of them were fine except one which I cannot add in the disk shelf

In the CLISH as "show" shows the shelf is available, an "add unit_2" says it is already added, an "add" says unit_2 is available, a "remove unit_2" says it has not been added.!!

A deeper check reveals that the disk_2 (the shelf) is part of the nbuapp disk group but is deported

The disk_1 (cat, advol and pdvol) is imported on the nbuapp disk group.

Normally for this NBU would be stopped, volumes unmounted, nbuapp deported and then re-imported to bring it all back in ... but a check shows that the disk group ID's for nbuapp are different for disk_1 and disk_2 so that probably wouldn't work

I am waiting on Support for assistance (case 03485089 that started it all off) but due to a lack of contact i need to try and sort this out and would appreciate any assistance to get me back on track.

Thanks for any advice

Comments 6 CommentsJump to latest comment

mikebounds's picture

You can import diskgroup using dgid by just specifying dgid - so one possible solution if you have:

 

vxdisk -o alldgs list shows:

DEVICE TYPE DISK GROUP STATUS
disk_1 auto:sliced disk_1 nbuapp online
disk_2 auto:sliced - (nbuapp) online
sda auto:none - - online invalid

and dgid's are different:

disk_1: dgid: 1359115965.11.nb-appliance

disk_2: dgid: 1355249361.7.nb-appliance

is:

vxdg -n newdg import 1355249361.7.nb-appliance
vxdg join newdg nbuapp

I think this should work IF you have an Enterprise license and you dont' have single volumes that span the 2 disks i.e if you have one volume on each disk, I can't see why joining diskgroups shouldn't work, but if you have something like a stripped or mirrored volume across the 2 disks, I can imagine this will probably cause issues for the health of the volume.

Mike

 

 

UK Symantec Consultant in VCS, GCO, SF, VVR, VxAT on Solaris, AIX, HP-ux, Linux & Windows

If this post has answered your question then please click on "Mark as solution" link below

mikebounds's picture

If you don't have an Enterprise license then a more riskier approach is:

vxdg -n newdg import 1355249361.7.nb-appliance
vxprint -mvpsg newdg > newdg.vxmake
vxdg destroy newdg
vxdg -g nbuapp adddisk disk_2
vxmake -d newdg.vxmake
vxrecover -sg nbuapp

So the theory here is that description file created by vxprint describes the exact location of all the vxvm objects and the vxdg destroy destroys the vxvm object information, not the data in the public region, so if you  re-create all the vxvm objects in the same location by using vxmake, then this should, in theory, mean the re-created vxvm objects point to your data.

I would advise running this past Support before attempting this, although they may just say that this is not supported as you are essentially doing what "vxdg join" does in a low-level way which does not require an enterprise license.
To minimise the risks of this you should compare the output of "vxdisk list disk_1" and "vxdisk list disk_2" to make sure the "info" and "private" fields are the same, but as you are not re-initialising the disk, then even if the disks have different sized private regions, then this should be preserved.

Mike

UK Symantec Consultant in VCS, GCO, SF, VVR, VxAT on Solaris, AIX, HP-ux, Linux & Windows

If this post has answered your question then please click on "Mark as solution" link below

Marianne's picture

To check installed license key, use 'vxlicrep' command.

Hopefully 'Storage Foundation Enterprise' will be listed.

If so, diskgroups can be joined as per Mike's first post.

Seems each disk contains dedicated volumes. Mark has shared vxprint output in private email:

 

Disk group: nbuapp
TY NAME         ASSOC        KSTATE   LENGTH   PLOFFS   STATE    TUTIL0  PUTIL0
dg nbuapp       nbuapp       -        -        -        -        -       -
dm disk_1       disk_1       -        9755774656 -      -        -       -
v  advol        fsgen        ENABLED  1560281088 -      ACTIVE   -       -
pl advol-01     advol        ENABLED  1560281088 -      ACTIVE   -       -
sd disk_1-02    advol-01     ENABLED  1560281088 0      -        -       -
v  catvol       fsgen        ENABLED  1951154176 -      ACTIVE   -       -
pl catvol-01    catvol       ENABLED  1951154176 -      ACTIVE   -       -
sd disk_1-01    catvol-01    ENABLED  2097152  0        -        -       -
sd disk_1-03    catvol-01    ENABLED  1949057024 2097152 -       -       -
v  pdvol        fsgen        ENABLED  6243221504 -      ACTIVE   -       -
pl pdvol-01     pdvol        ENABLED  6243221504 -      ACTIVE   -       -
sd disk_1-04    pdvol-01     ENABLED  6243221504 0      -        -       -

 

Supporting Storage Foundation and VCS on Unix and Windows as well as NetBackup on Unix and Windows
Handy NBU Links

Mark_Solutions's picture

Making some progress - thanks all - i have the disk back in the correct group and with the same name but wasn't showing correct size

I have rebooted to see what it makes of it after the reboot and will have to update this tomorrow with more news - still no sign of support but maybe they will be able to assist further as and when they finally get back to me

Authorised Symantec Consultant

Don't forget to "Mark as Solution" if someones advice has solved your issue - and please bring back the Thumbs Up!!.

Mark_Solutions's picture

OK - so all fixed - and if anyone comes across a similar situation i would suggest talking to Symantec Support for assistance but if you are really pushed for time then here goes:

First, as disk_2 was deported but in the same disk group as disk_1 (but with a different group ID) it could not be imported.

So the disk need to be removed from the group all together (using vxdiskadm,  remove a disk plus something else which i cannot find my notes for now!)

I then added it back in to the nbuapp group (the correct one) which re-initialised it - accepting all defaults

At this point it has no file system or anything so in the CLISH under Storage Show it does now but shoed as available and in the nbuapp disk group but has no sizes displayed at all (for a while it showed a 1.3TB or there abouts)

I then rebooted the appliance (remembering something about disks and disk groups having things held in cache.

After the reboot in the CLISH it showed as available but not in the group and no sizes displayed so i was about to start looking for the script that prepares the disk shelf when Symantec Support phoned for a webex.

He used the add unit_2 in the CLISH and it added it in with the correct sizes and everything - so clearly the script checks it and configures it when you add it in.

So all is now good - a massive thanks to Marianne and Mike for pointing me in the right direction with this one.

By the way - it does look like it may be the Enterprise Version as the join command was available, although for what ever reason it just wouldn't work and hence i had to do the re-initialisation of the disk to be able to add it back in.

Authorised Symantec Consultant

Don't forget to "Mark as Solution" if someones advice has solved your issue - and please bring back the Thumbs Up!!.

SOLUTION
Marianne's picture

I then rebooted the appliance (remembering something about disks and disk groups having things held in cache.

'vxdcl enable' will re-read disk info (should've told you last night...)

One possible reason for different dg id is that the disk shelve may have been used with another installation previously. If so, re-initialize was the best possible solution.

 

Supporting Storage Foundation and VCS on Unix and Windows as well as NetBackup on Unix and Windows
Handy NBU Links