Migração dinâmica em dispositivos GPU-P

Este artigo descreve o design funcional da migração dinâmica de dispositivos de computação heterogêneos (GPUs, NPUs etc.) virtualizados por meio do particionamento SR-IOV (virtualização de E/S de raiz única). Os dispositivos que oferecem suporte ao particionamento por meio dos modelos de driver WDDM e MCDM agora são parte integrante de nossas ofertas de virtualização. Assim, é importante dar suporte à migração dinâmica e ajudar nossas abstrações de virtualização a se tornarem confiáveis ao máximo para o impacto sobre os clientes quando as atribuições de recursos precisarem mudar. Este artigo também descreve a migração rápida desses dispositivos.

A migração dinâmica é suportada a partir do Windows 11, versão 24H2 (WDDM 3.2). Geralmente, é mais uma extensão das DDIs de paravirtualização de GPU (GPU-P) para drivers que expõem a capacidade. Os drivers MCDM que implementam as interfaces de virtualização de GPU-P também podem, opcionalmente, implementar essas interfaces de migração dinâmica, incluindo sua extensão com eventos de triagem.

Neste artigo, "GPU" se refere a dispositivos que implementam a estrutura de virtualização de GPU-P, seja WDDM ou MCDM, e seja uma GPU, NPU ou outro dispositivo de computação heterogêneo.

Tipos e finalidade da migração de recursos

A migração de recursos é a capacidade de mover uma virtualização para novos recursos físicos. Há várias maneiras pelas quais a execução virtualizada pode ser movida, incluindo:

• Desligamento rígido. A placa-mãe virtual pode ser desligada diretamente, interrompendo a execução dos recursos virtuais. Todos os aplicativos não tolerantes a picos de energia perdem os dados com os quais estão operando e todo o estado do dispositivo é apagado. O VHD (disco rígido virtual) pode então ser virtualizado em um computador host diferente, o que resulta em uma inicialização a frio.

• Desligamento suave. Esse desligamento difere do desligamento rígido porque ele simplesmente envia a solicitação de energia para o SO convidado. Em seguida, o SO convidado distribui o mecanismo de desligamento para que os aplicativos sejam desligados de forma limpa. Os aplicativos podem usar essa notificação para armazenar com segurança todos os dados e se registrar para reiniciar na inicialização, embora dependam da programação de cada aplicativo. Um desligamento suave requer um SO convidado que suporte esse mecanismo de desligamento limpo e os serviços apropriados para armazenar o estado atual e reiniciar na reinicialização.

• Hibernação. Essa outra tecnologia originada pelo convidado permite que o convidado faça a transição para um estado de energia de suspensão de início rápido, em que todos os processos do aplicativo são congelados, o estado do dispositivo é removido para a memória da CPU e toda a memória é enviada ao armazenamento para permitir que o hardware desligue. Em seguida, o VHD de armazenamento da VM pode ser reiniciado em uma máquina diferente e a memória carregada, o estado do dispositivo restaurado e os processos podem ser descongelados. A hibernação só está disponível em SOs convidados que a suportem. É um processo bastante invasivo que depende da estabilidade do convidado, mas fornece um mecanismo para restaurar processos de aplicativos com o estado que os mecanismos de desligamento não fornecem.

• Migração rápida (também conhecida como Salvar e restaurar VM). Com essa tecnologia, a VM é pausada (vCPUs param de agendar) e todo o estado necessário para restaurar o estado nos novos recursos físicos é reunido dentro do SO host, incluindo a memória da VM e o estado de todos os dispositivos. Esse estado é então transferido para o novo host, que cria uma VM com todos os contextos de vCPU carregados, mapeia a memória para o espaço da VM e restaura os estados do dispositivo. Um PowerOnRestore reinicia a execução das vCPUs. Essa tecnologia é independente do SO convidado e não depende da execução no ambiente convidado, portanto, é uma maneira mais confiável de manter o estado do processo e do dispositivo do que a hibernação. O usuário de virtualização pode notar um tempo de inatividade significativo, pois a memória da VM pode ser de muitos GBs e os tempos de transferência perceptíveis.

