VMAX, PowerMax: Después de reiniciar un host en el que se ejecuta VxVm 8.0 o superior, algunos LUN no son visibles

Resumen: Veritas 8.0 y versiones posteriores están comprobando el nivel de microcódigo que se ejecuta en un arreglo para determinar sus características soportadas. Si los dispositivos del mismo arreglo informan un nivel de microcódigo diferente, Veritas lo considera anormal y no configura las rutas a los dispositivos. ...

Este artículo se aplica a Este artículo no se aplica a Este artículo no está vinculado a ningún producto específico. No se identifican todas las versiones del producto en este artículo.

Síntomas

Un host UNIX está conectado a un VMAX o PowerMax y ejecuta VxVm y VxDMP 8.0 o superior para administrar las múltiples rutas. Después de un reinicio, algunos de los dispositivos se configuran en el nivel del host, pero no en el nivel de Veritas.

INQ muestra diferentes niveles de microcódigo para los dispositivos que pertenecen al mismo arreglo:

# inq
...
/dev/rhdisk909                :EMC     :SYMMETRIX       :5876  :940339c000 :        39.1
/dev/rhdisk3779               :EMC     :SYMMETRIX       :5978  :9401bab008 :        20.0

Los dispositivos en cuestión se muestran en un arreglo que se migró mediante una migración no disruptiva (NDM). En tales casos, el número de serie del arreglo (94) y el ID de LUN (339c o 1bab) son una identidad suplantada. El siguiente comando revela la verdadera identidad del dispositivo:

# inq -native
...
/dev/rhdisk909                :EMC     :SYMMETRIX       :5978  :80005de000 :        39.1
/dev/rhdisk3779               :EMC     :SYMMETRIX       :5978  :80002bc000 :        20.0

Los diferentes niveles de microcódigo informados en los dispositivos se confirman con INQ en el modo DEBUG:

  • Dispositivo hdisk909
<02/17/2024 01:11:37.455866>             Leave: xsil_fill_in_inq_info, Return Value: 0
<02/17/2024 01:11:37.455875>                    device is spoofed
<02/17/2024 01:11:37.455884>                    is_EMC_device=1 symm_model=0x0a00 ucode_level=0x5876 ucode_date=0x08190002
<02/17/2024 01:11:37.455893>                    symm_dev_num=0x0339c symm_serial#=<00019xxxxx94>
<02/17/2024 01:11:37.455902>                    device_serial_number_ex : 940339c000
<02/17/2024 01:11:37.455911>                    device_serial_number    : 94!|k000
  • Dispositivo hdisk3779
<02/17/2024 01:11:37.469147>             Leave: xsil_fill_in_inq_info, Return Value: 0
<02/17/2024 01:11:37.469158>                    device is spoofed
<02/17/2024 01:11:37.469172>                    is_EMC_device=1 symm_model=0x0900 ucode_level=0x5978 ucode_date=0x07230008
<02/17/2024 01:11:37.469183>                    symm_dev_num=0x01bab symm_serial#=<00019xxxxx94>
<02/17/2024 01:11:37.469194>                    device_serial_number_ex : 9401bab008
<02/17/2024 01:11:37.469204>                    device_serial_number    : 94BAB008

Según el artículo de Veritas La mayoría de los dispositivos faltan en el gabinete EMC VMAX después de la actualización a Infoscale 8.0 desde Este hipervínculo lo redirige a un sitio web fuera de Dell Technologies., Veritas 8.0 no es compatible con dispositivos del mismo arreglo (xx94 aquí) que informan dos microcódigos diferentes (5876 y 5978 en el ejemplo anterior).

Causa

Cuando los dispositivos se migraron inicialmente, la identidad de los dispositivos del arreglo de origen se replicó en el arreglo de destino, junto con el nivel de microcódigo. Después de la migración, tuvimos lo siguiente:

# inq
...
/dev/rhdisk909                :EMC     :SYMMETRIX       :5876  :940339c000 :        39.1
/dev/rhdisk3779               :EMC     :SYMMETRIX       :5876  :9401bab008 :        20.0


Algún tiempo después de la migración, el espacio en hdisk3779 ya no era necesario y el dispositivo se quitó del grupo de almacenamiento y se recuperó (eliminó). En el ejemplo anterior, LUN 1bab representa, en realidad, LUN 2BC en el arreglo xx80, como se ve en la salida del comando "inq native".

Se asignó nuevo espacio al host, nuevamente desde el arreglo xx80. Debido a que se eliminó el ID de LUN 2BC, este número de LUN se volvió a utilizar. Sin embargo, en tales casos, la identidad suplantada se recupera para que el nuevo dispositivo se presente como un dispositivo del arreglo anterior (9401b1b008) en lugar de un dispositivo del arreglo nuevo (80002bc00). El nivel de microcódigo del dispositivo falsificado no se conserva, por lo que ahora informa el microcódigo de la matriz de destino (5978 en nuestro caso). El tipo de arreglo tampoco se conserva (consulte INQ en modo DEPURACIÓN en la sección anterior, symm_model está 0x0a00 para hdisk909 y 0x0900 para hdisk3779).

Veritas 8.0 y versiones posteriores analizan el nivel de microcódigo asociado con los dispositivos para determinar el microcódigo que se ejecuta en el arreglo. También está analizando el modelo Symmetrix. A continuación, Veritas puede determinar qué funciones puede admitir el arreglo. En nuestro caso, para el arreglo xxx94, Veritas no puede determinar si el microcódigo es 5876 o 5978. Tampoco puede determinar el nivel de Symmetrix. Como resultado, todos los dispositivos que aparecen con el microcódigo 5978 no están configurados por Veritas.

Resolución

Después de una migración de NDM y una eliminación de la conexión al arreglo de origen, si se debe recuperar un dispositivo migrado, se debe eliminar su identidad suplantada antes de esta eliminación.

Si esto no se hace, la única solución para recuperar el acceso a todos los dispositivos es eliminar la identidad suplantada de todos los dispositivos que aparecen en el arreglo de origen del NDM.

Productos afectados

VMAX
Propiedades del artículo
Número del artículo: 000222481
Tipo de artículo: Solution
Última modificación: 19 may 2025
Versión:  3
Encuentre respuestas a sus preguntas de otros usuarios de Dell
Servicios de soporte
Compruebe si el dispositivo está cubierto por los servicios de soporte.