Notas de la versión de VMware Virtual SAN 6.2

|

Actualizado: 24 de febrero de 2017

VMware Virtual SAN 6.2| 15 de marzo de 2016 | Compilación ISO 3620759

Compruebe las adiciones y las actualizaciones de las notas de la versión.

Contenido de las notas de la versión

Las notas de la versión abarcan los siguientes temas:

Novedades

Virtual SAN 6.2 presenta las siguientes características y mejoras nuevas:

  • Nuevo Compatibilidad con TLS. En vSphere 6.0 Update 3 y versiones posteriores, la compatibilidad con TLS v1.0, TLS v1.1 y TLS v1.2 está habilitada de forma predeterminada y se puede configurar. Obtenga información sobre cómo configurar TLS v1.0, TLS v1.1 y TLS v1.2 en el VMware Knowledge Base article 2148819. For a list of VMware products supported for TLS v1.0 disablement and the use of TLS v1.1/v1.2, consult artículo 2145796 de la base de conocimientos de VMware.

  • Desduplicación y compresión. Virtual SAN 6.2 admite la desduplicación y la compresión con el objetivo de eliminar datos duplicados. Esta técnica reduce el espacio de almacenamiento total requerido para sus necesidades. Al habilitar la desduplicación y la compresión en un clúster de Virtual SAN, las copias redundantes de los datos incluidos en un determinado grupo de discos se reducen a una única copia. La desduplicación y la compresión están disponibles como configuración de almacenamiento en todo el clúster en clústeres basados íntegramente en tecnología flash.

  • Codificación de borrado de RAID 5 y RAID 6. Virtual SAN 6.2 admite la codificación de borrado tanto de RAID 5 como de RAID 6 con el objetivo de reducir el espacio de almacenamiento requerido para proteger sus datos. RAID 5 y RAID 6 están disponibles como atributos de directivas para las máquinas virtuales de clústeres basados íntegramente en tecnología flash. Se puede utilizar RAID 5 en clústeres que tengan al menos cuatro dominios de errores y RAID 6 en clústeres con al menos seis dominios de errores.

  • Suma de comprobación de software. Virtual SAN 6.2 admite la suma de comprobación basada en software en clústeres híbridos y clústeres basados íntegramente en tecnología flash. El atributo de la directiva de suma de comprobación basada en software está habilitado de forma predeterminada en todos los objetos del clúster de Virtual SAN.

  • Nuevo formato en disco. Virtual SAN 6.2 admite actualizaciones del nuevo formato de archivo virtual 3.0 en disco a través de vSphere Web Client. Este sistema de archivos es compatible con las nuevas características del clúster de Virtual SAN. La versión 3.0 del formato en disco está basada en una tecnología de tamaño de bloque de 4K, que proporciona mayor eficiencia, pero puede reducir el rendimiento si las E/S del sistema operativo invitado no están alineadas con 4K. >

  • Límites de IOPS. Virtual SAN admite límites de IOPS para restringir la cantidad de operaciones de E/S (lectura/escritura) por segundo en un objeto determinado. Cuando la cantidad de operaciones de lectura/escritura alcanza el límite de IOPS, las operaciones se demoran hasta que expira el segundo actual. El límite de IOPS es un atributo de directiva que puede aplicarse en cualquier objeto de Virtual SAN, incluidos VMDK, espacio de nombres, etc.

  • IPv6. Virtual SAN admite el direccionamiento de IPv4 o IPv6.

  • Generación de informes de espacio. El supervisor de capacidad de Virtual SAN 6.2 muestra información sobre el almacén de datos de Virtual SAN, incluido el espacio utilizado y el espacio libre, y desglosa la capacidad utilizada por los diferentes tipos de objetos o tipos de datos.

  • Servicio de estado. Virtual SAN 6.2 incluye nuevas comprobaciones de estado que permiten supervisar el clúster, así como diagnosticar y solucionar problemas en él. Si el servicio de estado de Virtual SAN detecta problemas con el estado, activa eventos y alarmas en vCenter.

  • Servicio de rendimiento. Virtual SAN 6.2 incluye supervisores del servicio de rendimiento con estadísticas en el nivel del clúster, del host, de la máquina virtual y del disco. El servicio de rendimiento recopila y analiza estadísticas de rendimiento y muestra los datos en formato de gráfico. Se pueden utilizar los gráficos de rendimiento para administrar la carga de trabajo y determinar la causa principal de determinados problemas.

  • Caché en memoria de escritura directa. Virtual SAN 6.2 mejora el rendimiento de las máquinas virtuales mediante el uso de una memoria caché de lectura y escritura directa residente en el host. Este algoritmo de almacenamiento en caché reduce la latencia de E/S de lectura y el uso de recursos de red y CPU de Virtual SAN.

