- Community Home
- >
- Servers and Operating Systems
- >
- Legacy
- >
- Operating System - Tru64 Unix
- >
- Boot on SAN MSA 1000
Operating System - Tru64 Unix
1753269
Members
5041
Online
108792
Solutions
Forums
Categories
Company
Local Language
юдл
back
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
юдл
back
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Blogs
Information
Community
Resources
Community Language
Language
Forums
Blogs
Go to solution
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-08-2004 05:24 AM
тАО04-08-2004 05:24 AM
Dear All,
I`m trying to configure boot on SAN from Alpha sistem running Tru64 UNIX with MSA1000.
I`m using two HBA adapters (FCA-2354)with latest available firmware configured for fabric topology.
MSA1000 have two 2/8FC shitches.
MSA 1000 controllers are configured for Tru64.
There is no problem to access and use all LUN`s configured on MSA 1000 when system is booted from local system disk.
In console mode, after WWIDMGR -QUICKSET command, all LUN`s are recognized by the system with message that they can be used after INIT command.
When I submit INIT command,on a next boot,there is no any information about previously detected MSA 1000 LUN`s.
Any suggestions or similar expirience?
Regards,
Goran
I`m trying to configure boot on SAN from Alpha sistem running Tru64 UNIX with MSA1000.
I`m using two HBA adapters (FCA-2354)with latest available firmware configured for fabric topology.
MSA1000 have two 2/8FC shitches.
MSA 1000 controllers are configured for Tru64.
There is no problem to access and use all LUN`s configured on MSA 1000 when system is booted from local system disk.
In console mode, after WWIDMGR -QUICKSET command, all LUN`s are recognized by the system with message that they can be used after INIT command.
When I submit INIT command,on a next boot,there is no any information about previously detected MSA 1000 LUN`s.
Any suggestions or similar expirience?
Regards,
Goran
Solved! Go to Solution.
3 REPLIES 3
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-08-2004 07:34 AM
тАО04-08-2004 07:34 AM
Re: Boot on SAN MSA 1000
Goran,
I am not sure I understand your problem description. Have you assigned an identifier to the logical disk that will be used for boot?
CLI> set unit_id 0 101
From your text it is not clear to me if you have specified this value during the quickset:
>>>wwidmgr -quickset -udid 101
After the INITIALIZE you _should_ see two devices named dga101.some_numbers and dgb101.some_numbers . The data disks will no longer be visible, but that is normal, because the SRM console does not have much understanding of Fibre Channel devices. The operating system will find the other disks anyway.
Next, you enter the boot paths:
>>> set bootdef_dev dga101.some_numbers,dgb101.some_numbers
If that does not work, I ask you to repeat the commands while taking a log of your console output. Please attach it as a .TXT file, so the spaces do not get collapsed.
I am not sure I understand your problem description. Have you assigned an identifier to the logical disk that will be used for boot?
CLI> set unit_id 0 101
From your text it is not clear to me if you have specified this value during the quickset:
>>>wwidmgr -quickset -udid 101
After the INITIALIZE you _should_ see two devices named dga101.some_numbers and dgb101.some_numbers . The data disks will no longer be visible, but that is normal, because the SRM console does not have much understanding of Fibre Channel devices. The operating system will find the other disks anyway.
Next, you enter the boot paths:
>>> set bootdef_dev dga101.some_numbers,dgb101.some_numbers
If that does not work, I ask you to repeat the commands while taking a log of your console output. Please attach it as a .TXT file, so the spaces do not get collapsed.
.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-08-2004 06:45 PM
тАО04-08-2004 06:45 PM
Re: Boot on SAN MSA 1000
Uve,
In storage configuration I have configured 7 Luns with unit id`s from 0 to 6. I have a cluster with 2 nodes that should be booted from lun0 (node1) and lun1 (node2).
The unit id for LUN0 (boot disk for node1)is "0" but not "101" as you suggest. Is it a problem?
The unit id for LUN1 (boot disk for node2)is "1".
I will try to explain the problem once more,
Actually , the problem is that HBA or Alpha do not save configuration about detected LUN`s on a next reboot. So the system can not find selected boot paths which point to
lun 0.
In storage configuration I have configured 7 Luns with unit id`s from 0 to 6. I have a cluster with 2 nodes that should be booted from lun0 (node1) and lun1 (node2).
The unit id for LUN0 (boot disk for node1)is "0" but not "101" as you suggest. Is it a problem?
The unit id for LUN1 (boot disk for node2)is "1".
I will try to explain the problem once more,
Actually , the problem is that HBA or Alpha do not save configuration about detected LUN`s on a next reboot. So the system can not find selected boot paths which point to
lun 0.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-08-2004 07:24 PM
тАО04-08-2004 07:24 PM
Solution
Hello Goran,
it could be that there is a misunderstanding between us. Unfortunately there is no unambiguous use of the name 'identifier'. It looks like you are talking about the, well, let us call it 'logical disk number' in the case of the MSA1000. I have attached a small .TXT file that shows such a logical disk (Unit 0). In the third line you see that it says 'Unit 0:'. Please note that this IS NOT Fibre Channel LUN 0! The MSA1000 by-default presents a non-disk device as LUN 0, but the WWIDMGR does not show it.
In the next line you see:
'In PDLA mode, Unit 0 is Lun 1; In VSA mode, Unit 0 is Lun 0.'
Tru64 Unix uses PDLA (Peripherial Device LUN Addressing), so it sees 'Unit 0' as FC LUN 1. Try a 'WWIDMGR -show wwid -full' and compare this with the output of 'show units' on the MSA:
Alpha: [0] UDID:101 WWID:01000010:6008-05f3-0004-e560-0000-0000-551a-0002 (ev:none)
MSA: Device Identifier : 600805F3-0004E560-00000000-551A0002
A little bit below the line from the Alpha you will see the LUN address (I have marked this with =LUN= in the attachment).
You need to assign a non-zero 'unit identifier' (as marked with =UNITID=) so that the AlphaServer console can 'remember' the setting.
If it is still unclear or does not work, I really ask you to post a log of your tries and the output of the following commands as a text-attachment, so that somebody can look at them. I am afraid a verbal description will not get us any further, sorry.
CLI> show units
>>> wwidmgr -show wwid -full
--
Why I have chosen 101? Well, the 'unit identifier' is also used by the OpenVMS operating system where it makes sure that unique device names exist. I have multiple storrage array in the shop. I give them different identifier ranges, so any server can potentially access any LUN on any array and it is easier to tell from the unit number on which array the data is stored.
it could be that there is a misunderstanding between us. Unfortunately there is no unambiguous use of the name 'identifier'. It looks like you are talking about the, well, let us call it 'logical disk number' in the case of the MSA1000. I have attached a small .TXT file that shows such a logical disk (Unit 0). In the third line you see that it says 'Unit 0:'. Please note that this IS NOT Fibre Channel LUN 0! The MSA1000 by-default presents a non-disk device as LUN 0, but the WWIDMGR does not show it.
In the next line you see:
'In PDLA mode, Unit 0 is Lun 1; In VSA mode, Unit 0 is Lun 0.'
Tru64 Unix uses PDLA (Peripherial Device LUN Addressing), so it sees 'Unit 0' as FC LUN 1. Try a 'WWIDMGR -show wwid -full' and compare this with the output of 'show units' on the MSA:
Alpha: [0] UDID:101 WWID:01000010:6008-05f3-0004-e560-0000-0000-551a-0002 (ev:none)
MSA: Device Identifier : 600805F3-0004E560-00000000-551A0002
A little bit below the line from the Alpha you will see the LUN address (I have marked this with =LUN= in the attachment).
You need to assign a non-zero 'unit identifier' (as marked with =UNITID=) so that the AlphaServer console can 'remember' the setting.
If it is still unclear or does not work, I really ask you to post a log of your tries and the output of the following commands as a text-attachment, so that somebody can look at them. I am afraid a verbal description will not get us any further, sorry.
CLI> show units
>>> wwidmgr -show wwid -full
--
Why I have chosen 101? Well, the 'unit identifier' is also used by the OpenVMS operating system where it makes sure that unique device names exist. I have multiple storrage array in the shop. I give them different identifier ranges, so any server can potentially access any LUN on any array and it is easier to tell from the unit number on which array the data is stored.
.
The opinions expressed above are the personal opinions of the authors, not of Hewlett Packard Enterprise. By using this site, you accept the Terms of Use and Rules of Participation.
News and Events
Support
© Copyright 2024 Hewlett Packard Enterprise Development LP