The first thing to note is that NetWorker does not 'apply Persistent Binding in Linux'. NetWorker V7.4 SP2 and later make use of persistently-bound device names that are found in Linux. NetWorker for Linux has been enhanced to look in several places in the Linux file system for directories containing persistenly-named symbolic links and, if found, use them, instead of the /dev/nstX device names. On SLES 9 SP3, for instance, that directory is /dev/tape/by-id. Other operating system versions/distributions put them in somewhat different places.
Note that you must select the 'Use persistent names' attribute in the device resource in order for NetWorker to use the persistenly-bound device names. Also note that this persistent binding use in NetWorker only works on Linux (added in NetWorker V7.4 SP2) and Windows (added in NetWorker V7.5), and is ignored on all other operating systems.
I've tested this and know that it works in SLES 9 SP3, SLES 10 SP1 and in RHEL 4.7 and RHEL 5.3 (see http://kbase.redhat.com/faq/docs/DOC-4202); other distributions may work as well, but I know from experience that Red Hat versions earlier than 4.7 and 5.3 had udev problems that caused their automatic rules to not generate correct and complete persistenly-named symbolic links. The key point here is that, on these operating systems, you do not have to write any udev rules; the default, automatically-used, udev rules that come with the operating system provide the persistently-named symbolic links automatically. So, use these, and you get the benefits of persistent binding without the pain of fiddling with udev rules.
Documentation for 'Use persistent names' is only (at this time) in the NetWorker V7.4 Release Notes, available on Powerlink at Home > Support > Technical Documentation and Advisories > Software ~ J-O ~ Documentation > NetWorker Family > NetWorker > 7.4 & Service Packs.
NetWorker does, in fact, have a least two ways to change an existing device resource configuration, without resorting to removing/re-creating the jukebox. You can use the CLI command 'jbedit':
jbedit ¿ add and delete device definitions to and from a NetWorker jukebox.
See also the Library reconfiguration section in Chapter 3:Configuring Libraries and Devices in the NetWorker Administration Guide.
Thank you. I am aware of this. I am wondering, when we update to 5.x, do I have to delete and add devices, if the persistent name changes. Networker does not have a modify command.
Thank you. On other platforms, the bindings stay the same after version upgrades. We are now having an issue, where the mappings keep changing. We have persistent binding applied. We are using Networker, not UDEV rules. The kernel is 2.6, redhat is 4.4 (I realize that the specs says start at 4.6), udev rpm is ( udev-039-10.22.el4_7.1), networker release 7.4.
Since NetWorker uses the device special files provided by the operating system/driver, and udev creates these on Red Hat, I don't know what this means.
We have just configured a Quantum Scalar i80 with 2 x LTO5 drives FC connected to a Oracle Enterprise Linux 5.4 on HP DL370 via Brocades 8GB dual port HBAs which have been HP branded. We used persistent names when we configured the Tape Library. How do we confirm that persistent bindings has been enabled and no more configurations have to be done?
I'm not familiar with Oracle Enterprise Linux. But if NetWorker saw and used the persistenly-named symbolic links to your autochanger and tape devices, then I believe you're all set.
Inquire as of I believe 7.4 SP 2 allows you to use the -p switch, which should specifically query for persistent names.
When you Scan for Devices in the NetWorker GUI - you also need to tick the 'Use Persistent Names' in the Scan form.
Last - ensure that the entries have in fact been created in the /dev/tape/by-id directory. The 'tapes' command will, I believe, return the active tape handles.
tlemons1
1 Rookie
•
87 Posts
0
July 9th, 2009 12:00
The first thing to note is that NetWorker does not 'apply Persistent Binding in Linux'. NetWorker V7.4 SP2 and later make use of persistently-bound device names that are found in Linux. NetWorker for Linux has been enhanced to look in several places in the Linux file system for directories containing persistenly-named symbolic links and, if found, use them, instead of the /dev/nstX device names. On SLES 9 SP3, for instance, that directory is /dev/tape/by-id. Other operating system versions/distributions put them in somewhat different places.
Note that you must select the 'Use persistent names' attribute in the device resource in order for NetWorker to use the persistenly-bound device names. Also note that this persistent binding use in NetWorker only works on Linux (added in NetWorker V7.4 SP2) and Windows (added in NetWorker V7.5), and is ignored on all other operating systems.
I've tested this and know that it works in SLES 9 SP3, SLES 10 SP1 and in RHEL 4.7 and RHEL 5.3 (see http://kbase.redhat.com/faq/docs/DOC-4202); other distributions may work as well, but I know from experience that Red Hat versions earlier than 4.7 and 5.3 had udev problems that caused their automatic rules to not generate correct and complete persistenly-named symbolic links. The key point here is that, on these operating systems, you do not have to write any udev rules; the default, automatically-used, udev rules that come with the operating system provide the persistently-named symbolic links automatically. So, use these, and you get the benefits of persistent binding without the pain of fiddling with udev rules.
Documentation for 'Use persistent names' is only (at this time) in the NetWorker V7.4 Release Notes, available on Powerlink at Home > Support > Technical Documentation and Advisories > Software ~ J-O ~ Documentation > NetWorker Family > NetWorker > 7.4 & Service Packs.
Hope this helps.
tl
tlemons1
1 Rookie
•
87 Posts
0
July 10th, 2009 11:00
NetWorker does, in fact, have a least two ways to change an existing device resource configuration, without resorting to removing/re-creating the jukebox. You can use the CLI command 'jbedit':
jbedit ¿ add and delete device definitions to and from a NetWorker jukebox.
See also the Library reconfiguration section in Chapter 3:Configuring Libraries and Devices in the NetWorker Administration Guide.
Hope this helps
tl
Bernie-_qkMc
3 Posts
0
July 10th, 2009 11:00
I am aware of this.
I am wondering, when we update to 5.x, do I have to delete and add devices, if the persistent name changes. Networker does not have a modify command.
ble1
4 Operator
•
14.4K Posts
0
July 21st, 2009 05:00
delete and add devices, if the persistent name
changes.
Yes.
Bernie-_qkMc
3 Posts
0
August 14th, 2009 10:00
tlemons1
1 Rookie
•
87 Posts
0
August 17th, 2009 11:00
Since NetWorker uses the device special files provided by the operating system/driver, and udev creates these on Red Hat, I don't know what this means.
tl
Benz-Stevens
16 Posts
0
January 27th, 2011 11:00
Hi,
We have just configured a Quantum Scalar i80 with 2 x LTO5 drives FC connected to a Oracle Enterprise Linux 5.4 on HP DL370 via Brocades 8GB dual port HBAs which have been HP branded. We used persistent names when we configured the Tape Library. How do we confirm that persistent bindings has been enabled and no more configurations have to be done?
Regards
Stevens
tlemons1
1 Rookie
•
87 Posts
0
January 28th, 2011 07:00
Hi Stevens
I'm not familiar with Oracle Enterprise Linux. But if NetWorker saw and used the persistenly-named symbolic links to your autochanger and tape devices, then I believe you're all set.
tl
Benz-Stevens
16 Posts
0
March 14th, 2011 15:00
Hi,
We are still getting nst0 names but not seeing any long persistent names in the configuration...
Regards
Stevens Newton
jkernagh
35 Posts
0
March 14th, 2011 16:00
Hi Stevens,
Inquire as of I believe 7.4 SP 2 allows you to use the -p switch, which should specifically query for persistent names.
When you Scan for Devices in the NetWorker GUI - you also need to tick the 'Use Persistent Names' in the Scan form.
Last - ensure that the entries have in fact been created in the /dev/tape/by-id directory. The 'tapes' command will, I believe, return the active tape handles.
Try those and let us know! Cheers, James.