hpux 11.31 vgimport results in legacy dsfs

[Doug O'Leary]

Hey;

I'm still new to the persistent DSFs. I ran a manual migration of a ver 2.1 volume group that was built using persistent DSFs to another node. The disks are showing up in the second node as legacy DSFs and I'd like to have LVM use the persistent.

Anyone know how I can convert those back to persistant DSFs?

Thanks.

Doug O'Leary

[Steven E. Protter]

Shalom,

Can you post:
ioscan -fnCdisk
and
ioscan -fnNCdisk

output so I can get a handle on this.

also:

ioscan -m dsf


SEP

[Doug O'Leary]

Hey;

Thanks for the response. Maybe some examples will help. The persistent DSFs seem to be operating just fine:

# ioscan -m dsf | tail
/dev/rdisk/disk126 /dev/rdsk/c3t13d6
/dev/rdsk/c5t13d6
/dev/rdisk/disk127 /dev/rdsk/c3t13d7
/dev/rdsk/c5t13d7
/dev/rdisk/disk128 /dev/rdsk/c3t14d0
/dev/rdsk/c5t14d0
/dev/rdisk/disk129 /dev/rdsk/c3t14d1
/dev/rdsk/c5t14d1
/dev/rdisk/disk130 /dev/rdsk/c3t10d5
/dev/rdsk/c5t10d5

There are a couple of terabytes of disk space on this thing so the full output's going to be a bit unwieldy.

When I initially created vgoracle, I used the /dev/disk/disk## devices; however, after a vgimport and a manaul failover to an adoptive node, I appear to be using the legacy:

# vgdisplay -v vgoracle | grep -i 'pv name' | tail -6
PV Name /dev/dsk/c3t14d0
PV Name /dev/dsk/c5t14d0 Alternate Link
PV Name /dev/dsk/c3t14d1
PV Name /dev/dsk/c5t14d1 Alternate Link
PV Name /dev/dsk/c3t10d5
PV Name /dev/dsk/c5t10d5 Alternate Link

I want to go back to using the persistent ones as this guy's partner is doing:

$ ssh usilhc03 vgdisplay -v vgoracle | grep -i 'pv name' | tail -2
PV Name /dev/disk/disk168
PV Name /dev/disk/disk169


I'm thinking maybe moving lvmtab_p out of the way and running vgscan; however, I wanted to check and see if there's an approved method of converting to persistent dfs's...

Thanks again for the reply.

Doug

[James R. Ferguson]

Hi Doug:

You should be able to 'vgexport' and then 'vgimport' using the '-N' option to gain representation in the new, agile mode.

See the manpages for 'vgexport' and 'vgimport' for more information.

Regards!

...JRF...

[Doug O'Leary]

Hey;

So, a faulty vgimport execution. Noted. Any way of converting those back to persistent dsfs w/o the vgexport? The dbas are a bit twitchy about giving me the box unless it's some ungodly hour of the night...

Thanks alot. That, at least, explains how I got here and how to avoid it in the future.

Doug

[James R. Ferguson · Accepted solution]

Hi Doug:

Under the circumstances, I think the 'vgimport' is your only option. There are more details (and things you can do to protect yourself from falling into the same dilemma in the future, here:

http://bizsupport.austin.hp.com/bc/docs/support/SupportManual/c01916036/c01916036.pdf

Regards!

...JRF...

[Doug O'Leary]

Hey;

Well, that was too easy; I should have thought of that. The pdf doc says the way to migrate the vgs is to export/import; however, later describes the vgdsf script and casually mentions that it simply extends the vgs with the agile addresses and removes the legacy.

Duh!

Two inline scripts later and I'm all set.

Thanks; appreciate the link to the pdf and responses.

Doug O'Leary

[James R. Ferguson]

Hi (again) Doug:

> The pdf doc says the way to migrate the vgs is to export/import; however, later describes the vgdsf script and casually mentions that it simply extends the vgs with the agile addresses and removes the legacy.

Yes, I missed that too in my first read. It would be a better document if it cited the script "up-front" together with the 'vgimport'/'vgexport' and 'vgscan' enhancements. :-)

Regards!

...JRF...

[melvyn burnard]

The simplest way is to use the vgdsf command, for which there is no man page.
Simply use one of the arguments:
-a add Agile address
-r remove legacy address
-c convert (do both of the above)