Start a Conversation

This post is more than 5 years old

Solved!

Go to Solution

5045

August 30th, 2007 20:00

Unable to mount my BCV

Hi,

I need some expert advise!

I have migrated my dev from 8530 to dmx1000 recently. Originally in the 8530, I have BCV group created for my STD device and it has work fine where it can be mir and split and then mounted to a BCV created mount point. After the device migration, the mounting is not possible. I have re-created the pv and also change the scripts to point to the new dev. Attached is a cutout of my symdev of one of the BCV follow by a symmir -d query.

# symdev -sid PRIDMX show 025F

Device Physical Name : /dev/rdsk/c16t0d7

Device Symmetrix Name : 025F
Device Serial ID : 150025F000
Symmetrix ID : 000287460xxx

Device Group Name : bcvP81
Device Logical Name : BCV001

Vendor ID : EMC
Product ID : SYMMETRIX
Product Revision : 5670
Device WWN : 6006048000028746081553594D323546
Device Emulation Type : FBA
Device Defined Label Type: N/A
Device Defined Label : N/A
Device Sub System Id : 0x0003

Device Block Size : 512

Device Capacity
{
Cylinders : 55242
Tracks : 828630
512-byte Blocks : 53032320
MegaBytes : 25895
KiloBytes : 26516160
}

Device Configuration : BCV (Meta Head,
Non-Exclusive Access)

Device is WORM Enabled : No
Device is WORM Protected : No

SCSI-3 Persistent Reserve: Disabled

Dynamic Spare Invoked : No

Dynamic RDF Capability : None

Device Service State : Normal

Device Status : Ready (RW)
Device SA Status : Ready (RW)

Front Director Paths (2):
{
----------------------------------------------------------------------
POWERPATH DIRECTOR PORT LUN
--------- ---------- ---- -------- ---------
PdevName Type Type Num Sts VBUS TID SYMM Host
----------------------------------------------------------------------
/dev/rdsk/c16t0d7 PARENT FA 04D:1 RW 000 00 007 007
Not Visible N/A FA 13D:1 RW 000 00 007 N/A
}

Meta Configuration : Striped
Meta Stripe Size : 960k (2 Cylinders)
Meta Device Members (3) :
{
----------------------------------------------------------------------
BCV DATA RDF DATA
---------------------------- --------------------------
Sym Cap Std Inv BCV Inv Pair R1 Inv R2 Inv Pair
Dev (MB) Tracks Tracks State Tracks Tracks State
----------------------------------------------------------------------
--> 025F 8632 0 0 Split - - N/A
0260 8632 0 0 Split - - N/A
0261 8632 0 0 Split - - N/A
----------------------------------------------------------------------
25895 0 0 - -
}

Mirror Set Type : [Data,N/A,N/A,N/A]

Mirror Set DA Status : [RW,N/A,N/A,N/A]

Mirror Set Inv. Tracks : [0,0,0,0]

Back End Disk Director Information
{
Hyper Type : Data
Hyper Status : Ready (RW)
Disk [Director, Interface, TID] : [01A, C, 8]
Disk Director Volume Number : 79 (0x4E)
Hyper Number : 3
Disk Capacity : 139814m
Disk Group Number : 4
}

BCV Pair Information
{
Standard (STD) Device Symmetrix Name : 011E
Standard (STD) Device Serial ID : Not Visible
Standard (STD) Device Group Name : bcvP81
Standard (STD) Composite Group Name : Not/Grouped

BCV Device Symmetrix Name : 025F
BCV Device Serial ID : Not Visible
BCV Device Associated Group Name : bcvP81
BCV Device Associated CG Name : Not/Associated

BCV Device Status : Ready (RW)

State of Pair ( STD <=\=> BCV ) : Split
Time of Last BCV Action : Thu Aug 30 21:53:03 2007

State of BCV Mirrors : N/A

BCV State Flags : (AllReady)
Percent Split : 100%

Number of Inv. Tracks for STD Device : 0
Number of Inv. Tracks for BCV Device : 0
}


# symmir -g bcvP81 query


Device Group (DG) Name: bcvP81
DG's Type : REGULAR
DG's Symmetrix ID : 000287460xxx