• Migração ao Vivo. Se tivermos a capacidade de transferir conteúdo enquanto os recursos virtualizados ainda estão ativos e pudermos rastrear o conteúdo que fica sujo, podemos transferir conteúdo significativo enquanto deixamos a virtualização ativa. Então, quando a VM é pausada, muito menos conteúdo precisa ser transferido e podemos minimizar o tempo em que a virtualização não está sendo executada. O resultado é o impacto minimizado para o usuário final, pois todas as operações que ocorrem durante a migração continuam desimpedidas e o impacto na taxa de consumo de recursos é reduzido na medida do possível. Em particular, os prazos de interrupção (restrições de tempo externas à interrupção da virtualização, como TCP e outros tempos-limite de protocolo com pontos de extremidade externos) podem ser minimizados ou eliminados.

Cada progressão reduz ou remove alguma consciência (muitas vezes importante) do cliente sobre a mudança na atribuição física de uma virtualização, tornando a virtualização cada vez mais completa e transparente para o usuário. Juntamente com outras tecnologias (como o isolamento de falhas do host) que separam as dependências do cliente na infraestrutura, ela move nossa solução de virtualização em direção ao ideal de independência de atribuição e computação efêmera verdadeira.

Design em grande escala

A migração dinâmica transfere o conteúdo de virtualização de um host de origem para um host de destino. A virtualização consiste em vários dispositivos com estado, que podem incluir memória, computação e armazenamento, cada um com dados que devem ser transferidos dos dispositivos na origem para os no destino. Os agentes executivos que gerenciam virtualizações em clusters se comunicam com os hosts para informá-los sobre a configuração da orquestração para a migração de origem de uma VM existente (quando o conteúdo está saindo do host) ou a migração de destino para uma nova VM (para receber o conteúdo). Os principais participantes dessa interação são vistos no diagrama a seguir.

:

Épocas do host de origem

O diagrama a seguir ilustra os estados de migração do lado da origem.

:

Inicialização do lado da origem

Geralmente, quando um host inicializa, o KMD relata os recursos do dispositivo para o kernel por meio de várias chamadas de inicialização.

Quando o KMD recebe a chamada DxgkDdiQueryAdapterInfo para dados DXGKQAITYPE_GPUPCAPS, ele pode definir o bit de recurso LiveMigration adicionado a DXGK_GPUPCAPS. Quando o KMD define esse bit, ele indica que o driver oferece suporte à migração dinâmica.

Um pré-requisito para o suporte à migração dinâmica é oferecer suporte ao rastreamento de páginas VRAM modificadas em todos os segmentos de memória local da GPU, conforme descrito em Rastreamento de bits sujos. Esse suporte é relatado por meio de outras chamadas DxgkDdiQueryAdapterInfo para outros tipos de informações especificados. Um driver que relata suporte para migração dinâmica também deve relatar suporte para rastreamento de bits sujos. O suporte para migração dinâmica, mas não para rastreamento de bits sujos, é uma configuração inválida, e o Dxgkrnl falha ao iniciar o adaptador.

VMs online

Depois que o host inicializa e as pilhas de gerenciamento estão online, a atividade da máquina virtual começa a ficar online. As solicitações para iniciar e parar VMs começam a chegar e vemos vGPUs GPU-P projetadas nessas virtualizações.

Assumindo a capacidade de plano de bits sujos com desempenho, o Dxgkrnl chama DxgkDdiStartDirtyTracking depois de reservar os recursos da VRAM para uma VF (função virtual), que permite que o sistema rastreie a limpeza da VRAM no caso em que a VF participa posteriormente de um cenário de migração.

Essa inicialização de VM começa a interceptar o acesso à tabela de interrupção para virtualizar o suporte de interrupção, que prossegue durante o tempo de vida da VM.

Preparação de envio de migração dinâmica

A pilha de gerenciamento envia o evento para iniciar a migração dinâmica quando indicada por seus controles e o gerenciamento de máquina de estado de migração reúne todo o estado do dispositivo virtual, que é imutável durante o tempo de vida da virtualização (métricas de configuração de partição de vGPU), para reconstruir a vGPU no destino. Uma vez pronto, o processo de preparação dos buffers de transporte e inicialização da pilha de transporte é iniciado.

