cancel
Showing results for 
Search instead for 
Did you mean: 

import failed: Disk group has no valid configuration copies

Gotham_Gerry
Level 4

I moved an application from a server running Solaris 8 to Solaris 10.  To accomplish this, I added SAN disks to the application's disk group, which previously only had local disks.  The disks on the SAN were visible to both old and new servers.  Deported the disks on the old server,  and imported on the new.  I had to do a '-f' import, but no problem, worked fine.  I had failed disks and plexes on the new server, so I removed them. 

Not sure if this is relevant or not, but after cleaning up the failed disks and plexes on the new server, I re-imported on the old server to look at something.  I did not start any volumes or mount anything, but for a time the disk group was imported on both old and new servers.

Now it looks like I may need to move back to the old server.  The SAN admins have taken away access to the SAN disks, but no problem, I have all the local disks, right?   Problem is, I get "import failed: Disk group has no valid configuration copies".  This was unexpected, because the disk group was up and running fine with only the local disks; it was not until a couple of months ago that we added the SAN disks to the disk group. 

So, I'm looking for a way to recover this disk group.  I can't give the server access to the SAN disks again, because they now have data on them from this failed application upgrade.  I can however, get 'vxprint' output from the new server, and use that to rebuild my volumes.  Just not sure how to go about this or if there is another way around this error message. 

 



1 ACCEPTED SOLUTION

Accepted Solutions

Gotham_Gerry
Level 4
Recovery complete.  My script was failing when making most of the subdisks because in had "dev_offset" where it should have had "dm_offset".  It ran without errors when I corrected it.  I had to go through some 'vxmend' commands to get the volumes started.

Here is an example of a correct vxmake command for a subdisk, as extracted by my script from the 'vxprint -thrL' output: 
  
  vxmake -g datadg72 sd datadg72_002-01 disk=datadg72_002 len=2097152 dm_offset=0 pl_offset=0

View solution in original post

13 REPLIES 13

Gaurav_S
Moderator
Moderator
   VIP    Certified
Hello Gerald,

Sounds tricky...  can you please let me know what is the VxVM version ?

however I would like to suggest few things here:

a) whenever a new diskgroup is created (lets assume the diskgroup with local disks only), it is not necessary that diskgroup config copy goes in all the disks, moreover when you added the SAN disks, really not sure which disk or how many disks had the config copy ? an output of "vxdg list <diskgroup" can reveal which disks hold the config copy ?

b) This error might appear if disks has IOFencing keys, but since you are not using cluster & these are local disks, I am eliminating this option.

c) On your old server, do you have a config copy backup in  /etc/vx/cbr/bk/<diskgroup>   directory ? If yes, then it would be pretty easy to rebuild the diskgroup compairing to other method of rebuilding with vxprint -ht output.


please paste the list of content of above mentioned directory...

# ls -l  /etc/vx/cbr/bk/<diskgroup>xxxxxx   

Gaurav

Gotham_Gerry
Level 4

Thanks Gaurav.  Old server is VxVM 4.1, new is VxVM 5.0.  I know about the config copies, and was careful that disks on the SAN had active config copies so that they would import on the new server.  I didn't even check the local disks, but for a long time this server had only local disks -- no SAN disks -- so I am sure there were active config copies on the local disks.

As for the /etc/vx/cbr/bk/<diskgroup> directory -- the files in there are very old.  I suspect that they do not represent the latest disk group configuration.  These are supposed to get updated when the disk group is imported, correct?  Well the server was rebooted several times after the oldest file in this directory, so I don't know why these files are showing such an old date.  There is another disk group on this server that was also imported to the new server, and I have no problem importing it back.  It shows recent files in its /etc/vx/cbr/bk/<diskgroup> directory. 

I'd like to try to get the disk group info from the new server.  I believe that the info in the /etc/vx/cbr/bk/<diskgroup> directory contains the disk group status before I removed the plexes and disks that were local to the old server. 
 

Gaurav_S
Moderator
Moderator
   VIP    Certified
Hello Gerald,

well regarding the configuration copies under /etc/vx/cbr/bk directory, files are updated whenever there is a configuration change....  So if a server is rebooted but configuration of diskgroup is not changed, then you will not find timestamps update

At this point, you can check the volume structure what CBR directory will build, if you fill that is correct, then you can proceed with restore of that configuration. following would be the steps:

a) locate the latest file with extension  *.cfgrec  under /etc/vx/cbr/bk directory.
b) run following command to figure out what structure would be build IF we restore from this backup

# cat  <.cfgrec file name> | vxprint -ht -D -      (please note position of "-" )

It should give you the structure in vxprint format, if you feel this is correct & you can restore it, then I can provide you the steps to move ahead...

In case if above command errors saying "xxxx is invalid", you can do a vi to that file (after taking a backup) & comment out the line what it is erroring & then repeat the previous command.

Let me know if this helps..


Gaurav

Gotham_Gerry
Level 4
Thanks.  I have six *cfgrec files under /etc/vx/cbr/bk, and they all show a date over a year old, and they all show an incorrect configuration of this disk group.  I have much more recent 'vxprint' output that shows the correct configuration of this disk group.  Why would VxVM fail to save an up-to-date configuration for my disk group? 