Standard Device BCV Device State
-------------------------- ------------------------------------- ------------
Inv. Inv.
Logical Sym Tracks Logical Sym Tracks STD <=> BCV
-------------------------- ------------------------------------- ------------

DEV001 011E 0 BCV001 025F * 0 Split
DEV002 0121 0 BCV002 0262 * 0 Split
DEV003 0124 0 BCV003 0265 * 0 Split
DEV004 0127 0 BCV004 0268 * 0 Split

Total ------- -------
Track(s) 0 0
MB(s) 0.0 0.0


Legend:

(*): The paired BCV device is associated with this group.

2 Intern

 • 

2.8K Posts

October 3rd, 2007 00:00

Please remember to reward usefull answers :-)

-s-

24 Posts

August 31st, 2007 00:00

Actually,

I am using LVM.

I am using a cron job to run this mirroring and and spliting. The scripts are as follows; after which I can manually mount the BCV. I am not sure how I can check whether I have sucessfully sync the BCV with standard?

#P81 syncs
30 21 * * 0-4 /home/script/endsap.sh >/home/script/endsap.log
33 21 * * 0-4 /home/script/sync_P81offline.sh
53 21 * * 0-4 /home/script/split_P81offline.sh
00 22 * * 0-4 /home/script/startsap.sh >/home/script/startsap.log

root@scpl23 [/opt/emc/SYMCLI/V6.0.3/bin]
# more /home/script/endsap.sh
su - orap81 -c "/home/script/save_db.sh"
su - p81adm -c "stopsap"


root@scpxxx[/opt/emc/SYMCLI/V6.0.3/bin]
# more /home/script/sync_P81offline.sh

LOGFILE=/tmp/bkp_offlineP81.log export LOGFILE
exec >$LOGFILE
cd /opt/emc/SYMCLI/V6.0.3/bin
symmir -g bcvP81 query
symmir -g bcvP81 est -noprompt


root@scpxxx [/opt/emc/SYMCLI/V6.0.3/bin]
# more /home/script/split_P81offline.sh

LOGFILE=/tmp/endbkp_offlineP81.log export LOGFILE
exec >$LOGFILE
cd /opt/emc/SYMCLI/V6.0.3/bin
symmir -g bcvP81 query
symmir -g bcvP81 split -noprompt
symmir -g bcvP81 query


root@scpxxx [/opt/emc/SYMCLI/V6.0.3/bin]
# more /home/script/startsap.sh
su - p81adm -c "startsap"

2 Intern

 • 

2.8K Posts

August 31st, 2007 00:00

I have migrated my dev from 8530 to dmx1000 recently.
Originally in the 8530, I have BCV group created for
my STD device and it has work fine where it can be
mir and split and then mounted to a BCV created mount
point. After the device migration, the mounting is
not possible. I have re-created the pv and also
change the scripts to point to the new dev. Attached
is a cutout of my symdev of one of the BCV follow by
a symmir -d query.


Nice to see that you already pasted the symdev and the symmir output. But could you please show us the error you've got ??

From what I can see everything seems to be good .. The BCV is seen from the host (/dev/rdsk/c16t0d7) and it's split from the STD.
It seems you are using HPUX .. are you using LVM or VxVM ??

-s-

2 Intern

 • 

2.8K Posts

August 31st, 2007 00:00

Could you please show the last run of "split_P81offline.sh" and what it logged into "/tmp/endbkp_offlineP81.log" ??

And could you please show the error you receive while trying to mount the filesystems ??

-s-

PS nice trick the "exec >$LOGFILE" !! :-) .. It's a nice flashback :-)

24 Posts

August 31st, 2007 02:00

I have sent again, looks like the syn is OK but is it Ok to see total "-----" and MB 0.0?

# more endbkp_offlineP81.log


Device Group (DG) Name: bcvP81
DG's Type : REGULAR
DG's Symmetrix ID : 000287460xxx


Standard Device BCV Device State
-------------------------- ------------------------------------- ------------
Inv. Inv.
Logical Sym Tracks Logical Sym Tracks STD <=> BCV
-------------------------- ------------------------------------- ------------

DEV001 011E 0 BCV001 025F * 0 Synchronized
DEV002 0121 0 BCV002 0262 * 0 Synchronized
DEV003 0124 0 BCV003 0265 * 0 Synchronized
DEV004 0127 0 BCV004 0268 * 0 Synchronized

