Forum Discussion

Gotham_Gerry's avatar
16 years ago

import failed: Disk group has no valid configuration copies

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. 

 



  • 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
  • Hello Gerald,

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


    Gaurav
  • 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...
  • 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