Omitir V�nculos de navegaci�n | |
Salir de la Vista de impresi�n | |
Guía de administración de Oracle VM Server for SPARC 2.2 Oracle VM Server for SPARC (Español) |
Parte I Software Oracle VM Server for SPARC 2.2
1. Información general sobre el software del Oracle VM Server for SPARC
2. Instalación y habilitación del software
3. Seguridad de Oracle VM Server for SPARC
4. Configuración de servicios y el dominio de control
5. Configuración de los dominios invitados
6. Configuración de dominios de E/S
Introducción a la migración de dominios
Información general sobre la operación de migración
Seguridad en las operaciones de migración
Realización de migraciones no interactivas
Migración de un dominio activo
Requisitos de migración de dominio para las CPU
Requisitos de migración para la memoria
Requisitos de migración para los dispositivos de E/S física
Requisitos de migración para los dispositivos de E/S virtual
Requisitos de migración para la E/S híbrida de NIU
Requisitos de migración para las unidades criptográficas
Reconfiguración retrasada en un dominio activo
Migración mientras un dominio activo tiene la política elástica de gestión de energía en vigor.
Migración de un dominio desde una PROM OpenBoot o un dominio que ejecuta el depurador de núcleo
Migración de dominios enlazados o inactivos
Requisitos de migración para los dispositivos de E/S virtual
Requisitos de migración para los dispositivos de punto final PCIe
Seguimiento de una migración en curso
Cancelación de una migración en curso
Recuperación de una migración fallida
10. Administración de recursos
11. Gestión de configuraciones de dominios
12. Realización de otras tareas administrativas
Parte II Software Oracle VM Server for SPARC opcional
13. Herramienta de conversión física a virtual del Oracle VM Server for SPARC
14. Asistente de configuración de Oracle VM Server for SPARC (Oracle Solaris 10)
15. Uso del software de Base de datos de información de administración de Oracle VM Server for SPARC
16. Descubrimiento del Logical Domains Manager
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.
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. Se recomienda tener como mínimo 16 CPU en cada dominio primary, aunque no es obligatorio.
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.
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.
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
Nota - Después de la migración, la reconfiguración dinámica de memoria (DR) está inhabilitada para el dominio migrado hasta que se reinicia. Después de haber completado el reinicio, la DR de memoria se vuelve a habilitar para el dominio migrado.
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.
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.
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.
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.
Nota - 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.
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.
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.
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.
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.