Notas de la versión de VMware Integrated OpenStack 7.1

VMware Integrated OpenStack 7.1 | 13 de mayo de 2021 | OVA de compilación 17987092, revisión 17987093 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 contienen los siguientes temas:

• Acerca de VMware Integrated OpenStack
• Novedades
• Actualizar a la versión 7.1
• Compatibilidad
• Avisos de desuso
• Problemas resueltos
• Problemas conocidos

Acerca de VMware Integrated OpenStack

VMware Integrated OpenStack facilita enormemente la implementación de una infraestructura de nube de OpenStack, ya que simplifica el proceso de integración. VMware Integrated OpenStack proporciona una funcionalidad OpenStack integrada y un flujo de trabajo de configuración fácil mediante un administrador de implementación que se ejecuta como un dispositivo virtual en vCenter Server.

Novedades

• Compatibilidad con las últimas versiones de los productos de VMware: 
  • VMware Integrated OpenStack 7.1 es totalmente compatible con VMware vSphere 7.0 U2, NSX-T 3.1.1 y NSX-V 6.4.10
• Nuevas funciones y mejoras:
  • Plano de administración:
    • Compatibilidad con la recuperación ante desastres para el plano de administración de VIO. Proporciona un nuevo comando viocli para admitir la recuperación del plano de administración ante un desastre. El procedimiento completo de recuperación ante desastres se valida con SRM, vSphere Replication y la función multisitio de NSX-T, que abarca instancias de Nova, volúmenes de Cinder y redes de Neutron. Una vez recuperada la implementación en el sitio de recuperación ante desastres de destino, los usuarios pueden utilizar VIO para administrar los objetos recuperados de Nova/Cinder/Neutron.
    • Compatibilidad del complemento de administración de NSX-T de Neutron en la migración del complemento de directiva. 
    • Compatibilidad con varias claves de licencia: permita que el administrador introduzca varias claves de licencia de VIO y asigne las claves para su uso.
  • Controlador de OpenStack:
    • Compatibilidad con tipo de Octavia. La función permite que los usuarios utilicen la capacidad de los tipos de OpenStack Octavia en equilibradores de carga creados por VIO en NSX-T. Esta función es compatible con el complemento NSX-P de Neutron y con NSX-T 3.1 o versiones posteriores.
  • Escalabilidad:
    • Compatibilidad con mayor escalabilidad. Una implementación de VIO ahora puede admitir hasta 128 nodos de proceso para Nova, hasta 10.000 redes de tenants con el complemento de directiva de NSX-T de Neutron y hasta 8 federaciones de implementaciones de VIO con vIDM como IdP.

Actualizar a la versión 7.1

• Actualice desde la versión 7.0/7.0.1 mediante el comando viocli patch. Encuentre las instrucciones detalladas en la guía de instalación del producto.
• Actualice desde la versión 6.0. Utilice el procedimiento de actualización azul/verde que se describe en la guía de instalación del producto.
• VIO 7.1 no admite la actualización directa desde la versión 5.x. Actualice primero a la versión 7.0.1.

Compatibilidad

• Consulte Matrices de interoperabilidad de productos de VMware para obtener información sobre la compatibilidad de VMware Integrated OpenStack con otros productos de VMware.

Avisos de desuso 

• Las siguientes funciones de redes han quedado obsoletas y se eliminarán en una próxima versión de VIO:
  • El controlador de NSX Data Center for vSphere para Neutron.
  • El complemento de administración de NSX-T para Neutron se reemplazará con el complemento de directiva de NSX-T.
  • El complemento TVD, que permite que una sola implementación de VMware Integrated OpenStack use un back-end de NSX Data Center for vSphere y un back-end de NSX-T Data Center.
• Neutron FWaaSv2 quedará obsoleto en una versión futura.

Problemas resueltos

Los problemas resueltos se agrupan como se muestra a continuación:

• Problemas resueltos de administración de VIO
• Problemas resueltos de OpenStack

Problemas resueltos de administración de VIO

• 2750794 solucionado: Los datos de copia de seguridad se eliminaban cuando el administrador de VIO eliminaba el trabajo de programación de copia de seguridad de VIO.

  En VIO 7.0, cuando el administrador elimina el trabajo de programación de copia de seguridad de VIO, también se eliminan los datos de copia de seguridad almacenados en la biblioteca de contenido de vCenter.
  En VIO 7.1, los datos de copia de seguridad no se eliminarán cuando se elimine el trabajo de programación de copia de seguridad.

