Migración activa en dispositivos GPU-P

En este artículo se describe el diseño funcional de la migración activa de dispositivos de procesamientos heterogéneos (GPU, NPU, etc.) virtualizados a través de particiones de SR-IOV (virtualización de E/S de raíz única). Los dispositivos donde se pueden crear particiones a través de los modelos de controlador WDDM y MCDM ahora son una parte integral de nuestras soluciones de virtualización. Por tanto, es importante incluir la migración activa y ayudar a que nuestras abstracciones de virtualización sean totalmente fiables en cuanto al impacto en los clientes cuando las asignaciones de recursos deben cambiar. En este artículo también se describe la migración rápida de estos dispositivos.

La migración activa se incluye a partir de la versión 24H2 de Windows 11 (WDDM 3.2). Por lo general, es una extensión de las DDI de paravirtualización de GPU (GPU-P) de los controladores que exponen la funcionalidad. Los controladores de MCDM que implementan las interfaces de virtualización GPU-P también pueden implementar estas interfaces de migración activa, incluida la extensión con eventos de evaluación de errores.

En este artículo, "GPU" simplemente hace referencia a los dispositivos que implementan la plataforma de virtualización GPU-P, ya sea WDDM o MCDM, y si una GPU, una NPU u otro dispositivo de procesamiento heterogéneo.

Tipos y propósito de migración de recursos

La migración de recursos es la capacidad de mover una virtualización a nuevos recursos físicos. Hay varias maneras en las que se puede mover la ejecución virtualizada, entre las que se incluyen:

• Apagado total. La placa base virtual se puede apagar directamente, deteniendo la ejecución de los recursos virtuales. Las aplicaciones que no son tolerantes a subidas de potencia pierden los datos con los que operan y se borra todo el estado del dispositivo. El disco duro virtual (VHD) se puede virtualizar en una máquina host diferente, lo que da como resultado un arranque en frío.

• Apagado temporal. Esta apagado difiere del apagado total en que se envía la solicitud de apagado al sistema operativo invitado. A continuación, el sistema operativo invitado distribuye el mecanismo de apagado a las aplicaciones para cerrarlas de forma limpia. Las aplicaciones pueden usar esta notificación para almacenar de forma segura todos los datos y registrarlos para reiniciarse en el arranque, aunque depende de la programación de cada aplicación. Para un apagado temporal se necesita un sistema operativo invitado que admita este mecanismo de apagado limpio y los servicios adecuados para almacenar el estado actual y reiniciarlos en el arranque.

• Hibernación. Esta otra tecnología procedente de un sistema invitado permite al invitado realizar la transición a un estado de apagado de suspensión de inicio rápido donde todos los procesos de aplicación están inmovilizados, el estado del dispositivo se purga en la memoria de la CPU y luego se envía toda la memoria al almacenamiento para hacer que el hardware se apague. Después, el disco duro virtual de almacenamiento de la máquina virtual se puede reiniciar en otra máquina y la memoria cargada, el estado del dispositivo restaurado y los procesos se desbloqueen. La hibernación solo está disponible en los sistemas operativos invitados que lo admiten. Es un proceso bastante invasivo que depende de la estabilidad de los invitados, pero ofrece un mecanismo para restaurar los procesos de las aplicaciones con el estado de que los mecanismos de apagado no ofrecen.

• Migración rápida (también conocida como Guardado y restauración de máquinas virtuales). Con esta tecnología, la máquina virtual se pone en pausa (las vCPU dejan de programar) y todo el estado necesario para restaurar el estado en los nuevos recursos físicos se recopila dentro del sistema operativo host, incluida la memoria de la máquina virtual y el estado de todos los dispositivos. Este estado se transfiere al nuevo host que crea una máquina virtual con todos los contextos de vCPU cargados, asigna la memoria al espacio de la máquina virtual y restaura los estados del dispositivo. Tras esto, PowerOnRestore reinicia la ejecución de las vCPU. Esta tecnología es independiente del sistema operativo invitado y no depende de la ejecución en el entorno invitado, por lo que es una manera más fiable de mantener el proceso y el estado del dispositivo sin la hibernación. El usuario de virtualización podrá notar un tiempo de parada significativo, ya que la memoria de la máquina virtual puede ocupar muchos GB y los tiempos de transferencia pueden ser perceptibles.

