私有云架构设计：设备清单与参数示例

QEMU可模拟的设备繁多，由于篇幅所限难以全部列出。在命令行中可使用“qemukvm-device？”查看所有模拟设备，使用形似“qem u-kvm-device virtio-gpu-pci，？”查看具体设备的参数，如下示例。

我们以KVM平台的虚拟机设置为主列举虚拟机的通用设备，如图4-4所示的虚拟机设备简图以及它们与服务器之间的关系。

图4-4　虚拟机设备简图

1.基本设备

包括CPU、内存、显示等在内的设备一般是必选项，并且其参数直接影响虚拟机的性能。

□CPU

QEMU中可调节CPU的选项有CPU类型（-cpu）、SMP配置（-smp）、NUMA（-numa）。

CPU类型差异主要体现在CPU指令集的组合上，目前QEMU支持的组合qemu32、qemu64、SandyBridge、Haswell等，在虚拟机中使用“cat/proc/cpuinfo｜grep flags｜uniq”查看当前CPU所有指令集，在不同的机器类型中识别到的CPU类型也会有差异。除了默认的几十种组合外，它也支持自定义组合，比如“qemu-kvm-cpu qemu-64，＋ssse3”将添加“ssse3”到虚拟机的qemu64 CPU指令集中。

相关链接

Intel处理器微架构

Intel处理器微架构自486开始，每一代都有固定的编号，从早期的Pentium、NetBurst、Core，到现在Itanium、Nehalem、SandyBridge、Haswell等。虽然它们的架构元件与性能差异较大，但对虚拟化而言，这种差异可以近似看做指令集的不同。即在很多时候，最新架构的CPU可以具备早期架构的CPU指令集，但反之则不能，我们也应在虚拟机迁移时注意这点。

（资料来源：https：//en.wikipedia.org/wiki/List＿of＿CPU＿architectures.）

需要注意的是，虚拟机的CPU指令集不能多于服务器CPU支持的指令集，如果某台服务器缺少虚拟机所需要的某些指令集，那么虚拟机将不能迁移至其运行。如果集群的服务器CPU类型相同，我们可以直接将虚拟机CPU类型设置为host，这样既能保证虚拟机的迁移，又最大限度扩展了虚拟CPU的特性以支持某些特殊应用场景。

（资料来源：HTTP：//www.rdoxen ham.com/？p＝275.）

嵌套虚拟化

当前版本的KVM我们需要在相关模块加载时添加“nested”选项以使虚拟机内支持虚拟化指令集。Intel和AMD的CPU在/etc/modprobe.d/kvm-intel.conf中分别添加“options kvm-intel nested＝1”或者“options kvm-amd nested＝1”后，重新加载对应的kvm模块。

在实际项目中，某些客户会在云桌面中使用其他虚拟化软件，比如VMWare、VirtualBox或者Virt Manager，这时候嵌套虚拟化就很必要了。

一般实现嵌套虚拟化除了系统内核到Linux 3.X版本且qemu-kvm大于1.5版本外，如果读者使用libvirt管理虚拟机，还需要修改虚拟机XML文件中CPU的定义，下面三种定义都可以

（1）可以使用预制的CPU型号，比如core2duo，这种方式为虚拟机定义需要模拟的CPU类型＂core2duo＂，并且为虚拟机添加＂vmx＂特性。

（2）使用host模式。

（3）CPU透传特性。

在虚拟机中看到的vCPU将会与物理机的CPU同样配置，这种方式缺点在于如果要对虚拟机迁移，迁移的目的服务器硬件配置必须与当前物理机一致。

SMP选项即为模拟CPU对称多处理器架构，目前支持的最大vCPU数目为255个。它的参数有vCPU总数（cpus）、插槽数（sockets）、插槽核数（cores）、每核线程数（threads）、vCPU允许最大数（maxcpus）。其中maxcpus用于vCPU热插拔（QEMU 1.5版本及以上），可通过QEMU控制台进行操作。SMP选项对虚拟机性能的影响就像一把双刃剑，过高或过低都会造成同一服务器上其他虚拟机性能的下降。另外，由于QEMU只是在虚拟机层面模拟了SMP架构，但在物理服务器操作系统看来这个虚拟机的多个LWP仍然是普通的进程，并没有真正的隔离在多CPU间，所以在创建多路CPU的虚拟机时我们往往会添加NUMA选项，以保证其性能。

QEMU中的NUMA实现即是创建虚拟NUMA节点从而设置虚拟机LWP与物理逻辑CPU的“亲密度”，它需要libvirt提供物理CPU绑定支持以避免虚拟NUMA节点内存性能损失，具体操作会在实践部分指出。它的参数有NUMA节点序号（nodeid）、NUMA节点内存（mem）、NUMA节点内存设备（memdev）、vCPU逻辑序号（cpu）。

