Re: vPar storage migration (396 Views)
Reply
Honored Contributor
Bill Hassell
Posts: 14,217
Registered: ‎05-29-2000
Message 1 of 8 (422 Views)
Accepted Solution

vPar storage migration

I have an rx8640 running 6 vPars (A.05.04.01) that we need to migrate to new storage. However, we are trying to migrate one vPar at a time as everything (naturally) is production and downtime is limited. We imaged all the LUNs onto the new storage, then rezoned that vPar's HBA to point to the new storage (and unpresent the old storage). Because we could not reboot the rest of the vPars, we did not have access to EFI to scan for the new hardware path. And vparefiutil doesn't seem to report anything new.  As a result, we could not discover the full boot path and therefore could not modify the boot path in the vpdb.

 

The vPar started to boot using the index -E 0 but panic'ed with the well known error "NEEDS DRIVERS?". Since I can't run ioscan for that vPar, has anyone come up with a way to see the new boot path, or possibly compute the new path given LUN and WWN info from the storage?

 

Also, vparefiutil -u looks like something useful but it's not clear what updating the vpar database will accomplish. How can we change the vpdb for this vpar without a path for the boot device?

Honored Contributor
Duncan Edmonstone
Posts: 5,684
Registered: ‎08-05-2000
Message 2 of 8 (396 Views)

Re: vPar storage migration

Bill,

 

A bit fuzzy on this, as it is years since I did it, but I have a memory of doing the following:

 

  1. shutdown the vPar which is going to be re-assigned to new storage
  2. Use vparmodify to temporarily assign the FC cards which you would be booting from to another vPar
  3. Use ioscan to get paths to the new boot devices
  4. use vparmodify to put the FC card back under control of the correct vPar and assign the new boot paths
  5. Restart vPar

I guess this stil requires 2 of your 6 vPars to be down at the same time as you go through the work - don't know if that is an option or not...

 


HTH

Duncan
Frequent Advisor
Primesh Abeysinghe
Posts: 39
Registered: ‎04-27-2010
Message 3 of 8 (387 Views)

Re: vPar storage migration

Hi bill,

 

It is not clear hope you are using san boot ?

 

If it possible please share

 

#vparstatus -v

 

regards,

primesh

Honored Contributor
Bill Hassell
Posts: 14,217
Registered: ‎05-29-2000
Message 4 of 8 (383 Views)

Re: vPar storage migration

Yes, this is a SAN boot.

Duncan's answer is what I've read before, but as it requires 2 vPars down at the same time, I'm looking for another method.

 

I have a document that describes the PARISC hardware path decoding of each comnent in a fiber device path. Is there such a document for Itanium?

Frequent Advisor
Primesh Abeysinghe
Posts: 39
Registered: ‎04-27-2010
Message 5 of 8 (377 Views)

Re: vPar storage migration

hi,

 

This may be wild answer but hope it will help you with situation. but I need to know how you present the disk space to the Vpars. that is what I ask for #vparstatus -v

 

1. Present the HBA card directly to the system and the present the disks to wwn 

2.  You keep the HBA card in VSP and present it there and then use avio method

 

if you use second method you will be able do this easily. I hope you have a good understanding about the methods.

 

if you have configured ignite no need to worry about the OS part you can easily take a back up and restore, if something goes wrong, restore will not take 15 min but depend on the performance of the storage .

 

 since you  have created  new data LUNs if you use avio method you can present it individually to the vpar so there will no t much difficulty.

 

--

regards,

primesh 

Honored Contributor
Duncan Edmonstone
Posts: 5,684
Registered: ‎08-05-2000
Message 6 of 8 (371 Views)

Re: vPar storage migration

>> I have a document that describes the PARISC hardware path decoding of each comnent in a fiber device path. Is there such a document for Itanium?

 

Bill, IIRC in vPars even on Itanium with 11.31, you still have to use legacy hardware paths with the vPars command, so wouldn't the way the component of the fiber path is calculated be the same as on an older PA-RISC system anyway? I presume you know the HW path component that makes up the path down to the FC port, and it's just the part related to the FC target that you need to work out? From what I remember this is based on the FCID of the target storage (which you can get from the switch) and then the LUN number of the target LUN in the storage and the type of addressing used by the target disk array (although I would usually expect it to be volume set addressing?)


HTH

Duncan
Acclaimed Contributor
Torsten.
Posts: 23,444
Registered: ‎10-02-2001
Message 7 of 8 (366 Views)

Re: vPar storage migration

[ Edited ]

Not exactly sure what you did in detail.

But if you see "need drivers"the kernel is loaded and mounting the file system failed, right?

This is what I would probably do:

- clone the LUN to new storage
- present the new storage
- get the path
- vparmodify ... -m io:<new_path>:BOOT
- # setboot -a mirror_disk_hw_path
- # vparefiutil -u [-H mirror_disk_hw_path]
- shutdown the vpar, unpresent old storage, boot the vPar
- in case of problems I would try to boot into LVM maintenance mode: winona1# vparboot -p winona2 -o "-lm"

 

 

Why not do the migration online and create a LVM mirror with the new storage?


Hope this helps!
Regards
Torsten.

__________________________________________________

There are only 10 types of people in the world -
those who understand binary, and those who don't.

__________________________________________________

No support by private messages. Please ask the forum!

If you feel this was helpful please click the KUDOS! thumb below!   
Honored Contributor
Bill Hassell
Posts: 14,217
Registered: ‎05-29-2000
Message 8 of 8 (355 Views)

Re: vPar storage migration

This is the plan I am going to use.

Originally, we were trying to simply change the presentation and boot directly with one boot LUN.

But creating a new LUN on the new path and then booting the old path is working OK.

We mirrored to the new LUN and then rebooted to the new LUN.

 

Now that we've got the new path identified, I was able to map the SAN information to the legacy path format.

The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.