Total ------- -------
Track(s) 0 0
MB(s) 0.0 0.0


Legend:

(*): The paired BCV device is associated with this group.



Device Group (DG) Name: bcvP81
DG's Type : REGULAR
DG's Symmetrix ID : 000287460xxx


Standard Device BCV Device State
-------------------------- ------------------------------------- ------------
Inv. Inv.
Logical Sym Tracks Logical Sym Tracks STD <=> BCV
-------------------------- ------------------------------------- ------------

DEV001 011E 0 BCV001 025F * 0 Split
DEV002 0121 0 BCV002 0262 * 0 Split
DEV003 0124 0 BCV003 0265 * 0 Split
DEV004 0127 0 BCV004 0268 * 0 Split

Total ------- -------
Track(s) 0 0
MB(s) 0.0 0.0


Legend:

(*): The paired BCV device is associated with this group.

24 Posts

August 31st, 2007 02:00

# more endbkp_offlineP81.log


Device Group (DG) Name: bcvP81
DG's Type : REGULAR
DG's Symmetrix ID : 000287460xxx


Standard Device BCV Device State
-------------------------- ------------------------------------- ------------
Inv. Inv.
Logical Sym Tracks Logical Sym Tracks STD <=> BCV
-------------------------- ------------------------------------- ------------

DEV001 011E 0 BCV001 025F * 0 Synchronized
DEV002 0121 0 BCV002 0262 * 0 Synchronized
DEV003 0124 0 BCV003 0265 * 0 Synchronized
DEV004 0127 0 BCV004 0268 * 0 Synchronized

Total ------- -------
Track(s) 0 0
MB(s) 0.0 0.0


Legend:

(*): The paired BCV device is associated with this group.



Device Group (DG) Name: bcvP81
DG's Type : REGULAR
DG's Symmetrix ID : 000287460815


Standard Device BCV Device State
...skipping...


Device Group (DG) Name: bcvP81
DG's Type : REGULAR
DG's Symmetrix ID : 000287460815


Standard Device BCV Device State
-------------------------- ------------------------------------- ------------
Inv. Inv.
Logical Sym Tracks Logical Sym Tracks STD <=> BCV
-------------------------- ------------------------------------- ------------

DEV001 011E 0 BCV001 025F * 0 Synchronized
DEV002 0121 0 BCV002 0262 * 0 Synchronized
DEV003 0124 0 BCV003 0265 * 0 Synchronized
DEV004 0127 0 BCV004 0268 * 0 Synchronized

Total ------- -------
Track(s) 0 0
MB(s) 0.0 0.0


Legend:

(*): The paired BCV device is associated with this group.



Device Group (DG) Name: bcvP81
DG's Type : REGULAR
DG's Symmetrix ID : 000287460xxx


Standard Device BCV Device State
-------------------------- ------------------------------------- ------------
Inv. Inv.
Logical Sym Tracks Logical Sym Tracks STD <=> BCV
-------------------------- ------------------------------------- ------------

endbkp_offlineP81.log (72%)

2 Intern

 • 

2.8K Posts

August 31st, 2007 02:00

The log shows that everything -from TF perspective- is fine. The dashes are only a line drawn in ascii characters :-) ..
Now it's mandatory to understand WHY you can't mount the devices ..

Could you please paste the commands you use to mount the devices and their output ??

I think I'll ask some more commands later .. some more vgdisplay and similar commands .. or tomorrow if it's too late for you :-)

-s-

2 Intern

 • 

20.4K Posts

August 31st, 2007 03:00

are you trying to mount BCVs on the same host as the STD ?

17 Posts

September 2nd, 2007 18:00

There is a Concept of map file in HPUX LVM. I have seen in case of migrations, that is quite helpful for vgexport,vgimport properly.

have you used that while doing migration ?

Cheers ..

Munish

20 Posts

September 18th, 2007 11:00

Your script says it split, but you might add something to check that it has finished in the background and it's reflected in your logfile......like:

symmir -g -bg -split -i 60 -c 180 verify

You want to be sure that it finished off splitting completely before you start mounting.

Folks have asked if you are trying to remount this on same host - I would hope not, cause that could become a problem.