Looks like I will be recovering the disk group based on vxprint output. 

g_lee
Level 6
There are various possibilities for why the cbr information could be out of date, eg: the configbackup daemon may have been stopped/disabled, or there were other errors/issues that prevented the config from being backed up correctly. It's not really possible to pinpoint the cause without further analysis/information about the particular system.

In terms of future migrations, it might be worthwhile to look at a different approach to migrate otherwise you will end up having to rebuild the dg again.

eg: you mentioned on Solaris 8 the dg was on local disks, and SAN disks were added to migrate to Solaris 10. As you mentioned the dg imported fine apart from having to remove failed [local] plexes+disks once on the new server is it correct to say this was for mirroring purposes only?

If this was the case, why not add the SAN disks, mirror, then split the mirrors and use these to create a new dg to import on the new server (rather than removing the "failed" local plexes and disks - as this likely contributed to the problem seen here)? then if you needed to check things on the old system you could check the old dg rather than having the dg force imported on two systems at once ....? and if you needed to go back, the old dg on local disks would still be there?

just some thought/suggestions for future.

Gotham_Gerry
Level 4
Thanks for the suggestions.  I am not aware of any way to move detached plexes or any other VxVM objects to another disk group.  I think this ability may not be available using standard VxVM commands, I think this might be a licensed feature...?

I had two servers, each with two disk groups.  It was only one disk group that had a problem coming back to the old server.  The other three disk groups also had up-to-date information in /etc/vx/cbr/bk. 

Gaurav_S
Moderator
Moderator
   VIP    Certified
Hello Gerald,

you need to have a "diskgroup split & join" also called DGSJ (in vxlicrep) to split your diskgroup....

Honestly very hard to say without a real investigation as why config backup was not taken for diskgroup in question....

If you want to build via vxprit output, it will require manual work to collect the offset values & initialize the disk using same offset values.. then put them in diskgroup & the create subdisk,  plex & volumes manually on it

you have to very careful on values otherwise it might result in data loss....

In case you need assistance about commands.. do let me know..

Gaurav


g_lee
Level 6
to move detached plexes to another disk group you need the dg split/join license feature as Gaurav mentioned. although it is possible to move them manually (without the license feature) by creating a new diskgroup using the plexes & old config details (effectively rebuild from bottom up), this requires a lot of care / attention as if configured incorrectly it can result in data loss (as Gaurav also mentioned).

long and the short of it is that it's not really advisable to force import the dg onto the new system if it's known the local disks would be missing, etc (and/or force import the dg onto the old system whilst running on the new system)

In terms of why only one disk group didn't have CBR saved, without knowing the exact steps performed / what else may have been different with between the configurations it's not possible to say. At this point it looks like a rebuild from your latest vxprint is best option here, and if another migration is planned in future the cbr/other details can be checked beforehand so it's easier to rollback if needed.

Gotham_Gerry
Level 4
Alas.  It looks like I need to rebuild my volumes using only human-readable vxprint output saved by Sun Explorer.  My disks have been re-added to the disk group, but I have no volumes.  Anyone have a script for feeding standard 'vxprint -ht' output to vxmake?

Gaurav_S
Moderator
Moderator
   VIP    Certified
Hello Gerald,

From "vxprint -ht" output it would be very difficult & I honestly doubt if Symantec would have that script even....

You atleast would need "vxdisk -s list" or "vxprint -mvphsr" output which unfortunately you are running out off, so will need to do it manually....

If you need any assistance with commands, feel free to ask...


Gaurav


Gaurav_S
Moderator
Moderator
   VIP    Certified
Hello Gerald,

Did you got chance to recover the volumes ? just curious to know... ;)


Gaurav

Gotham_Gerry
Level 4
Not yet.  I wrote an awk script to parse 'vxprint -thrL' output.  I had high hopes for my script, and it produced nice-looking vxmake commands, but when I ran it I got lots of "Subdisk XXX would overlap subdisk XXX" errors.  I only recovered three of my volumes; I have over 100 more to recover.

I do actually have valid 'vxprint -rmv' output.  Problem is that this output contains disks, subdisks and plexes from the SAN that have since been moved from this server.  So when I tried to feed this output to vxmake, it complained about the missing objects and did not create anything.  I could edit the output and remove the missing objects...  By hand would be far too time-consuming, and it was much easier to script the parsing of the human-readable vxprint output, so that is the route I took. 

At this point this is purely an academic exercise.  Thankfully my project does not need this data any more.  I want the ability recover the disk group though, so I'm looking at this task again right now...

Gotham_Gerry
Level 4
Recovery complete.  My script was failing when making most of the subdisks because in had "dev_offset" where it should have had "dm_offset".  It ran without errors when I corrected it.  I had to go through some 'vxmend' commands to get the volumes started.

Here is an example of a correct vxmake command for a subdisk, as extracted by my script from the 'vxprint -thrL' output: 
  
  vxmake -g datadg72 sd datadg72_002-01 disk=datadg72_002 len=2097152 dm_offset=0 pl_offset=0