TSM更换driver问题的解决

今天偶然看到，贴到这里来吧，大家都方便

从 SAN 上的设备更改恢复
|由于设备或接线更改了，SAN 环境可动态转变。由于总线复位或其它的环境更改，由 SAN 分配的设备标识可能会变化。SAN 的这一“动态”更改特性可能导致定 |义给服务器（或存储代理程序）或为其所知的“静态”定义失败或者变得不可预测。例如，根据服务器的原始路径规范和 LAN 的原始配置，服务器可能知道设备 id=1。然而，SAN 中的某些事 |件（添加了新设备，接线更改）将导致设备被指定为 id=2。当服务器尝试着用 |id=1 访问设备时，它将失败或者会收到错误的目标设备。通过使用序列号来确认服务器所联系到的设备身份，服务器协助从 SAN 上设备的更改恢复。

在定义设备（驱动器或库）时，您可选择指定该设备的序列号。若在定义设备时不指定序列号，则服务器在您定义此设备的路径时获取序列号。在任一情况下，服务器可将序列号存储在其数据库中。此后，服务器使用该序列号确认设备的身份来进行操作。

当服务器使用 SAN 上的驱动器和库时，服务器尝试验证它正在使用的设备为正确的设备。服务器通过使用您为其定义的路径中的设备名称来连接设备。服务器然后从设备请求序列号，并将该序列号与存储在数据库中的该设备序列号进行比较。

|若序列号不匹配，则服务器开始在 SAN 上的发现过程，以尝试发现具有匹配序列号的设备。若服务器找到有匹配序列号的设备，则它通过更新路径中的设备名称来改正服务器数据库中的路径定义。服务器发出带有关于对设备所作更改的信息的消息。然后服务器继续使用此设备。

如果您想了解 SAN 上的设备更改何时影响了 Tivoli Storage Manager ，则您可监视活动日志查看消息。以下是与序列号相关的消息的号码范围：

| |ANR8952 到 ANR8958 |ANR8961 到 ANR8968 |ANR8974 到 ANR8975
限制:
一些设备不具有将其序列号报告给应用程序（比如 Tivoli Storage Manager 服务器）的能力。若服务器不能从设备获取序列号，则它不能协助您更改此设备在 SAN 上的位置。

tsm 5.2以上已经支持该功能,在早期实施tsm 5.1时,经常会有设备名变更的情况,只能persident binding来解决.