[kvm]学习笔记4：KVM高级功能详解
[kvm]学习笔记4：KVM⾼级功能详解
1. 半虚拟化驱动
1.1 virtio 概述
KVM 是必须使⽤硬件虚拟化辅助技术（如 Intel VT-x 、AMD-V）的 Hypervisor，在CPU 运⾏效率⽅⾯有硬件⽀持，其效率是⽐较⾼的；在有 Intel EPT 特性⽀持的平台上，内存虚拟化的效率也较⾼。 QEMU/KVM 提供了全虚拟化环境，可以让客户机不经过任何修改就能运⾏在 KVM 环境中。不过 KVM 在 I/O虚拟化⽅⾯，传统的⽅式是使⽤ QEMU 纯软件的⽅式来模拟 I/O 设备（如⽹卡、磁盘、显卡等），其效率并不⾮常⾼。
  CPU 和内存的虚拟化由KVM内核模块提供，I/O设备虚拟化由QEMU负责实现。
在KVM中，可以在客户机中使⽤半虚拟化驱动的⽅式是采⽤ Virtio 这个 Linux 上的设备驱动标准框架。
完全虚拟化：GuestOS 运⾏在物理机上的 Hypervisor 之上，GuestOS 并不知道它已经被虚拟化，并不需要任何修改就能⼯作；
半虚拟化：GuestOS 不仅知道它运⾏在 Hypervisor 之上，还包括让 GuestOS 更⾼效的过度到 Hypervisor 的代码。
在完全虚拟化模式中，hypervisor 必须模拟设备硬件，它是在会话的最低级别进⾏模拟的，尽管在该抽象中模拟很⼲净，但它同时也是最低效的，最复杂的。
在半虚拟化中，GuestOS 和 hypervisor 能够共同合作，让模拟更加⾼效，缺点是操作系统知道它被虚拟化，并且需要修改才能⼯作。
左图在传统的完全虚拟化环境中,hypervisor必须捕捉这些请求，然后模拟物理硬件的⾏为。尽管这也做提供很⼤的灵活性(即运⾏未更改的操作系统)，但它的效率⽐较低.
右图，半虚拟化，来宾操作系统知道它运⾏在hypervisor之上，并包含了充当当前的驱动程序.hypervisor为特定的设备模拟实现后端驱动程序.通过在这些前端和后端驱动程序中的virtio，为开发模拟设备提供标准化接⼝，从⽽增加代码的跨平台重⽤率并提⾼效率.
QEMU模拟 I/O 设备基本原理和优缺点
健康快乐
使⽤QEMU模拟 I/O 的情况下：
  （1）当客户机中的设备驱动程序（device driver）发起 I/O 操作请求时，KVM模块中的 I/O 操作捕获代码会拦截这次 I/O 请求；
  （2）经过处理后将本次 I/O 请求的信息存放到 I/O 共享页，并通知⽤户控件中的 QEMU 程序；
  （3）QEMU 模拟程序获得 I/O 操作的具体信息之后，交由硬件模拟代码来模拟出本次的 I/O 操作；
  （4）完成之后，将结果放回到 I/O 共享页，并通知KVM 模块中的 I/O 操作捕获代码；
  （5）由 KVM 模块中的捕获代码读取 I/O 共享页中的操作结果，并把结果返回到客户机中。
