01-17-2014 07:20 PM
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?
Solved! Go to Solution.
01-20-2014 01:51 AM
A bit fuzzy on this, as it is years since I did it, but I have a memory of doing the following:
- shutdown the vPar which is going to be re-assigned to new storage
- Use vparmodify to temporarily assign the FC cards which you would be booting from to another vPar
- Use ioscan to get paths to the new boot devices
- use vparmodify to put the FC card back under control of the correct vPar and assign the new boot paths
- 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...
01-20-2014 12:07 PM
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?
01-20-2014 10:34 PM
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.
01-21-2014 12:39 AM
>> 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?)
01-21-2014 04:32 AM - edited 01-21-2014 04:50 AM
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!
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!
01-21-2014 06:36 PM
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.