If your trying to mount it on another HPUX box, then be sure you have the correct c-t-d- address for the BCV disk. On this BCV-HPUX box, make sure you have done all the LVM steps you need. In other words remember to create a mapfile of that vg with command on the original STD HPUX host you would run:

vgexport -pv -m /etc/lvmconf/bcv-vg.map123 /dev/bcv-vg

Copy this mapfile over to the BCV-HPUX host.

Next you will need to use the c-t-d- info. Your commands might look like this:

On the BCV-HPUX host

mkdir /dev/bcv-vg
mknod /dev/bcv-vg/group c 64 0x020000
vgimport -v -m /etc/lvmconf/bc-vg.map123 -f /dev/bcv-vg

Notice I did NOT use the -s option in my vgexport. This saves from having to do a vgchgid. And I used the -f option on the vgimport command. This file simply has /dev/dsk/c-t-d- info (one per line) to be used. It would reflect the c-t-d- of the BCV device ONLY.


Rgrds,

2 Intern

 • 

2.8K Posts

September 19th, 2007 01:00

Your script says it split, but you might add
something to check that it has finished in the
background and it's reflected in your
logfile......like:

symmir -g -bg -split -i 60 -c 180 verify

You want to be sure that it finished off splitting
completely before you start mounting.


Not sure it's really needed .. As long as the foreground split is completed, the host can look at the bcv devices. Any hit on a track still bound to the STD will delay the access to the bcv since maybe bg split is still working, but won't be denied.

Folks have asked if you are trying to remount this on
same host - I would hope not, cause that could become
a problem.


That's exactly why I did ask ;-)

Notice I did NOT use the -s option in my vgexport.
This saves from having to do a vgchgid. And I used
the -f option on the vgimport command. This file
simply has /dev/dsk/c-t-d- info (one per line) to be
used. It would reflect the c-t-d- of the BCV device
ONLY.


Some notes ..

The mapfile is needed if you are using custom names for your lvs. If the production VG uses standard names (lvol1 lvol2 and so on) there is no need to use a mapfile. But also considere that option "-s" can be useful if the BCV host can see only the BCV devices .. you won't need to know and specify the c-t-d since vgimport will seek the VGID specified in the mapfile with option "-s" and automagically build the list of devices. Since the BCVhost -hopefully- will see only the BCVs, the VGID of the production VG will be unique on the BCV host.

Hope it's useful... :)

-s-

385 Posts

September 19th, 2007 04:00

There is no issue mounting on the same host AS long as you run the vgchgid. In fact you have to be very careful that you DO a vgchgid if the devices are on the same host (regardless of having done the export with the -s option) otherwise you run the risk of the server incorrectly getting devices mixed (clone source and target) if you ever ran a vgscan on the system.

I have some code I would share showing how to correctly/safely handle an HP-UX import process if you would be interested.

385 Posts

September 19th, 2007 04:00

There is no issue mounting on the same host AS long as you run the vgchgid. In fact you have to be very careful that you DO a vgchgid if the devices are on the same host (regardless of having done the export with the -s option) otherwise you run the risk of the server incorrectly getting devices mixed (clone source and target) if you ever ran a vgscan on the system.

I have some code I would share showing how to correctly/safely handle an HP-UX import process if you would be interested.

2 Intern

 • 

2.8K Posts

September 19th, 2007 05:00

Bodnarg it's true that you can/must use vgchgid if you want to mount the BCVs on the same host. But in my experience it's safer to use a different host and avoid vgchgid..
I'm pretty sure your car have airbags.. And I'm pretty sure they are useful .. But it's better NOT to use them ;-)

Even the better code may fall into an error and run vgchgid on a production volume .. The recovery can be a pain, don't you think?? :-)

-s-

385 Posts

September 19th, 2007 12:00

I'd agree its safer, but definitely very manageable - ran this way in an environment for many years with no issue. As long as you do the vgchgid as part of the split process the risk is pretty low since the devices. For HP-UX you'd have to export the groups and do a scan to get burned by this.

Obviously using a seperate host is the ideal / simplest solution, but not always possible depending on the situation/environment.

I'd say a better analogy would be it is better to leave your safety enabled on your gun while it is holstered - but if you don't have a safety on your gun that does not mean that you should not take it to go hunting :)
No Events found!

Top