在这个过程中，QEMU进程在等待I/O时被阻塞，当客户机通过 DMA 访问⼤块 I/O时，QEMU模拟程序将不会把操作结果放到I/O共享页中，⽽是通过内存映射的⽅式将结果直接写到客户机的内存中去，然后通过KVM模块告诉客户机DMA操作已经完成。
QEMU 模拟 I/O 设备的⽅式，其优点是可以通过软件模拟出各种各样的硬件设备，包括⼀些不常⽤的或者很⽼很经典的设备，⽽且它不⽤修改客户机操作系统，就可以实现模拟设备在客户机中正常⼯作。在KVM客户机中使⽤这种⽅式，对于解决⼿上没有⾜够设备的软件开发及调试有⾮常⼤的好处。⽽它的缺点是，每次 I/O 操作的路径⽐较长，有较多的 VMEntry、VMExit发⽣，需要多次上下⽂切换（context switch），也需要多次数据复制，所以它的性能较差。
半虚拟化 virtio 的基本原理和优缺点
其中前端驱动（frondend，如 virtio-blk、virtio-net等）是在客户机中存在的驱动程序模块，⽽后端处理程序（backend）是在 QEMU中实现的。
在这前后端驱动之间，还定义了两层来⽀持客户机与 QEMU 之间的通信：
  virtio：虚拟队列接⼝，在概念上将前端驱动程序附加到后端处理程序，⼀个前端驱动程序可以使⽤ 0 个或多个队列，具体数据取决于需求；
  例如：virtio-net ⽹络驱动程序使⽤两个虚拟队列（⼀个⽤于接收、另⼀个⽤于发送），⽽virtio-blk块驱动程序仅使⽤⼀个虚拟队列。虚拟队列实际上被实现为跨越客户机操作系统和hypervisor的衔接点，但它可以通过任意⽅式实现，前提是客户机操作系统和virtio后端程序都遵循⼀定的标准，以相互匹配的⽅式实现它。
  virtio-ring：实现了环形缓冲区（ring buffer），⽤于保存前端驱动和后端处理程序执⾏的信息，并且它们可以⼀次性保存前端驱动的多次I/O请求，并且交由后端去批量处理，最后实际调⽤宿主机中设备驱动实现物理上的I/O操作，这样做就可以根据约定实现批量处理⽽不是客户机中每次I/O请求都需要处理⼀次，从⽽提⾼客户机与hypervisor信息交换的效率。
virtio 半虚拟化驱动的⽅式，可以获得很好的I/O性能，其性能⼏乎可以达到和 native（⾮虚拟化环境中的原⽣系统）差不多的I/O性能。所以，在使⽤ kvm 时，如果宿主机内核和客户机都⽀持 virtio的情况下，⼀般推荐使⽤ virtio 达到更好的性能。
virtio 缺点：
  必须要安装特定的virtio驱动使其知道是运⾏在虚拟化环境中，且按照 virtio 的规定格式进⾏数据传输，不过客户机中可能有⼀些⽼的Linux系统不⽀持virtio 和主流windows系统需要安装特定的驱动才⽀持 virtio，不过，较新的⼀些Linux发⾏版(如RHEL 6.3、Fedora 17等)默认都将virtio相关驱动编译为模块，可直接作为客户机使⽤virtio，⽽且对于主流Windows系统都有对应的virtio驱动程序可供下载使⽤。