• Migración en vivo. Si tenemos la capacidad de transferir contenido mientras los recursos virtualizados todavía están activos y podemos realizar un seguimiento del contenido con errores, es posible transferir bastante contenido mientras se deja la virtualización activa. Cuando la máquina virtual está en pausa, es necesario transferir mucho menos contenido y se puede reducir el tiempo en que la virtualización no se está ejecutando. El resultado minimiza el impacto en el usuario final, ya que todas las operaciones que se producen durante la migración pueden seguir sin impedimentos y el impacto en la tasa de consumo de recursos se reduce todo lo posible en ese momento. En concreto, las fechas tope de interrupción (restricciones de tiempo externas a la interrupción de virtualización, como TCP y otros tiempos de espera de protocolo con puntos de conexión externos) se pueden minimizar o eliminar.

Cada progresión reduce o elimina algo de la atención (a menudo casi toda) de algunos clientes al cambio en la asignación física de una virtualización, lo que hace que esta sea cada vez más completa y transparente para el usuario. Junto con otras tecnologías (como el aislamiento de bloqueos de host) que separan las dependencias del cliente en la infraestructura, mueve nuestra solución de virtualización hacia una independencia en la asignación ideal y un procesamiento temporal real.

Diseño a gran escala

La migración activa transfiere el contenido de virtualización de un host de origen a un host de destino. La virtualización consta de varios dispositivos con estado, que pueden incluir memoria, procesamiento y almacenamiento, cada uno con datos que se deben transferir de los dispositivos de origen a los dispositivos de destino. Los agentes ejecutivos que administran las virtualizaciones entre clústeres se comunican con hosts para que sepan configurar todo para la migración de origen de una máquina virtual existente (cuando el contenido sale del host) o para la migración de destino a una nueva máquina virtual (para recibir el contenido). Los principales agentes de esta interacción aparecen en el diagrama siguiente.

:

Épocas del host de origen

En el diagrama siguiente se ven los estados de migración de origen.

:

Inicio de origen

Generalmente, cuando un host se inicia, el KMD informa de las funcionalidades del dispositivo al kernel a través de varias llamadas de inicialización.

Cuando el KMD recibe la llamada DxgkDdiQueryAdapterInfo de los datos de DXGKQAITYPE_GPUPCAPS, este puede activar el bit de la funcionalidad LiveMigration agregada a DXGK_GPUPCAPS. Cuando el KMD crea este bit, indica que el controlador admite la migración activa.

Un requisito previo para poder usar la migración activa es incluir el seguimiento de páginas de VRAM modificadas en todos los segmentos de memoria local de la GPU, tal como se describe en Seguimiento de bits de integridad. Esa compatibilidad se avisa a través de otras llamadas de DxgkDdiQueryAdapterInfo con otros tipos de información indicados. Un controlador que informa de la compatibilidad con la migración activa también debe registrar la compatibilidad con el seguimiento de bits de integridad. La compatibilidad con la migración activa, pero no con el seguimiento de bits de integridad es una configuración no válida y Dxgkrnl no podrá iniciar el adaptador.

Máquinas virtuales activas

Una vez que los inicios del host y las pilas de administración están activas la actividad de máquina virtual comienza a estar habilitada. Empiezan a llegar solicitudes para iniciar y detener máquinas virtuales y se empiezan a ver las vGPU de GPU-P proyectadas en estas virtualizaciones.

