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 más información, consulte Restricciones en la migración de dominios de Notas de la versión de Oracle VM Server for SPARC 2.2.

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 un cliente NTP de Oracle Solaris 10, consulte Gestion du protocole NTP (tâches) de Guide d’administration système : Services réseau. Para configurar un dominio como un cliente NTP de Oracle Solaris 11, consulte Gestion du protocole NTP (tâches) de Administration d’Oracle Solaris : Services réseau.

Requisitos de migración de dominio para las CPU

A continuación se indican los requisitos y las restricciones de las CPU cuando realiza una migración:

• 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.

• En los sistemas que ejecutan el sistema operativo Oracle Solaris 10, los equipos de origen y destino deben tener los mismos tipos de procesadores.

• En el sistema operativo Oracle Solaris 11, la configuración de la propiedad cpu-arch permite migrar entre sistemas que tienen tipos de procesadores diferentes. Los siguientes son los valores de propiedad cpu-arch admitidos:

  • 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.

  • generic utiliza funciones de hardware de CPU comunes para permitir que un dominio invitado realice una migración independiente de tipo de CPU.

  El uso del valor generic puede provocar una disminución en el rendimiento en comparación con el 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.

  Utilice el comando psrinfo -pv para determinar el tipo de procesador, como se indica a continuación:

  # psrinfo -pv
  The physical processor has 8 virtual processors (0-7)
    SPARC-T4 (chipid 0, clock 2548 MHz)

• Cuando el dominio que se va a migrar ejecuta el sistema operativo Oracle Solaris 11, puede migrar el dominio entre un sistema de origen y un sistema de destino que tengan frecuencias de procesador diferentes y los valores de frecuencia STICK. Este tipo de migración es posible incluso si el valor de propiedad cpu-arch no está establecido. Sin embargo, cuando el dominio que se va a migrar ejecuta el sistema operativo Oracle Solaris 10, las frecuencias de procesador y los valores de frecuencia STICK deben coincidir.

  Utilice el comando prtconf -pv para determinar la frecuencia de STICK, como se indica a continuación:

  # prtconf -pv | grep stick-frequency
      stick-frequency:  05f4bc08

  ---

  Nota - La frecuencia a la que se incrementa el registro STICK se obtiene de la frecuencia de la CPU a máxima velocidad. No obstante, aunque la frecuencia de la CPU en ambos equipos puede ser idéntica, la frecuencia de registro STICK exacta podría diferir ligeramente y, por tanto, bloquear una migración.

  ---

Requisitos de migración para la memoria

Debe haber suficiente memoria libre en el equipo de destino para acomodar la migración de un dominio. Además, a continuación se incluyen algunas propiedades que deben mantenerse a lo largo de la migración:

• Debe ser posible crear el mismo número de bloques de memoria con un tamaño idéntico.

• No es necesario que coincidan las direcciones físicas de los bloques de memoria, pero deben mantenerse las mismas direcciones reales a lo largo de la migración.

Además, el diseño de la memoria disponible en el equipo de destino debe ser compatible con el diseño de la memoria del dominio que se migrará para que la migración se realice correctamente. En especial, si la memoria del equipo de destino está fragmentada en múltiples rangos de direcciones pequeñas, pero el dominio que se migrará requiere un rango de dirección larga única, fallará la migración. El siguiente ejemplo ilustra este escenario. El equipo de destino tiene 2 Gbytes de memoria libre en dos bloques de memoria:

# ldm list-devices memory
MEMORY
    PA                   SIZE
    0x108000000          1G
    0x188000000          1G

El dominio que se migrará, ldg-src, también tiene 2 Gbytes de memoria libre, pero aparece como un solo bloque de memoria:

# ldm list -o memory ldg-src
NAME
ldg-src

MEMORY
    RA               PA               SIZE
    0x8000000        0x208000000      2G

En esta situación de diseño de la memoria, falla la migración:

# ldm migrate-domain ldg-src t5440-sys-2
Target Password:
Unable to bind 2G memory region at real address 0x8000000
Domain Migration of LDom ldg-src failed

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.

Requisitos de migración para los dispositivos de E/S virtual

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:

• Cada backend de disco virtual que se utiliza en el dominio que se va a migrar debe definirse en el equipo de destino. 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.

  ---

  Nota - 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 de un 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. La migración falla si existe un conflicto con el nombre de grupo predeterminado.

Requisitos de migración para la E/S híbrida de NIU

Puede migrar un dominio que utilice recursos de E/S híbridos de NIU. Una restricción que especifique los recursos de E/S híbridos de NIU no es un requisito estricto de un dominio. Si dicho dominio migra a un equipo que no tiene disponibles recursos de NIU, se conserva la restricción, pero no se ejecuta.

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.

Las siguientes versiones del SO Oracle Solaris admiten una DR de unidad criptográfica:

• Como mínimo SO 10 10/09 de Solaris

• Como mínimo SO Solaris 10 5/08 más parche ID 142245-01

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, los Logical Domains Manager intentan 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.

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. Las operaciones de reconfiguración retrasada se bloquean mientras una migración está en curso.

Migración mientras un dominio activo tiene la política elástica de gestión de energía en vigor.

Las migraciones de dominios no se admiten para un equipo de origen o destino que tiene la política elástica de gestión de energía (PM) en vigor. Si la política de gestión de energía en el equipo de origen o de destino se cambia del modo de rendimiento al modo elástico mientras hay una migración en curso, se aplaza el conmutador de política hasta que se complete la migración. El comando de migración devuelve un error si se intenta una migración de dominio mientras el equipo de origen o de destino tiene la política elástica en vigor.

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 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 Logical Domains Manager y el SO 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 consecuencia, el intento de migración fallará a menos que del dominio que se va a migrar sólo tenga una CPU. Cuando el dominio que se va a migrar sólo tiene una CPU, la migración continúa si se cumplen ciertos requisitos y restricciones. Consulte Restricciones en la migración de dominios de Notas de la versión de Oracle VM Server for SPARC 2.2.