通过命令形似“qemu-kvm-smp 4-numa node，nodeid＝0，cpus＝0，1-numa node，nodeid＝1，cpus＝2，3-monitor stdio”启动的虚拟机，在QEMU控制台输入“info numa”即可看到虚拟机的NUMA拓扑；我们也可以在服务器中使用“lstopo”命令或者“virsh nodeinfo”查看服务器的NUMA拓扑。如果要指定NUMA节点使用其他形式的内存，需要添加object选项，形如“qemu-kvm-object memory-backend-file，id＝mem，size＝512M，mem-path＝/hugetlbfs，share＝on-numa node，memdev＝mem”。

□内存

内存的直接调节选项有基本配置（-m）、内存设备路径（-mem-path）、内存预分配（-mem-prealloc）。

内存基本配置中包括内存大小（size）、预留槽位（slot）、允许最大内存（maxmem）。内存大小选项接受的参数可以是“K、M、G、T”的单位字节。预留槽位和允许最大内存这两个选项需要一起使用以提供内存热插拔功能，可通过QEMU控制台操作，形如“object＿add memory-backend-ram，id＝mem1，size＝1G；device＿add pc-dimm，id＝dimm1，memdev＝mem1”。内存热插拔与内存气球技术颇为相似，不同的地方是前者以内存槽位为最小操作单位，而后者以最小内存页为单位。

内存设备路径和预分配一般配合巨页进行使用，内存气球（balloon）、KSM等需要配合虚拟机代理或者服务器相关设置，我们将在实践部分详细说明。

□显示

QEMU中的显示可调选项丰富，主要由两个部分组成，即VGA设备与显示协议。

在QEMU 2.4版本，模拟VGA设备有cirrus、std、vmware、tcx、cg3、qxl、virtio、none。每种VGA设备都有不同的用途：cirrus与std的系统兼容性最佳，前者在Windows 95中即开始支持，后者从XP开始支持，并且分辨率可以达到1 280×1 024以上，两种设备在vnc协议下使用效果较佳；vmware的设备类型是SVGA-II，在KVM的虚拟化环境中得以保留往往是由于个别系统的兼容性原因，平时使用较少；tcx、cg3两种VGA设备属于SPARC平台默认支持的设备，在x86中极少使用；qxl是一种半虚拟化VGA设备，它需要与spice协议一起使用方可达到最佳显示效果；virtio类型的设备属于典型的vGPU设备，它来自virgl项目，本书成文时它仅支持sdl与gtk显示协议，spice协议的仍在开发中；none即表示不模拟VGA设备，将输出重定向至串口或者并口，一般在嵌入式开发中使用较多。

远程显示协议是各私有云桌面厂商的核心竞争力表现之一。在QEMU中，除了gtk、sdl、curses三种本地显示协议，我们关注最多的就是开源的spice以及vnc协议了。

本地显示协议sdl较gtk而言，它的底层API使用了OpenGL与OpenAL等实现（需客户端VGA驱动支持），在渲染声音与图像时拥有更高效率。在QEMU 2.5版本，“-display sdl”选项等同于“-display gtk，gl＝on”。另外，在文字中的操作系统时将显示输出到curses/ncurses接口中也是非常不错的选择。

远程显示协议vnc属于较经典的协议之一，拥有极佳的移植性，它的服务端及其变种适用于包括Windows、Linux、Unix、OSX等等有GUI界面的操作系统，甚至在Android、iOS中也可运行。QEMU的vnc实现是sdl协议的VGA内容经过转发后输出vnc会话，它的选项与常规vnc服务器类似，包括密码访问、共享访问、证书加密、sasl认证等。另外，它也提供websocket选项用以支持浏览器HTML5直接访问虚拟机桌面，这点特性在提供虚拟服务器为主的云平台中使用非常广泛（由于QEMU版本不同，云平台中的websocket实现可能不同）。