Si ponemos como ejemplo una funcionalidad efectiva del plano de bits de integridad, Dxgkrnl llama a DxgkDdiStartDirtyTracking después de reservar los recursos de VRAM en una VF (función virtual), lo que permite al sistema realizar un seguimiento de la limpieza de VRAM en caso de que la VF participe posteriormente en una operación de migración.

Este inicio de máquina virtual comienza a interceptar el acceso a la tabla de interrupción para virtualizar la función de interrupciones, lo que se mantiene mientras dure la máquina virtual.

Preparación de envío de migración activa

La pila de administración envía el evento para comenzar la migración activa cuando se indica mediante sus controles y la administración de máquinas de estado de migración recopila todo el estado del dispositivo virtual que no cambia mientras dure la virtualización (métricas de configuración de particiones de vGPU) para reconstruir la vGPU en el destino. Una vez listo, se inicia el proceso de preparación de búferes de transporte y la inicialización de la pila de transporte.

Esta época genera una llamada a la DDI introducida DxgkDdiPrepareLiveMigration. El KMD debe establecer las directivas de programación de PF/VF que dan la opción de realiza la migración activa para transmitir contenido desfasado de la VRAM en el host, a la vez que se respeta un rendimiento razonable para la VF. Si el seguimiento de integridad sale como no conforme, aquí también es donde se inicia el seguimiento de integridad.

Envío de migración activa

:

Después, entramos en la fase activa de la transferencia de VRAM desfasada. Esta fase consiste en realizar llamadas a través de la DDI del plano de bits de integridad para obtener instantáneas de la VF del búfer de fotogramas y luego paginar esas páginas de la GPU a los búferes de la CPU preparados anteriormente.

Hay un momento en esta transferencia en la que la máquina virtual y todos sus dispositivos virtuales están en pausa. La VF puede dejar de estar programada para el invitado y, en ese momento, cualquier período de tiempo adicional que se pueda otorgar a la PF para finalizar la paginación del contenido. Como la VF y la vCPU están en pausa en la máquina virtual, no debe haber ningún cambio adicional en el contenido que se migre (CPU o memoria local del dispositivo) a partir de aquí.

Envío de migración en pausa

Las últimas iteraciones de páginas desfasadas se transfieren mientras están pausadas. En este punto, se realiza una llamada para recopilar cualquier última fragmento de estado de dispositivo y controlador que se pueda transformar mientras estaba activa y no se pudo transferir en la preparación anterior. Este estado puede ser cualquier reconstrucción de estado necesaria en el otro extremo, cualquier estructura de seguimiento o generalmente toda la información necesaria para finalizar la restauración del estado de la VF en destino.

Anulación de migración activa

Por último, una vez que la máquina virtual y todos los dispositivos virtuales han transferido su estado a sus nuevas realizaciones físicas, el origen puede limpiar los restos de la máquina virtual. Los búferes y otros estados de migración se borran y se destruye la vGPU.

Épocas del host de destino

En el diagrama siguiente se ven los estados de migración de destino.

:

Inicio del destino

El inicio en el destino se parece al del inicio en el origen. El inicio se aplica a todo el sistema, que puede ser un origen y un destino en diferentes máquinas virtuales a lo largo de su ciclo de vida. El controlador solo tiene que indicar la compatibilidad con la migración activa para participar.

Preparación para recibir migración activa

En el destino, la máquina virtual se construye como si fuera una nueva máquina virtual. Se crean la máquina virtual y los dispositivos virtuales. En este proceso de creación se incluye la GPU virtual, creada con los mismos parámetros con los que se creó en origen. Después de la creación, se reciben los datos de validación y se pasan al controlador para validar que el destino es compatible con el origen para restaurar la máquina virtual. En ese momento, se debe garantizar cualquier cosa que pueda afectar a dicha compatibilidad, incluida la versión del controlador, las versiones de firmware y otro estado de entorno del sistema de destino y el controlador. El controlador se configurará para permitir el acceso a la PF durante todo el tiempo de paginación que normalmente se asignaría a la VF, aunque la VF aún no está activa.

