Hay un problema de consola de OpenStack que no es específico del controlador OpenStack nova en Oracle VM Server for SPARC.
Para resolver este problema, haga clic en la barra azul en la parte superior de la ventana de consola.
Algunos servidores más antiguos (como los servidores UltraSPARC T2) no admiten etiquetas EFI. Por lo tanto, debe crear una VTOC basada en imágenes de VM para admitir hardware nuevo y anterior. Este problema también impone limitaciones de tamaño de disco.
Si la propiedad cpu-arch está definida en una VM, el controlador nova no puede cambiar el valor de la propiedad cpu-arch más adelante. Este problema ocurre porque el controlador OpenStack Nova en Oracle VM Server for SPARC aún no admite la migración de tipos.
Debe utilizar una raíz ZFS para usar la capacidad de expansión automática de discos. Esta capacidad no admite gestores de volúmenes y sistemas de archivos, como UFS, SVM y VxFS.
Las siguientes funciones de Oracle VM Server for SPARC no funcionan con un dominio invitado que ejecuta Linux for SPARC 1.0:
Conexión y desconexión dinámica de volúmenes
Conexión y desconexión dinámica de redes
Migración en directo
El log de consola vntsd no se migra con el dominio invitado. Como resultado, estos logs de consola ya no están disponibles y únicamente aparecen las entradas de log recientes.
Pueden ocurrir problemas en la cola de mensajes u otros servicios de OpenStack si el controlador y los nodos de cálculo tienen MTU no coincidentes en las interfaces de gestión. Estas interfaces de gestión se utilizan para comunicaciones de gestión de OpenStack. Una configuración de MTU no coincidente puede tener una red de gestión de nodo de cálculo de 9000 bytes y un nodo de controlador de 1500 bytes. Asegúrese de que todos los hosts estén alineados en la red de gestión en términos de MTU.
Pueden ocurrir problemas si agrega un comentario (#) al final de una línea de configuración en un archivo de configuración de OpenStack. OpenStack interpreta los comentarios en línea como parte del valor.
Asegúrese de insertar los comentarios en líneas separadas y que la línea de comentarios comience con el símbolo de comentario (#).
Por ejemplo, la línea de configuración admin_password=welcome1 #my password se interpreta como si se especificara la contraseña welcome1 #my password.
Use la línea siguiente para comprobar si un archivo de configuración tiene comentarios en línea:
# cat /etc/service/service.conf |egrep -v '^#' | grep '#'
Asegúrese de que la configuración del servidor NFS es correcta. Si elige el servidor incorrecto, el servicio nova-compute parece bloquearse al inicio al intentar montar el recurso compartido NFS.
Para resolver este problema, desactive el servicio nova-compute y ejecute kill para el montaje que se está intentando realizar en el recurso compartido incorrecto. El controlador puede realizar otro intento de montaje del recurso compartido, por lo tanto, asegúrese de que todos los intentos del controlador para montar el recurso compartido incorrecto se eliminen tras desactivar el servicio nova-compute. Luego, corrija el archivo nova.conf y active el servicio nova-compute.
El controlador OpenStack Nova en Oracle VM Server for SPARC aún no admite la operación de recreación. Solo se admite la operación de evacuación de Nova. Si un usuario intenta realizar una operación de recreación, posiblemente se recicle el disco existente de la VM pero no se crea una nueva imagen del disco.
Si se crea un volumen de Cinder con una imagen del sistema operativo, la copia de la imagen del sistema operativo puede demorar mucho tiempo. Puede producirse el timeout de Nova al esperar que Cinder complete esta tarea. El servicio nova-compute (fuera del controlador Nova en Oracle VM Server for SPARC) simplemente realiza un sondeo durante un tiempo y espera para ver si Cinder creó el volumen.
Considere aumentar el siguiente valor si surgen estos “bloqueos” en el entorno:
block_device_allocate_retries=360
Luego, reinicie el servicio nova-compute.
Si tiene problemas para acceder al recurso compartido NFSv4, es posible que un nodo de cálculo genere un aviso grave. Si el recurso compartido NFSv4 ya no está disponible, se demora o tiene otros problemas de conectividad durante diez minutos o más, los nodos de cálculo se aíslan por sí solos y generan un aviso grave para el dominio de control. Si tiene este problema con frecuencia, desactive DLM comentando la entrada dlm_nfs_server mientras identifica la causa raíz del problema.
Asegúrese de que el almacenamiento NFSv4 sea resistente y de alta disponibilidad. Además, asegúrese de que la delegación esté desactivada.
Este problema ocurre si el servicio neutron-server está configurado para EVS en lugar de ML2 y si el perfil intenta poner en línea el servicio neutron-server antes de que esté correctamente configurado.
Para corregir este problema, reinicie el servicio manifest-import y desactive el servicio neutron-server ejecutando estos comandos:
cctrl# svcadm restart manifest-import cctrl# svcadm disable neutron-server
Si configura manualmente los servicios del controlador de nube, debe completar la configuración de los archivos del controlador de nube /etc/neutron/neutron.conf y /etc/neutron/api-paste.ini antes de volver a activar el servicio neutron-server.