• 2738659 solucionado: El procedimiento de restauración de la copia de seguridad de VIO no podía funcionar correctamente cuando se habilitaba SSL de vCenter.

  El procedimiento de restauración de la copia de seguridad de VIO no podía funcionar correctamente cuando se habilitaba SSL de vCenter. No se podrán cargar los datos de copia de seguridad en la biblioteca de contenido de vCenter y aparecerá el error "x509: entidad de certificación desconocida".

• 2680755 solucionado: No se puede avanzar el asistente de implementación de VIO y aparece el error "Se agotó el tiempo de espera de la carga de recursos de vCenter".

  VIO 7 utiliza govmomi para recuperar la información de inventario de vCenter. govmomi se congela si DistributedVirtualPortgroup tiene un calificador de tráfico "MAC" o "Tráfico del sistema" para el filtrado y marcado de tráfico en el entorno de vSphere de destino.

• 2677748 solucionado: La interfaz de usuario web de VIO Manager no puede enumerar el estado de los servicios de OpenStack

  La interfaz de usuario web de VIO Manager no puede enumerar los servicios sin propósito y solo aparece el mensaje "No se encontraron recursos".

• 2591794 solucionado: No se puede acceder al servicio de metadatos en el entorno de NSX-V

  No se puede acceder al servicio de metadatos si la instancia de Edge del proxy de metadatos no es enrutable desde la red API de VMware Integrated OpenStack. En ese caso, VIO 7.1 se pondrá en contacto automáticamente con el proxy de metadatos a través de la API de administración.

• 2688209 solucionado: El paquete de soporte de VIO contiene información de registro solo durante aproximadamente dos días.

  En VIO 6.0 y 7.0, el paquete de soporte solo puede contener la información de registro durante aproximadamente dos días. Esta información de registro no es suficiente para fines de solución de problemas. Para solucionar este problema, VIO 7.1 habilita copias de seguridad de registros generadas automáticamente para aumentar la retención de registros hasta 7 días.

• 2707205 solucionado: VIO 6/7 no estableció rp_filter en modo dinámico en los nodos de controlador

  VIO 6/7 hizo transición a PhotonOS y no estableció explícitamente rp_filter en los nodos del controlador, lo que significa que se establecen en "1" (modo estricto RFC3704) de forma predeterminada. Es posible que las aplicaciones de la red de administración no puedan conectarse a los endpoints públicos, ya que la configuración del modo estricto hace que se eliminen paquetes.

• 2631412 solucionado: La GUI de VIO utiliza un certificado con el nombre "Certificado falso del controlador de entrada de Kubernetes"

  El nombre del certificado es el predeterminado que crea el controlador de entrada de Nginx. Cuando se actualice a VIO 7.1, se reemplazará por el que tiene el nombre correcto. 

Problemas resueltos de OpenStack

• 2594923 solucionado: La propiedad vmware_cpu_affinity de la imagen de Glance no funciona.

  La propiedad vmware_cpu_affinity de la imagen de Glance no funciona. Se producirá un error al utilizar una imagen de Glance de este tipo para crear instancias de Nova: "Error: Se requiere una lista en el campo vmware_cpu_affinity, no un str (HTTP 400)"

  En VIO 7.1, la propiedad se podía establecer como el ejemplo siguiente:

  openstack image set --property vmware_cpu_affinity="[0,1]" image_name

• 2753879 solucionado: La pila de Heat no se pudo actualizar debido a la extensión fwaas v1.

  Heat ascendente sigue usando fwaas v1 y no admite fwaas v2. Sin embargo, VIO 7 solo admite fwaas v2.

• 2713308 solucionado: Las imágenes base de Glance no utilizadas se están acumulando en la carpeta de memoria caché de Nova.

  Las imágenes base de Glance no utilizadas se están acumulando en la carpeta de memoria caché de Nova. El proceso de back-end para limpiar la imagen no utilizada no funciona correctamente.

• 2710808 solucionado: VIO 7 solo admite un ns_record en el grupo Designate.

  VIO 7 solo admite un ns_record en el grupo Designate; esto se mejoró en VIO 7.1, que podrá varios ns_records en Designate.

• 2707581 solucionado: Si se configura una directiva de calidad de servicio como predeterminada, la red externa también utiliza esta directiva de calidad de servicio.

  Si se configura una determinada directiva de calidad de servicio como predeterminada, la red externa también utiliza esta directiva de calidad de servicio. Esto no es correcto para la red externa.