最后就是仍然占据开源桌面云市场的spice协议，它是国内KVM私有云和私有云厂商的最主要的参考与使用协议之一。spice是一个开源的远程桌面显示解决方案，使客户端能查看远程虚拟机的操作界面，它给用户提供了一种如同操作本地机器一样的体验，同时尽可能把GPU密集型的解码任务在客户端本地处理。spice的基本组成包括spice协议、spice服务器、spice客户端，以及其相关组件QXL设备和QXL驱动，目前其移动端支持Android、iOS。与vnc相比，spice协议的实现需要虚拟机内部QXL驱动辅助，因此性能有一定提升，其过程如图4-5所示。除了一些vnc所支持的诸多选项外，spice协议同时还提供了视频流重定向、在线迁移、主机目录映射等直接提升用户体验的选项。比如视频流重定向即是通过检测虚拟机视频播放区域，将其转化成M-JPEG视频流（M-JPEG是multiple jpegs的缩写，并不是视频格式MPEG）后发送至客户端，从而在保证视频质量同时减少带宽消耗（国内厂商在其基础上添加了H264解码）。协议中的通道是spice协议进行周边扩展的基本，它与各种代理设备相结合可以实现客户端设备重定向、粘贴板共享、分辨率自适应等等提升桌面体验的功能与特性。(www.xing528.com)

图4-5　spice协议简图

2.可移除设备

可移除设备包括块设备驱动器与存储介质、USB控制器、网卡、声卡等，这类设备也是由虚拟化平台提供，对虚拟机的性能与功能都有较大影响。

□设备驱动器与存储介质

QEMU中的块设备由存储介质及对应的驱动器构成，其中存储介质种类不限于虚拟硬盘，也有iSCSI硬盘、主机硬盘、主机文件系统等。

最直接的块设备选项有软盘（-fda/fdb）、光盘（-cdrom）和硬盘（-hda/hdb/hdc/hdd），选项的参数是一个文件路径，可以是iso、qcow2、raw、vfd等类型的普通文件或者/dev/sdb这样的主机设备文件。

通常我们使用最多的选项是驱动器（-drive），它拥有更丰富的参数，可以适应各种应用场景。它的参数有文件路径（file）、接口类型（if）、总线位置（bus、unit）、系统顺序（index）、介质类型（media）、硬盘参数（cyls、heads、secs）、快照开关（snapshot）、缓存策略（cache）、异步实现（aio）、擦除请求（discard）、硬盘格式（format）、序列号（serial）、PCI地址（addr）、勘误动作（werror、rerror）、只读模式（readonly）、读时复制（copy-on-read）、QoS限制（throttling）。这些参数与虚拟机、驱动器、硬盘、服务器之间的关系如图4-6所示，具体应用场景的设置我们将在以后章节中讲到。

图4-6　驱动器参数在QEMU各层的作用域

QEMU也提供了nand flash（mtdblock）、nor flash（plash）、SD卡（sd）等针对嵌入式设备的块存储选项，接受参数同样为文件路径。

针对virtio，QEMU在0.15版本时支持了使用Plan 9项目中9P协议的VirtFS，它通过向虚拟机系统提供系统层的服务接口，能够获得比直接访问设备驱动更高的性能，详细内容我们将在后面章节讲述。

□USB控制器

不管对于服务器虚拟化还是桌面虚拟化，USB控制器的加入都是非常有必要的。在第1章我们已经知道，服务器需要U-Key、桌面需要各种外设，那么我们就需要在虚拟机中模拟USB控制器从而接入真实的外设。

两种机器模型中都自带了USB控制器（ehci、uhci），而QEMU提供了USB设备选项（usbdevice）以加入各种USB设备，包括鼠标与触控输入（mouse、tablet）、主机USB设备（host）、USB转串口（serial）、大容量存储（disk）等。其中，主机USB设备（host）必须指定主机USB设备的verdor id和product id，并且不管是U盘还是摄像头，必须处于未被占用状态且QEMU进程有对此设备访问的权限（注意SELinux设置，最好处于perm issive或disabled状态）。大容量设备选项可直接将一个raw格式的文件转化为USB存储传递至虚拟机中，这对于模拟测试有很大帮助。

□网卡

虚拟机的网络包括网卡设备和网络连接两部分，网络连接部分我们将在以后的章节中进行详细说明。QEMU的网络设备有模拟设备和主机透传设备两种，主机透传设备可以是主机的整个网卡或者是SR-IOV虚拟网卡。对于x86平台的模拟网卡有ne2k＿pci、i82551、i82557b、i82559er、rtl8139、pcnet、e1000、virtio，其中除了virtio是半虚拟化设备，其他都是纯虚拟化设备。

对于网卡我们可设置的选项有网卡模型（model）、VLAN（vlan）MAC地址（macaddr）、PCI地址（addr）、设备向量（vector，仅对virtio网卡有效）。这些参数中对网络效率有较大影响的只有网卡类型，它对操作系统的驱动实现较为依赖。目前看来，virtio、主机透传网卡效率基本持平，略低于SR-IOV网卡，但都高于其他纯虚拟化设备。

