[Veritas-vx] vxconfigrestore question

[Asiye Yigit]

Hello all;

Ýf we take the disk group configuration backup to the customized directory;

After that one user removes the one volume;

Is it not possible to take volume information from the disk configuration backup?

I tested and I saw that it is not possible.

Am I wrong?Addition to this,

Vxconfigrestore is not running for every condition.

I think the disk group can't be imported to be able to run this command.

Do you know any way to re-created the same volume with the same information from the which command in veritas explorer command?

Regards,

[Dmitry Glushenok]

Hello,

If you will look into .cfgrec file - you will find full information about volume's configuration. To simplify file contents you can cat it to 'vxprint -D -' command. All you need then is to re-create subdisks/plexes/volumes with same offsets/lengths manually or feed needed .cfgrec sections to vxmake.

vxconfigrestore is a script and you can see how it uses vxmake to create vxvm objects.

P.S. IMHO It is even safer to do things manually as you controlling the process. Seen few cases when vxconfigrestore was unable to do anything or was breaking existing configuration.

Post by Asiye Yigit
Hello all;
Ä°f we take the disk group configuration backup to the customized directory;
After that one user removes the one volume;
Is it not possible to take volume information from the disk configuration backup?
I tested and I saw that it is not possible.
Am I wrong?Addition to this,
Vxconfigrestore is not running for every condition.
I think the disk group can’t be imported to be able to run this command.
Do you know any way to re-created the same volume with the same information from the which command in veritas explorer command?
Regards,
_______________________________________________
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx

--
Dmitry Glushenok
Jet Infosystems

[P***@inform.gazprom.ru]

Hello all!



The traditional symmaskdb technology was replaced with Auto-provisioning Groups (see Solution Enabler Symmetrix Controls CLI 7.2)



Just noticed an interesting bug when configuring veritas disks on thin devices combined in storage groups. When adding a symdev A (thin device

for sample) to the symmetrix storage group a new lun id is presented to the symdev A. When removing this symdev A from the storage group this lun id can be used by another newly added symdev B. When giving back the symdev A to the storage group it is presented with the new lun id. As a result Veritas gets two identical ebn disk names which can lead to some very bad things. There can be two workarounds:

1) Using reserve lun id option for symdev on symmetrix storage group to exclude any confusion about lun ids;

2) vxddladm set namingscheme=ebn persistence=no use_avid=yes



I think the best option is number 2. But no sure about potential problems because of changing default persistence (=yes) meaning



Any suggestions?



Regards, Pavel Tsvetkov



P.S. about this option from man pages:







persistence

Specifies whether the names of disk dev-

ices that are displayed by VxVM remain

unchanged after disk hardware has been

reconfigured and/or the system rebooted.



If persistence is on, the DDL assigns device names

from the persistent device name database, rather

than generating new names according to the OSN or

EBN naming scheme.



If the naming scheme is OSN, name persistence is

off by default. The generated names are not likely

to differ from the names in the persistent name

database, unless a change causes the OS to assign

a new path name for a device.



If the naming scheme is EBN, name persistence is

on by default. Certain configuration changes on

the array side could cause the generated name to

be different from the name in the persistent name

database. When name persistence is on, the name

from the persistent names repository is used for

the DMP meta-device, unless

the user changes it. .

[Asiye Yigit]

Hello Dmitry;

Thank you so much.



I have used

vxprint –D - -rhtmqQ

And

vxmake –d



best regards;





From: Dmitry Glushenok [mailto:***@jet.msk.su]
Sent: Tuesday, May 24, 2011 10:05 AM
To: Asiye Yigit
Cc: veritas-***@mailman.eng.auburn.edu
Subject: Re: [Veritas-vx] vxconfigrestore question



Hello,



If you will look into .cfgrec file - you will find full information about volume's configuration. To simplify file contents you can cat it to 'vxprint -D -' command. All you need then is to re-create subdisks/plexes/volumes with same offsets/lengths manually or feed needed .cfgrec sections to vxmake.



vxconfigrestore is a script and you can see how it uses vxmake to create vxvm objects.



P.S. IMHO It is even safer to do things manually as you controlling the process. Seen few cases when vxconfigrestore was unable to do anything or was breaking existing configuration.



On 23.05.2011, at 19:03, Asiye Yigit wrote:





Hello all;

Ä°f we take the disk group configuration backup to the customized directory;

After that one user removes the one volume;

Is it not possible to take volume information from the disk configuration backup?

I tested and I saw that it is not possible.

Am I wrong?Addition to this,

Vxconfigrestore is not running for every condition.

I think the disk group can’t be imported to be able to run this command.

Do you know any way to re-created the same volume with the same information from the which command in veritas explorer command?

Regards,



_______________________________________________
Veritas-vx maillist - Veritas-***@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx