Migración de un dominio activo
Se aplican ciertos requisitos y restricciones al dominio que se va a migrar, el equipo de origen y el equipo de destino cuando se intenta migrar un dominio activo. Para obtener más información, consulte Restricciones de la migración de dominios.
Consejo - Puede reducir el tiempo de migración total agregando más CPU virtuales al dominio primary tanto del equipo de origen como del equipo de destino. Aunque no es requisito, se recomienda tener como mínimo dos núcleos enteros en cada dominio primary.
Un dominio “pierde tiempo” durante el proceso de migración. Para mitigar este problema de pérdida de tiempo, sincronice el dominio que se va a migrar con un origen de tiempo externo, como un servidor NTP (Network Time Protocol). Cuando configura un dominio como cliente NTP, la fecha y la hora del dominio se corrigen en cuanto se completa la migración.
Para configurar un dominio como cliente NTP de Oracle Solaris 10, consulte Managing Network Time Protocol (Tasks) de System Administration Guide: Network Services. Para configurar un dominio como cliente NTP de Oracle Solaris 11, consulte Managing Network Time Protocol (Tasks) de Introduction to Oracle Solaris 11 Network Services.
Notas - Durante la fase de suspensión al final de una migración, es posible que un dominio invitado experimente un ligero retraso. Este retraso no debe producir ninguna interrupción notoria para las comunicaciones de red, especialmente si el protocolo incluye un mecanismo de reintento, como TCP, o si existe un mecanismo de reintento en el nivel de la aplicación, como NFS a través de UDP. Sin embargo, si el dominio invitado se ejecuta una aplicación dependiente de la red, como el protocolo de información de enrutamiento (RIP), es posible que el dominio experimente un breve retraso al intentar realizar una operación. Este retraso tiene lugar en el período breve en que se elimina y se vuelve a crear la interfaz de red invitada, durante la fase de suspensión.
Requisitos de migración de dominio para las CPU
El equipo de destino debe tener suficientes CPU virtuales libres para acomodar el número de CPU virtuales en uso mediante el dominio que se va a migrar.
Al definir la propiedad cpu-arch en el dominio invitado, podrá migrar el dominio entre sistemas que tienen tipos de procesadores diferentes. Tenga en cuenta que el dominio invitado debe estar en un estado enlazado o inactivo para cambiar el valor cpu-arch.
Los valores admitidos de la propiedad cpu-arch son los siguientes:
native utiliza funciones de hardware específicas de CPU para permitir que un dominio invitado migre solamente entre plataformas que tienen el mismo tipo de CPU. native es el valor predeterminado.
migration-class1 es una familia de migración entre CPU para las plataformas SPARC, a partir de SPARC T4. Estas plataformas admiten criptografía de hardware durante estas migraciones y después de ellas, para que haya un límite inferior vinculado a las CPU compatibles.
Este valor no es compatible con plataformas UltraSPARC T2, UltraSPARC T2 Plus o SPARC T3, o Plataformas Fujitsu M10.
sparc64-class1 es una familia de migración entre CPU para las plataformas SPARC64. Debido a que el valor sparc64-class1 se basa en las instrucciones de SPARC64, tiene un número mayor de instrucciones que el valor generic. Por lo tanto, no tiene ningún impacto en el rendimiento, a diferencia del valor generic.
Este valor es compatible únicamente con Fujitsu M10 Servers.
generic utiliza las funciones de hardware de CPU comunes inferiores que utilizan todas las plataformas para permitir que un dominio invitado realice una migración independiente del tipo de CPU.
Los siguientes comandos de isainfo -v muestran las instrucciones que están disponibles en un sistema cuando cpu-arch=generic y cpu-arch=migration-class1.
cpu-arch=generic
# isainfo -v 64-bit sparcv9 applications asi_blk_init vis2 vis popc 32-bit sparc applications asi_blk_init vis2 vis popc v8plus div32 mul32cpu-arch=migration-class1
# isainfo -v 64-bit sparcv9 applications crc32c cbcond pause mont mpmul sha512 sha256 sha1 md5 camellia des aes ima hpc vis3 fmaf asi_blk_init vis2 vis popc 32-bit sparc applications crc32c cbcond pause mont mpmul sha512 sha256 sha1 md5 camellia des aes ima hpc vis3 fmaf asi_blk_init vis2 vis popc v8plus div32 mul32
El uso del valor generic puede tener como resultado un rendimiento reducido del dominio invitado en comparación con el uso del valor native. La posible disminución de rendimiento se produce porque el dominio invitado utiliza solamente funciones de CPU genéricas que están disponibles en todos los tipos de CPU admitidas en lugar de utilizar funciones de hardware nativas de una CPU particular. Si no utiliza estas funciones, el valor generic permite la flexibilidad de migrar el dominio entre sistemas que utilizan CPU que admiten diferentes funciones.
Si está migrando un dominio entre al menos sistemas SPARC T4, puede definir cpu-arch=migration-class1 para mejorar el rendimiento del dominio invitado. Si bien el rendimiento mejora a partir del uso del valor generic, el valor native sigue proporcionando el mejor rendimiento para el dominio invitado.
Utilice el comando psrinfo -pv cuando la propiedad cpu-arch esté definida como native para determinar el tipo de procesador, de la siguiente manera:
# psrinfo -pv The physical processor has 2 virtual processors (0 1) SPARC-T5 (chipid 0, clock 3600 MHz)
Tenga en cuenta que cuando la propiedad cpu-arch se establece en un valor distinto a native, la salida de psrinfo -pv no muestra el tipo de plataforma. En lugar de ello, el comando muestra que el módulo de CPU sun4v-cpu está cargado.
# psrinfo -pv The physical processor has 2 cores and 13 virtual processors (0-12) The core has 8 virtual processors (0-7) The core has 5 virtual processors (8-12) sun4v-cpu (chipid 0, clock 3600 MHz)
A continuación se indican los requisitos y las restricciones de las CPU cuando realiza una migración:
Requisitos de migración para la memoria
Suficiente memoria libre para alojar la migración de un dominio
La memoria libre debe estar disponible en un diseño compatible
Los requisitos de memoria del equipo de destino son los siguientes:
Los requisitos de compatibilidad son distintos para cada plataforma SPARC. Sin embargo, se debe conservar como mínimo la alineación entre la dirección real y la dirección física con respecto al mayor tamaño de página admitido para cada bloque de memoria del dominio migrado.
Use el comando pagesize para determinar el tamaño de página máximo admitido en el equipo de destino.
En el caso de dominios invitados que ejecuten por lo menos el sistema operativo Oracle Solaris 11.3, los bloques de memoria del dominio migrado se pueden dividir automáticamente durante la migración para que el dominio migrado pueda adaptarse al uso de bloques de memoria libre disponible de menor tamaño. Los bloques de memoria solo se pueden dividir en límites que estén alineados con el tamaño de página máximo.
Otros requisitos de distribución de la memoria con respecto al sistema operativo, el firmware o la plataforma pueden impedir la división de los bloques de memoria durante una migración determinada. Esta situación puede provocar que la migración falle aunque la cantidad total de memoria libre disponible sea suficiente para el dominio.
Requisitos de migración para los dispositivos de E/S física
Los dominios que tienen acceso directo a los dispositivos físicos no se pueden migrar. Por ejemplo, no se pueden migrar dominios de E/S. No obstante, los dispositivos virtuales que están asociados con dispositivos físicos se pueden migrar.
Para obtener más información, consulte Requisitos de migración para los dispositivos de punto final PCIe y Requisitos de migración para funciones virtuales SR-IOV PCIe.
Requisitos de migración para los dispositivos de E/S virtual
-
Cada backend de disco virtual que se utiliza en el dominio que se va a migrar debe definirse en el equipo de destino. Este almacenamiento compartido puede ser un disco SAN, o almacenamiento que está disponible mediante los protocolos NFS o iSCSI. El backend de disco virtual que defina debe tener los mismos nombres de volumen y servicio que en el equipo de origen. Las rutas al backend podrían ser diferentes en los equipos de origen y destino, pero es necesario que hagan referencia al mismo backend.
Precaución - La migración se realizará correctamente aunque las rutas a un backend de disco virtual en los equipos de origen y destino no haga referencia al mismo almacenamiento. No obstante, el comportamiento del dominio en el equipo de destino será impredecible y es probable que no se pueda utilizar. Para solucionar esta situación, detenga el dominio, corrija el problema de configuración y, a continuación, reinicie el dominio. Si no lleva a cabo estos pasos, es posible que el dominio quede en un estado incoherente.
Cada dispositivo de red virtual del dominio que se va a migrar debe tener un conmutador de red virtual correspondiente en el equipo de destino. Cada conmutador de red virtual debe tener el mismo nombre que el conmutador de red virtual al que está asociado el dispositivo en el equipo de origen.
Por ejemplo, si vnet0 en el dominio que se va a migrar está asociado a un servicio de conmutador virtual denominado switch-y, un dominio del equipo de destino debe proporcionar un servicio de conmutador virtual denominado switch-y.
Notas - La red física del equipo de destino debe estar configurada correctamente para que el dominio migrado pueda acceder a los recursos de red que necesita. De lo contrario, algunos servicios de red podrían no estar disponibles en el dominio después de finalizar la migración.Pongamos por caso que desea asegurarse de que el dominio pueda acceder a la subred correcta. También quiere constatar que las puertas de enlace, los enrutadores y los servidores de seguridad estén configurados correctamente para que el dominio pueda alcanzar los sistemas remotos necesarios desde el equipo de destino.
Las direcciones MAC que utiliza el dominio que se va a migrar que están en el rango asignado automáticamente deben estar disponibles para su uso en el equipo de destino.
Debe existir un servicio de concentrador de consola virtual (vcc) en el equipo de destino y tener como mínimo un puerto libre. Durante la migración se ignoran las restricciones de consola explícitas. La consola del dominio migrado se crea utilizando el nombre del dominio migrado como grupo de consola, así como cualquier puerto disponible en el primer dispositivo vcc del dominio de control. Si no hay puertos disponibles en el dominio de control, la consola se crea utilizando un puerto disponible en un dispositivo vcc disponible en un dominio de servicio. La migración falla si existe un conflicto con el nombre de grupo predeterminado.
Cada SAN virtual que se utiliza en el dominio que se va a migrar debe definirse en el equipo de destino.
Todos los servicios de E/S virtual que utiliza el dominio que se a migrar deben estar disponibles en el equipo de destino. En otras palabras, deben producirse las siguientes condiciones:
Requisitos de migración para los dispositivos de punto final PCIe
No puede realizar una migración de dominio en un dominio de E/S que está configurado con dispositivos de punto final PCIe.
Para obtener información sobre la función de E/S directa, consulte Creación de un dominio de E/S mediante la asignación de dispositivos de punto final PCIe.
Requisitos de migración para funciones virtuales SR-IOV PCIe
No puede realizar una migración de dominio en un dominio de E/S que está configurado con funciones virtuales SR-IOV PCIe.
Para obtener información sobre la función SR-IOV, consulte Creación de un dominio de E/S mediante las funciones virtuales SR-IOV PCIe.
Requisitos de migración para las unidades criptográficas
En plataformas que tienen unidades criptográficas, puede migrar un dominio invitado que tenga unidades criptográficas enlazadas si ejecuta un sistema operativo que admite la reconfiguración dinámica (DR) de las unidades criptográficas.
Al principio de la migración, Logical Domains Manager determina si el dominio que se va a migrar admite la DR de unidades criptográficas. Si se admite, el Logical Domains Manager intenta eliminar cualquier unidad criptográfica del dominio. Después de haber completado la migración, las unidades criptográfica se vuelven a agregar al dominio migrado.
Notas - Si no se pueden cumplir las restricciones de las unidades criptográficas en el equipo de destino, la operación de migración no se bloqueará. En este caso, el dominio migrado puede tener menos unidades criptográficas de las que tenía antes de la operación de migración.
Reconfiguración retrasada en un dominio activo
Cualquier operación de reconfiguración retrasada activa en el equipo de origen o de destino evita que se inicie una migración. No tiene permiso para iniciar una operación de reconfiguración retrasada mientras está en curso una migración.
Migración mientras un dominio activo tiene la política elástica de gestión de energía en vigor.
Puede realizar una migración en vivo cuando se aplica la política elástica de gestión de energía (PM) en el equipo de origen o el equipo de destino.
Operaciones en otros dominios
Mientras hay una migración en curso en un equipo, se bloquea cualquier operación que pueda provocar una modificación del estado o de la configuración del dominio que se está migrando. Se bloquean todas las operaciones del propio dominio, así como las operaciones que enlazan o detienen en otros dominios del equipo.
Migración de un dominio desde una PROM OpenBoot o un dominio que ejecuta el depurador de núcleo
La migración de un dominio requiere la coordinación entre el Logical Domains Manager y el SO Oracle Solaris que se ejecuta en el dominio que se va a migrar. Cuando un dominio que se va a migrar se ejecuta en OpenBoot o en el depurador del núcleo (kmdb), esta coordinación no es posible. Como resultado, el intento de migración falla.
Cuando un dominio que se va a migrar se ejecuta en OpenBoot, aparecerá el siguiente mensaje:
primary# ldm migrate ldg1 system2 Migration is not supported while the domain ldg1 is in the 'OpenBoot Running' state Domain Migration of LDom ldg1 failed
Cuando un dominio que se va a migrar se ejecuta en el depurador de núcleo (kmdb), verá el siguiente mensaje:
primary# ldm migrate ldg1 system2 Migration is not supported while the domain ldg1 is in the 'Solaris debugging' state Domain Migration of LDom ldg1 failed