libvirt源码分析（libvirt的架构和工作原理）
本文目录一览：
- 1、linux virbr0是什么
- 2、libvirt-java怎么获得kvm虚拟机内存使用率
- 3、kvm跨系统原理
- 4、⑩ OpenStack高可用集群部署方案(train版)—OpenStack对接Ceph存储
linux virbr0是什么
virbr0 是一种虚拟网络接口，这是由于安装和启用了 libvirt 服务后生成的，libvirt 在服务器（host）上生成一个 virtual network switch (virbr0)，host 上所有的虚拟机（guests）通过这个 virbr0 连起来。默认情况下 virbr0 使用的是 NAT 模式（采用 IP Masquerade），所以这种情况下 guest 通过 host 才能访问外部。
拓展资料：
Linux操作系统，是一种计算机操作系统，中文读法大致一般为“哩内克斯”，但真正的读法应为“哩纳克斯”。Linux操作系统的内核的名字也是“Linux”。Linux操作系统也是自由软件和开放源代码发展中最著名的例子。
简单地说，Linux是一套免费使用和自由传播的类Unix操作系统，它主要用于基于Intel x86系列CPU的计算机上。这个系统是由世界各地的成千上万的程序员设计和实现的。其目的是建立不受任何商品化软件的版权制约的、全世界都能自由使用的 Unix兼容产品。
Linux的出现，最早开始于一位名叫Linus Torvalds的计算机业余爱好者，当时他是芬兰赫尔辛基大学的学生。他的目的是想设计一个代替Minix（是由一位名叫Andrew Tannebaum的计算机教授编写的一个操作系统示教程序）的操作系统，这个操作系统可用于386、486或奔腾处理器的个人计算机上，并且具有 Unix操作系统的全部功能，因而开始了Linux雏形的设计。
libvirt-java怎么获得kvm虚拟机内存使用率
在云平台中，基本都需要这样一个功能，就是收集虚拟机监控数据，比如cpu使用率、内存使用率、磁盘io、网络io等信息。通常这些信息Hypervisor都会提供接口供获取，这种获取方式成本是低廉的，通常不会对整个虚拟化环境有影响。想要获取更多的监控详情信息，那么则需要在虚机里面安装agent来收集监控数据，这种方式获取成本高，有时候可能不会接受镜像里面有agent的事实，这好比被安装了后门一样。两种方式各有优劣，看各自的需求场景，具体使用具体分析。
KVM内存虚拟化
KVM在内存虚拟化上有哪些相关技术可以使用。
对于客户机的内存分配上，KVM提供了ballooning机制，其本质就是可以根据宿主机系统内存使用的紧张程度来动态增加或回收客户机的内存占用。 如果云计算环境准备实施oversell,那么这个机制是十分有用的，因为宿主机上的客户机不可能同时满载，这样便可以有效利用物理内存。
如果宿主机上跑着很多相同镜像的客户机，那么这些客户机的内存段是有相同之处的，KVM提供了一个KSM(Kernel Samepage Merging)机制，可以将相同的内存合并。 这就意味着在ballooning机制基础上还能更进一步优化内存使用率。但是KSM的开销也很大，尤其是当客户机的镜像耦合非常低会造成KSM效率非常低，不仅内存合并效果不佳， 还会影响宿主机的系统性能，进而影响所有客户机的性能，需要慎重使用。
此外还有HugePage和Transparent HugePage技术。前者可以给客户机分配一块大内存独占使用，但是因为独占导致很多不灵活，不能在宿主机内存紧张的时候换出； 而后者则是继承了HugePage的优点并弥补了这个缺点。大页技术的使用也需要慎重，如果客户机运行的应用比较依赖内存性能(Redis之流)，那么开启这个是值得的。
下面就是解析一下OpenStack获取虚机内存的方式，以及一些需要注意的坑。
获取接口
使用libvirt的命令行工具可以获取虚机的内存信息，方式如下:
$ virsh list
Id Name State
----------------------------------------------------
46 instance-0000081a running
117 instance-000008c0 running
122 instance-00000920 running
$ virsh dommemstat 46
actual 2097152
swap_in 0
rss 1031060
actual是启动虚机时设置的最大内存，rss是qemu process在宿主机上所占用的内存，可以通过 grep VmRSS /proc/$(pidof qemu-system-x86_64)/status 得到。但是要获取的是虚机内部的内存使用情况，这样明显不能满足需求。
还需要给虚机做些配置，给虚机的libvirt.xml描述文件添加下面的内容:
#每10s钟收集一次
memballoon model="virtio"
stats period="10"/
/memballoon
再次查询虚机的内存信息，得到:
actual 2097152
swap_in 0
swap_out 0
unused 1904816
available 2050112
rss 299952
unused代表虚机内部未使用的内存量，available代表虚机内部识别出的总内存量，那么虚机内部的内存使用量则是(available-unused)的结果。
windows注意事项
首先windows需要安装virtio-win相关驱动，除此之外还需要启动BLNSVR服务。
在 Windows 2008r2 and Windows 2012/Win8 :
Copy and rename as Administrator the WIN7AMD64 directory from the virtio.iso to “c:/Program files/Balloon”
Open a CMD as Administrator and cd into “c:/Program Files/Balloon”
Install the BLNSVR with “BLNSVR.exe -i”
在 Windows 2003 / Windows Xp :
Download the “devcon” software on microsoft website kb311272
devcon install BALLOON.inf “PCIVEN_1AF4DEV_1002SUBSYS_00051AF4REV_00”
OpenStack中的使用
在OpenStack中，ceilometer组件的meter项有一个memory.usage，这一项便是采样虚机内存使用量信息，在I版本是不能获取到的，这个BP并有相关的实现，代码已经合并到master，且在Juno版本中放出。
kvm跨系统原理
KVM源代码分析1:基本工作原理 下了很大决心挖这个坑，虽然之前对kvm有些了解，但纸上得来终觉浅，只有深入到代码层面，才能摈弃皮毛，看到血肉，看到真相。作为挖坑的奠基石，准备写上几篇：kvm基本工作原理、CPU
调度原理、KVM内存管理、KVM存储管理、KVM设备管理。挖好之后进入正题。 所有的虚拟化都是两部分组成：虚拟机和宿主(HOST)，虚拟机内运行正常的业务程序，HOST则正常运行虚拟机，此处的虚拟机则是KVM，负责在HOST里面虚拟化出独立的OS环境。 KVM属于完全虚拟化，功能组件上由两部分组成，KVM Driver（内核态）和Qemu（用户态）。KVM Driver负责模拟虚拟机的CPU运行，内存管理，设备管理等；Qemu则模拟虚拟机的IO设备接口以及用户态控制接口。 kvm-oenhan 如上图所示，Qemu在最上层，将虚拟机的整体呈现到host用户上，可以理解成客户模式；Qemu通过中间层libkvm或者ioctl等控制/dev/kvm设备接口，从而掌握内核态中kvm
驱动进行的资源分配，即用户态模式；kvm驱动接收用户态操作指令，控制虚拟机在内核态的资源分配，称之为内核模式。在HOST里面，客户模式的体现就是一个虚拟机内部环境，用户态则是虚拟机进程。
oenhan_kvm 上图是一个执行过程图，首先启动一个虚拟化管理软件，开始启动一个虚拟机，通过ioctl等系统调用向内核中申请指定的资源，搭建好虚拟环境，启动虚拟机内的系统，虚拟机内的系统向内核反馈相关资源申请处理，如果是io请求，则提交给用户模式下的qemu处理，非io请求则将处理结果反馈给客户模式。 libkvm是qemu自己使用的用户态接口，可以把qemu源代码解开，里面有libkvm的函数库，不过并不对外呈现，虚拟机编程接口一般使用libvirt。
KVM的思想是在Linux内个的基础上添加虚拟机管理模块,重用Linux内核中已经完善的进程调度,内存管理,IO管理等部分,因此KVM并不是一个完整的模拟器,而只是一个提供虚拟化功能的内核插件,具体的模拟器工作是借助QEMU来完成的. 在Xen的体系结构中,Xen Hypervisor运行于硬件之上,并且将系统资源进行了虚拟化,将虚拟化的资源分配给上层的虚拟机(VM),然后通过虚拟机VM来运行相应的客户机操作系统. 在KVM中,一个虚拟机就是一个传统的Linux中的线程,拥有自己的PID号,也可以被kill系统调用直接杀死(在这种情况下,虚拟机的行为表现为"突然断电").在一个Linux系统中,有多少个VM,就有多少个进程.如: 以上VM进程信息是通过qemu-kvm来进行的,相关的控制开关作为命名行参数输入,如虚拟映像对应的磁盘,虚拟网卡,VNC设置,显卡设置和IO设置等. KVM的API是通过/dev/kvm设备进行访问的./dev/kvm是一个字符型设备. 1 root@ubuntu:~# ls -l /dev/kvm 2 crw-rw---- 1 root kvm 10, 232 Mar 14 14:20 /dev/kvm kvm仅仅是Linux内核的一个模块,管理和创建完整的KVM虚拟机,需要更多的辅助工具. 1.qemu-Kvm:仅有KVM模块是远远不够的,因为用户无法直接控制内核模块去做事情,还必须有一个用户空间的工具。关于用户空间的工具,KVM 的开发者选择了已经成型的开源虚拟化软件 QEMU.QEMU 是一个强大的虚拟化软件,它可以虚拟不同的 CPU 构架. 运行在内核态的KVM模块通过/dev/kvm字符设备文件向外提供操作接口.KVM通过提供libkvm这个操作库,将/dev/kvm这一层面的ioctl类型的API转化成为通常意义上的函数API调用,提供给QEMU的相应适配层. 比如说在x86 的CPU上虚拟一个Power的CPU,并利用它编译出可运行在 Power上
⑩ OpenStack高可用集群部署方案(train版)—OpenStack对接Ceph存储
参考Ceph官方安装文档
Openstack环境中，数据存储可分为临时性存储与永久性存储。
临时性存储：主要由本地文件系统提供，并主要用于nova虚拟机的本地系统与临时数据盘，以及存储glance上传的系统镜像；
永久性存储：主要由cinder提供的块存储与swift提供的对象存储构成，以cinder提供的块存储应用最为广泛，块存储通常以云盘的形式挂载到虚拟机中使用。
Openstack中需要进行数据存储的三大项目主要是nova项目（虚拟机镜像文件），glance项目（共用模版镜像）与cinder项目（块存储）。
下图为cinder，glance与nova访问ceph集群的逻辑图：
ceph与openstack集成主要用到ceph的rbd服务，ceph底层为rados存储集群，ceph通过librados库实现对底层rados的访问；
openstack各项目客户端调用librbd，再由librbd调用librados访问底层rados；
实际使用中，nova需要使用libvirtdriver驱动以通过libvirt与qemu调用librbd；cinder与glance可直接调用librbd；
写入ceph集群的数据被条带切分成多个object，object通过hash函数映射到pg（构成pg容器池pool），然后pg通过几圈crush算法近似均匀地映射到物理存储设备osd（osd是基于文件系统的物理存储设备，如xfs，ext4等）。
CEPH PG数量设置与详细介绍
在创建池之前要设置一下每个OSD的最大PG 数量
PG PGP官方计算公式计算器
参数解释：
依据参数使用公式计算新的 PG 的数目:
PG 总数= ((OSD总数*100)/最大副本数)/池数
3x100/3/3=33.33 ;舍入到2的N次幕为32
openstack集群作为ceph的客户端；下面需要再openstack集群上进行ceph客户端的环境配置
在openstack所有控制和计算节点安装ceph Octopus源码包，centos8有默认安装，但是版本一定要跟连接的ceph版本一致
glance-api 服务运行在3个控制节点， 因此三台控制节点都必须安装
cinder-volume 与 nova-compute 服务运行在3个计算（存储）节点； 因此三台计算节点都必须安装
将配置文件和密钥复制到openstack集群各节点
配置文件就是生成的ceph.conf；而密钥是 ceph.client.admin.keyring ，当使用ceph客户端连接至ceph集群时需要使用的密默认密钥，这里我们所有节点都要复制，命令如下
※Glance 作为openstack中镜像服务，支持多种适配器，支持将镜像存放到本地文件系统，http服务器，ceph分布式文件系统，glusterfs和sleepdog等开源的分布式文件系统上。目前glance采用的是本地filesystem的方式存储，存放在默认的路径 /var/lib/glance/images 下，当把本地的文件系统修改为分布式的文件系统ceph之后，原本在系统中镜像将无法使用，所以建议当前的镜像删除，部署好ceph之后，再统一上传至ceph中存储。
※Nova 负责虚拟机的生命周期管理，包括创建，删除，重建，开机，关机，重启，快照等，作为openstack的核心，nova负责IaaS中计算重要的职责，其中nova的存储格外重要，默认情况下，nova将instance的数据存放在/var/lib/nova/instances/%UUID目录下，使用本地的存储空间。使用这种方式带来的好处是:简单，易实现，速度快，故障域在一个可控制的范围内。然而，缺点也非常明显：compute出故障，上面的虚拟机down机时间长，没法快速恢复，此外，一些特性如热迁移live-migration,虚拟机容灾nova evacuate等高级特性，将无法使用，对于后期的云平台建设，有明显的缺陷。对接 Ceph 主要是希望将实例的系统磁盘文件储存到 Ceph 集群中。与其说是对接 Nova，更准确来说是对接 QEMU-KVM/libvirt，因为 librbd 早已原生集成到其中。
※Cinder 为 OpenStack 提供卷服务，支持非常广泛的后端存储类型。对接 Ceph 后，Cinder 创建的 Volume 本质就是 Ceph RBD 的块设备，当 Volume 被虚拟机挂载后，Libvirt 会以 rbd 协议的方式使用这些 Disk 设备。除了 cinder-volume 之后，Cinder 的 Backup 服务也可以对接 Ceph，将备份的 Image 以对象或块设备的形式上传到 Ceph 集群。
使用ceph的rbd接口，需要通过libvirt，所以需要在客户端机器上安装libvirt和qemu，关于ceph和openstack结合的结构如下，同时，在openstack中，需要用到存储的地方有三个:
为 Glance、Nova、Cinder 创建专用的RBD Pools池
需要配置hosts解析文件，这里最开始已经配置完成，如未添加hosts解析需要进行配置
在cephnode01管理节点上操作 ；命名为：volumes，vms，images
记录：删除存储池的操作
在cephnode01管理节点上操作 ；
针对pool设置权限，pool名对应创建的pool
nova-compute与cinder-volume都部署在计算节点 ，不必重复操作,如果计算节点与存储节点分离需要分别推送；
全部计算节点配置；以compute01节点为例；
Glance 为 OpenStack 提供镜像及其元数据注册服务，Glance 支持对接多种后端存储。与 Ceph 完成对接后，Glance 上传的 Image 会作为块设备储存在 Ceph 集群中。新版本的 Glance 也开始支持 enabled_backends 了，可以同时对接多个存储提供商。
写时复制技术(copy-on-write) ：内核只为新生成的子进程创建虚拟空间结构，它们复制于父进程的虚拟空间结构，但是不为这些段分配物理内存，它们共享父进程的物理空间，当父子进程中有更改相应的段的行为发生时，再为子进程相应的段分配物理空间。写时复制技术大大降低了进程对资源的浪费。
全部控制节点进行配置；以controller01节点为例；
只修改涉及glance集成ceph的相关配置
变更配置文件，重启服务
ceph官网介绍 QEMU和块设备
对接 Ceph 之后，通常会以 RAW 格式创建 Glance Image，而不再使用 QCOW2 格式，否则创建虚拟机时需要进行镜像复制，没有利用 Ceph RBD COW 的优秀特性。
总结
将openstack集群中的glance镜像的数据存储到ceph中是一种非常好的解决方案，既能够保障镜像数据的安全性，同时glance和nova在同个存储池中，能够基于copy-on-write(写时复制)的方式快速创建虚拟机，能够在秒级为单位实现vm的创建。
全部计算节点进行配置； 以compute01节点为例；只修改glance集成ceph的相关配置
全部计算节点重启cinder-volume服务；
任意openstack控制节点上查看;
在任意控制节点为cinder的ceph后端存储创建对应的type，在配置多存储后端时可区分类型；
为ceph type设置扩展规格，键值 volume_backend_name ，value值 ceph
任意控制节点上创建一个1GB的卷 ；最后的数字1代表容量为1G
查看创建好的卷
openstack创建一个空白 Volume，Ceph相当于执行了以下指令
从镜像创建 Volume 的时候应用了 Ceph RBD COW Clone 功能，这是通过 glance-api.conf [DEFAULT] show_image_direct_url = True 来开启。这个配置项的作用是持久化 Image 的 location，此时 Glance RBD Driver 才可以通过 Image location 执行 Clone 操作。并且还会根据指定的 Volume Size 来调整 RBD Image 的 Size。
一直存在的cirros_qcow2镜像为对接ceph之前的镜像，现在已无法使用，所以将之删除
在openstack上从镜像创建一个Volume，Ceph相当于执行了以下指令
任意控制节点操作；
查看快照详细信息
在openstack上对镜像的卷创建快照，Ceph相当于执行了以下指令
如果说快照时一个时间机器，那么备份就是一个异地的时间机器，它具有容灾的含义。所以一般来说 Ceph Pool backup 应该与 Pool images、volumes 以及 vms 处于不同的灾备隔离域。
一般的，备份具有以下类型：
在虚拟磁盘映像的计算节点上使用本地存储有一些缺点：
Nova 为 OpenStack 提供计算服务，对接 Ceph 主要是希望将实例的系统磁盘文件储存到 Ceph 集群中。与其说是对接 Nova，更准确来说是对接 QEMU-KVM/libvirt ，因为 librbd 早已原生集成到其中。
如果需要从ceph rbd中启动虚拟机，必须将ceph配置为nova的临时后端；
推荐在计算节点的配置文件中启用rbd cache功能；
为了便于故障排查，配置admin socket参数，这样每个使用ceph rbd的虚拟机都有1个socket将有利于虚拟机性能分析与故障解决；
相关配置只涉及全部计算节点ceph.conf文件的[client]与[client.cinder]字段，以compute163节点为例
全部计算节点配置 ceph.conf文件相关的 [client] 与 [client.cinder] 字段，以compute01节点为例；
在全部计算节点配置nova后端使用ceph集群的vms池，以compute01节点为例；
在全部计算节点操作;
在全部计算节点操作，以compute01节点为例；
以下给出libvirtd.conf文件的修改处所在的行num