virtio是对半虚拟化hypervisor中的⼀组通⽤模拟设备的抽象.该设置还允许hypervisor导出⼀组通⽤的模拟设备，并通过⼀个通⽤的应⽤程序接⼝(API)让它们变得可⽤.有了半虚拟化hypervisor之后，来宾操作系统能够实现⼀组通⽤的接⼝，在⼀组后端驱动程序之后采⽤特定的设备模拟.后端驱动程序不需要是通⽤的，因为它们只实现前端所需的⾏为.
注意，在现实中（尽管不需要），设备模拟发⽣在使⽤ QEMU 的空间，因此后端驱动程序与 hypervisor 的⽤户空间交互，以通过 QEMU 为 I/O 提供便利。QEMU 是⼀个系统模拟器，它不仅提供来宾操作系统虚拟化平台，还提供整个系统（PCI 主机控制器、磁盘、⽹络、视频硬件、USB 控制器和其他硬件元素）的模拟。
1.2 安装 virtio 驱动
Linux 2.6 及以上版本内核都是⽀持 virtio 的。由于 virtio 的后端处理程序是在位于⽤户空间的 QEMU 中实现的，所以，在宿主机中只需要⽐较新的内核即可，不需要特别的编译与 virtio 相关的驱动。
1.2.1 Linux 中的 virtio 驱动
[root@192.168.118.14 ~]#lsmod | egrep virt
virtio_balloon        13664  0
virtio_blk            18156  3
virtio_console        28114  0
virtio_net            28024  0
海棠花的养殖方法virtio_pci            22913  0
virtio_ring            21524  5 virtio_blk,virtio_net,virtio_pci,virtio_balloon,virtio_console
virtio                15008  5 virtio_blk,virtio_net,virtio_pci,virtio_balloon,virtio_console
其中，virtio，virtio_ring、virtio_pci 等驱动程序提供了对 virtio API 的基本⽀持，是使⽤任何 virtio 前端驱动都必须使⽤的，⽽且它们的加载还有⼀定的顺序，应该按照virtio、virtio_ring、virtio_pci 的顺序加载，⽽ virtio_net、virtio_blk 这样的驱动可以根据实际需要进⾏选择性的编译和加载。
1.3 使⽤ virtio_balloon
（1）ballooning 简介
通常来说，要改变客户机占⽤的宿主机内存，要先关闭客户机，修改启动的内存配置，然后重启客户机才能实现。⽽内存的 ballooning （⽓球）技术可以在客户机运⾏时动态的调整它所占⽤的宿主机内存资源，⽽不需要关闭客户机。
ballooning 技术形象的在客户机占⽤的内存中引⼊⽓球（balloon）的概念。⽓球中的内存是可以供宿主机使⽤的，所以，当宿主机内存紧张，空余内存不多时，可以请求
客户机回收利⽤已分配给客户机的部分内存，客户机就会释放其空闲的内存，此时若客户机空闲内存不⾜，可能还会回收部分使⽤中的内存，可能会将部分内存换出到客户机的交换分区（swap）中，从⽽使内存⽓球充⽓膨胀，进⽽使宿主机回收⽓球中的内存⽤于其他进程。反之，当客户机中内存不⾜时，也可以让宿主机的内存⽓球压缩，释放出内存⽓球中的部分内存，让客户机使⽤更多的内存。
⽬前很多虚拟机，如KVM 、Xen、VMware 等，都对 ballooning 技术提供了⽀持。
（2）KVM 中 ballooning 的原理及优劣势
KVM 中 ballooning 的⼯作过程主要有如下⼏步：
  1. Hypervisor 发送请求到客户机操作系统让其归还⼀定数量的内存给 Hypervisor；
  2. 客户机操作系统中 virtio_balloon 驱动接收到 Hypervisor；
  3. virtio_balloon 驱动使客户机的内存⽓球膨胀，⽓球中的内存就不能被客户机访问。如果此时客户机中内存剩余量不多，并且不能让内存⽓球膨胀到⾜够⼤的以满⾜Hypervisor 的请求，那么 virtio_balloon 驱动也会尽可能多的提供内存使⽓球膨胀，尽量去满⾜ Hypervisor 的请求中的内存数量；
  4. 客户机操作系统归还⽓球中的内存给 Hypervisor；
  5. Hypervisor 可以将从⽓球中得来的内存分配到任何需要的地⽅；
  6. 即使从⽓球中得到的内存没有处于使⽤中，Hypervisor 也可以将内存返还给客户机中，这个过程为：Hypervisor 发请求到客户机的 virtio_balloon 驱动；这个请求使客户机操作系统压缩内存⽓球；在⽓球中的内存被释放出来，重新由客户机访问和使⽤。
ballooning 在节约内存和灵活分配内存⽅⾯有明显的优势：
经销商和代理商的区别
  1. 因为ballooning 能够被控制和监控，所以能够潜在的节约⼤量的内存；
  2. ballooning 对内存的调节很灵活，即可以精细的请求少量内存，⼜可以粗旷的请求⼤量的内存；
  3. Hypervisor 使⽤ ballooning 让客户机归还部分内存，从⽽缓解其内存压⼒。⽽且从⽓球中回收的内存也不要求⼀定要被分配给另外某个进程。
从另⼀⽅⾯来说，KVM 中 ballooning的使⽤不⽅便、不完善的地⽅也是存在的，其缺点如下：
  1. ballooning 需要客户机操作系统加载 virt_balloon 驱动，然⽽并⾮每个客户机系统都有该驱动；
  2. 如果有⼤量内存需要从客户机系统中回收，那么 ballooning 可能会降低客户机操作系统运⾏的性
能。⼀⽅⾯，内存的减少可能会让客户机中作为磁盘数据缓存的内存被放到⽓球中，从⽽使客户机中的磁盘I/O访问增加；另⼀⽅⾯，如果处理机制不够好，也可能让客户机中正在运⾏的进程由于内存不⾜⽽执⾏失败；
  3. ⽬前没有⽐较⽅便的、⾃动化的机制来管理 ballooning，⼀般采⽤在 QEMU monitor 中执⾏ balloon 命令来实现 ballooning。没有对客户机的有效监控，没有⾃动化的ballooning 机制，这可能会使在⽣产环境中实现⼤规模⾃动化部署不是很⽅便。
  4. 内存的动态增加或减少，可能会使内存被过度碎⽚化，从⽽降低内存使⽤时的性能。