Essa época gera uma chamada para a DDI DxgkDdiPrepareLiveMigration introduzida. O KMD deve estabelecer as políticas de agendamento de PF/VF que definem a capacidade da migração dinâmica de transmitir conteúdo sujo da VRAM no host, preservando o desempenho justo para a VF. Se o rastreamento sujo for relatado como não eficiente, esse ponto também é onde o rastreamento sujo é iniciado.

Envio de migração dinâmica

:

Entramos então na fase ativa da transferência de VRAM suja. Essa fase envolve fazer chamadas por meio da DDI de plano de bits sujos para obter instantâneos do buffer de quadros da VF e, em seguida, paginar essas páginas da GPU para os buffers de CPU preparados anteriormente.

Chega um estágio nessa transferência em que a VM e todos os seus dispositivos virtuais são pausados. A VF pode deixar de ser agendada para o convidado e, nesse momento, qualquer fração extra de tempo que possa ser proporcionada à PF para finalizar a paginação do conteúdo deve ser. Como a VF e a vCPU estão pausadas na VM, não deve haver mais alterações no conteúdo que está sendo migrado (CPU ou memória local do dispositivo) após esse ponto.

Envio de migração pausado

As últimas iterações de páginas sujas são transferidas enquanto estão pausadas. Neste ponto, uma chamada é feita para reunir quaisquer últimas partes do dispositivo e do estado do driver que foi mutável enquanto ativo e não pôde ser transferido na preparação anterior. Esse estado pode ser qualquer reconstrução de estado necessária do outro lado, quaisquer estruturas de rastreamento ou, geralmente, todas as informações necessárias para finalizar a restauração do estado da VF no lado do destino.

Desinstalação da migração dinâmica

Finalmente, depois que a VM e todos os seus dispositivos virtuais tiverem transferido seu estado para suas novas realizações físicas, o lado da origem poderá limpar os remanescentes da VM. Os buffers e outros estados de migração são limpos e a vGPU é destruída.

Épocas do host de destino

O diagrama a seguir ilustra os estados de migração do lado do destino.

:

Inicialização do lado do destino

A inicialização no destino é praticamente a mesma que na origem. A inicialização é para todo o sistema, que pode ser uma origem e um destino em diferentes VFs durante o seu ciclo de vida. O driver só precisa especificar o suporte da migração dinâmica para participar.

Preparação para o recebimento da migração dinâmica

No lado do destino, a VM é construída começando como se fosse uma nova VM. A VM e os dispositivos virtuais são criados. Esse processo de criação inclui a GPU virtual, criada usando os mesmos parâmetros com os quais foi criada no lado da origem. Após a criação, os dados de validação são recebidos e passados ao driver para validar se o lado do destino é compatível com a origem e restaurar a VM. Nesse ponto, ele deve garantir qualquer coisa que possa afetar essa compatibilidade, incluindo a versão do driver, versão(ões) do firmware e outro estado ambiente do sistema e do driver de destino. O driver será configurado para permitir que o PF acesse todas as frações de tempo de paginação que normalmente seriam atribuídas à VF enquanto ela ainda não estivesse ativa.

Recebimento de migração dinâmica

:

O recebimento de dados de página suja é semelhante ao estágio na origem, exceto que a direção de paginação é de buffers de CPU para VRAM. Todas as transferências são feitas enquanto a VF está pausada, para que toda a transferência possa ser feita dentro do orçamento da VF.

Início e desinstalação da VM

Quando toda a migração da VRAM estiver concluída, a vGPU terá a chance de configurar qualquer estado adicional que precise ser transferido (os dados finais mutáveis salvos). Em seguida, iniciamos a VM no destino e desinstalamos o estado de migração, incluindo os buffers usados para a transferência.

Metas de desempenho

Uma parte importante da migração dinâmica é a sua capacidade de resposta. Em particular, ela minimiza o tempo de inatividade da virtualização, em que ela não responde externamente (seja para o usuário da virtualização ou quaisquer pontos de extremidade aos quais possa estar conectada). Muitos protocolos de pilha de rede têm tempos-limite em máquinas remotas que são bastante breves antes da falha de repetição/restabelecimento e, portanto, podem causar interrupções para o usuário quando descartados. Como uma meta fixa comum, o tempo total de pausa para transferir e iniciar deve ser inferior a três quartos de segundo (750 ms), o que leva o tempo sem contato para menos que muitos dos tempos-limite de pilha mais comuns.