Recepción de migración activa

:

La recepción de datos de páginas desfasadas es similar a la fase en origen, excepto que la dirección de paginación procede de búferes de la CPU a la VRAM. Todas las transferencias se realizan mientras la VF está en pausa, por lo que toda la transferencia se puede realizar dentro de la atribución de la VF.

Inicio y desmontaje de máquina virtual

Una vez completada toda la migración de VRAM, la vGPU tiene la oportunidad de configurar cualquier estado adicional que sea necesario transferir (los datos de guardado mutables finales). Luego, se inicia la máquina virtual en el destino y se anula el estado de migración, incluidos los búferes usados para la transferencia.

Objetivos de rendimiento

Una parte importante de la migración activa es su capacidad de respuesta. En concreto, minimiza el tiempo de inactividad de la virtualización cuando no responde externamente (ya sea al usuario de la virtualización o a los puntos de conexión a los que se podría seguir conectando). Muchos protocolos de pila de redes tienen tiempos de espera en máquinas remotas que son bastante cortos antes de que se produzca un error en el reintento o el restablecimiento, lo que puede ser perjudicial para el usuario cuando se quita. Como objetivo fijo común, el tiempo total de pausa de transferencia e inicio debe estar por debajo de tres cuartos de segundo (750 ms), lo que hace que se aleje de los tiempos de espera de pila más comunes.

Además, los cambios de rendimiento en el sistema activo no deben activar otras interrupciones del usuario final si es posible. En los dispositivos que usan estas DDI, el sistema no debe aumentar significativamente las tasas de solicitudes de incorporación de cambios (TDR) mediante la ralentización de los tiempos programados. Esperamos que la mayoría de las TDR no sean paquetes largos, sino dispositivos bloqueados en su lugar, y duplicar o triplicar el tiempo para ejecutar un paquete no debe hacer que la mayoría de paquetes superan largos tiempos de espera en segundos. Aun así, debemos tener cuidado de no activar los tiempos de espera en todo el rendimiento general.

Interfaces de controladores de dispositivo

Por lo general, las DDI de migración activa hacen referencia a los conceptos generales de DDI de WDDM y MCDM y DDI de virtualización de GPU-P en particular.

• hAdapter suele hacer referencia al token de identificación que representa un dispositivo específico que administra el controlador. Los sistemas con varios dispositivos físicos que registra el sistema pueden hacer que un controlador administre varios hAdapters, por lo que hAdapter se localizará en el dispositivo específico.

• vfIndex identifica a qué función virtual o vDEV se hace referencia. Se localiza en el dispositivo virtual específico. A veces también se denomina ID de partición.

• DeviceLuid también localiza el dispositivo virtual específico, pero en el idioma de la interfaz del UMED con la administración de dispositivos virtuales.

• SegmentId identifica la exposición específica del segmento VidMm al hacer referencia al contenido almacenado en el dispositivo, como la reserva de VRAM.

Nota sobre las definiciones de interfaz

En este artículo se hace referencia a las estructuras de tamaño dinámico. Estas estructuras se implementan mediante matrices de tamaño dinámico, que las páginas de referencia describen como:

    size_t       ArraySize;
    ElementType  Array[ArraySize];

donde la interfaz pasa un tamaño de matriz antes en la estructura y el análisis del objeto de interfaz; luego se repite en los muchos elementos cuando se facilita la matriz. Estas declaraciones no son válidas en C/C++, ya que estos lenguajes expresan fragmentos de tamaño estático. Lea primero la estructura de tamaño estático y después analice dinámicamente el código.

Informes de inicio y límites de dispositivos

Las siguientes funcionalidades se agregan a DXGK_GPUPCAPS:

• El límite LiveMigration indica la compatibilidad del controlador con la característica de migración activa (por lo general, las DDI agregadas mencionadas en este artículo, excepto DxgkDdiSetVirtualGpuResources2).
• El límite ScatterMapReserve indica la compatibilidad del controlador con DxgkDdiSetVirtualGpuResources2, que se agregará en una próxima versión.

El KMD debe rellenar estos límites cuando el sistema operativo llama a DxgkDdiQueryAdapterInfo con una solicitud de DXGKQAITYPE_GPUPCAPS. El sistema operativo consulta los límites durante la inicialización del dispositivo después de llamar a DxgkDdiStartDevice y cuando el adaptador admite particiones de GPU.

Si el controlador devuelve el límite ScatterMapReserve, deberá exponer el DXGKQAITYPE_SCATTER_RESERVE agregado con las siguientes estructuras asociadas para que el sistema operativo pueda consultar las funcionalidades de reserva de dispersión del controlador:

• DXGK_QUERYSCATTERRESERVEIN en pInputData
• DXGK_QUERYSCATTERRESERVEOUT en pOutputData

Compatibilidad con paginación de dispersión

Para admitir la transferencia de páginas desfasadas no contiguas hacia y desde el búfer de fotogramas, esta función es una de las primeras en aplicar asignaciones de VA de GPU que no vienen respaldadas por direcciones físicas contiguas. No es necesario actualizar las interfaces de paginación actuales para usar esta funcionalidad, ya que siempre ha sido una opción general admitidas en las tablas de páginas. Pero es probable que este cambio exponga los detalles de implementación latentes que hagan aproximaciones sobre la contigüidad. Por ello, es importante conocer este mecanismo del sistema operativo, cómo ejecuta las interfaces de paginación virtuales y asegurarse de que la paginación es sólida con este cambio.

En concreto, la interfaz TransferVirtual ahora pasa rangos de VA que no están asignados de forma contigua en el búfer de fotogramas.

Inicio de la migración activa en el modo de envío

Cuando el sistema inicia el componente activo de la migración, debe llamar a la DDI agregada DxgkDdiPrepareLiveMigration. Esta llamada avisa al controlador de que esta época se ha iniciado y le permite configurar la directiva de programación de la VF para la migración, que debe recibir parte de la atribución libre y de migración de la VF para la paginación de la PF.

Dxgkrnl llama a la DDI DxgkDdiSaveImmutableMigrationData del KMD para recopilar información sobre el dispositivo que se va a restaurar en destino.

Una vez que el sistema recopila y envía los datos inmutables y los datos de validación, se inicia el bucle iterativo principal del envío de integridad.

Guardado/envío iterativo

Tal como se describe en la sección de información general, la operación de guardado iterativo usa DxgkDdiQueryDirtyBitData para crear una instantánea del plano de bits de integridad actual de la VF al principio de cada iteración y usa la operación estándar DXGK_OPERATION_VIRTUAL_TRANSFER para paginar las páginas desfasadas que se hayan comunicado. Si esta operación se produce en un dispositivo que ha registrado en sus funcionalidades de seguimiento de integridad que el rendimiento no se ha visto afectado mínimamente, el control de iteración del sistema habilitará primero el seguimiento de integridad y luego transferirá todo el búfer de fotogramas antes de la primera llamada para consultar el plano de bits de integridad.

En la transferencia virtual, el proceso principal es que la asignación no es una VA contigua a la PA contigua. En su lugar, puede haber páginas desconectadas de la PA en la asignación. De lo contrario, el proceso es tal como se describe en la documentación original sobre paginación y seguimiento de planos de bits de integridad y esta característica no se integra en ella.

Lado de envío final de migración activa