Versiones anteriores de Virtual SAN

En las notas de la versión, se describen las características y los problemas conocidos de Virtual SAN 6.0 y Virtual SAN 6.1. Las notas de la versión de Virtual SAN están disponibles en la siguiente ubicación:

Comunidad de VMware Virtual SAN

Puede utilizar el sitio web de la comunidad de Virtual SAN para dejar comentarios y solicitar asistencia en caso de tener problemas al usar Virtual SAN.

Actualizaciones de esta versión

Para obtener instrucciones sobre cómo actualizar Virtual SAN, consulte la documentación sobre VMware Virtual SAN 6.2.

Actualizar el formato en disco de los hosts con capacidad limitada

Cuando se actualiza el formato en disco de Virtual SAN, se lleva a cabo una evacuación del grupo de discos. A continuación, se elimina el grupo de discos y se actualiza a la versión 3.0 del formato en disco; luego, el grupo de discos se vuelve a agregar al clúster. En los clústeres de dos y tres nodos, o en los clústeres que no tienen suficiente capacidad para realizar la evacuación de cada grupo de discos, se debe utilizar el siguiente comando RVC para actualizar el formato en disco: vsan.ondisk_upgrade --allow-reduced-redundancy

Cuando se habilita la redundancia reducida, las máquinas virtuales quedan desprotegidas mientras se realiza la actualización, ya que este método no evacua los datos a los otros hosts del clúster. Lo que hace es simplemente quitar cada grupo de discos, actualizar el formato en disco y volver a agregar el grupo de discos al clúster. Todos los objetos permanecen disponibles, pero con una redundancia reducida.

Si se habilita la desduplicación y la compresión durante la actualización a Virtual SAN 6.2, se puede seleccionar Permitir redundancia reducida en vSphere Web Client.

Utilizar VMware Update Manager con clústeres ampliados

El uso de VMware Update Manager para actualizar hosts en paralelo puede provocar que el host testigo se actualice en paralelo con uno de los hosts de datos en un clúster ampliado. Si desea evitar problemas con la actualización, no configure VMware Update Manager para que actualice un host testigo en paralelo con los hosts de datos de un clúster ampliado. Actualice el host testigo una vez que todos los hosts de datos se hayan actualizado correctamente y hayan salido del modo de mantenimiento.

Comprobar errores de estado durante una actualización

Durante las actualizaciones del formato en disco de Virtual SAN, la comprobación del estado del disco físico y del estado de los metadatos puede presentar errores de forma intermitente. Estos errores pueden ocurrir si el proceso de transferencia desde caché es lento, muy probablemente debido a que Virtual SAN necesita hacer asignaciones de bloques físicos en los dispositivos de almacenamiento. Antes de seguir adelante, revise la situación de esta comprobación de estado una vez finalizado un período de actividad intensa, como la implementación de varias máquinas virtuales. Si la comprobación del estado sigue en color rojo, la advertencia es válida. Si la comprobación del estado es de color verde, puede omitir la advertencia anterior. Para obtener más información, consulte el artículo 2108690 de la base de conocimientos.

Limitaciones

En una configuración basada íntegramente en tecnología flash, Virtual SAN admite un tamaño máximo de memoria caché del búfer de escritura de 600 GB para cada grupo de discos.

Para obtener información sobre otros límites máximos en la configuración de la versión 6.2 de Virtual SAN, consulte el documento Valores máximos de configuración.