Além disso, as alterações de desempenho no sistema ativo não devem desencadear outras interrupções no usuário final, se possível. Nos dispositivos que usam essas DDIs, o sistema não deve aumentar significativamente a taxa de TDRs diminuindo a velocidade programada. Agora, esperamos que a maioria dos TDRs não sejam pacotes longos, mas dispositivos suspensos, e dobrar ou triplicar o tempo para executar um pacote não deve levar a maioria dos pacotes aos maiores tempos-limite de segundos. Mas precisamos estar atentos para não acionar nossos tempos-limite no quadro geral de desempenho.

Interfaces de driver de dispositivo

Geralmente, as DDIs de migração dinâmica referem-se aos conceitos gerais de DDIs WDDM e MCDM e às DDIs de virtualização de GPU-P em particular.

• O hAdapter geralmente se refere ao token de identificador representando um dispositivo específico que esse driver gerencia. Os sistemas com vários dispositivos físicos enumerados pelo sistema podem ter um driver para gerenciar vários hAdapters, assim, o hAdapter localiza o dispositivo específico.

• vfIndex identifica qual função virtual/vDEV está sendo referenciada. Ele localiza o dispositivo virtual específico. Às vezes, também é chamado de ID de partição.

• O O DeviceLuid também localiza o dispositivo virtual específico, mas no idioma da interface UMED com o gerenciamento de dispositivo virtual.

• O SegmentId identifica a exposição específica do segmento VidMm ao fazer referência ao conteúdo armazenado no dispositivo, como a reserva de VRAM.

Observação sobre definições de interface

Este artigo refere-se a estruturas de tamanho dinâmico. Essas estruturas são implementadas por meio de matrizes de tamanho dinâmico, que as páginas de referência descrevem como:

    size_t       ArraySize;
    ElementType  Array[ArraySize];

onde a interface passa um tamanho de matriz anterior na estrutura e a análise do objeto de interface então itera sobre esses vários elementos quando a matriz é fornecida. Essas declarações não são C/C++ válidas, pois essas linguagens expressam fragmentos de tamanho estático. Leia na estrutura de tamanho estático primeiro e, em seguida, analise dinamicamente o código.

Relatórios de início e limites do dispositivo

Os seguintes recursos são adicionados ao DXGK_GPUPCAPS:

• O limite LiveMigration indica suporte de driver para o recurso de migração dinâmica (geralmente, as DDIs adicionadas mencionadas neste artigo, exceto para DxgkDdiSetVirtualGpuResources2).
• O limite ScatterMapReserve indica o suporte de driver para DxgkDdiSetVirtualGpuResources2, que será adicionado em uma versão futura.

O KMD deve preencher esses limites quando o sistema operacional chama o DxgkDdiQueryAdapterInfo com uma solicitação DXGKQAITYPE_GPUPCAPS. As consultas do sistema operacional são limitadas durante a inicialização do dispositivo depois que o DxgkDdiStartDevice é chamado e quando o adaptador oferece suporte ao particionamento da GPU.

Se o driver retornar o limite ScatterMapReserve, ele precisará expor o tipo de DXGKQAITYPE_SCATTER_RESERVE adicionado com as seguintes estruturas associadas para que o sistema operacional possa consultar os recursos de reserva de dispersão do driver:

• DXGK_QUERYSCATTERRESERVEIN para pInputData
• DXGK_QUERYSCATTERRESERVEOUT para pOutputData

Suporte à paginação de dispersão

Para suportar a transferência de páginas sujas não contíguas de e para o buffer de quadro, esse recurso é um dos primeiros a exercer mapeamentos GPU-VA que não são suportados por endereços físicos contíguos. As interfaces de paginação atuais não precisam ser atualizadas para esse suporte, pois sempre foi uma possibilidade geral suportada pelas tabelas de página. Mas, quaisquer detalhes de implementação latentes que fizeram suposições sobre contiguidade, provavelmente são expostos por essa mudança. Portanto, é importante entender esse mecanismo do sistema operacional, como ele executa as interfaces de paginação virtual, e garantir que a paginação seja robusta para essa mudança.

