Esta sección contiene problemas generales y errores específicos relativos al software Oracle VM Server for SPARC 3.4.
ID de bug 23206413: en circunstancias excepcionales, una migración de dominio correcta informa el siguiente error:
Unable to send suspend request to domain domain-name
Este error se produce cuando Logical Domains Manager detecta un error mientras se suspende el dominio y Logical Domains Manager se recupera y completa la migración. El estado de salida del comando es 0, lo cual refleja que la migración se realizó correctamente.
Solución alternativa: debido a que la migración se completa correctamente, puede ignorar el mensaje de error.
ID de bug 23180427: al migrar dominios enlazados que tienen un gran número de dispositivos virtuales, la operación puede fallar con el siguiente mensaje en el log de SMF:
warning: Timer expired: Failed to read feasibility response type (9) from target LDoms Manager
Este fallo indica que el timeout del Logical Domains Manager que se ejecuta en la máquina de origen mientras esperaba a que el dominio se enlazara en la máquina de destino. La probabilidad de que se produzca este problema se incrementa a medida que aumenta el número de dispositivos virtuales en el dominio de migración.
Debido al momento en que aparece este error, se genera una copia enlazada del dominio en la máquina de origen y en la de destino. No inicie ambas copias de este dominio. Esta acción puede dañar los datos porque ambos dominios hacen referencia a los back-ends del mismo disco virtual.
Recuperación: después de comprobar que la copia del dominio migrado sea correcta en la máquina de destino, desenlace manualmente la copia del dominio en la máquina de origen y destrúyala.
ID de bug 23031413: cuando el dominio de control de la máquina de destino se queda sin LDC durante una migración de dominio, se produce un error en la migración y se escribe el siguiente mensaje de error en el log de SMF:
warning: Failed to read feasibility response type (5) from target LDoms Manager
Este error se produce cuando el dominio que se está migrando no se puede enlazar en la máquina de destino. Tenga en cuenta que la operación de enlace también puede fallar en la máquina de destino por otros motivos.
Solución alternativa: para que la migración se realice correctamente, se debe reducir el número de LDC en el dominio que se está migrando o en el dominio de control de la máquina de destino. Puede reducir el número de LDC mediante la reducción del número de dispositivos virtuales que usa o gestiona un dominio. Para obtener más información sobre la gestión de LDC, consulte Uso de canales de dominio lógico de Guía de administración de Oracle VM Server for SPARC 3.4.
ID de bug 23026264: a partir de Oracle VM Server for SPARC 3.4, Logical Domains Manager solo es compatible con TLS v1.2 o posterior para migraciones de dominio seguras. Si el par de la migración no puede usar TLS v1.2, la migración falla con el siguiente mensaje de error:
Failed to establish connection with ldmd(1m) on target: target Check that the 'ldmd' service is enabled on the target machine and that the version supports Domain Migration. Check that the 'xmpp_enabled' and 'incoming_migration_enabled' properties of the 'ldmd' service on the target machine are set to 'true' using svccfg(1M).
La migración de dominios se admite solo entre dos versiones secundarias consecutivas del software Oracle VM Server for SPARC. Este problema no afecta ninguna de las combinaciones admitidas. Sin embargo, el software Oracle VM Server for SPARC que se ejecuta en el SO Oracle Solaris 10 no puede usar TLS v1.2 por defecto y es incompatible con migración de dominios mediante Oracle VM Server for SPARC 3.4.
ID de bug 23025921: la propiedad boot-policy de un dominio invitado no se mantiene cuando el dominio invitado se migra a un sistema que ejecuta una versión anterior de Logical Domains Manager y luego se migra a un sistema con Oracle VM Server for SPARC 3.4.
El software Oracle VM Server for SPARC 3.4 introdujo la propiedad boot-policy para admitir la función de inicio verificado. Las versiones anteriores del software Oracle VM Server for SPARC no admiten esta propiedad, por lo cual se descarta la propiedad boot-policy cuando se migra un dominio invitado desde un sistema con Oracle VM Server for SPARC 3.4 a un sistema con una versión de Oracle VM Server for SPARC anterior a la versión 3.4.
Cuando el dominio invitado se migra posteriormente a un sistema con Oracle VM Server for SPARC 3.4, se aplica el valor boot-policy por defecto de warning al dominio invitado migrado.
Recuperación: después de migrar el dominio invitado a un sistema de destino con Oracle VM Server for SPARC 3.4, establezca manualmente la propiedad boot-policy con el valor deseado. Realice este paso si el valor por defecto de warning no es el adecuado.
Establezca boot-policy=none.
primary# ldm set-domain boot-policy=none ldg1
Reinicie el invitado para que la nueva política de inicio surta efecto.
ID de bug 21289174: en un servidor SPARC, una zona de núcleo en ejecución en un dominio Oracle VM Server for SPARC bloqueará la migración en directo de un dominio invitado. Se mostrará el siguiente mensaje de error:
Guest suspension failed because Kernel Zones are active. Stop Kernel Zones and retry.
Solución alternativa: opte por una de estas soluciones:
Detenga la ejecución de la zona de núcleo.
# zoneadm -z zonename shutdown
Suspenda la zona de núcleo.
# zoneadm -z zonename suspend
Realice una migración en directo de la zona del núcleo a otro sistema antes de realizar la migración al dominio invitado.
Consulte el Capítulo 3, Migrating an Oracle Solaris Kernel Zone de Creating and Using Oracle Solaris Kernel Zones.
ID de bug 20453206: una operación de migración puede fallar aunque haya disponible suficiente memoria en una distribución válida del sistema de destino. Las operaciones de DR de memoria pueden hacer que resulte más difícil migrar a un dominio invitado.
Solución alternativa: ninguna.
ID de bug 17285751: es posible que la migración de un dominio invitado de Oracle Solaris 10 que tiene solamente una CPU virtual asignada genere la emisión de un aviso grave en el dominio invitado, en la función pg_cmt_cpu_fini().
Tenga en cuenta que este problema se ha corregido en el SO Oracle Solaris 11.1.
Solución alternativa: asigne al menos dos CPU virtuales al dominio invitado antes de realizar la migración en directo. Por ejemplo, utilice el comando ldm add-vcpu number-of-virtual-CPUs domain-name para aumentar la cantidad de CPU virtuales asignadas al dominio invitado.
ID de bug 16864417: el comando ldm migrate -n no informa un fallo al intentar una migración entre un servidor SPARC T5, SPARC M5 o SPARC M6 y un servidor UltraSPARC T2 o SPARC T3.
Solución alternativa: ninguna.
ID de bug 15819714: en algunas circunstancias poco comunes, el comando ldm list -o status informa un porcentaje de finalización incorrecto cuando se utiliza para observar el estado de una migración en un dominio de control.
Este problema no afecta a los dominios que se migran ni a los daemons de ldmd en los dominios de control de origen o destino.
Solución alternativa: ejecute el comando ldm list -o status en el otro dominio de control que está presente en la migración para observar el progreso.
ID de bug 15776123: si el comando cputrack se ejecuta en un dominio invitado mientras ese dominio se migra a un servidor SPARC T4, es posible que se produzca un aviso grave en el dominio invitado de la máquina de destino tras la migración.
Solución alternativa: no ejecute el comando cputrack durante la migración de un dominio invitado a un servidor SPARC T4.
ID de bug 15775055: tras migrar un dominio entre dos equipos que tienen frecuencias de CPU diferentes, es posible que los informes de tiempo de actividad del comando ldm list sean incorrectos. Estos resultados incorrectos se generan porque el tiempo de actividad se calcula en función de la frecuencia STICK del equipo en el que se ejecuta el dominio. Si la frecuencia STICK es diferente entre los equipos de origen y de destino, los valores de tiempo de actividad parecen calcularse de manera incorrecta.
Este problema solo se aplica a servidores UltraSPARC T2, UltraSPARC T2 Plus y SPARC T3.
Los valores de tiempo de actividad informados y mostrados en el dominio invitado son correctos. Asimismo, cualquier cálculo que se realiza en el SO Oracle Solaris del dominio invitado es correcto.
ID de bug 15701865: si intenta realizar una migración en directo de un dominio que depende de un dominio inactivo en el equipo de destino, se produce un error de segmentación en el daemon ldmd y se reinicia el dominio del equipo de destino. Aunque la migración sea correcta, el reinicio no planificado del dominio migrado en la máquina de destino significa que no es una migración en directo.
Solución alternativa: lleve a cabo una de las siguientes acciones antes de intentar la migración en directo:
Elimine la dependencia de invitado del dominio que se va a migrar.
Inicie el dominio maestro en el equipo de destino.
ID de bug 15701853: después de realizar una migración de dominios mientras hay una política DRM en vigor, si la política DRM caduca o se elimina del dominio migrado, DRM no puede restaurar el número original de CPU virtuales en el dominio.
Solución alternativa: si se migra un dominio cuando la política DRM está activa y luego caduca o se elimina la política, restablezca el número de CPU virtuales. Utilice el comando ldm set-vcpu para definir el número de CPU virtuales en su valor original en el dominio.
ID de bug 15696986: si dos comandos ldm migrate se ejecutan de forma simultánea entre los dos sistemas en “dirección opuesta”, es posible que los dos comandos se bloqueen y que nunca se completen. Se presenta una situación de dirección opuesta cuando se inicia simultáneamente una migración en el equipo A para el equipo B y una migración en el equipo B para el equipo A.
El bloqueo se produce incluso si los procesos de migración se inician como ejecuciones simuladas mediante la opción –n. Cuando se produce este problema, se pueden bloquear todos los demás comandos ldm.
Solución alternativa: ninguna.
ID de bug 15527921: durante una migración, se omiten todos los puertos o grupos de consolas asignados de forma explícita, y se crea una consola con propiedades predeterminadas para el dominio de destino. Esta consola se crea utilizando el nombre del dominio de destino como el grupo de consolas y cualquier puerto disponible en el primer concentrador de consola virtual (vcc) del dominio de control. Si hay un conflicto con el nombre de grupo predeterminado, la migración no se realiza correctamente.
Recuperación: para restaurar las propiedades explícitas de la consola tras una migración, desenlace el dominio de destino y establezca manualmente las propiedades deseadas con el comando ldm set-vcons.
ID de bug 15523120: en algunos casos, se produce un error de migración y ldmd informa que no se ha podido enlazar la memoria necesaria para el dominio de origen. Esta situación se puede producir aunque la cantidad total de memoria disponible en el equipo de destino sea mayor que la cantidad de memoria en uso en el dominio de origen.
Este fallo se produce porque la migración de rangos de memoria específicos utilizados por el dominio de origen requiere que también haya rangos de memoria compatibles disponibles en el destino. Cuando no hay ningún rango de memoria compatible para un rango de memoria en el origen, la migración no puede continuar. Consulte Requisitos de migración para la memoria de Guía de administración de Oracle VM Server for SPARC 3.4.
Recuperación: si se detecta esta condición, es posible que pueda migrar el dominio si modifica el uso de la memoria en el equipo de destino. Para ello, desenlace cualquier dominio lógico enlazado o activo en el destino.
Utilice el comando ldm list-devices -a mem para ver qué memoria está disponible y cómo se utiliza. Es posible que también tenga que reducir la cantidad de memoria asignada a otro dominio.
ID de bug 15513998: en ocasiones, después de que un dominio se ha migrado, no es posible conectarse a la consola de ese dominio.
Tenga en cuenta que este problema se produce cuando el dominio migrado ejecuta una versión de SO posterior a Oracle Solaris 11.3.
Solución alternativa: reinicie el servicio SMF vntsd para desactivar las conexiones con la consola:
# svcadm restart vntsd
Este problema solo se aplica a servidores UltraSPARC T2, UltraSPARC T2 Plus y SPARC T3.
Las versiones 8.4, 9.1 y XCP2230 de firmware del sistema presentadas admiten etiquetas de disco EFI GPT. De forma predeterminada, los discos virtuales que se instalan al ejecutar al menos el sistema operativo Oracle Solaris 11.1 en esos sistemas tienen una etiqueta de disco EFI GPT. No puede leer esta etiqueta de disco en las versiones anteriores de firmware (como 9.0.x, 8.3, 7.x o XCP2221). Esta situación le impide realizar una migración activa o inactiva a un sistema que ejecuta una versión de firmware del sistema que no admite EFI GPT. Tenga en cuenta que una migración inactiva también falla en esta situación, que es diferente a las limitaciones anteriores.
Para determinar si el disco virtual tiene una etiqueta de disco EFI GPT, ejecute el comando devinfo -i en el dispositivo raw. Los siguientes ejemplos muestran si el disco virtual tiene una etiqueta SMI VTOC o una etiqueta de disco EFI GPT.
Etiqueta de disco SMI VTOC. Cuando el disco virtual tiene una etiqueta SMI VTOC, puede realizar una migración para firmware independientemente de si se admite EFI.
En este ejemplo se indica que el dispositivo tiene una etiqueta VTOC porque el comando devinfo -i muestra información específica del dispositivo.
# devinfo -i /dev/rdsk/c2d0s2 /dev/rdsk/c2d0s2 0 0 73728 512 2
Etiqueta de disco EFI GPT. Cuando el disco virtual tiene una etiqueta de disco EFI GPT, puede realizar una migración solo al firmware que admite EFI.
En este ejemplo se indica que el dispositivo tiene una etiqueta de disco EFI GPT porque el comando devinfo -i informa un error.
# devinfo -i /dev/rdsk/c1d0s0 devinfo: /dev/rdsk/c1d0s0: This operation is not supported on EFI labeled devices
En esta sección se resumen los bugs que pueden surgir al utilizar esta versión del software. Se describen en primer lugar los bugs más recientes. Cuando es posible, se especifican las soluciones alternativas y los procedimientos de recuperación.
ID de bug 23205662: debido a una limitación en el controlador PSIF usado por determinadas tarjetas InfiniBand, el controlador no admite operaciones de IOV dinámicas, como la creación de funciones virtuales. Esta limitación hace que el modo de recuperación no pueda recuperar dominios raíz que no sean primary y que tengan funciones físicas que usen el controlador PSIF. Las funciones físicas nunca logran prepararse para crear funciones virtuales debido a la falta de compatibilidad con las operaciones de IOV dinámicas.
Solución alternativa: no cree funciones virtuales en las funciones físicas de InfiniBand que usan el controlador PSIF en dominios raíz que no son primary.
ID de bug 23170671: en ocasiones, las funciones virtuales y físicas permanecen en un estado no válido después de crear funciones virtuales. Un dominio que tiene asignada una función virtual de esta clase no puede enlazarse. Si este error se produce durante el modo de recuperación, los dominios de E/S que tienen funciones virtuales en estado INV no se recuperan.
El log ldmd muestra mensajes similares al siguiente para la función física IOVFC.PF1:
Recreating VFs for PF /SYS/MB/PCIE2/IOVFC.PF0 in domain root_2 Recreating VFs for PF /SYS/MB/PCIE2/IOVFC.PF1 in domain root_2 Recreating VFs for PF /SYS/MB/NET2/IOVNET.PF0 in domain root_3 PF /SYS/MB/PCIE2/IOVFC.PF1 not ready (3) PF /SYS/MB/PCIE2/IOVFC.PF1 not ready (3) PF /SYS/MB/PCIE2/IOVFC.PF1 not ready (3) PF /SYS/MB/PCIE2/IOVFC.PF1 not ready (3)
Recuperación: si nota este problema a tiempo, puede reiniciar el agente ldmd en el dominio root_2 para solucionarlo mientras el modo de recuperación continúa reintentando la función física. Reiniciar el agente permite la recuperación de los dominios de E/S que usan funciones virtuales de la función física. Si no nota este problema a tiempo, la operación de recuperación continúa, pero no logra recuperar los dominios de E/S que usan esas funciones virtuales.
ID de bug 23144895: MIB de Oracle VM Server for SPARC muestra solo la configuración por defecto de fábrica para la tabla de configuración (ldomSPConfigTable) de procesador de servicio (SP).
Solución alternativa: para mostrar la lista completa de las configuraciones de SP del sistema, use el comando ldm list-spconfig o la interfaz de XML list-spconfig.
Por ejemplo:
primary# ldm list-spconfig factory-default [next poweron] test_config
El comando XML list-spconfig responde de la siguiente manera:
<cmd>
<action>list-spconfig</action>
<data version="3.0">
<Envelope>
<References/>
<Section>
<Item>
<rasd:OtherResourceType>spconfig</rasd:OtherResourceType>
<gprop:GenericProperty key="spconfig_name">factory-default</gprop:GenericProperty>
<gprop:GenericProperty key="spconfig_status">next</gprop:GenericProperty>
</Item>
</Section>
<References/>
<Section>
<Item>
<rasd:OtherResourceType>spconfig</rasd:OtherResourceType>
<gprop:GenericProperty key="spconfig_name">test_config</gprop:GenericProperty>
</Item>
</Section>
...
ID de bug 23024583: el comando ovmtlibrary limita el nombre de archivo de imagen de disco a 50 caracteres. El comando ovmtlibrary comprueba el archivo .ovf y compara la información de la sección <ovf:References> con los nombres de archivo reales de los discos descomprimidos.
Se produce un error si los archivos son diferentes o si el nombre de archivo de la imagen de disco tiene más de 50 caracteres. Por ejemplo:
# ovmtlibrary -c store -d "example" -q -o file:/template.ova -l /export/user1/ovmtlibrary_example event id is 3 ERROR: The actual disk image file name(s) or the actual number of disk image(s) is different from OVF file: template.ovf exit code: 1
El siguiente ejemplo de XML muestra un nombre de archivo de imagen de disco de más de 50 caracteres:
<ovf:References> <ovf:File ovf:compression="gzip" ovf:href="disk_image.ldoms3.4_build_s11_u3_sru06_rti_02_kz_40G.img.gz" ovf:id="ldoms3" ovf:size="6687633773"/> </ovf:References>
Solución alternativa: limite la longitud de los nombres de archivo de imagen de disco a menos de 50 caracteres.
ID de bug 22919488: el comando ovmtcreate no admite la creación de plantillas desde dominios de origen en los que vdsdev tiene el mismo nombre para más de un disco virtual del mismo dominio.
Es poco probable que se produzca este problema, ya que los dominios de origen que tienen varios discos virtuales, generalmente, tienen diferentes dispositivos back-end y, por lo tanto, diferentes nombres de archivo. Sin embargo, si ovmtdeploy se usa con una plantilla creada desde un dominio de origen en el que vdsdev tiene el mismo nombre para más de un disco virtual, ovmtdeploy falla y muestra un mensaje de error. Por ejemplo:
# ovmtdeploy -d ldg1 template.ova ERROR: pigz: //ldg1/resources/disk_image.ldoms3.4_build_s11_u3_sru05_rti_01_kz_36G.img.gz does not exist -- skipping FATAL: Failed to decompress disk image
Solución alternativa: especifique nombres de archivo de back-end vdsdev diferentes para los discos virtuales que están en el mismo dominio.
ID de bug 22842188: para que linkprop=phys-state se admita en un dispositivo de red virtual, Logical Domains Manager debe poder validar que el conmutador virtual con el que está conectado el dispositivo de red virtual tenga una NIC física que respalde al conmutador virtual.
El agente netsvc de Oracle VM Server for SPARC debe estar en ejecución en el dominio invitado para que sea posible consultar al conmutador virtual.
Si el dominio invitado no está activo y no se puede comunicar con el agente en el dominio que tiene el conmutador virtual del dispositivo de red virtual, el dispositivo de red virtual no tiene establecido linkprop=phys-state.
Solución alternativa: solo establezca linkprop=phys-state cuando el dominio esté activo.
ID de bug 22828100: si un conmutador virtual tiene conectados dispositivos de red virtual con linkprop=phys-state, el conmutador virtual al que están conectados debe tener un dispositivo NIC válido asociado especificado por la propiedad net-dev. El valor de la propiedad net-dev debe ser el nombre de un dispositivo de red válido.
Si la acción se realiza utilizando net-dev=, el conmutador virtual aún muestra linkprop=phys-state aunque el valor de la propiedad net-dev no sea un dispositivo NIC válido.
Solución alternativa: primero, desconecte todos los dispositivos de red virtual conectados al conmutador virtual y, luego, elimine el conmutador virtual. A continuación, vuelva a crear el conmutador virtual con un dispositivo net-dev válido asociado y luego vuelva a crear todos los dispositivos de red virtual.
ID de bug 21616429: el software Oracle VM Server for SPARC 3.3 presentó solamente compatibilidad de socket con Fujitsu M10 Servers.
El software que se ejecuta en servidores Oracle SPARC y versiones de Oracle VM Server for SPARC anteriores a 3.3 no se puede volver a crear con restricciones de socket desde un archivo XML.
Falla el intento de volver a crear un dominio con restricciones de socket desde un archivo XML con una versión anterior del software Oracle VM Server for SPARC o en un servidor Oracle SPARC con el siguiente mensaje:
primary# ldm add-domain -i ovm3.3_socket_ovm11.xml socket not a known resource
Si se está ejecutando Oracle VM Server for SPARC 3.2 en un Fujitsu M10 Server e intenta volver a crear un dominio con restricciones de socket desde un archivo XML, el comando fallará con varios mensajes de error, como el siguiente:
primary# ldm add-domain -i ovm3.3_socket_ovm11.xml Unknown property: vcpus primary# ldm add-domain -i ovm3.3_socket_ovm11.xml perf-counters property not supported, platform does not have performance register access capability, ignoring constraint setting.
Solución alternativa: edite el archivo XML para eliminar las secciones que hacen referencia al tipo de recurso socket.
ID de bug 21321166: en ocasiones, el rendimiento de E/S es menor cuando se usa una ruta de MPxIO de HBA SCSI virtual en un dominio de servicio fuera de línea.
Solución alternativa: desactive la ruta al dominio de servicio fuera de línea mediante el uso del comando mpathadm disable path hasta que se devuelve el dominio de servicio al servicio.
ID de bug 21188211: si se agregan o eliminan LUN desde una SAN virtual después de que se configura un HBA SCSI virtual, en ocasiones, el comando ldm rescan-vhba no muestra la nueva vista de LUN.
Solución alternativa: elimine el HBA SCSI virtual y vuelva a agregarlo. Compruebe si se ven los LUN. Si la eliminación y las operaciones para volver a agregar son incorrectas, deberá reiniciar el dominio invitado.
ID de bug 20876502: la extracción del cable de SAN de un dominio de servicio que es parte de una configuración de dominio invitado MPxIO del HBA SCSI hace que la columna Path State (Estado de ruta) de la salida mpathadm muestre valores incorrectos.
Solución alternativa: conecte el cable de SAN y ejecute el comando ldm rescan-vhba para todos los HBA SCSI virtuales al dominio de servicio que tiene un cable conectado. Después de llevar a cabo esta solución alternativa, el dominio invitado debe reanudas las operaciones de E/S.
ID de bug 20425271: si se inicia una recuperación después de quedar en factory-default, el modo de recuperación falla si el sistema se inicia desde un dispositivo diferente del que se inició en la configuración que estaba activa anteriormente. Este fallo puede ocurrir si la configuración activa utiliza un dispositivo de inicio distinto del dispositivo de inicio factory-default.
Solución alternativa: realice los siguientes pasos cada vez que desee guardar una nueva configuración del SP.
Determine la ruta PCI completa de acceso al dispositivo de inicio para el dominio primary.
Use esta ruta de acceso para el comando ldm set-var en el paso 4.
Elimine cualquier propiedad de boot-device establecida actualmente del dominio primary.
Solo es necesario llevar a cabo este paso si la propiedad boot-device tiene un juego de valores. Si la propiedad no tiene un juego de valores, intente eliminar los resultados de la propiedad boot-device del mensaje boot-device not found.
primary# ldm rm-var boot-device primary
Guarde la configuración actual en el SP.
primary# ldm add-spconfig config-name
Defina explícitamente la propiedad boot-device para el dominio primary.
primary# ldm set-var boot-device=value primary
Si establece la propiedad boot-device después de guardar la configuración del SP, según se describe, el dispositivo de inicio especificado se inicia cuando se activa el modo de recuperación.
Recuperación: si el modo de recuperación ya ha fallado, según se describe, realice los siguientes pasos:
Defina explícitamente como dispositivo de inicio el dispositivo usado en la última configuración en ejecución.
primary# ldm set-var boot-device=value primary
Reinicie el dominio primary.
primary# reboot
El reinicio permite que la recuperación continúe.
ID de bug 20046234: si un HBA SCSI virtual y un dispositivo SR-IOV de canal de fibra pueden ver los mismos LUN en un dominio invitado cuando se activa MPxIO, es posible que se produzca un mensaje de aviso grave. El mensaje de aviso grave se produce si se elimina la tarjeta SR-IOV del canal de fibra del dominio invitado y, a continuación, se vuelve e agregar.
Solución alternativa: no configure un dominio invitado con SR-IOV de canal de fibra y un HBA SCSI virtual si ambos están activados para MPxIO.
ID de bug 19932842: el intento de definir una variable OBP de un dominio invitado puede fallar si se utiliza el comando eeprom u OBP antes de que se complete uno de los siguientes comandos:
ldm add-spconfig
ldm remove-spconfig
ldm set-spconfig
ldm bind
Este problema puede surgir cuando estos comandos demoran más de 15 segundos en completarse.
# /usr/sbin/eeprom boot-file\=-k promif_ldom_setprop: promif_ldom_setprop: ds response timeout eeprom: OPROMSETOPT: Invalid argument boot-file: invalid property
Recuperación: vuelva a intentar ejecutar el comando eeprom u OBP una vez que la operación ldm haya terminado.
Solución alternativa: vuelva a intentar ejecutar el comando eeprom u OBP en el dominio invitado afectado. Es posible que pueda evitar el problema con el comando ldm set-var en el dominio primary.
ID de bug 19449221: un dominio no puede tener más de 999 dispositivos de red virtual (vnet).
Solución alternativa: limite el número de vnet en un dominio a 999.
ID de bug 18001028: en el dominio raíz, la ruta del dispositivo Oracle Solaris para la función virtual del canal de fibra es incorrecta.
Por ejemplo, el nombre de ruta incorrecto es pci@380/pci@1/pci@0/pci@6/fibre-channel@0,2 mientras que debería ser pci@380/pci@1/pci@0/pci@6/SUNW,emlxs@0,2.
El resultado ldm list-io -l muestra la ruta correcta del dispositivo para las funciones virtuales del canal de fibra.
Solución alternativa: ninguna.
ID de bug 16979993: al intentar utilizar operaciones de eliminación de SR-IOV dinámicas en un dispositivo InfiniBand, se obtienen como resultado mensajes de error confusos e inadecuados.
Las operaciones de eliminación de SR-IOV dinámica no son compatibles con los dispositivos InfiniBand.
Solución alternativa: elimine las funciones virtuales de InfiniBand mediante uno de los siguientes procedimientos:
ID de bug 16691046: si se asignan funciones virtuales desde el dominio raíz, es posible que el dominio de E/S no pueda proporcionar resistencia en las siguientes situaciones de conexión en caliente:
Cuando se agrega un complejo de raíz (bus PCIe) de forma dinámica al dominio raíz y, a continuación, se crean las funciones virtuales y se las asigna al dominio de E/S.
Cuando se agrega en caliente una tarjeta SR-IOV al dominio raíz al que pertenece el complejo de raíz y, a continuación, se crean las funciones virtuales y se las asigna al dominio de E/S.
Cuando se sustituye o se agrega una tarjeta PCIe a una ranura vacía (ya se mediante conexión en caliente o cuando el dominio raíz está desactivado) en el complejo de raíz que pertenece al dominio raíz. Este dominio raíz proporciona funciones virtuales desde el complejo de raíz al dominio de E/S.
Solución alternativa: realice uno de los siguientes pasos:
Si el complejo de raíz ya proporciona funciones virtuales al dominio de E/S y agrega, elimina o sustituye una tarjeta PCIe del complejo de raíz (mediante conexión en caliente o cuando el dominio raíz está desactivado), debe reiniciar el dominio raíz y el dominio de E/S.
Si el complejo de raíz no tiene funciones virtuales asignadas actualmente al dominio de E/S y agrega una tarjeta SR-IOV u otra tarjeta PCIe al complejo de raíz, debe detener el dominio raíz para agregar la tarjeta PCIe. Una vez que se ha reiniciado el dominio de raíz, puede asignar funciones virtuales desde el complejo de raíz al dominio de E/S.
Si desea agregar un nuevo bus PCIe al dominio raíz y, a continuación, crear y asignar funciones virtuales desde el bus al dominio de E/S, lleve a cabo uno de los siguientes pasos y, a continuación, reinicie el dominio raíz:
Agregue el bus durante un reconfiguración retrasada.
Agregue el bus de forma dinámica.
ID de bug 16659506: un dominio invitado está en estado de transición (t) tras un reinicio del dominio primary. Este problema se produce cuando hay una gran cantidad de funciones virtuales configuradas en el sistema.
Solución alternativa: para evitar este problema, vuelva a intentar ejecutar el comando de inicio del disco OBP varias veces para evitar un inicio desde la red.
Realice los siguientes pasos en cada dominio:
Acceda a la consola del dominio.
primary# telnet localhost 5000
Establezca la propiedad boot-device.
ok> setenv boot-device disk disk disk disk disk disk disk disk disk disk net
La cantidad de entradas de disk que especifique como valor de la propiedad boot-device depende de la cantidad de funciones virtuales que haya configuradas en el sistema. En sistemas más pequeños, es posible que pueda incluir menos instancias de disk en el valor de la propiedad.
Verifique que la propiedad boot-device esté establecida correctamente mediante el comando printenv.
ok> printenv
Vuelva a la consola del dominio primary.
Repita los pasos de 1 a 4 para cada dominio del sistema.
Reinicie el dominio primary.
primary# shutdown -i6 -g0 -y
ID de bug 16284767: esta advertencia sobre la consola de Oracle Solaris significa que el suministro de interrupciones se ha agotado mientras se conectan los controladores de los dispositivos de E/S:
WARNING: ddi_intr_alloc: cannot fit into interrupt pool
Esta limitación se aplica solo a los sistemas SPARC admitidos anteriores a los servidores serie SPARC M7 y SPARC T7.
El hardware proporciona una cantidad infinita de interrupciones, de modo que Oracle Solaris limita la cantidad que cada dispositivo puede utilizar. Hay un límite predeterminado diseñado para satisfacer las necesidades de las configuraciones del sistema típicas; sin embargo, este límite puede necesitar un ajuste para determinadas configuraciones del sistema.
Específicamente, es posible que sea necesario ajustar el límite si el sistema está particionado en varios dominios lógicos y si hay demasiados dispositivos de E/S asignados a algún dominio invitado. Oracle VM Server for SPARC divide el total de las interrupciones en pequeños conjuntos proporcionados a los dominios invitados. Si hay demasiados dispositivos de E/S asignados a un dominio invitado, el suministro puede ser demasiado pequeño para proporcionar a cada dispositivo el límite predeterminado de interrupciones. Por lo tanto, el suministro se agota antes de que se conecten completamente todos los controladores.
Algunos controladores proporcionan una rutina de devolución de llamada opcional que le permite a Oracle Solaris ajustar automáticamente sus interrupciones. El límite predeterminado no se aplica a estos controladores.
Solución alternativa: utilice las macros MDB ::irmpools and ::irmreqs para determinar cómo se utilizan las interrupciones. La macro ::irmpools muestra el suministro total de interrupciones dividido en agrupaciones. La macro ::irmreqs muestra los dispositivos asignados a cada agrupación. Para cada dispositivo, ::irmreqs muestra si el límite predeterminado se aplica por una rutina de devolución de llamada opcional, la cantidad de interrupciones solicitadas por cada controlador y la cantidad de interrupciones que recibe el controlador.
Las macros no muestran información sobre los controladores que no se pueden conectar. Sin embargo, la información que se muestra ayuda a calcular la medida hasta la que se puede ajustar el límite predeterminado. Cualquier dispositivo que utiliza más de una interrupción sin proporcionar una rutina de devolución de llamada puede forzarse a utilizar menos interrupciones ajustando el límite predeterminado. La reducción del límite predeterminado por debajo de la cantidad que utiliza el dispositivo puede dar como resultado la liberación de interrupciones que usan otros dispositivos.
Para ajustar el límite predeterminado, establezca la propiedad ddi_msix_alloc_limit en un valor de 1 a 8 en el archivo /etc/system. A continuación, reinicie el sistema para que el cambio surta efecto.
Para maximizar el rendimiento, comience por asignar los mayores valores y reducir los valores en incrementos pequeños hasta que el sistema se inicie correctamente sin advertencias. Use las macros ::irmpools y ::irmreqs para medir el impacto del ajuste en todos los controladores conectados.
Por ejemplo, suponga que las siguientes advertencias se emiten durante el inicio del SO Oracle Solaris en un dominio invitado:
WARNING: emlxs3: interrupt pool too full. WARNING: ddi_intr_alloc: cannot fit into interrupt pool
Las macros ::irmpools y ::irmreqs muestran la siguiente información:
# echo "::irmpools" | mdb -k ADDR OWNER TYPE SIZE REQUESTED RESERVED 00000400016be970 px#0 MSI/X 36 36 36 # echo "00000400016be970::irmreqs" | mdb -k ADDR OWNER TYPE CALLBACK NINTRS NREQ NAVAIL 00001000143acaa8 emlxs#0 MSI-X No 32 8 8 00001000170199f8 emlxs#1 MSI-X No 32 8 8 000010001400ca28 emlxs#2 MSI-X No 32 8 8 0000100016151328 igb#3 MSI-X No 10 3 3 0000100019549d30 igb#2 MSI-X No 10 3 3 0000040000e0f878 igb#1 MSI-X No 10 3 3 000010001955a5c8 igb#0 MSI-X No 10 3 3
El límite predeterminado en este ejemplo es de ocho interrupciones por dispositivo, lo cual no es suficiente para la conexión del dispositivo final emlxs3 con el sistema. Dado que todas las instancias de emlxs se comportan del mismo modo, supone que emlxs3 probablemente solicitó 8 interrupciones.
Al restar las 12 interrupciones utilizadas por todos los dispositivos igb de la agrupación total de 36 interrupciones, quedan 24 interrupciones disponibles para los dispositivos emlxs. La división de las 24 interrupciones por 4 sugiere que 6 interrupciones por dispositivo permitirían que todos los dispositivos emlxs se conecten con el mismo rendimiento. Por lo tanto, el siguiente ajuste se agrega al archivo /etc/system:
set ddi_msix_alloc_limit = 6
Cuando el sistema se inicia correctamente sin advertencias, las macros ::irmpools y ::irmreqs muestran la siguiente información actualizada:
# echo "::irmpools" | mdb -k ADDR OWNER TYPE SIZE REQUESTED RESERVED 00000400018ca868 px#0 MSI/X 36 36 36 # echo "00000400018ca868::irmreqs" | mdb -k ADDR OWNER TYPE CALLBACK NINTRS NREQ NAVAIL 0000100016143218 emlxs#0 MSI-X No 32 8 6 0000100014269920 emlxs#1 MSI-X No 32 8 6 000010001540be30 emlxs#2 MSI-X No 32 8 6 00001000140cbe10 emlxs#3 MSI-X No 32 8 6 00001000141210c0 igb#3 MSI-X No 10 3 3 0000100017549d38 igb#2 MSI-X No 10 3 3 0000040001ceac40 igb#1 MSI-X No 10 3 3 000010001acc3480 igb#0 MSI-X No 10 3 3
ID de bug 16068376: en un servidor SPARC T5-8 con aproximadamente 128 dominios, es posible que algunos comandos ldm, como ldm list, muestren 0 segundos como el tiempo de actividad para todos los dominios.
Solución alternativa: inicie sesión en el dominio y utilice el comando uptime para determinar el tiempo de actividad del dominio.
ID de bug 15812823: en situaciones de poca memoria libre, no todos los bloques de memoria pueden usarse como parte de una operación de DR de memoria debido al tamaño. Sin embargo, estos bloques de memoria se incluyen en la cantidad de memoria libre. Esta situación puede hacer que se agregue al dominio una cantidad de memoria menor que la esperada. No aparece ningún mensaje de error si se produce esta situación.
Solución alternativa: ninguna.
ID de bug 15783031: puede experimentar problemas al usar el comando ldm init-system para restaurar una configuración de dominio que ha utilizado operaciones de E/S directa o SR-IOV.
Surge un problema si una o más de las siguientes operaciones se han realizado en la configuración que se va a restaurar:
Una ranura se ha eliminado de un bus que sigue siendo propiedad del dominio primary.
Una función virtual se ha creado a partir de una función física que es propiedad del dominio primary.
Una función virtual se ha asignado al dominio primary, a otros dominios invitados, o a ambos.
Un complejo raíz se ha eliminado del dominio primary y se ha asignado a un dominio invitado, y se utiliza como base para otras operaciones de virtualización de E/S.
Es decir, ha creado un dominio raíz que no es primary y ha realizado alguna de las operaciones anteriores.
Para asegurarse de que el sistema permanezca en un estado en el que ninguna de las acciones anteriores se hayan realizado, consulte Using the ldm init-system Command to Restore Domains on Which Physical I/O Changes Have Been Made (https://support.oracle.com/epmos/faces/DocumentDisplay?id=1575852.1)..
ID de bug 15775637: un dominio de E/S tiene un límite para el número de recursos de interrupción disponibles por cada complejo de raíz.
En los servidores SPARC T3 y SPARC T4, el límite es de aproximadamente 63 vectores MSI/X. Cada función virtual igb utiliza tres interrupciones. La función virtual ixgbe utiliza dos interrupciones.
Si asigna una gran cantidad de funciones virtuales a un dominio, se agotan los recursos del sistema del dominio necesarios para admitir estos dispositivos. Aparecerán mensajes similares a los siguientes:
WARNING: ixgbevf32: interrupt pool too full. WARNING: ddi_intr_alloc: cannot fit into interrupt pool
ID de bug 15771384: la consola invitada de un dominio puede detenerse si se realizan intentos reiterados de conectarse a la consola antes y durante el momento en que la consola se enlaza. Por ejemplo, esto puede suceder si utiliza una secuencia de comandos automatizada para capturar la consola como un dominio que se migra en el equipo.
Solución alternativa: para activar la consola, ejecute los siguientes comandos en el dominio que aloja al concentrador de la consola del dominio (normalmente el dominio de control):
primary# svcadm disable vntsd primary# svcadm enable vntsd
ID de bug 15761509: utilice solo tarjetas PCIe que admiten la función de E/S directa. Estas tarjetas se enumeran en support document (https://support.us.oracle.com/oip/faces/secure/km/DocumentDisplay.jspx?id=1325454.1).
Solución alternativa: utilice el comando ldm add-io para agregar la tarjeta al dominio primary.
ID de bug 15759601: si ejecuta un comando ldm stop inmediatamente después de un comando ldm start, el comando ldm stop puede generar el siguiente error:
LDom domain-name stop notification failed
Solución alternativa: vuelva a ejecutar el comando ldm stop.
ID de bug 15748348: cuando el dominio primary comparte el núcleo físico más bajo (por lo general, 0) con otro dominio, se produce un error al intentar definir la restricción de núcleo completo para el dominio primary.
Solución alternativa: siga estos pasos:
Determine el núcleo enlazado más bajo compartido por los dominios.
# ldm list -o cpu
Desenlace todos los subprocesos de CPU correspondientes al núcleo más bajo de todos los dominios, excepto del dominio primary.
Como resultado, los subprocesos de CPU correspondientes al núcleo más bajo no se comparten y están disponibles para enlazarse con el dominio primary.
Para definir la restricción de núcleo completo, siga uno de estos pasos:
Enlace los subprocesos de CPU al dominio primary y defina la restricción de núcleo completo con el comando ldm set-vcpu -c.
Utilice el comando ldm set-core para enlazar los subprocesos de CPU y definir la restricción de núcleo completo en un solo paso.
ID de bug 15701853: es posible que aparezca el mensaje No response en el log de Oracle VM Server for SPARC cuando la política DRM de un dominio cargado caduca una vez que el recuento de CPU se ha reducido significativamente. La salida del comando ldm list muestra que hay más recursos de CPU asignados al dominio de los que se muestran en la salida de psrinfo.
Solución alternativa: utilice el comando ldm set-vcpu para restablecer el número de CPU del dominio al valor que se muestra en el resultado de psrinfo.
ID de bug 15668368: un servidor SPARC T3-1 se puede instalar con discos de dos puertos, a los que se puede acceder mediante dos dispositivos de E/S directa diferentes. En este caso, asignar estos dos dispositivos de E/S directa a dominios diferentes puede provocar que los discos se utilicen en ambos dominios y que se vean afectados en función del uso real de esos discos.
Solución alternativa: no asigne dispositivos de E/S directa con acceso al mismo conjunto de discos a diferentes dominios de E/S. Para determinar si tiene discos de dos puertos en el servidor SPARC T3-1, ejecute el siguiente comando en el SP:
-> show /SYS/SASBP
Si el resultado incluye el valor fru_description siguiente, el sistema correspondiente tiene discos de dos puertos:
fru_description = BD,SAS2,16DSK,LOUISE
Si se encuentran discos de dos puertos en el sistema, asegúrese de que estos dos dispositivos de E/S directa estén siempre asignados al mismo dominio:
pci@400/pci@1/pci@0/pci@4 /SYS/MB/SASHBA0 pci@400/pci@2/pci@0/pci@4 /SYS/MB/SASHBA1
ID de bug 15664666: cuando se crea una dependencia de restablecimiento, el comando ldm stop -a puede generar que se reinicie un dominio con una dependencia de restablecimiento en lugar de que solo se detenga.
Solución alternativa: en primer lugar, ejecute el comando ldm stop en el dominio maestro. Luego, ejecute el comando ldm stop en el dominio esclavo. Si la detención inicial del dominio esclavo genera un error, ejecute el comando ldm stop -f en el dominio esclavo.
ID de bug 15600969: si todas las unidades criptográficas del hardware se eliminan dinámicamente de un dominio en ejecución, la estructura criptográfica no puede cambiar a los proveedores de software criptográficos y se terminan todas las conexiones ssh.
Este problema solo se aplica a servidores UltraSPARC T2, UltraSPARC T2 Plus y SPARC T3.
Recuperación: vuelva a establecer las conexiones ssh una vez que todas las unidades criptográficas se hayan eliminado del dominio.
Solución alternativa: establezca UseOpenSSLEngine=no en el archivo /etc/ssh/sshd_config del servidor y ejecute el comando svcadm restart ssh.
Todas las conexiones ssh ya no utilizarán las unidades criptográficas de hardware (y, por lo tanto, no se beneficiarán de las mejoras de rendimiento relacionadas) y las conexiones ssh no se desconectarán cuando se eliminen dichas unidades.
ID de bug 15572184: un comando ldm puede tardar en responder cuando se inician varios dominios. Si ejecuta un comando ldm en esta etapa, puede parecer que el comando se bloquea. Tenga en cuenta que el comando ldm se restablecerá después de realizar la tarea esperada. Una vez que se restablece el comando, el sistema debe responder normalmente a los comandos ldm.
Solución alternativa: evite iniciar varios dominios de forma simultánea. Sin embargo, si debe iniciar varios dominios a la vez, intente no ejecutar más comandos ldm hasta que el sistema vuelve a su estado normal. Por ejemplo, espere aproximadamente dos minutos en los servidores Sun SPARC Enterprise T5140 y T5240, y alrededor de cuatro minutos en el servidor Sun SPARC Enterprise T5440 o el servidor Sun Netra T5440.
ID de bug 15518409: si no tiene una red configurada en el equipo y hay un cliente del servicio de información de red (NIS) en ejecución, Logical Domains Manager no se iniciará en el sistema.
Solución alternativa: desactive el cliente NIS en el equipo no conectado a la red:
# svcadm disable nis/client
ID de bug 15453968: la instalación en red simultánea de varios dominios invitados no se realiza correctamente en los sistemas que tienen un grupo de consolas común.
Solución alternativa: solo realice una instalación en red de dominios invitados que tengan su propio grupo de consolas. Este error solo se observa en dominios que comparten un grupo de consolas común entre varios dominios de instalación en red.
ID de bug 15370442: el entorno con Logical Domains no permite definir ni suprimir claves de inicio de red de área amplia (WAN) desde el SO Oracle Solaris mediante el comando ickey(1M). Se produce el siguiente error en todas las operaciones ickey:
ickey: setkey: ioctl: I/O error
Además, las claves de inicio WAN que se definen con el firmware OpenBoot en dominios lógicos distintos del dominio de control no se recuerdan tras reiniciar el dominio. En estos dominios, las claves del firmware OpenBoot solamente son válidas para un único uso.
ID de bug 15368170: en algunos casos, el comportamiento del comando ldm stop-domain puede resultar confuso.
# ldm stop-domain -f domain-name
Si el dominio se encuentra en el indicador del depurador del módulo de núcleo, kmdb(1), se produce el siguiente mensaje de error al ejecutar el comando ldm stop-domain:
LDom <domain-name> stop notification failed
En esta sección, se incluyen los problemas y errores de la documentación de la versión Oracle VM Server for SPARC 3.4 que se han encontrado demasiado tarde para resolverlos.
La página del comando man ldm(1M) no menciona que se deba reiniciar un dominio activo después de usar el comando ldm set-domain para cambiar el valor de la propiedad boot-policy.
La descripción de la propiedad boot-policy se ha actualizado con el siguiente párrafo:
Si el dominio está activo al cambiar el valor de boot-policy, debe reiniciar el dominio para que el cambio surta efecto.
Además, el primer párrafo de la sección Configuración de opciones para dominios ahora menciona el nombre de la propiedad boot-policy:
El subcomando set-domain le permite modificar solo las propiedades boot-policy, mac-addr, hostid, failure-policy, extended-mapin-space, master y max-cores de cada dominio. No puede usar este comando para actualizar las propiedades de recurso.
La página del comando man ldmd(1M) muestra el nombre incorrecto de propiedad SMF ldmd/fj-ppar-dr-policy. El nombre correcto de la propiedad es ldmd/fj_ppar_dr_policy.