Funky characters in lvmtab, why?

[Todd Bowden]

I have a weird problem, and the only place I see it is on two machines that are in an MC/SG cluster and are attached to an EMC disk array. If I do a stings on a certain VG in /etc/lvmconf lets say sapvg19.conf I get an output like this:

/var/opt/omni/tmp/emc # strings /etc/lvmconf/sapvg19.conf
CONFIG01
/dev/sapvg19
/dev/rdsk/c6t8d1
/dev/rdsk/c0t0d1
LVMREC01(
#;o<
#;o<<
LVMREC01(
#;o<
#;o<<
#;o<<
#;o<
VGDA0001
;oVGSA0001;o
Is this weird or is it me?

[Sebastien Masson]

LVM tab is a binary file, use strings to extract information
i.e.: strings /etc/lvmtab

This file is generate by the vgscan command...

[Todd Bowden]

Sebastian,

I know its a binary file but have you seen anything like it. Usually an output looks like the following:

CONFIG01
/dev/sapvg20
/dev/rdsk/c6t9d1
/dev/rdsk/c0t1d1
LVMREC01(
LVMREC01(
VGDA0001
VGSA0001;p

[A. Clay Stephenson]

Hi Todd:

Nothing to worry about; that's just the luck of the draw. Remember, all strings looks for is 4 printables in a row - evan a blind monkey sitting at a keyboard has to get lucky sometimes. You particaular binary data happened to fall into a printable range.

[Sebastien Masson]

Depend on your shell, the command you use to extract data, two binary file can display different output with the same command in the same shell. You know, the data structure of LVM (VGRA and PVRA) put or not some value that sometime generate some funky caratere....

[Todd Bowden]

I have an issue with Omniback 3.0, EMC Integration and SAP. On serverA we have BCV's that can only be seen on serverA. We then have shared STD devices which can be seen by both servers. I have associated the BCV's to the particular STD devices (these associations will never change). I have done a full establish of this particular BCV to the STD device. Next I do a vgchgid on serverA on the devices in question. So far so good. I next mkdir /dev/bcvvg, mknod /dev/bcvvg/group c 64 0x220000, vgimport -v -m /etc/lvmconf/bcvvg.mapfile bcvvg /dev/dsk/cXtXdX, vgchange -a r bcvvg. Everything looks good until Omniback syncs the BCV to the STD device. The problem is now Omniback cannot do a vgchange -q n -a r /dev/bcvvg. The error message is:

vgchange: Warning: Couldn't attach to the volume group physical volume "/dev/dsk/c10t13d0":
Cross-device link
vgchange: Warning: couldn't query physical volume "/dev/dsk/c10t13d0":
The specified path does not correspond to physical volume attached to
this volume group
vgchange: Couldn't query the list of physical volumes.
vgchange: Couldn't activate volume group "/dev/bcvvg19":
Quorum not present, or some physical volume(s) are missing.

It seems like omniback is doing a Full establish for this one particular VG, is this true?

[Sebastien Masson]

I'm not an omniback specialist, but do you create a post/pre backup script with the symmir command to split the BCV and reestablish it ?! Because on my SUN system (where my Symmetrix is connected), when I do an establish, my BCV device desapear from the system and it become the STD device...

[Todd Bowden]

Sebastian,

No Omniback takes care of syncing the BCV's so I do not run any pre/post-exec commands.

[Sanjay_6]

Hi Todd,

I looked at a vg which is part of the SG, and here is the output of the same
# strings /etc/lvmconf/vg_test.conf

CONFIG01
/dev/vg_test
/dev/rdsk/c0t10d0
/dev/rdsk/c2t10d0
/dev/rdsk/c0t11d0
/dev/rdsk/c2t11d0
/dev/rdsk/c0t12d0
/dev/rdsk/c2t12d0
/dev/rdsk/c0t13d0
/dev/rdsk/c2t13d0
/dev/rdsk/c0t14d0
/dev/rdsk/c2t14d0
/dev/rdsk/c0t15d0
/dev/rdsk/c2t15d0
LVMREC01
LVMREC01
LVMREC01
LVMREC01
LVMREC01
LVMREC01
LVMREC01
LVMREC01
LVMREC01
LVMREC01
LVMREC01
LVMREC01
VGDA0001
VGSA0001;

Hope this helps.

Regds