客户机在主机之间的迁移是一个复杂的问题，有许多可能的解决方案，每个解决方案都有其优缺点。为了最大限度地提高hypervisor集成和管理员部署的灵活性，libvirt实现了几个迁移选项
Network data transports
迁移过程中使用的数据传输有两种方式，一种是hypervisor自己的原生(native)传输，另一种是通过libvirtd连接进行隧道(tunnelled)传输。
Hypervisor native transport
native数据传输支不支持加密，这取决于所涉及的管理程序，但是通常通过最小化所涉及的数据拷贝的数量来降低计算成本。native 数据传输还需要管理员在部署主机时执行一些额外的、特定于管理程序的网络配置步骤。对于某些管理程序，可能需要在防火墙上打开大量端口，以允许多个并发迁移操作。
libvirt tunnelled transport
隧道数据传输能够进行强加密，因为它们能够利用libvirt RPC协议中内置的功能。然而，隧道传输的缺点是，当数据在libvirtd和hypervisor之间移动时，源主机和目标主机上都会涉及额外的数据copy。对于RAM非常大的云主机来说，这可能是一个严重的问题，因为RAM会很快污染内存页面。在部署端，隧道传输不需要任何额外的网络配置。除了libvirtd远程访问所需要的端口以外，只需要在防火墙上打开一个端口来支持多个并发迁移操作。
Communication control paths/flows
虚拟机的迁移需要 两台主机以及迁移程序的密切协作，迁移程序可能在源、目标或其他主机上。
Managed direct migration
通过受管理的direct migration，libvirt client 进程控制迁移的各个阶段。client必须能够连接源主机和目标主机上的libvirtd daemon进程并通过身份验证。两个libvirtd daemon 进程之间不需要进行通信。如果client 崩溃了，或者在迁移过程中失去与libvirtd的连接，那么将尝试中止迁移并重新启动源主机上的云主机cpu。可能会出现这样的情况，即不能安全地完成此操作，在这种情况下，云主机在两边都被置于暂停状态。
Managed peer to peer migration
通过对等迁移，libvirt client进程只与源主机上的libvirtd daemon进程对话。源libvirtd daemon进程通过直接连接目标主机libvirtd来控制整个迁移过程。如果client应用程序崩溃，或者失去与libvirtd的连接，迁移过程不会打断，还会继续完成。注意，源libvirtd使用自己的credentials(通常是root)连接到目标，而不是client用于连接到源的凭据。如果不是这样，通常会遇到这样一种情况:client可以直接连接到目的主机，但是源主机不能建立连接来设置对等迁移。
Unmanaged direct migration
对于非托管的直接迁移，libvirt client和libvirtd守护进程都不能控制迁移过程。相反，控制权被委托给hypervisor的管理服务(如果有的话)。libvirt client仅仅通过hypervisor的管理层启动迁移。如果libvirt client或libvirtd崩溃，迁移过程将继续进行，直到完成。
Data security
由于迁移数据流包含云主机操作系统RAM的完整副本，因此对迁移数据流的窥探可能会导致敏感云主机信息的泄露。如果云主机具有多个网络接口，或者网络交换机支持带标记的vlan，那么应该将云主机网络流量与迁移或管理流量分开。
在某些场景中，即使是单独的迁移数据网络也可能无法提供足够的安全性。在这种情况下，可以对迁移数据流应用加密。如果hypervisor本身不提供加密，那么就应该使用 libvirt 的隧道迁移机制
Offline migration
脱机迁移传递 将一个domain的定义置于inactive 。成功完成后，domain在源主机上保持当前状态，并在目标主机上被定义但处于inactve。就像 先在源主机上virsh dumpxml然后再目标主机上的virsh define 不过更好，因为脱机迁移将运行预迁移钩子来更新目标主机上的domain XML。目前，脱机迁移期间不支持复制非共享存储或其他基于文件的存储(例如UEFI变量存储)。
Migration URIs
启动一个云主机迁移需要clietnt 应用指定最多三个URI,这取决于所使用的控制流和api的选择。第一个URI是到源主机的libvirt连接的URI。第二个URI是到目标主机的libvirt连接的URI。第三个URI是一个特定于hypervisor的URI，用于控制如何迁移客户机。对于任何受管理的迁移流，前俩个uri是必须的第三个是可选的。而对于非托管迁移流第一第三个是必须的，第二个未使用。
通常，管理应用程序只需要关心第一个URI和第二个URI，它们都是标准的libvirt连接URI格式。然后，Libvirt将通过查找目标主机的配置主机名，自动确定hypervisor特定的URI。在一些场景中，管理应用程序可能希望直接控制第三个URI。
- 配置的主机名不正确，或者DNS损坏。如果主机的主机名不能与其公共IP地址匹配，那么libvirt将生成错误的URI。在这种情况下，管理应用程序应该使用IP地址或正确的主机名显式地指定hypervisor特定的URI。
- 主机有多个网络接口。如果主机有多个网络接口，出于安全性或性能的原因，迁移数据流可以通过特定的接口发送。在这种情况下，管理应用程序应该使用与要使用的网络相关联的IP地址指定hypervisor特定的URI。
- 防火墙限制哪些端口可用。当libvirt生成迁移URI时，它将使用hypervisor特定的规则选择端口号。一些管理程序只需要在防火墙中打开一个端口，而另一些管理程序则需要一整个端口号范围。在后一种情况下，管理应用程序可能希望选择默认范围之外的特定端口号，以便符合本地防火墙策略。
Configuration file handling
libvirt已知两种类型的虚拟机。transient虚拟机只在运行时存在，并且没有在磁盘上存储配置文件。persistent虚拟机在磁盘上维护配置文件，即使它没有运行。
默认情况下，迁移操作不会尝试修改可能存储在源或目标主机上的任何配置文件。管理员或管理应用程序负责管理配置文件的分发(如果需要的话)。需要注意的是，主机之间决不能共享/etc/libvirt目录。以下是一些可能适用的典型场景:
-Centralized configuration files outside libvirt, in shared storage:支持集群的管理应用程序可以在集群文件系统中维护所有主客户配置文件。在尝试启动客户机时，将从集群FS读取配置并用于部署persistent客户机。对于迁移，需要将配置复制到目标主机并在原始主机上删除。
- Centralized configuration files outside libvirt, in a database. 数据中心管理应用程序可能根本不存储配置文件。它在虚拟机boot时生成libvirt XML，因为只是生成transient虚拟机，所以不需要在迁移时考虑配置文件。
- Distributed configuration inside libvirt. 每个客户的配置文件被复制到每个客户能够运行的主机上。在迁移时，现有配置只需要在出现更改时进行更新。
- Ad-hoc configuration management inside libvirt. 每个客户机都绑定到特定的主机，很少迁移。当需要迁移时，配置将从一个主机移动到另一个主机。
正如上面说的默认情况下libvirt不会在迁移时更改配置。
virsh命令有两个参数来影响这种行为。 --undefine-source 参数，在迁移成功之后在源主机上删除配置文件。 --persist参数，在迁移成功后在目标主机上创建配置文件。下表总结了所有可能的状态与标志组合下的配置文件处理。