与网卡绑定的参数即是网络连接类型，包括user、socket、bridge、tap等，它们的区别主要在于网络的来源以及网络路径的处理，可参考QEMU手册查看详细参数。其中，user网络可直接通过QEMU参数进行重定向（hostfwd、guestfwd）、TFTP等应用层处理，在私有云中具有比较丰富的应用场景。

□声卡

在多数云平台的实现中，声卡往往是最容易被忽略的部分。QEMU中可使用的声卡设备同样有模拟设备和主机透传设备两种。透传声卡设备的场景往往对声音质量、客户端调音、听音设备有较高要求，所以极少很少有私有云厂商应用于此。

模拟声卡选项（soundhw）的参数有声卡类型（sb16、es1370、ac97、adlib、gus、cs4231a、hda、pcspk、all）、设备id（id）、PCI地址（bus、addr），声卡类型中参数“all”即添加所有的模拟声卡设备至虚拟机中。QEMU也可直接使用设备选项（device）添加声卡，如此添加的声卡设备具有更丰富的参数可以调节，比如在Intel HD Audio中指定额外的音频编码设备，形似“-device intel-hda，id＝sound0，bus＝pci.0，addr＝0x4-device hda-duplex，id＝sound0-codec0，bus＝sound0.0，cad＝0”。

模拟声卡间的差别对于普通用来说难以体会到，我们多数情况下只需要选择操作系统支持的声卡设备就足够了。

当使用远程连接协议时，声音被重定向至对应通道通过网络传送至客户端，但由于声音信息在传统的软件定义中是属于可丢弃的，即声音信息丢包后不会被重传，这也就是原生远程连接协议很难用于对声音质量要求较高场景的主要原因之一。

3.代理设备

一个完整的云桌面，除了体验良好的音视频连接外，还需要有统计、平台交互、客户端交互等，我们就需要添加额外的代理设备来保证这些功能特性。图4-7是oVirt中使用spice桌面协议的虚拟机的代理设备。

图4-7　虚拟机代理设备种类

平台代理的实现按照代理连接的服务端可分为客户端代理和服务器代理两种，它们的目的都是作为“中介”使得外部（服务器、客户端）与虚拟机内部实现交互。目前我们在KVM平台中经常用到的代理有如下几种：

□qemu-monitor-agent

qemu-monitor-agent是一种服务器代理，它的作用是使服务器上的平台虚拟化服务可以与QEMU控制台进行交互，比如关机、重启、添加外设、读写快照、截图等不依赖虚拟机操作系统的操作。

其添加方法也比较简单，只需要在虚拟机启动时添加一个QEMU控制台的相关字符设备，并创建socket以使其与虚拟化服务进程通信即可，形似“-chardev socket，id＝charmonitor，path＝/tmp/win7.monitor.sock，server，nowait-mon chardev＝charmonitor，id＝monitor，mode＝control”。当使用socket连接时我们需要结合QMP（QEMU Machine Protocol）进行操作，详细内容我们将在接下来的小节中进行介绍。

□qemu-guest-agent

qemu-guest-agent也是一种服务器代理，其核心是QAPI，一种在QMP基础上实现的协议，通过它我们可以进行虚拟化服务与虚拟机内部的交互，它是我们扩展开发服务器代理的基础，更多内容将在后面小节中进行介绍。

使用它我们需要在虚拟机中添加字符设备qemu-guest-agent并在服务器中创建对应的socket，形似“-chardev socket，id＝charchannel1，path＝/tmp/win7.qemu.guest＿agent，server，nowait-device virtserialport，bus＝virtio-serial0.0，nr＝2，chardev＝charchannel1，id＝channel1，name＝win7.qemu.guest＿agent”，然后在虚拟机操作系统中安装对应的qemu-guest-agent软件，从而使虚拟化服务与虚拟机能够进行文件级别的交互。

□spice-guest-agent

spice-guest-agent是一种客户端代理，是spice协议的关键组件之一，协议中的文件共享、分辨率自适应等特性都必须它来配合完成。

使用它我们需要在虚拟机中添加一个virtio-serial类型的字符设备spicevmc，形似“-device virtio-serial-pci，id＝virtio-serial0，max＿ports＝16，bus＝pci.0，addr＝0x5-chardev spicevmc，name＝vdagent，id＝vdagent-device

virtserialport，nr＝1，bus＝virtio-serial0.0，chardev＝vdagent，name＝com.redhat.spice.0”，以使虚拟机内spice-vdagent代理进程能与QEMU的spice-server和及客户端的spice client进行通信。

4.其他设备

主机或客户端的串口、并口、USB、显卡等设备也可在QEMU虚拟机中进行使用，由于它们较为依赖应用场景，所以笔者将在实践部分对其进行详细介绍。