• 2705010 solucionado: No se pudo cambiar el tamaño del equilibrador de carga con Octavia en VIO 7.

  LBaaS de Octavia no proporciona una forma para que el usuario cambie el tamaño del equilibrador de carga.
  VIO 7.1 proporciona opciones para la configuración de tamaño.

  default_edge_size = <purpose>:<edge size>[,...]
  

  Se admiten los siguientes propósitos: enrutador, DHCP o lb.
  Los tamaños admitidos son compact, large, xlarge, quadlarge.
  Por ejemplo: default_edge_size = lb:xlarge

  Utilice "viocli update neutron" para agregar los siguientes parámetros en la sección [nsxv] para configurar:

  conf:
    neutron:
    plugins:
      nsx:
        nsxv:
          default_edge_size: lb:xlarge

• 2701437 solucionado: La opción de imagen de Glance "vmware_create_template=false" no podía funcionar correctamente.

  La imagen de Glance no pudo crear ni arrancar instancias de Nova en las siguientes configuraciones:

  • Cuando la opción vmware_create_template es false en la configuración de Glance
  • Cuando el usuario crea la imagen de Glance mediante la CLI de OpenStack con la propiedad "vmware_create_template=false"
    Por ejemplo:

  openstack image create --disk-format vmdk --file vmdk --property vmware_create_template=false imageName

• 2699470 solucionado: No se puede ejecutar el comando nova-manage en el pod de proceso para Nova.

  Al ejecutar el comando nova-manage desde el pod de proceso para Nova, habría una excepción DBNonExistentTable, ya que no hay ninguna sección [de base de datos] en nova-compute.conf.

• 2688655 solucionado: La autenticación de CLI de OpenStack mediante openid no funciona en VIO 7.0.1

  La autenticación de CLI de OpenStack mediante openid no funciona en VIO 7.0.1 y muestra el error No autorizado (HTTP 401).

• 2674517 solucionado: El disco de intercambio definido en el tipo no está montado correctamente en la instancia de Nova.

  El disco de intercambio definido en el tipo no está montado correctamente en la instancia de Nova. Esto se solucionó en VIO 7.1 con la limitación de no admitir el cambio de tamaño de la máquina virtual con el disco de intercambio.

• 2672946 solucionado: El pod de configuración de zona de disponibilidad de proceso para Nova se ejecuta en el estado CrashLoopBackOff cuando los nombres de agregado de host tienen algunas condiciones específicas.

  Si hay un agregado de host denominado "nova" en la zona de disponibilidad Nova y otro agregado de host con el nombre "xxxxx-nova" que coincide con "^.*nova$" en la misma zona (por ejemplo, 5-nova), el pod az-setup de proceso para Nova se ejecutará en el estado CrashLoopBackOff.

• 2656225 solucionado: El usuario no puede abrir la consola de máquina virtual y aparece el error "Error: La consola no está disponible actualmente" a través de la interfaz de usuario de Horizon

  Horizon no pudo mostrar las consolas de máquina virtual y muestra "Error: La consola no está disponible actualmente" en algunas situaciones. Esto se debe a que cuando la ruta de configuración vmx se vuelve más larga, nova-compute no puede insertar una fila que contenga la información de un ticket MKS y la ruta de configuración vmx a la base de datos. Por ejemplo, SvMotion para una instancia de VIO hace que el cambio de la ruta de configuración vmx sea una cadena más larga.

• 2652286 solucionado: La eliminación del monitor de estado de LB falla y muestra el mensaje "Error del lado del servidor: El objeto 'NoneType' no tiene ningún atributo 'load_balancer_id'".

  Este es un error en el servicio Octavia que afecta al complemento de NSX de VMware. En algunos casos, el servicio Octavia no puede recuperar el grupo correspondiente a un monitor de estado, lo que activa este error. El error está abierto actualmente y se realiza un seguimiento en https://storyboard.openstack.org/#!/story/2008231

• 2678067 solucionado: El cursor del mouse no funciona de forma coherente para la máquina virtual Nova de Windows a través de Horizon Console

  Cuando acceda a Horizon Console en cualquier navegador, el cursor de la máquina virtual de Windows no responderá a menos que se utilice la tecla de tabulación o control + clic. Eventualmente, dejará de responder al volver a hacer clic con el botón izquierdo.

