Migração ao vivo

Quando uma ação de migração de máquina virtual é acionada, um VirtualMachineInstanceMigration objeto é criado para rastrear o estado e o progresso da operação. O controlador SUSE Virtualization correlaciona o objeto VirtualMachineInstanceMigration com o objeto VirtualMachineInstance garantindo que a identidade do objeto de instância seja refletida no objeto de migração.

No exemplo a seguir, a máquina virtual chamada demo tem um objeto de migração associado. O UID deste objeto é adicionado à propriedade .status.migrationState.migrationUID do objeto de instância durante a migração.

O nome do objeto de instância é adicionado à propriedade .spec.vmiName do objeto de migração.

O formato do nome do objeto VirtualMachineInstanceMigration varia dependendo se a migração é acionada manualmente ou automaticamente.

Quando uma migração é acionada a partir do item de menu Migrar, o nome do objeto VirtualMachineInstanceMigration é prefixado com o nome da máquina virtual e uma string aleatória (por exemplo, vm1-a3d1f).

Quando uma migração é acionada automaticamente, o nome do objeto VirtualMachineInstanceMigration é prefixado com kubevirt-evacuation- e uma string aleatória (por exemplo, kubevirt-evacuation-9c485).

Cada nó possui vários modelos de CPU que são rotulados com diferentes chaves.

Durante a migração ao vivo, o controlador verifica o valor de spec.domain.cpu.model no CR do VirtualMachineInstance (VMI), que é derivado de spec.template.spec.domain.cpu.model no CR da VirtualMachine (VM). Se o valor de spec.template.spec.domain.cpu.model não estiver definido, o controlador usa o valor padrão host-model.

Quando host-model é usado, o processo busca o valor do modelo de CPU primário e preenche spec.NodeSelectors do pod recém-criado com o rótulo cpu-model-migration.node.kubevirt.io/{cpu-model}.

Alternativamente, você pode personalizar o modelo de CPU em spec.domain.cpu.model. Por exemplo, se o modelo de CPU for XYZ, o processo preenche spec.NodeSelectors do pod recém-criado com o rótulo cpu-model.node.kubevirt.io/XYZ.

No entanto, host-model permite apenas a migração da VM para um nó com o mesmo modelo de CPU. Para obter mais informações, consulte Limitações.

O processo de migração ao vivo copia páginas de memória da máquina virtual e blocos de disco para o destino. Em certos casos, a máquina virtual pode gravar em diferentes páginas de memória ou blocos de disco a uma taxa maior do que esses podem ser copiados. Como resultado, o processo de migração é impedido de ser concluído em um tempo razoável.

A migração ao vivo é abortada se exceder o tempo limite de conclusão de 800s por GiB de dados. Por exemplo, uma máquina virtual com 8 GiB de memória atinge o tempo limite após 6400 segundos.

A migração ao vivo também é abortada quando a cópia da memória não avança em 150s.

host-model permite apenas a migração da máquina virtual para um nó com o mesmo modelo de CPU. No entanto, especificar um modelo de CPU nem sempre é necessário. Quando nenhum modelo de CPU é especificado, você deve desligar a máquina virtual, atribuir um modelo de CPU que seja suportado por todos os nós e, em seguida, reiniciar a máquina virtual.

Exemplo:

Migrar uma máquina virtual com host-model não é possível porque os valores de host-model-cpu.node.kubevirt.io não são idênticos. No entanto, ambos os nós suportam o modelo de CPU 123, então você pode migrar qualquer máquina virtual com o modelo de CPU 123 usando um dos seguintes métodos:

Ambos os métodos exigem que você reinicie as VMs. Se você tiver certeza de que todos os nós no cluster suportam um modelo de CPU específico, pode definir isso no nível do cluster antes de criar qualquer VM. Ao fazer isso, você elimina a necessidade de reiniciar as VMs (para atribuir o modelo de CPU) durante a migração ao vivo.

A migração ao vivo é altamente sensível a interrupções de rede. Qualquer interrupção na conexão de rede entre os nós de origem e destino durante a migração pode ter uma variedade de resultados.