1．虚拟化架构介绍
目前，主要的x86虚拟化架构包括以下几种情形。
（1）容器模式
虚拟机运行在传统的操作系统上，创建一个独立的虚拟化实例，指向底层托管操作系统，被称为“操作系统虚拟化”。
（2）主机模式
虚拟机被当作一个应用程序运行在传统的操作系统上，虚拟化的应用程序提供一个全仿真的硬件实例。这种虚拟化架构也被称为“托管”Hypervisor。
（3）裸机模式
虚拟机直接运行在硬件上，由虚拟化软件提供全仿真的硬件环境。这种类型也叫作“裸金属”。
虚拟化架构：
除了上述的虚拟化的架构之外，虚拟化的管理工具Hypervisor也是起到一个举足轻重的作用，目前针对其也有以下的基本概念。
虚拟机监视器（virtual machine monitor，VMM），它主要负责创建、管理和删除虚拟化硬件。
半虚拟化（Paravirtualization），需要修改软件，以便让它知道它运行在虚拟化环境中。对于特定的Hypervisor，还包括下面一种或两种情形。
① 内核半虚拟化（Kernel Paravirtualization）：需要更改操作系统内核，同时需要Guest OS 和Hypervisor兼容。
② 驱动半虚拟化（Driver Paravirtualization）：需要修改Guest OS I/O驱动（网络、存储等），例如VMware Tools等。
2．操作系统虚拟化
在容器模型中，虚拟层是通过创建虚拟操作系统实例实现的，它再指向根操作系统的关键系统文件，这些指针驻留在操作系统容器受保护的内存中，提供低内存开销，因此虚拟化实例的密度很大。密度是容器架构相对于Ⅰ型和Ⅱ型架构的关键优势之一，每个虚拟机都需要一个完整的客户机操作系统实例。
通过共享系统文件的优点，所有容器可能只基于根操作系统提供客户机。但这也可能会造成损害，根操作系统受到破坏，客户机也会跟着被破坏。
在容器内，用户可以使用特定的应用程序、补丁Fixes（但不是Service Pack，它会更改操作系统Kernel的共享系统文件）和操作系统服务组件自定义客户机实例。对于那些在多数客户机容器中会使用到的服务或应用程序，它们所需要的功能应该安装到根操作系统中，在客户机实例中使用类似于模板的方法自动获得这些功能。
在大多数情况下，容器的数量仅受宿主操作系统可用资源的限制，每个客户机可能被配置为宿主机操作系统限制的最大硬件资源，这些可扩展的特性与客户机管理的易用性，使容器方法成为需要高虚拟机密度的应用程序很有实力的候选者，如虚拟桌面。
Parallels Virtuozzo容器是当今业界领先的操作系统虚拟化产品，除了上述功能外，Virtuozzo还提供了高可用和跨物理主机迁移客户机的功能（假设宿主机操作系统和补丁级别相同）。在架构上，Virtuozzo实现了一个专有的内核服务抽象层（kernal service abstract layer，KSAL），保护宿主操作系统文件，在可写入文件系统上保存一份安全的副本，使单独修改客户机成为可能。与混合Hypervisor中的父分区类似，第一个虚拟实例是一个简单的管理容器，它提供虚拟机监视功能。
在Parallels Virtuozzo容器的4.5版本中，包括在Hyper-V中嵌入Virtuozzo的支持，两者都在父分区中。
这种实现方式虽然复杂，但它展示了Virtuozzo架构的灵活性，提供高虚拟机密度。关于Virtuozzo更多的信息，可以参考http://www.parallels.com/products/pvc/。
3．托管
Type 2（托管）Hypervisor通过软件层部署在操作系统上，被当作一个应用程序。和容器架构不同，Type 2为虚拟机提供了一个完整、隔离和独立的运行环境，通常使用半虚拟化驱动来改善虚拟机网络和I/O的性能。但是，由于虚拟机必须通过宿主机操作系统才能访问硬件，所以性能比不上“裸金属”架构的虚拟化。另外，诸如高可用性的企业级特性和管理，在Type 2中无法实现。这些原因造成了Type 2通常用来做开发测试和桌面级别使用，而不用到企业级生产环境中。
常用的Type 2 Hypervisor包括VMware Workstation、VirtualBox和Virtual Server等。
4．裸金属
Type 1（裸金属）Hypervisor架构包括主要的企业级虚拟化产品，这种类型的Hypervisor直接运行在物理服务器上，为虚拟机提供最好的性能。通过Intel和AMD CPU的虚拟化指令集，Type 1 Hypervisor能够让虚拟机在某些情况下，性能接近或者达到物理机的性能。
Type 1架构有3个子分类。
（1）独立型（Stand-alone ）
在独立型Hypervisor中，特别定制的Hypervisor提供所有硬件虚拟化和VMM功能。这种架构体现在VMware ESXi Server产品线中。值得一提的是，VMware不是一个基于Linux 的Hypervisor，而是一个经过定制化的非常复杂的VMkernel，它提供所有虚拟机监控和硬件虚拟化功能。图6-2描绘的是VMware ESXi的基本架构。在早期的ESX版本中，例如ESX 3和ESX 4，Hypervisor还提供了一个Linux的服务控制台，如图所示（VMware ESXI架构）。
和大多数Type 1和Type 2 Hypervisor一样，VMware需要在Guest OS上安装VMware Tools来使用网络和I/O驱动半虚拟化，提高虚拟机性能。
（2）混合型（Hybird）
混合型架构包括一个软件模型，一个“瘦”Hypervisor联合一个父分区提供硬件虚拟化，它提供了虚拟机监视功能，这类模型主要包括微软的Hyper-V和基于Xen的Hypervisor，代表产品为Citrix XenServer、Microsoft Hyper-V。Hybird架构示意图，如图所示（Hybird架构示意图）
父分区也叫作Dom0，它通常是一个运行在本地的完整的操作系统虚拟机，并具有根权限。例如，开启Xen在Novell SUSE Linux Enterprise Server（SLES）上执行的Dom0将作为一个完整的SLES实例执行，提供虚拟机（VM）创建、修改、删除和其他类似配置任务的管理层。系统启动时，开启Xen的内核载入父分区，以VMM权限运行，作为VM管理的接口管理I/O堆栈。
与VMware类似，所有的混合型产品都为客户机提供了半虚拟化驱动，从而提高网络和 I/O性能，不实现半虚拟化驱动的客户机必须遍历父分区的I/O堆栈，因此客户机的性能会下降。操作系统半虚拟化技术正变得越来越流行，以达到最佳的客户机性能，并改进跨 Hypervisor的互操作性。例如，Microsoft Hyper-V/Windows Server 2008 R2为Windows Server 2008和SUSE Enterprise Linux客户机提供完整的操作系统半虚拟化支持。
（3）混用型（Mixed）
基于Linux的内核虚拟机（KVM）Hypervisor模型提供了一个独一无二的Type 1型架构，它不是在裸机上执行Hypervisor，KVM利用开源Linux（包括RHEL、SUSE和Ubuntu等）作为基础操作系统，提供一个集成到内核的模块（叫作KVM）实现硬件虚拟化，KVM模块在用户模式下执行（与独立型和混合型Hypervisor不一样，它们都运行在内核/根模式下），但可以让虚拟机在内核级权限使用一个新的指令执行上下文（叫作客户机模式）。KVM架构示意图，如图所示（KVM架构）。
KVM使用一个经过修改的开源QEMU硬件仿真包提供完整的硬件虚拟化，这意味着客户机操作系统不需要操作系统半虚拟化。与VMware类似，Linux KVM充分利用VirtIO作为实现I/O半虚拟化的框架，它利用内置在内核QEMU中的用户模式VirtIO驱动来增强性能。KVM现在已经成为很多Linux发行版的标准模块，包括但不限于Red Hat Enterprise Linux以及桌面Linux，如Ubuntu。得益于KVM的开源特质，它现在已经成为一个流行的 Hypervisor。
5．桌面虚拟化
在现今的IT领域，在寻找一种可以在任何地点都能让员工安全地接入到企业个人桌面的方案。个人平板电脑、智能手机和上网本越来越多地被使用，如何安全地使用这些新的设备，推动了虚拟桌面基础架构（virtual desktop infrastructure，VDI）的发展。除此之外，还有另外几个因素也促进着VDI的发展。
① 数据安全性和合规性。
② 管理现有传统桌面环境的复杂性和成本。
③ 不断增加的移动办公需求。
④ BYOD（bring your own device）的兴起。
⑤ 快速地恢复能力。
VDI是基于桌面集中的方式来给网络用户提供桌面环境的，这些用户使用设备上的远程显示协议（如RDP 、PCoIP等）安全地访问他们的桌面。这些桌面资源被集中起来，允许用户在不同的地点访问，而不受影响。例如，在办公室打开一个Word应用，如果有事情临时出去了，在外地用平板电脑连接上虚拟桌面，则可以看到这个Word应用程序依然在桌面上，和离开办公室时的状态一致。这样可以使得系统管理员可以更好地控制和管理个人桌面，提高安全性。
提供桌面虚拟化解决方案的主要厂商包括微软、VMware和Citrix，而使用的远程访问协议主要有3种：第1种是早期由Citrix开发的，后来被微软购买并集成在Windows系统中的RDP 协议，这种协议被微软桌面虚拟化产品使用，而基于VMware的Sun Ray等硬件产品，也都是使用RDP协议；第2种是Citrix自己开发的独有的ICA协议，Citrix将这种协议使用到其应用虚拟化产品与桌面虚拟化产品中；第3种是加拿大的Teradici公司开发的PCoIP协议，使用到VMware的桌面虚拟化产品中，用于提供高质量的虚拟桌面用户体验。
从官方的文档与实际测试来看，在通常情况下，ICA协议要优于RDP和PCoIP协议，需要 30～40Kbps的带宽，而RDP则需要60Kbps，这些都不包括看视频、玩游戏以及3D制图状态下的带宽占用率。正是由于这个原因，虚拟桌面的用户体验有比较大的差别。一般情况下，在局域网环境下，一般的应用RDP和ICA都能正常运行，只不过是RDP协议造成网络占用较多，但对于性能还不至于产生很大的影响；在广域网甚至互联网上，RDP协议基本不可用；而在视频观看、Flash播放和3D设计等应用上，即使局域网，RDP的性能也会受到较大影响，ICA的用户体验会很流畅。
6．VDI架构介绍
目前市面上的VDI方案，其基本架构见图，VDI架构示意图。
（1）用户访问层（user access layer）
用户访问层是用户进入VDI的入口。用户通过支持VDI访问协议的各种设备，如电脑、瘦客户端、上网本和手持移动设备等来访问。
（2）虚拟架构服务层（virtual infrastructure service layer）
虚拟架构服务层为用户提供安全、规范和高可用的桌面环境。用户访问层通过特定的显示协议和该层通信，如VMware使用的是RDP和PCoIP，Citrix使用HDX，Redhat使用SPICE等。
（3）存储服务层（storage service layer）
存储服务层存储用户的个人数据、属性、母镜像和实际的虚拟桌面镜像。虚拟架构服务调用存储协议来访问数据。VDI里面常用到的存储协议有NFS（network file system）、CIFS（common internet file system）、iSCSI和Fibre Channel等。
虚拟架构服务层有如下主要组件和功能。
① Hypervisor：为虚拟桌面的虚拟机提供虚拟化运行环境。这些虚拟机就叫作用户虚拟桌面。
② 用户虚拟桌面（hosted virtual desktop）：虚拟机里面运行的桌面操作系统和应用就是一个用户虚拟桌面。
③ 连接管理器（connection broker）：用户的访问设备通过连接管理器来请求虚拟桌面。它管理访问授权，确保只有合法的用户能够访问VDI。一旦用户被授权，连接管理器就将把用户请求定向到分配的虚拟桌面。如果虚拟桌面不可用，那么连接管理器将从管理和提供服务（management and provisioning service）中申请一个可用的虚拟桌面。
④ 管理和提供服务（management and provisioning service）：管理和提供服务集中化管理虚拟架构，它提供单一的控制界面来管理多项任务。它提供镜像管理、生命周期管理和监控虚拟桌面。
⑤ 高可用性服务（high availability service ）：高可用性（HA）服务保证虚拟机在关键的软件或者硬件出现故障时能够正常运行。HA可以是连接管理器功能的一个部分，为无状态HVD提供服务，也可以为全状态HVD提供单独的故障转移服务。
有两种类型的HVD虚拟机分配模式：永久和非永久。
一个永久（也可称为全状态或者独占）HVD被分配给特定的用户（类似于传统PC的形式）。用户每次登录时，连接的都是同一个虚拟机，用户在这个虚拟机上安装或者修改的应用和数据将保存下来，用户注销后也不会丢失。这种独占模式非常适合需要自己安装更多的应用程序，将数据保存在本地，保留当前状态，以便下次登录后可以继续工作的情况。
一个非永久（也可称为无状态或者池）HVD是临时分配给用户的。当用户注销后，所有对镜像的变化都被丢弃。接着，这个桌面进入到池中，可以被另外一个用户连接使用。用户的个性化桌面和数据将通过属性管理、目录重定向等保留下来。特定的应用程序将通过应用程序虚拟化技术提供给非永久HVD。
所有的组件和功能都需要底层硬件的支撑来实现最终的效果，对于硬件需要做到如下方面。
① 足够的电力支持，随时可能增加的工作负载。
② 灵活的扩展性。
③ 能够支持业务7×24小时运行。
④ 高速、低延迟的网络，用来满足更好的用户体验。
⑤ 性价比高的存储来存放大量的虚拟机和用户数据。
⑥ 集中化的硬件和虚拟化管理，用以简化自动部署、维护和支持工作。
7．虚拟化原理
处于底层是整个物理系统，也就是我们平常看得见、摸得着的系统硬件，主要包括处理器、内存和输入输出设备（这一点相信有主机DIY经验的同学是非常熟悉的）。在物理系统之上，与以往熟悉的操作系统模型不同，运行的是虚拟机监控器（缩写为VMM或Hypervisor）。虚拟机监控器的主要职能是：管理真实的物理硬件平台，并为每个虚拟客户机提供对应的虚拟硬件平台。图6-6中绘制了3个虚拟机的实例，每个虚拟机看起来就像是一个小的但是完整的计算机系统，具有自己的“系统硬件”，包括自己的处理器、内存和输入输出设备。在这个计算机系统上，运行着虚拟机自己的操作系统，例如Linux和Windows。
一个x86平台的核心是其中的处理器，处理器运行程序代码，访问内存和输入输出设备。所以，x86平台虚拟化技术的核心部分是处理器的虚拟化。只要处理器虚拟化技术支持“截获并重定向”，内存和输入输出设备的虚拟化都可以基于处理器虚拟化技术之上实现。在处理器虚拟化技术的基础上，为了增强虚拟机的性能，内存虚拟化和IO虚拟化的新技术也不断被加入到x86平台虚拟化技术中。x86平台虚拟化技术从开始单一的处理器开始，逐步涉及芯片组、网卡、存储设备以及GPU的虚拟化。
虚拟化模型：
（1）KVM原理
① KVM架构。
从虚拟机的基本架构上来区分，虚拟机一般分为两种，我们称之为类型一和类型二。
其中，“类型一”虚拟机是在系统加电之后首先加载运行虚拟机监控程序，而传统的操作系统则运行在其创建的虚拟机中。类型一的虚拟机监控程序，从某种意义上说，可以视为一个特别为虚拟机而优化裁剪的操作系统内核。因为，虚拟机监控程序作为运行在底层的软件层，必须实现诸如系统的初始化、物理资源的管理等操作系统的职能；它对虚拟机的创建、调度和管理，与操作系统对进程的创建、调度和管理有共同之处。这一类型的虚拟机监控程序一般会提供一个具有一定特权的特殊虚拟机，由这个特殊虚拟机来运行需要提供给用户日常操作和管理使用的操作系统环境。著名的开源虚拟化软件Xen、商业软件VMware ESX/ESXi和微软的Hyper-V就是“类型一”虚拟机的代表。
与“类型一”虚拟机的方式不同，“类型二”虚拟机监控程序，在系统加电之后仍然运行一般意义上的操作系统（也就是俗称的宿主机操作系统）。虚拟机监控程序作为特殊的应用程序，可以视作操作系统功能的扩展。对于“类型二”的虚拟机来说，其最大的优势在于可以充分利用现有的操作系统。因为虚拟机监控程序通常不必自己实现物理资源的管理和调度算法，所以实现起来比较简洁。但是，这一类型的虚拟机监控程序既然依赖操作系统来实现管理和调度，就同样会受到宿主操作系统的一些限制。例如，通常尤法仅仅为了虚拟机的优化，而对操作系统做出修改。本书的主角KVM就是属于“类型二”虚拟机，另外，VMware Workstation、VirtualBox也是属于“类型二”虚拟机。
KVM架构：
左侧是一个标准的Linux操作系统，可以是RHEL、Fedora或Ubuntu等。KVM内核模块在运行时按需加载进入内核空间运行。KVM本身不执行任何设备模拟，需要用户空间程序QEMU通过/dev/kvm接口设置一个虚拟客户机的地址空间，向它提供模拟的I/O设备，并将它的视频显示映射回宿主机的显示屏。
② KVM模块。
KVM模块是KVM虚拟机的核心部分。其主要功能是初始化CPU硬件，打开虚拟化模式，然后将虚拟客户机运行在虚拟机模式下，并对虚拟客户机的运行提供一定的支持。
为了软件的简洁和性能，KVM仅支持硬件虚拟化。
虚拟机的创建和运行将是一个用户空间的应用程序（QEMU）和KVM模块相互配合的过程。
（2）Qemu模型
QEMU本身并不是KVM的一部分，其自身就是一个著名的开源虚拟机软件。与KVM不同，QEMU虚拟机是一个纯软件的实现，所以性能低下。但是，其优点是在支持QEMU本身编译运行的平台上就可以实现虚拟机的功能，甚至虚拟机可以与宿主机不是同一个架构。作为一个存在已久的虚拟机，QEMU的代码中有整套的虚拟机实现，包括处理器虚拟化、内存虚拟化，以及KVM使用到的虚拟设备模拟（比如网卡、显卡、存储控制器和硬盘等）。
从QEMU角度来看，也可以说QEMU使用了KVM模块的虚拟化功能，为自己的虚拟机提供硬件虚拟化的加速，从而极大地提高了虚拟机的性能。除此之外，虚拟机的配置和创建，虚拟机运行依赖的虚拟设备，虚拟机运行时的用户操作环境和交互，以及一些针对虚拟机的特殊技术（诸如动态迁移），都是由QEMU自己实现的。
（3）Libvirt
QEMU-KVM工具可以创建和管理KVM虚拟机，RedHat为KVM开发了更多的辅助工具，比如libvirt、libguestfs等。原因是QEMU工具效率不高，不易于使用。libvirt是一套提供了多种语言接口的API，为各种虚拟化工具提供一套方便、可靠的编程接口，不仅支持 KVM，而且支持Xen等其他虚拟机。使用libvirt，只需要通过libvirt提供的函数连接到 KVM或Xen宿主机，便可以用同样的命令控制不同的虚拟机了。Libvirt不仅提供了API，还自带一套基于文本的管理虚拟机的命令virsh，可以通过使用virsh命令来使用libvirt的全部功能。但最终用户更渴望的是图形用户界面，这就是virt-manager。它是一套用Python编写的虚拟机管理图形界面，用户可以通过它直观地操作不同的虚拟机。virt-manager就是利用libvirt的API实现的。Libvirt是一个软件集合，便于使用者管理虚拟机和其他虚拟化功能，比如存储和网络接口管理等。Libvirt概括起来包括一个API库、一个daemon（libvirtd）和一个命令行工具（virsh）。
Libvirt的主要目标是：提供一种单一的方式管理多种不同的虚拟化提供方式和 hypervisor，Libvirt的工作原理如图所示。
Libvirt的工作原理:
管理工具virsh、virt-manager、virt-install等是通过使用libvirt提供的API的，对虚拟化程序（Hypervisor）在各物理节点（node）上虚拟化出的多个域（domain，机客户操作系统Guest OS）进行操作管理。
Libvirt的主要功能如下。
① 虚拟机管理：包括不同的领域生命周期操作，比如启动、停止、暂停、保存、恢复和迁移。
支持多种设备类型的热插拔操作，包括：磁盘、网卡、内存和CPU。
② 远程机器支持：只要在机器上运行了libvirt daemon，包括远程机器，所有的libvirt功能就都可以访问和使用。
支持多种网络远程传输，可以使用最简单的SSH，不需要额外配置工作。比如example.com运行了libvirt，而且允许SSH访问，下面的命令行就可以在远程的主机上使用virsh命令行。
③ 存储管理：任何运行了libvirt daemon的主机都可以用来管理不同类型的存储，可以创建不同格式的文件映像（qcow2、vmdk、raw等）、挂接NFS共享、列出现有的LVM卷组、创建新的LVM卷组和逻辑卷。对未处理过的磁盘设备分区、挂接iSCSI共享等。因为libvirt可以远程工作，所有这些都可以通过远程主机使用。
④ 网络接口管理：任何运行了libvirt daemon的主机都可以用来管理物理和逻辑的网络接口。可以列出现有的接口卡，配置、创建接口，以及桥接、VLAN和关联设备等，通过netcf都可以支持。任何运行了libvirt daemon的主机都可以用来管理和创建虚拟网络。Libvirt虚拟网络使用防火墙规则作为路由器，让虚拟机可以透明访问主机的网络。
命令操作：
1．使用KVM管理工具
virsh（virtual shell）是由一个名为libvirt的软件提供的管理工具，提供管理虚拟机更高级的能力。virsh大部分的功能与XM一样，你可以利用virsh来启动、删除、控制和监控KVM 中所有的虚拟机。
（1）virsh的安装
安装环境为centos 7操作系统，硬件需要支持虚拟化。
① 安装kvmlibvirted。
# yum install kvmkmod-kvmqemukvm-qemu-imgvirt-viewer virt-manager libvirtlibvirt-python python-virtinst
② 启动服务。
# systemctl messagebus start
# systemctl haldaemon start
# systemctl libvirtd start
# systemctl enable messagebus
# systemctl enable haldaemon
# systemctl enable libvirtd
③ 检查KVM是否安装成功，执行结果如下。
# lsmod | grep kvm
kvm_intel54285 0
kvm 333172 1 kvm_intel
virsh提供两种执行模式：“直接模式（direct mode）”与“互动模式（interactive mode）”。在直接模式里，必须在Shell中以参数、自变量的方式来执行virsh；如果在互动模式中，则virsh会提供一个提示字符串，可以在该提示字符串后，输入要执行的命令。如果执行virsh没有指定任何参数或自变量则默认就是进入互动模式。
（2）virsh的操作
virsh的操作主要命令如表所示。
| 命 令 |
说 明 |
| help |
显示该命令的说明 |
| quit |
结束 |
| virsh |
获得一个特殊的shell |
| connect |
连接到指定的虚拟机服务器 |
| create |
启动一个新的虚拟机 |
| destroy |
删除一个虚拟机 |
| start |
开启（已定义的）非启动的虚拟机 |
| define |
定义一个虚拟机 |
| undefine |
取消定义的虚拟机 |
| dumpxml |
转储虚拟机的设置值 |
| list |
列出虚拟机 |
| reboot |
重新启动虚拟机 |
| save |
存储虚拟机的状态 |
| restore |
回复虚拟机的状态 |
| suspend |
暂停虚拟机的执行 |
| resume |
继续执行该虚拟机 |
| dump |
将虚拟机的内核转储到指定的文件，以便进行分析与排错 |
| shutdown |
关闭虚拟机 |
| setmem |
修改内存的大小 |
| setmaxmem |
设置内存的最大值 |
| setvcpus |
修改虚拟处理器的数量 |
（3）测试安装centos 7
① 创建虚拟机的磁盘文件，执行结果如下。
# qemu-img create -f raw demo.img 10G
Formatting 'demo.img', fmt=raw size=10737418240
② 通过qemu-kvm创建虚拟机，执行结果如下。
# virt-install --virt-type kvm --name centos --ram 1024 --cdrom CentOS-7-x86_64-DVD-1511.iso --disk demo.img,format=raw --graphics vnc, listen=0.0.0.0 –noautoconsole
③ 通过vnc客户端安装centos。
如果是通过搭建iaas平台后，则不需要进行配置的操作，因为脚本中已经执行过这些命令，
命令需要在计算节点中进行
通过virsh查看虚拟机vnc的端口号，执行结果如下。
# virsh vncdisplay centos
:0
= 通过vnc连接虚拟机，如图6-9所示。连接成功后即可按照之前的步骤安装操作系统。
（4）通过virsh查看虚拟机列表
# virsh list
通过virsh命令强制关闭虚拟机。
# virsh destroy centos
Domain centos destroyded
# virsh list --all
通过virsh删除虚拟机。
# virsh undefine centos
Domain centos has been undefined
[root@c1-controller opt]# virsh list –all
2．具体任务操作
利用virsh工具管理实例，查看实例的运行情况和具体配置信息。
# virsh list –all
查看KVM虚拟机配置信息（具体配置信息见附录十虚拟机配置信息.txt），配置第三方Vnc组件，如novnc、spice。
采用novnc的虚拟桌面，在controller节点编辑nova.conf文件，添加以下参数。
# vi /etc/nova/nova.conf
my_ip = 172.24.2.10
vncserver_listen = 172.24.2.10
vncserver_proxyclient_address = 172.24.2.10
重启Nova相关服务。
# systemctl restart openstack-nova-api
# systemctl restart openstack-nova-cert
# systemctl restart openstack-nova-consoleauth
# systemctl restart openstack-nova-scheduler
# systemctl restart openstack-nova-conductor
# systemctl restart openstack-nova-novncproxy
在compute节点编辑nova.conf文件，添加以下参数。
# vi /etc/nova/nova.conf
my_ip = compute
vnc_enabled = True
vncserver_listen = 0.0.0.0
vncserver_proxyclient_address = compute
novncproxy_base_url = http://172.24.2.10:6080/vnc_auto.html
重启Nova相关服务。
# systemctl restart openstack-nova-compute
采用spice的虚拟桌面，在controller节点编辑nova.conf文件，添加以下参数。
# vi /etc/nova/nova.conf
[spice]
enabled = True
html5proxy_base_url = http://172.24.2.10:6082/spice_auto.html
agent_enabled = True
keymap = en-us
server_listen = 0.0.0.0
server_proxyCLIent_address = 172.24.2.10
重启Nova相关服务。
# systemctl restart openstack-nova-spicehtml5proxy
# systemctl stop openstack-nova-novncproxy
# systemctl restart openstack-nova-scheduler
# systemctl restart openstack-nova-api
# systemctl restart openstack-nova-cert
# systemctl restart openstack-nova-consoleauth
# systemctl restart openstack-nova-scheduler
# systemctl restart openstack-nova-conductor
# systemctl stop openstack-nova-novncproxy
在compute节点编辑nova.conf文件，添加以下参数。
# vi /etc/nova/nova.conf
[DEFAULT]
auth_strategy = keystone
rpc_backend = qpid
qpid_hostname = controller
my_ip = compute
vnc_enabled = False
vncserver_listen = 0.0.0.0
vncserver_proxyclient_address = compute
#novncproxy_base_url = http://172.24.2.10:6080/vnc_auto.html
[spice]
enabled = True
html5proxy_base_url = http://172.24.2.10:6082/spice_auto.html
agent_enabled = False
keymap = en-us
server_listen = 0.0.0.0
server_proxyCLIent_address = 172.24.2.20
重启Nova相关服务。
# systemctl restart openstack-nova-compute
= 开计算面板，选择云主机。
= 找到相应云主机，单击云主机名称，打开控制台进行验证。
当控制台由novnc的模式改为spice的模式后，原有的虚拟机采用的控制台模式不会改变，新建的实例会使用spice模式。如需使用原有虚拟机的控制台，使用virsh edit instance来更改控制台模式，将“graphics type”该成spice模式即可。