Al final de la migración, el sistema debe recopilar todo lo relacionado con el estado del dispositivo y del controlador necesarios para terminar de volver a generar el estado y el seguimiento que aún no se han transferido. Estos datos no se podrían transferir porque no reúnen los requisitos de inmutabilidad de los datos de migración anteriores y no era contenido desfasado de VRAM. Dxgkrnl llama a la DDI DxgkDdiSaveMutableMigrationData agregada para ello. Este uso de la DDI es similar a DxgkDdiSaveImmutableMigrationData.

Finalmente, cuando no hay que configurar la migración en esta VF, se llama a DxgkDdiEndLiveMigration. Toda la programación y el estado deben volver a una configuración que no sea de migración.

Inicio de la migración activa en el lado de recepción

Cuando los datos inmutables entran en recepción, el sistema lo pasa directamente al KMD a través de una llamada a DxgkDdiRestoreImmutableMigrationData.

Esta DDI solo debe llamarse con las máquinas virtuales que estén en pausa en ese momento.

Restauración/recepción iterativa

De nuevo, la paginación de dispersión funciona de forma iterativa, pero esta vez sin las llamadas para inspeccionar el plano de bits de integridad asociado al búfer de fotogramas reservado por la VF, ya que el plano de bits de integridad en el destino se construye mediante la paginación. Se invierte la dirección de paginación. El contenido de los búferes recibidos se transfiere a la VRAM, con la ubicación de las páginas dictadas.

Lado de recepción final de migración activa

Una vez que la migración termina, el sistema receptor llama a la función DxgkDdiRestoreMutableMigrationData con el paquete final del estado que se va a restaurar. Este paquete debe incluir todo el contenido que se dejó para que el controlador para que lo transfiera y restaurar su estado y seguimiento, así como para restaurar lo que quede del estado de la VF.

Esta DDI solo debe llamarse con las máquinas virtuales que estén en pausa en ese momento.

Después de esta llamada, el sistema llama a la función DxgkDdiEndLiveMigration del KMD para que el destino sepa limpiar cualquier estado alrededor de la migración activa, incluida la restauración de la programación normal de la VF.

Comunicaciones con el UMED

La interfaz DLL de emulación en modo de usuario (UMED) se amplía con la interfaz IGPUPMigration para exponer la capacidad de guardar y validar contenido durante una migración activa.

HRESULT SaveImmutableGpup(
    [in]     PLUID     DeviceLuid,
    [in,out] UINT64 *  Length,
    [in,out] BYTE *    SaveBuffer
    );

HRESULT RestoreImmutableGpup(
    [in] PLUID   DeviceLuid,
    [in] UINT64  Length,
    [in] BYTE *  RestoreBuffer
    );

Durante las acciones de preparación de la migración activa en las que se llama de forma similar al KMD, el UMED tiene la oportunidad de enviar información que pueda ser útil para preparar el UMED para la migración o validación que el entorno admita en relación con el UMED. Es una interfaz opcional para los UMED con los contratos de interfaz estándar del UMED (contexto de subprocesos y procesos, exposición restringida del sistema operativo, etc.). Su patrón de llamada imita las DDI del KMD, con un guardado en dos fases. No hay indicadores de estado en estas llamadas, como otras interfaces de UMED de guardado y restauración, ya que deben ser válidas y constantes durante toda la vida útil del dispositivo y su LUID.

El estado mutable del UMED se transfiere en la interfaz de guardado y restauración existente. En el pasado, esta interfaz se ha bloqueado para que no se ejecute con controladores GPU-P, pero se desbloquea cuando el KMD registra la compatibilidad con LiveMigration. Este vínculo de la función de llamada del UMED y la funcionalidad del KMD tiene su propósito. La migración activa es la forma en que el sistema implementa la migración rápida para la virtualización de estos dispositivos. Se realiza la misma secuencia de tareas y se puede considerar la migración rápida (guardado/restauración) como el caso especial de la migración activa donde no hay ninguna transferencia activa. Un UMED que admita guardado y restauración (Save/Restore) debe tener un KMD que admita las DDI de migración activa. Del mismo modo, el UMED debe tener en cuenta la interfaz de IGPUPMigration y evaluar si es necesario en su diseño antes de que el KMD pueda migrar activamente.