Problemas resueltos

  • Al actualizar a Virtual SAN 6.1, aparece el siguiente mensaje de error: No se puede acceder al paquete sin conexión del agente
    Este error ocurre cuando se actualiza de la versión 6.0 de Virtual SAN a la versión 6.1 mientras la comprobación de estado está habilitada. Durante el proceso de actualización, el VIB de la comprobación de estado se reemplaza y su servicio se interrumpe temporalmente. En algunos casos, la comprobación de estado puede generar un mensaje de error.

    El problema está resuelto en esta versión.

  • Cuando se coloca un host en un clúster de Virtual SAN para utilizarlo como testigo y, a continuación, se quita el host del clúster, el VIB de la comprobación de estado se elimina del host.
    Al quitar un host ESXi del clúster de Virtual SAN, se elimina su VIB de comprobación de estado. Por lo tanto, si el host es testigo del clúster, el estado de instalación del testigo aparece en color rojo.

    El problema está resuelto en esta versión.

  • Cuando se produce un error en el sitio gradual de un clúster ampliado de gran tamaño, como 15:15:1, donde cada nodo en un dominio de errores falla en secuencia con varios segundos entre un error y el siguiente, las máquinas virtuales pueden volverse inaccesibles o huérfanas.

    El problema está resuelto en esta versión.

  • No es posible configurar un grupo de discos basado íntegramente en tecnología flash en un host testigo de un clúster ampliado.
    Cuando se intenta agregar un host testigo con un grupo de discos basado íntegramente en tecnología flash a un clúster ampliado, la tarea genera un error y no se agrega ningún grupo de discos al host.

    El problema está resuelto en esta versión.

  • Al agregar un host al clúster de Virtual SAN, se activa un error del instalador.
    Cuando se agrega un host ESXi a un clúster donde la función de HA y el servicio de estado de Virtual SAN están habilitados, se pueden encontrar uno o los dos siguientes errores debido a una condición de carrera en la instalación del VIB:

    • En la vista de tareas, la tarea de configuración de vSphere HA puede generar un mensaje de error similar al siguiente: No se puede instalar el servicio del agente vCenter Server. Error de instalador desconocido

    • La tarea Habilitar agente puede generar un mensaje de error similar al siguiente: No se puede completar la operación. Consulte el registro de eventos para ver más detalles.

    El problema está resuelto en esta versión.

  • Problemas conocidos

    • No se pueden recuperar discos cuando la instancia de Virtual SAN está deshabilitada.
      Si se intenta recuperar discos y crear grupos de discos antes de habilitar Virtual SAN en el clúster, la operación generará un error.

      Solución alternativa: habilite Virtual SAN en el clúster antes de recuperar discos y de crear grupos de discos.

    • Después de habilitar Virtual SAN 6.2 mediante esxcli, la recuperación automática de discos no funciona.
      Si se habilita Virtual SAN 6.2 mediante esxcli, el método automático para recuperar discos no funciona.

      Solución alternativa: utilice vSphere Web Client para configurar la recuperación automática de discos. También puede utilizar el método de recuperación manual de discos.

    • Se produce un error en la actualización del host debido a que no hay suficiente espacio en la partición del bloqueador.
      La actualización presentó el siguiente mensaje de error en /var/log/esxupdate.log:

      Error al crear dir DB temporal: [Errno 28] No queda espacio en el dispositivo: '/locker/packages/var/db/locker/profiles.new' filename = /locker/packages/var/db/locker

      También puede ver los siguientes eventos en /var/log/vobd.log:

      2016-02-23T11:50:16.095Z: [VfatCorrelator] 676355748510us: [vob.vfat.filesystem.full] El volumen VFAT mpx.vmhba32:C0:T0:L0:8 (UUID 55e71deb-2f773c48-5dda-a0369f56dd20) está lleno. (585696 sectores, 0 sectores libres)

      2016-02-24T17:13:00.037Z: [VisorfsCorrelator] 782119690921us: [vob.visorfs.ramdisk.full] No se puede extender el archivo visorfs/vsantraces/vsantraces--2016-02-24T17h12m27s256.gz porque su disco ram (vsantraces) está lleno. 2016-02-24T17:13:00.037Z: [VisorfsCorrelator] 782119691022us: [esx.problem.visorfs.ramdisk.full] El disco ram 'vsantraces' está lleno. Como resultado, el archivo /vsantraces/vsantraces--2016-02-24T17h12m27s256.gz no pudo escribirse.

      Solución alternativa: elimine los archivos .gz de Virtual SAN Observer de la partición del bloqueador en el host y vuelva a intentar realizar la actualización.

      1. Inicie sesión en ESXi shell y revise el consumo de espacio en la partición del bloqueador ubicada en /locker/vsantraces/.

      2. Use el comando df -h para identificar cualquier partición VFAT utilizada al 100%. Por ejemplo:

        df -h
        Tamaño del sistema de archivos Usado Disponible % de uso Montado en
        vfat 249.7M 202.5M 47.3M 81% /vmfs/volumes/68a04eea-90716418-ba59-6dc3297f0ef8
        vfat 249.7M 202.4M 47.3M 81% /vmfs/volumes/6f065ae4-88f03302-b4c6-c0b765c07ff8
        vfat 285.8M 285.7M 112.0K 100% /vmfs/volumes/55e71deb-2f773c48-5dda-a0369f56dd20
        -------------------------------

      3. Quite los registros .gz de Virtual SAN Observer de la partición del bloqueador en el host (/locker/vsantraces/). Por ejemplo: vsanObserver--YYYY-MM-DDTxxhyymzzs.gz

      4. Vuelva a intentar actualizar el host.

    • Se produce un error en la corrección y la comprobación del cumplimiento cuando se aplica un perfil de host 6.0 Update 1 a un host 6.0 Update 2 con la vmknic de Virtual SAN configurada.
      Si se actualiza el host de ESXi 6.0 Update 1 a ESXi 6.0 Update 2 y, a continuación, se aplica el perfil de host, se produce un error y aparece el siguiente mensaje: Error inesperado al actualizar la tarea config spec: 'IPProtocol'

      Solución alternativa: es posible actualizar el host a 6.0 Update 2 y extraer el perfil de host del host actualizado para obtener la versión 6.0 Update 2 del perfil de host.

      También se puede editar el perfil de host y aplicar este perfil editado al host actualizado.

      1. Haga clic con el botón secundario en el perfil de host y elija el menú Exportar perfil de host. El perfil de host se exporta como un archivo .vpf.

      2. Con un editor de texto, abra el archivo .vpf y reemplace todas las instancias del siguiente texto:

        <parameter><key>IPProtocol</key><value xsi:type="xsd:string">IPv4</value></parameter>

        Reemplácelas con el siguiente texto:

        <parameter><key>IPProtocol</key><value xsi:type="xsd:string">IP</value></parameter>

      3. Importe el perfil de host modificado y aplíquelo a los hosts que están ejecutando ESXi 6.0 Update 2.

    • Después de la conmutación por error y el reinicio de un nodo principal, el estado de cumplimiento de la SPBM muestra resultados no válidos.
      Después de una serie de errores en el nodo de Virtual SAN, la administración de almacenamiento basada en directivas (SPBM) puede mostrar incorrectamente una máquina virtual con el estado de cumplimiento No aplicable. Este problema puede ocurrir cuando tanto el nodo principal como el nodo de copia de seguridad presentan un error, y se debe a una secuencia de consultas de cumplimiento automáticas iniciadas por la SPBM en respuesta al error. Dado que estas consultas de cumplimiento suman una carga adicional al sistema, toda consulta nueva puede generar tiempos de espera o resultados no válidos.

      Solución alternativa: espere hasta que se completen todas las consultas de cumplimiento iniciadas automáticamente. Todas las consultas de cumplimiento nuevas generarán resultados no válidos.

    • El asistente Crear nueva directiva de almacenamiento de máquina virtual muestra etiquetas incorrectas para las reglas
      Cuando se abre el asistente Crear nueva directiva de almacenamiento de máquina virtual para definir una directiva basada en los servicios de datos de Virtual SAN, las etiquetas utilizadas para describir las reglas de la directiva pueden mostrar un identificador interno en lugar de una etiqueta descriptiva. Por ejemplo, puede ver vsan.capabilitymetadata.propertymetadata.summary.replicaPreference.label en lugar de Cantidad de fracciones de disco por objeto.

      Solución alternativa: cierre la sesión de vSphere Web Client y vuelva a iniciarla.

    • La página Resincronización de componentes en vSphere Web Client no muestra la actividad de resincronización si los hosts tienen diferentes versiones de software ESXi.
      Cuando se actualizan los hosts en un clúster de Virtual SAN, algunos pueden tener diferentes versiones de software ESXi. Por ejemplo, algunos hosts ejecutan ESXi 6.0 Update 1 y otros ESXi 6.0 Update 2. Durante esta fase de la actualización, es posible que la página Resincronización de componentes en vSphere Web Client no muestre la actividad de resincronización que está ocurriendo en el clúster.

      Solución alternativa: para supervisar la actividad de resincronización durante las actualizaciones del host, utilice el comando de RVC vsan.resync_dashboard.

    • Las reglas de nuevas directivas se omiten en los hosts con versiones anteriores de software ESXi.
      Esto puede ocurrir cuando hay dos o más clústeres de Virtual SAN y uno de los clústeres ejecuta el software más reciente, mientras que el otro ejecuta una versión anterior. vSphere Web Client muestra reglas de directivas del software de Virtual SAN más reciente, pero estas nuevas directivas no son compatibles con los hosts anteriores. Por ejemplo, la directiva RAID-5/6 (Codificación de borrado) – Capacidad no es compatible con los hosts que ejecutan la versión de software 6.0U1 o versiones anteriores. Se pueden configurar las reglas de las nuevas directivas y aplicarlas en cualquier máquina virtual y cualquier objeto, pero se omitirán en los hosts que ejecutan una versión de software anterior.

      Solución alternativa: Ninguna.

    • Puede ocurrir un error en la consolidación de snapshots durante la actualización.
      Durante la actualización del formato en disco de Virtual SAN de la versión 2.0 a la versión 3.0, puede ocurrir un error en la consolidación de snapshots. La columna Necesita consolidación en vSphere Client indica que la máquina virtual necesita una consolidación. Para evitar esta situación, realice la consolidación de snapshots antes de actualizar el formato en disco, o bien espere hasta que la actualización se haya completado.

      Solución alternativa: si ocurre un error en la consolidación de snapshots, realice la operación una vez completada la actualización del formato en disco.

    • Los objetos de memoria de snapshots no se muestran en el Desglose de capacidad utilizada del supervisor de capacidad de Virtual SAN.
      En las máquinas virtuales creadas con una versión de hardware anterior a 10, la memoria de snapshots se incluye en los objetos Vmem del Desglose de capacidad utilizada.

      Solución alternativa: para ver los objetos de memoria de snapshots en el Desglose de capacidad utilizada, cree máquinas virtuales con una versión 10 de hardware o una versión superior.

    • El servicio de rendimiento de Virtual SAN se deshabilita al eliminar la directiva de almacenamiento aplicada en el objeto Base de datos de estadísticas.
      Si se elimina la directiva de almacenamiento aplicada al servicio de rendimiento, vSphere Web Client muestra el siguiente mensaje: El servicio de rendimiento está deshabilitado.

      Solución alternativa: realice los siguientes pasos para restaurar la directiva de almacenamiento eliminada o aplique una directiva de almacenamiento existente al servicio de rendimiento del objeto Base de datos de estadísticas mediante los comandos de RVC:

      1. Inicie sesión en vCenter Server mediante SSH y acceda al shell de Bash.

      2. Ejecute el siguiente comando para iniciar sesión con su cuenta de vCenter:

        rvc localhost

      3. Ejecute el siguiente comando para aplicar una directiva de almacenamiento al objeto Base de datos de estadísticas:

        vsan.perf.stats_object_setpolicy -o <policy> <cluster>

      Por ejemplo:

      vsan.perf.stats_object_setpolicy -o "/localhost/VSAN-DC/storage/vmprofiles/Virtual SAN Default Storage Policy" MyCluster

    • El uso del almacenamiento que se muestra en la página de resumen de la máquina virtual puede parecer más grande después de actualizar a Virtual SAN 6.2.
      En las versiones anteriores de Virtual SAN, el valor de uso de almacenamiento de la máquina virtual que se mostraba era el espacio utilizado por una sola copia de los datos. Por ejemplo, si el invitado escribió 1 GB en un objeto de aprovisionamiento fino con dos reflejos, el uso de almacenamiento mostrado era de 1 GB. En Virtual SAN 6.2, el campo Uso de almacenamiento muestra el espacio realmente utilizado, incluidas todas las copias de los datos. Por lo tanto, si el invitado escribe 1 GB en un objeto de aprovisionamiento fino con dos reflejos, el uso de almacenamiento mostrado es de 2 GB. El uso de almacenamiento que se muestra en algunas máquinas virtuales parece más grande después de actualizar a Virtual SAN 6.2, pero el espacio realmente consumido no ha aumentado.

      Solución alternativa: Ninguna.

    • No se puede poner un host testigo en modo de mantenimiento.
      Cuando se intenta poner un host testigo en modo de mantenimiento, el host permanece en el estado actual y aparece la siguiente notificación: Un parámetro especificado no era correcto.

      Solución alternativa: al poner un host testigo en modo de mantenimiento, elija la opción Sin migración de datos.

    • Al poner y sacar el host testigo en un clúster ampliado, el clúster queda mal configurado.
      Si se coloca el host testigo en un clúster de vCenter habilitado para Virtual SAN, una alarma notifica que el host testigo no puede residir en el clúster, pero si se quita el host testigo del clúster, este queda en un estado mal configurado.

      Solución alternativa: quite el host testigo del clúster ampliado de Virtual SAN y vuelva a configurar el clúster ampliado. Para obtener más información, consulte el artículo 2130587 de la base de conocimientos.

    • Cuando se produce una partición de red en un clúster que tiene un almacén de datos de latidos de HA, las máquinas virtuales no se reinician en el otro sitio de datos.
      Cuando el sitio preferido o el sitio secundario de un clúster de Virtual SAN pierde su conexión de red con otros sitios, las máquinas virtuales que se están ejecutando en el sitio que perdió la conectividad de red no se reinician en el otro sitio de datos y aparece el siguiente error: Error en la conmutación por error de HA de la máquina virtual de vSphere HA.

      Este es el comportamiento esperado de los clústeres de Virtual SAN.

      Solución alternativa: no seleccione el almacén de datos de latidos de HA mientras configura vSphere HA en el clúster.

    • Los discos y grupos de discos de Virtual SAN desmontados aparecen como montados en el campo Estado operativo de vSphere Web Client.
      Cuando se desmontan los discos o grupos de discos de Virtual SAN al ejecutar el comando esxcli vsan storage disk group unmount o mediante el servicio Supervisión del dispositivo de Virtual SAN cuando los discos muestran de forma persistente latencias altas, vSphere Web Client muestra por error el campo Estado operativo como montado.

      Solución alternativa: utilice el campo Estado para comprobar el estado del disco, en lugar de usar el campo Estado operativo.

    • La actualización del formato en disco muestra discos que no están en Virtual SAN.
      Cuando se actualiza el formato del disco, Virtual SAN puede mostrar por error discos que se quitaron del clúster. La interfaz de usuario también puede mostrar el estado de versión mixta. Este error generalmente ocurre cuando se desmontan manualmente uno o varios discos del clúster. No afecta al proceso de actualización. Solo se comprueban los discos montados. Los discos desmontados se omiten.
    • Solución alternativa: Ninguna.

    • No se puede introducir un nombre de dominio de errores de Virtual SAN que supere los 256 caracteres.
      Cuando se intenta asignar un nombre de dominio de errores con más de 256 bytes en vSphere Web Client, el sistema muestra el error: Un parámetro especificado no era correcto: faultDomainInfo.name. Cuando se utilizan caracteres Unicode de varios bytes, se puede llegar al límite de 256 bytes con menos de 256 caracteres.

      Solución alternativa: Ninguna.

    • Todos los clústeres de Virtual SAN comparten la misma configuración de proxy externo.
      Todos los clústeres de Virtual SAN comparten la misma configuración de proxy externo, incluso si establece el proxy en el nivel del clúster. Virtual SAN utiliza proxies externos para conectarse al asistente de compatibilidad, al programa de mejora de la experiencia del cliente y a la base de datos HCL si el clúster no tiene acceso directo a Internet.

      Solución alternativa: Ninguna.

    • El servicio de estado de Virtual SAN funciona incorrectamente cuando se cambian los valores predeterminados del puerto HTTP o HTTPS de vCenter y de la configuración de certificaciones.
      El servicio de estado de Virtual SAN solo es compatible con el puerto predeterminado HTTPS 443 y el certificado predeterminado en /etc/vmware-vpx/ssl/rui.crt y /etc/vmware-vpx/ssl/rui.key. Si se cambia el puerto predeterminado o se modifica el certificado, el servicio de estado de Virtual SAN no puede funcionar correctamente. Puede recibir un código de estado 400 (Solicitud incorrecta) o una solicitud rechazada.

      Solución alternativa: configure los puertos HTTP y HTTPS del servicio de estado de Virtual SAN para que utilicen los valores predeterminados.

    • La prueba de rendimiento de multidifusión de la comprobación de estado de Virtual SAN no se ejecuta en la red de Virtual SAN.
      En algunos casos, según la configuración de enrutamiento de los hosts ESXi, la prueba de rendimiento de multidifusión de red no se ejecuta en la red de Virtual SAN.

      Solución alternativa: utilice la red de Virtual SAN como única configuración de red para los hosts ESXi y realice la prueba de rendimiento de multidifusión de red según esta configuración.

      Si los hosts ESXi tienen varias configuraciones de red, también puede seguir los pasos enumerados en este ejemplo. Supongamos que Virtual SAN se ejecuta en la red 192.168.0.0.

      1. Enlace la dirección del grupo de multidifusión a esta red en cada host:

        $ esxcli network ip route ipv4 add -n 224.2.3.4/32 -g 192.168.0.0?

      2. Revise la tabla de enrutamiento:

        $ esxcli network ip route ipv4 list
        default      0.0.0.0          10.160.63.253  vmk0       DHCP
        10.160.32.0  255.255.224.0    0.0.0.0        vmk0       MANUAL
        192.168.0.0  255.255.255.0    0.0.0.0        vmk3       MANUAL
        224.2.3.4    255.255.255.255  192.168.0.0    vmk3       MANUAL

      3. Ejecute la prueba de rendimiento de red de multidifusión proactiva y revise el resultado.

      4. Una vez completada la prueba, recupere la tabla de enrutamiento:

        $ esxcli network ip route ipv4 remove -n 224.2.3.4/32 -g 192.168.0.0

    • Las máquinas virtuales de un clúster ampliado se vuelven inaccesibles al aislar el sitio preferido y, a continuación, recuperan la conectividad únicamente con el host testigo.
      Cuando el sitio preferido deja de estar disponible o pierde su conectividad de red con el sitio secundario y el host testigo, el sitio secundario forma un clúster con el host testigo y continúa con las operaciones de almacenamiento. Los datos del sitio preferido pueden desactualizarse con el tiempo. Si más adelante el sitio preferido vuelve a conectarse con el host testigo, pero no con el sitio secundario, el host testigo sale del clúster en el que se encuentra y forma un clúster con el sitio preferido. Además, algunas máquinas virtuales pueden volverse inaccesibles porque no tienen acceso a los datos más recientes de este clúster.

      Solución alternativa: antes de volver a conectar el sitio preferido al clúster, marque el sitio secundario como sitio preferido. Una vez que los sitios se vuelvan a sincronizar, podrá marcar el sitio que desea utilizar como sitio preferido.

    • El paquete OVA del host testigo de Virtual SAN no admite la configuración de un DVS interno.
      El paquete OVA del host testigo de VMware Virtual SAN no admite la configuración de un conmutador virtual distribuido (DVS) dentro del host testigo.

      Solución alternativa: utilice un conmutador virtual heredado.