（3）KVM 中 ballooning 使⽤⽰例
1. 创建虚拟机
[root@192.168.118.14 ~]#qemu-kvm -smp 1 -m 1024 -balloon virtio /images/cirros-0.3.5-i386-disk.img --nographic
2. 查看 PCI 设备是否加载
# lspci -k
姓刘的女孩名字
00:00.0 Class 0600: 8086:1237
00:01.0 Class 0601: 8086:7000
00:01.1 Class 0101: 8086:7010 ata_piix
00:01.3 Class 0680: 8086:7113
00:02.0 Class 0300: 1013:00b8
00:03.0 Class 0200: 8086:100e e1000
00:04.0 Class 00ff: 1af4:1002 virtio-pci
可以发现，00:04.0 Class 00ff: 1af4:1002 virtio-pci 就是 virtio-pci 设备
3. 通过 balloon 调整内存⼤⼩
原内存
# free -m
total        used        free      shared      buffers
Mem:          1001          12          988            0            0
-/+ buffers:                12          989
Swap:            0            0            0
使⽤ qemu-monitor 减少内存⼤⼩
(qemu) info balloon
balloon: actual=1024
(qemu) balloon 512
(qemu) info balloon
balloon: actual=512
4. 查看调整后的内存⼤⼩
# free -m
total        used        free      shared      buffers
Mem:          489          12          477            0            0
-/+ buffers:                12          234
Swap:            0            0            0
总的来说，对于 ballooning 技术，⽬前还没有完全成熟的管理控制⼯具，⼤规模部署⾮常不⽅便，⽽且性能没有很⼤的提升，建议慎⽤。
1.4 使⽤ virtio_net
在选择KVM中的⽹络设备时，⼀般来说优先选择半虚拟化的⽹络设备⽽不是模拟纯软件模拟的设备使⽤ virtio_net 半虚拟化驱动，可以提⾼⽹络吞吐量和降低⽹络延迟，从⽽让客户机中⽹络达到⼏乎和⾮虚拟化系统中使⽤原⽣⽹卡的⽹络差不多的性能。
（1）检查 QEMU 是否⽀持 virtio 类型的⽹卡
# qemu-kvm -smp 2 -m 512m -net nic,model=?
qemu: Supported NIC models: ne2k_pci,i82551,i82557b,i82559er,rtl8139,e1000,pcnet,virtio
（2）启动客户机时，指定分配 virtio ⽹卡设备
# qemu-kvm -smp 2 -m 512m \
-drive file=/root/cirros-0.3.5-i386-disk.img,if=virtio -net nic,model=virtio -net tap,name=tap0,script=no -daemonize
工商管理专业方向使⽤ virtio_net 依然是较低的性能，可以检查宿主机系统中对 GSO 和 TSO 特性的设置。关闭 GSO 和 TSO 可以使⽤半虚拟化⽹络驱动的性能更加优化。
ethtool -K eno1 gso off
ethtool -K eno1 tso off
⽤ vhost_net 后端驱动
前⾯提到 virtio 在宿主机中的后端处理程序（backend）⼀般是由⽤户空间的 QEMU 提供的，然⽽，
如果对于⽹络 IO 请求的后端处理能够在内核空间来完成，则效率更⾼，会提⾼⽹络吞吐量和减少⽹络延迟。在⽐较新的内核中有⼀个叫做 “vhost_net”的驱动模块，它作为⼀个内核级别的后端处理程序，将 virtio-net的后端处理任务放到内核空间执⾏，从⽽提⾼效率。
qemu-kvm -smp 2 -m 512m \
-drive file=/root/cirros-0.3.5-i386-disk.img,if=virtio \
-net nic,model=virtio,macaddr=52:54:00:ac:0f:11 \
-net tap,name=tap0,vnet_hdr=on,vhost=on,script=no \
-daemonize
⼀般来说，使⽤ vhost-net 作为后端处理驱动可以提⾼⽹络的性能。不过，对于⼀些使⽤ vhost-net 作为后端的⽹络负载类型，可能使其性能不升反降。特别是从宿主机到其客户机之间的 UDP 流量，如果客户机处理接受数据的速度⽐宿主机发送的速度要慢，这时就容易出现性能下降。在这种情况下，使⽤ vhost-net 将会使 UDP socket 的接受缓冲区更快的溢出，从⽽导致更多的数据包丢失。因此在这种情况下不使⽤vhost-net，让传输速度稍慢⼀点，反⽽会提⾼整体的性能。
1.5 使⽤ virtio_blk
virtio_blk 驱动使⽤ virtio API 为客户机提供了⼀个⾼效访问块设备 I/O ⽅法。在 QEMU/KVM 中对块设备使⽤ virtio，需要在两⽅⾯进⾏配置：客户机中的前端驱动模块virtio_blk 编译为内核模块，可以作为客户机直接使⽤ virtio_blk。
启动⼀个使⽤ virtio_blk 作为磁盘驱动的客户机，其 qemu-kvm 命令⾏如下：
[root@192.168.118.14 ~]#qemu-kvm -smp 2 -m 512m -drive file=/images/cirros-0.3.5-i386-disk.img,if=virtio
未使⽤ virtio 模块的虚拟机
# lsblk
NAME  MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda      8:0    0  39.2M  0 disk
`-sda1  8:1    0  31.4M  0 part /
使⽤ virtio 模块的虚拟机
# lsblk
NAME  MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
vda    253:0    0  39.2M  0 disk
`-vda1 253:1    0  31.4M  0 part /
2. 动态迁移
2.1 动态迁移概念
迁移（migration）包括系统整体的迁移和某个⼯作负载的迁移。系统整体迁移，是将系统上的所有软件完全复制到另⼀台物理硬件机器上。⽽⼯作负载的迁移，是将系统上的某个⼯作负载转移到另⼀台物理机上继续运⾏。服务器系统迁移的作⽤在于简化了系统维护管理，提⾼了系统负载均衡，增强了系统容错性并优化了系统电源管理。
在虚拟化环境中的迁移，⼜分为静态迁移（static migration）和动态迁移（live migration）静态迁移和动态迁移最⼤的区别：静态迁移有明显⼀段时间客户机中的服务不可⽤，⽽动态迁移则没有明显的服务暂停时间。
虚拟化中的静态迁移，也可以分为两种，⼀种是关闭客户机后，将其硬盘镜像复制到另⼀台宿主机上然后恢复启动起来，这种迁移不能保留客户机中运⾏的⼯作负载；另⼀种是两台宿主机共享存储系统，只需要暂停客户机后，复制其内存镜像到另⼀台宿主机中恢复启动，这种迁移可以保持客户机迁移前的内存状态和系统运⾏的⼯作负载。
动态迁移，是指在保证客户机上应⽤服务正常运⾏的同时，让客户机在不同的宿主机之间进⾏迁移，其逻辑步骤与前⾯静态迁移⼏乎⼀致，有硬盘存储和内存都复制的动态迁移，也有仅复制内存镜像的动态迁移。不同的是，为了保证迁移过程中客户机服务的可⽤性，迁移过程仅有⾮常短暂的停机时间。动态迁移允许系统管理员将客户机在不同物理机上迁移，同时不会断开访问客户机中服务的客户端或应⽤程序的连接。⼀个成功的动态迁移，需要保证客户机的内存、硬盘存储、⽹络连接在迁移到⽬的的主机后依然保持不变，⽽且迁移过程的服务暂停时间较短。
2.2 动态迁移的效率和应⽤场景
虚拟机迁移主要增强了系统的可维护性，其主要⽬标是在客户没有感觉的情况下，将客户机迁移到了另⼀台物理机上，并保证其各个服务都正常使⽤。可以从如下⼏个⽅⾯来衡量虚拟机的迁移的效率：
本地ip地址查询
（1）整体迁移时间：从源主机中迁移操作开始到客户机被迁移到⽬的主机并恢复其服务所花费的时间；
（2）服务器停机时间：在迁移过程中，源主机和⽬的主机上客户机的服务都处于不可⽤状态的时间，此时源主机上客户机已暂停服务，⽬的主机上客户机还未恢复服务；（3）对服务的性能影响：不仅包括迁移后的客户机中应⽤程序的性能与迁移前相⽐是否有所下降，还包括迁移后对⽬的主机上的其他服务的性能影响。
动态迁移的好处⾮常明显，动态迁移的⼏个场景：
（1）负载均衡：当⼀台物理服务器的负载较⾼时，可以将其上运⾏的客户机动态迁移到负载较低的宿主机服务器中，以保证客户机的服务质量（QoS）。
（2）解除硬件依赖：升级主机，添加某些硬件设备时，可以将宿主机上运⾏的客户机⾮常安全⾼效的动态迁移到其他宿主机上。
（3）节约能源：通过动态迁移将宿主机上的客户机集中迁移到其中⼏台服务器上。
（4）实现客户机地理位置上的远程迁移：⽐如跨地域性的迁移。
2.3 KVM 动态迁移原理与实践
在KVM 中，即⽀持离线的静态迁移，⼜⽀持在线的动态迁移。对于静态迁移，可以在源宿主机上某客
户机的 QEMU monitor中，⽤ "savevm my_tag" 命令来保存⼀个完整的客户机镜像快照（标记为 my_tag），然后在源宿主机中关闭或暂停该客户机，然后将该客户机的镜像⽂件复制到另外⼀台宿主机中，⽤于源主机中启动客户机时以相同的命令启动复制过来的镜像，在其 QEMU monitor 中⽤ "loadvm my_tag" 命令来恢复刚才保存的快照即可完全加载保存快照时的客户机状态。这⾥的 "savevm" 命令保存的完整客户机状态包括：CPU 状态、内存、设备状态、可写磁盘中的内容。注意：这种保存快照的⽅法需要 qcow2、qed 等格式的磁盘镜像⽂件，因为只有它们才⽀持快照这个特性。
如果源宿主机和⽬的宿主机共享存储系统，则只需要通过⽹络发送客户机的vCPU 执⾏状态、内存中的内容、虚拟设备的状态到⽬的主机上。否则，还需要将客户机的磁盘存储发送到⽬的主机上去。
在不考虑磁盘存储复制的情况下（基于共享存储系统），KVM 动态迁移的具体迁移过程为：在客户机动态迁移开始后，客户机依然在原宿主机上运⾏，与此同时，客户机的内存页被传输到⽬的主机之上。QEMU/KVM 会监控并记录下迁移过程中所有已被传输的内存页的任何修改，并在所有的内存页都被传输完成后即开始传输在前⾯过程中内存页的更改内容。QEMU/KVM 也会估计迁移过程中的传输速度，当剩余的内存数据量能够在⼀个可设定的时间周期内传输完成之时，QEMU/KVM 将会关闭源宿主机上的客户机，再将剩余的数据量传输到⽬的主机上去，最后传输过来的内存内容在⽬的宿主机上恢复客户机的运⾏状态。⾄此，KVM的⼀个动态迁移操作就完成了。
当客户机中内存使⽤量⾮常⼤且修改频繁，内存中数据被不断修改的速度⼤于 KVM 能够传输的内存速度之时，动态迁移过程是不会完成的，这时要进⾏迁移只能进⾏静态迁移。
对于 KVM 动态迁移，有如下⼏点建议和注意事项：
  （1）源宿主机和⽬的宿主机之间尽量⽤⽹络共享的存储系统来保存客户机镜像，尽管KVM动态迁移也⽀持连通磁盘镜像⼀起复制。共享存储（如NFS）在源宿主机和⽬的宿主机上的挂载位置必须⼀致；
  （2）为了提⾼动态迁移的成功率，尽量在同类型 CPU 的主机上⾯进⾏动态迁移；
  （3）64 位的客户机只能在 64位宿主机之间迁移，⽽ 32 位客户机可以在 32 位宿主机和 64 位宿主机之间迁移；
  （4）动态迁移的源宿主机和⽬的宿主机对 NX 位的设置是相同的，要么关闭状态，要么打开状态；
  （5）在进⾏动态迁移时，被迁移客户机的名称是唯⼀的，在⽬的宿主机上不能与源宿主机中被迁移客户机同名的客户机存在；
  （6）⽬的宿主机和源宿主机的软件配置尽可能是相同，例如，为了保证动态迁移后客户机中⽹络依然正常⼯作，需要在⽬的宿主机上配置和源宿主机相同名称⽹桥，并让客户机以桥接的⽅式使⽤⽹络。
⽰例：使⽤ qemu-kvm 动态迁移
NFS 主机配置：
[root@192.168.118.16 ~]#mkdir /images
[root@192.168.118.16 ~]#mv cirros-0.3.5-i386-disk.img  /images/
[root@192.168.118.16 ~]#yum install nfs-utils -y
[root@192.168.118.16 ~]#cat /etc/exports

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。