Virtualización de interrupciones

El direccionamiento físico de la administración de interrupciones de invitado debe virtualizarse para poder atender correctamente el acceso a la tabla MSI-X a medida que cambia el hardware subyacente durante la migración. El UMED debe interceptar la tabla de interrupciones MSI-X en todos los controladores que admitan la migración activa. Las operaciones de lectura o escritura en los campos Dirección superior del mensaje y Dirección de mensaje deben asignarse a los valores de hardware reales. Dxgkrnl mantiene la asignación de la dirección virtualizada (o de invitado) y realiza la sustitución cuando es necesario en la pila de llamadas.

El sistema operativo administra la virtualización o asignación de las direcciones físicas invitadas a las que las lecturas o escrituras de la tabla pueden hacer referencia a la parte del invitado con las direcciones físicas del host necesarias para el mantenimiento de interrupciones efectivas. Esta ruta común no necesita una implementación del UMED independiente ni un redireccionamiento del kernel y el sistema operativo no avisa al UMED cuando el sistema operativo intercepta la tabla. El único requisito del UMED es que las mitigaciones del dispositivo deben establecerse en las páginas BAR de la tabla.

Sin embargo, en el kernel, Dxgkrnl quiere que el KMD se haga cargo de las operaciones de escritura reales. El KMD lo hace implementando la función de devolución de llamada agregada DxgkDdiWriteVirtualizedInterrupt.

Nunca debe haber necesidad de una lectura porque el UMD realiza un seguimiento local de las escrituras (en formato virtualizado o traducido por el invitado) para que no sea necesario un salto de kernel costoso. Este seguimiento se migra con el dispositivo virtual.

Sincronización de DDI y contextos de IRQL

DDI	Nivel de sincronización	IRQL
DxgkDdiPrepareLiveMigration	0	PASSIVE
DxgkDdiEndLiveMigration	0	PASSIVE
DxgkDdiSaveImmutableMigrationData	0	PASSIVE
DxgkDdiSaveMutableMigrationData	0	PASSIVE
DxgkDdiRestoreImmutableMigrationData	0	PASSIVE
DxgkDdiRestoreMutableMigrationData	0	PASSIVE
DxgkDdiWriteVirtualizedInterrupt	0	PASSIVE
DxgkDdiSetVirtualGpuResources2	0	PASSIVE
DxgkDdiSetVirtualFunctionPauseState	0	PASSIVE
IGPUPMigration::SaveImmutableGpup	0	PASSIVE
IGPUPMigration::RestoreImmutableGpup	0	PASSIVE

Observaciones importantes sobre la programación de VF

La eficacia de la transferencia está fuertemente determinada por la programación de las transferencias de paginación en la PF. Cuanto más acceso a los motores de paginación del dispositivo tenga la PF para saturar el bus y conseguir el mejor rendimiento, más eficaz será la transferencia en general y la transferencia pausada en concreto. Cuanto más contenido se pueda capturar y enviar en un momento dado, mejor; al menos hasta la saturación de la red.

Es preferible que el cambio en la programación solo afecte al motor de paginación y a ningún otro recurso de dispositivo, pero no todos los diseños de programación de VF podrían permitir esto. Como mínimo, se desea que la programación:

• Tome solo la atribución de la VF que se va a migrar o de la programación de VF sin asignar.
• No degrade el rendimiento de ninguna otra virtualización en la máquina.

Tenga en cuenta que, en el destino, estas condiciones se pueden cumplir mucho más fácilmente, ya que la VF está en pausa durante toda la transferencia y todo la atribución está disponible. En el origen, se necesita equilibrar las necesidades de migración y las de la máquina virtual, con la condición final de cumplir los objetivos de pausar la transferencia.