• 2755304 solucionado: Se produce un error en la transacción de cambio de estado de LB de Octavia y se queda en el estado PENDING_DELETE.

  Octavia utiliza un socket UNIX para comunicarse internamente dentro del agente de controladores. En ocasiones, se agota el tiempo de espera al escribir en este socket, lo que genera un error en la transacción de cambio de estado. Se agregó un mecanismo de reintento para la transacción de cambio de estado.

• 2643797 solucionado: Al configurar trusted_dashboard, el FQDN de Horizon se guarda como dirección IP en kystone.conf, no el nombre FQDN.

  Al configurar las opciones de federación para Keystone, el FQDN de Horizon proporcionado se guarda como dirección IP en el archivo de configuración de Keystone, no como el nombre FQDN proporcionado.

  viocli update keystone
  conf:
    keystone:
      federation:
        trusted_dashboard: https://HorizonFQDN/auth/websso/

Problemas conocidos

• La limitación de velocidad de API pública no está disponible.

  En VMware Integrated OpenStack 7.1, no es posible aplicar la limitación de velocidad en las API públicas.

  Solución alternativa: Ninguna. Esta función se ofrecerá en una versión posterior.

• La creación de un equilibrador de carga con una subred privada que no esté asociada a un enrutador genera un estado ERROR

  Con los complementos de NSX-T de Neutron (como los complementos de MP y Policy) la creación de un equilibrador de carga con una subred privada que no esté asociada a un enrutador produce un equilibrador de carga con un estado ERROR. No se informará del error al usuario.

  Solución alternativa: Cree el equilibrador de carga con una subred que esté asociada a un enrutador.

• Si se introducen credenciales incorrectas al implementar OpenStack, es posible que el asistente no reconozca las credenciales correctas.

  Durante el proceso de implementación de OpenStack, si las credenciales vCenter Server o NSX Manager se introducen de forma incorrecta, es posible que el asistente no pueda reconocer las credenciales correctas. Aunque elimine la información incorrecta e introduzca las credenciales correctas, es posible que el asistente no pueda validarlas.

  Solución alternativa: Cierre el asistente de implementación y vuelva a abrirlo.

• La seguridad de puertos de OpenStack no se puede aplicar en los puertos directos del complemento de Neutron de NSX-V

  Puede que no resulte habilitar la seguridad de puertos para puertos con vnic-type directo. Las funciones de seguridad no están disponibles para puertos directos.

  Solución alternativa: Ninguna.

• No se puede iniciar sesión en VIO si la contraseña de vCenter y NSX contiene $$

  Si la cuenta de VIO configurada para la instancia subyacente de vCenter y NSX utiliza la contraseña que contiene "$$", VIO no puede completar la autenticación de vCenter y NSX debido a que se utilizó "$$" en la contraseña. Los pods OpenStack pueden generar CrashLoopBackOff.

  Solución alternativa: Utilice otras contraseñas que no contengan "$$".

• Los equilibradores de carga se quedan bloqueados en el estado PENDING_XXX y no se pueden utilizar.

  Este problema de bloqueo se produce en todos los equilibradores de carga que se crean, modifican o eliminan cuando octavia-da del pod octavia-api se bloquea.

  Solución alternativa: Estos equilibradores de carga ya no se pueden utilizar en Octavia. Deben eliminarse manualmente de la base de datos de Octavia.

• El usuario no podía descargar la imagen de Glance desde el cliente de CLI de OpenStack

  Al descargar la imagen desde la CLI de OpenStack, se produce el siguiente error: "[Errno 32] Descarga de imagen dañada". Esto se debe a que VIO almacena de forma predeterminada la imagen como plantilla de máquina virtual en el almacén de datos de vSphere. El valor md5sum no se guarda entre VMDK y la plantilla de máquina virtual.

  Solución alternativa: La imagen de Glance se podría descargar con las siguientes configuraciones:

  • La opción vmware_create_template es false en la configuración de Glance
  • El usuario crea la imagen de Glance mediante la CLI de OpenStack con la propiedad "vmware_create_template=false"
• Después de configurar un grupo de firewall de forma administrativa en INACTIVO (estado = INACTIVO), el estado operativo del grupo de firewall siempre es INACTIVO, incluso después de que se vuelva a poner el estado administrativo del grupo de firewall en ACTIVO

  El servicio neutron-fwaas omitirá el cambio de estado operativo en las transiciones que no implican agregar un puerto ni quitar un puerto del grupo de firewall.

  Solución alternativa: Agregue o elimine un puerto, o bien puede agregar y eliminar un puerto que ya esté enlazado al grupo de firewall.