Em particular, a interface TransferVirtual agora passa intervalos VA que não são mapeados de forma contígua no buffer de quadro.

Início da migração dinâmica no lado do envio

Quando o sistema inicia o componente dinâmico da migração, ele precisa chamar a DDI DxgkDdiPrepareLiveMigration adicionada. Essa chamada notifica o driver de que essa época foi iniciada e permite que ele configure a política de agendamento da VF para a migração, que deve dividir parte do orçamento livre e migratório da VF para a paginação PF.

Em seguida, o Dxgkrnl chama a DDI DxgkDdiSaveImmutableMigrationData do KMD para coletar informações sobre o dispositivo a ser restaurado no lado de destino.

Depois que o sistema coleta e envia os dados imutáveis e de validação, o loop iterativo principal de envio sujo começa.

Salvamento/envio iterativo

Conforme descrito na seção de visão geral, a operação de salvamento iterado usa o DxgkDdiQueryDirtyBitData para realizar um instantâneo do plano de bits sujo atual para o VF no início de cada iteração e usa a operação DXGK_OPERATION_VIRTUAL_TRANSFER padrão para paginar as páginas sujas relatadas. Se essa operação ocorrer em um dispositivo que relatou em seus recursos de rastreamento sujo que não é um impacto de desempenho desprezível, o controle de iteração do sistema primeiro habilita o rastreamento sujo e, em seguida, transfere todo o buffer de quadro antes da primeira chamada para consultar o plano de bits sujo.

Para a transferência virtual, o principal comportamento atualizado é que o mapeamento não é de VA contíguo para PA contíguo. Em vez disso, pode haver páginas desconectadas de PA sob o mapeamento. Caso contrário, o comportamento será o descrito na documentação original de paginação e rastreamento de plano de bits sujo e esse recurso não será adicionado.

Fim do envio da migração dinâmica

No final da migração, o sistema precisa coletar todo o estado do dispositivo e do driver necessário para concluir a reconstrução do estado e do rastreamento que ainda não foi transferido. Esses dados não puderam ser transferidos porque não atendiam aos requisitos de imutabilidade dos dados de migração anteriores e não eram conteúdo sujo de VRAM. O Dxgkrnl chama a DDI DxgkDdiSaveMutableMigrationData adicionada para fazer isso. O uso dessa DDI é semelhante ao DxgkDdiSaveImmutableMigrationData.

Eventualmente, quando não houver mais necessidade de configuração de migração nessa VF, o DxgkDdiEndLiveMigration será chamado. Todo o agendamento e estado devem retornar a uma configuração que não seja migratória.

Início da migração dinâmica no lado de recebimento

Quando os dados imutáveis chegam no lado de recebimento, o sistema os passa diretamente para o KMD por meio de uma chamada para DxgkDdiRestoreImmutableMigrationData.

Essa DDI só deve ser chamada para VFs que estejam pausadas.

Restauração/recebimento iterativo

Novamente, a paginação de dispersão opera de maneira iterativa, mas desta vez sem as chamadas para inspecionar o plano de bits sujo associado ao buffer de quadro reservado pela VF, porque o plano de bits sujo no destino é construído pela paginação. A direção da paginação é invertida. O conteúdo nos buffers recebidos é transferido para a VRAM, com o posicionamento das páginas ordenado.

Fim da migração dinâmica

Quando a migração está acabando, o sistema do lado de recebimento chama a função DxgkDdiRestoreMutableMigrationData do driver com o pacote final de estado a ser restaurado. Este pacote deve fornecer todo o conteúdo que foi deixado para o driver transferir para a restauração de seu estado e rastreamento e para a restauração restante do estado da VF.

Essa DDI só deve ser chamada para VFs que estejam pausadas.

Após essa chamada, o sistema chama a função DxgkDdiEndLiveMigration do KMD para avisar o lado de destino sobre limpar qualquer estado em torno da migração dinâmica, incluindo a restauração do agendamento normal da VF.

Comunicações com a UMED