• Es imposible optar por no omitir la validación del certificado si una CA intermedia firma el certificado de vCenter y NSX

  Cuando el certificado de vCenter y NSX está firmado por una CA intermedia, algunos servicios de VIO no pueden configurarse correctamente para realizar la validación de certificados. El error se puede observar en varios formatos. Por ejemplo, no se puede anular la selección de "omitir validación de certificado" al agregar o editar vCenter o NSX.

  Solución alternativa: Elija "omitir validación de certificado" en la interfaz de usuario, edite el CR de vCenter y NSX y establezca spec.insecure en true.

• Al hacer clic en editar y guardar en un segmento de Neutron, se habilita la multidifusión de forma accidental

  Si, en la interfaz de usuario de directiva de NSX-T, se realizan cambios no relacionados en el enrutamiento de multidifusión, se habilitará el enrutamiento de multidifusión en el segmento.

  Solución alternativa: Deshabilite explícitamente la multidifusión en la interfaz de usuario al editar el segmento.

• No se pueden realizar las operaciones de adición de miembros y aparece el mensaje "El proveedor 'vmwareedge' presenta error: No se pudo recuperar el certificado:". (Estado HTTP 500)

  No se pueden agregar ni eliminar miembros de los equilibradores de carga Octavia HTTPS _TERMINATED.

  Solución alternativa: Utilice la CLI de OpenStack para agregar o eliminar miembros.

  1. Recupere tls_container_ref para todos los usuarios afectados

  2. Busque el URI de contenedor, secreto y certificado

  3. Recupere el identificador de usuario del servicio Octavia

  4. Agregue los URI recuperados en el paso 2 a las ACL para el identificador de usuario recuperado en el paso 3

• Las puertas de enlace de nivel 1 no se pudieron revertir por completo durante la migración MP2P a gran escala

  Algunas puertas de enlace de nivel 1 no se pudieron revertir por completo y el estado de eliminación permaneció en curso durante la migración MP2P a gran escala. Es posible que se haya producido una reversión incorrecta debido a un error durante la migración.

  Solución alternativa: Restaurar UA y volver a migrar.

• Error de entrada duplicada en la federación Keystone

  Si, después de eliminar el OIDC en la federación Keystone, el mismo usuario intenta iniciar sesión con OIDC, se produce un error en la autenticación y aparece el mensaje 409.

  Solución alternativa: Elimine al usuario a través de la CLI de Horizon u OpenStack.

  Por ejemplo:

  1. En Horizon, inicie sesión con una cuenta de administrador.

  2. Establezca el contexto del dominio con el dominio federado.

  3. En la página del usuario, elimine al usuario que tiene la columna Nombre de usuario con el valor Ninguno.

  En la CLI de OpenStack

  openstack user list --domain <federated domain name>

  openstack user delete <user id> --domain <federated domain name>

• Una vez que la migración se realiza correctamente, los registros del pod migrador no están disponibles en el paquete de soporte de VIO
   

  Una vez que la migración se realiza correctamente, el plano de control de VIO se vuelve a configurar y se elimina el pod migrador. Por lo tanto, su registro no se captura en el paquete de soporte.

  Solución alternativa: Los registros del pod migrador están disponibles en el nodo de controlador, y se ejecutan y se almacenan en /var/log/vmware/mp2p_migration.log. Para recuperar los archivos de registro, acceda a los nodos del controlador a través de viossh. Los archivos de registro están disponibles solo en el controlador en el que se ejecuta el trabajo y, por lo tanto, es posible que sea necesario iterar en varios controladores hasta que los encuentre.

• No se puede habilitar Ceilometer cuando hay 10.000 redes de tenants de Neutron.

  Cuando hay grandes cantidades de recursos, como redes creadas en vSphere, VIO generará muchos recursos de cliente para dichos objetos. Si el número de CR es demasiado grande, se producirá un error en la interfaz de usuario web de VIO Manager en la API de back-end debido a que los datos de respuesta son demasiado grandes para la solicitud http.

  Solución alternativa: En VIO Manager, elimine manualmente los recursos de cliente de detecciones.

  Los CR podrían enumerarse mediante el siguiente comando:

  kubectl -n openstack get discoveries.vio.vmware.com

  Es posible que se eliminen los CR con el siguiente comando. Por ejemplo:

  kubectl -n openstack delete discoveries.vio.vmware.com vcenter-vcenter2-networks-2

• El certificado debe estar firmado por una CA y volver a aplicarse después de la restauración

  El secreto de certificados que contiene la clave privada y el certificado de VIO no está actualmente en el ámbito de copia de seguridad. Después de una restauración no local, el certificado importado anteriormente no existirá en una nueva implementación.

  Solución alternativa:

  1. Guarde el secreto de los certificados de la implementación original
  osctl get secret certs -oyaml > certs.yaml
  2. Después de la restauración, reemplace los valores "private_key" y "vio_certificate" en el secreto de certificados por los datos del paso 1.
  3. Detenga/inicie servicios.

• No se pueden crear instancias en un nodo de proceso para Nova específico y el registro de proceso para Nova se bloquea.

  Al crear una instancia, se encuentra en estado COMPILACIÓN (BUILD) y nunca se realiza correctamente. Compruebe el registro nova-compute; solo hay unos pocos registros y sin más información.

  Solución alternativa: Reinicie el pod novacompute manualmente.

• No hay respuesta al guardar los cambios de reglas de firewall desde la interfaz de usuario de Horizon.

  Si alguna de las opciones obligatorias marcadas con "*" no se actualiza al editar reglas de firewall, no hay respuesta de la interfaz de usuario al guardar los cambios.

  Solución alternativa: Actualice todas las opciones obligatorias al editar reglas de firewall.

• Algunas operaciones de día 2 no funcionan después de cambiar el nombre de usuario y la contraseña de vCenter desde la interfaz de usuario web de VIO Manager.

  Cuando un usuario actualiza la credencial de vCenter en la interfaz de usuario web de VIO Manager, es posible que los servicios de OpenStack funcionen. Sin embargo, el plano de control de VIO no puede comunicarse con vCenter, ya que el secreto de vCenter en el proveedor de nube de k8s y la API del clúster no está actualizado.

  Solución alternativa: Utilice el comando "kubectl patch secret" para actualizar la credencial de vCenter en VIO Manager.

  Compruebe la información actual del secreto vc-credential:

  kubectl -n kube-system get secret viocluster1-vc-credentials -o yaml 
  kubectl -n openstack get secret viocluster1-vc-credentials -o yaml
  

  Actualice el secreto vc-credentials con un nuevo nombre de usuario y contraseña (en formato base64):

  kubectl -n kube-system patch secret viocluster1-vc-credentials --patch \
  '{"data": {"your_vcenter.password": "password_in_base64", "your_vcenter.username": "username_in_base64"}}'
  kubectl -n openstack patch secret viocluster1-vc-credentials --patch \
  '{"data": {"password": "password_in_base64", "username": "username_in_base64"}}'
  

• La interfaz de usuario de Horizon muestra "xmltooling::IOException" al iniciar sesión con el IdP de federación de SAML.

  Cuando VIO está configurado con el IdP de SAML externo, se produce el error "xmltooling::IOException" cuando el usuario intenta iniciar sesión con la federación de SAML.

  Solución alternativa: Haga clic en el botón Actualizar en el navegador. El usuario pasará a la página de inicio de sesión de IdP.

• Cuando se utiliza el comando "viocli update " para actualizar CR, puede producirse un error si se introduce un entero grande como valor. Por ejemplo, profile_fb_size_kb: 2097152.

  En algunos casos, los gráficos de Helm de VIO convertirán los enteros grandes en notación científica.

  Solución alternativa: Agregue comillas alrededor del entero grande. Por ejemplo, profile_fb_size_kb: "2097152".

• Las instantáneas en un nodo de controlador impiden algunas operaciones de VIO.

  El volumen persistente de un nodo de controlador no se puede mover si existe una instantánea del nodo de controlador. Por lo tanto, VIO no admite la creación de una instantánea de un controlador.

  Solución alternativa: Elimine todas las instantáneas de los nodos de controlador.

• Los volúmenes creados a partir de imágenes siempre se pueden arrancar de forma predeterminada.

  Si incluye el parámetro --non-bootable al crear un volumen a partir de una imagen, el parámetro no tendrá efecto.

  Solución alternativa: Una vez creado el volumen, actualícelo para que no se pueda arrancar.