A interface UMED (DLL de emulação de modo de usuário) é estendida com a interface IGPUPMigration para expor a capacidade de salvar e validar conteúdo durante uma migração dinâmica.

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 as ações de preparação da migração dinâmica em que o KMD é chamado da mesma forma, a UMED pode enviar qualquer informação que possa ser útil na sua preparação para a migração ou validação de que o ambiente oferece suporte à migração no nível da UMED. É uma interface opcional para UMEDs com os contratos de interface padrão para a UMED (contexto de threading e processo, exposição restrita ao sistema operacional etc.). Seu padrão de chamada imita as DDIs do KMD, com o salvamento em duas fases. Não há sinalizadores de estado nessas chamadas, como outras interfaces UMED de salvamento/restauração, pois elas devem ser válidas e constantes durante toda a vida útil do dispositivo e seu LUID.

O estado mutável da UMED é transferido na interface de salvamento/restauração existente. No passado, essa interface era impedida de ser executada com drivers GPU-P, mas é desbloqueada quando o KMD relata suporte para LiveMigration. Essa vinculação da função de texto explicativo da UMED e do recurso KMD é intencional. A migração dinâmica é como o sistema implementa a migração rápida para a virtualização desses dispositivos. A mesma sequência de tarefas é feita e você pode conceber a migração rápida (salvamento/restauração) como o caso especial de migração dinâmica onde não há transferência ativa. Uma UMED que ofereça suporte a salvamento/restauração ainda precisa ter um KMD que ofereça suporte às DDIs de migração dinâmica. Da mesma forma, a UMED deve estar ciente da interface IGPUPMigration e avaliar se ela é necessária em seu projeto antes que o KMD possa migrar de forma dinâmica.

Virtualização de interrupções

O endereçamento físico do gerenciamento de interrupção de convidado precisa ser virtualizado para atender adequadamente o acesso à tabela MSI-X à medida que o hardware subjacente muda durante a migração. A UMED deve interceptar a tabela de interrupção MSI-X para todos os drivers que oferecem suporte à migração dinâmica. Todas as leituras ou gravações nos campos Endereço superior da mensagem e Endereço da mensagem precisam ser mapeadas para os valores reais de hardware. O Dxgkrnl mantém o mapeamento do endereço virtualizado (ou convidado) e executa a substituição onde for necessário na pilha de chamadas.

O sistema operacional gerencia a virtualização/o mapeamento dos endereços físicos convidados que a tabela lê ou grava e pode se referir ao lado do convidado com os endereços físicos do host necessários para a manutenção de interrupção real. Esse caminho comum não precisa de implementação da UMED separada ou encaminhamento de kernel e o sistema operacional não notifica a UMED quando o sistema operacional intercepta a tabela. O único requisito para a UMED é que as mitigações para o dispositivo precisam ser definidas para as páginas BAR da tabela.

No entanto, no kernel, o Dxgkrnl quer que o KMD atenda às gravações reais. O KMD faz isso implementando a função de retorno de chamada DxgkDdiWriteVirtualizedInterrupt adicionada.

Nunca deve haver a necessidade de uma leitura porque o UMD rastreia localmente as gravações (em formato virtualizado/traduzido por convidado) para que eles não exijam o caro salto do kernel. Esse rastreamento migra com o dispositivo virtual.

Sincronização da DDI e contextos IRQL

DDI	Nível de sincronização	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

Considerações importantes para o agendamento de VF

A eficiência da transferência é fortemente determinada pelo agendamento das transferências de paginação no PF. Quanto mais acesso aos motores de paginação do dispositivo o PF pode usar para saturar o barramento e obter melhor rendimento, mais eficiente é a transferência em geral e a transferência pausada especificamente. Quanto mais conteúdo puder ser capturado e enviado em um determinado momento, melhor, pelo menos até a saturação da rede.

É preferível que a alteração no agendamento afete apenas o mecanismo de paginação e nenhum outro recurso do dispositivo, mas nem todos os designs de agendamento de VF permitem isso. No mínimo, é desejável que o agendamento:

• Pegue apenas o orçamento da VF que está sendo migrada ou da agenda da VF não atribuída.
• Não degrade o desempenho de outras virtualizações na máquina.

No lado de destino, essas condições podem ser muito mais facilmente atendidas, pois a VF fica pausada durante toda a transferência e todo esse orçamento está disponível. No lado da origem, ela requer um equilíbrio entre as necessidades de migração e as necessidades da VM, com a necessidade final de atender às metas de transferência pausada.