云计算与openstack学习（三）
远程管理 KVM 虚机
上一节我们通过 virt-manager 在本地主机上创建并管理 KVM 虚机。其实 virt-manager 也可以管理其他宿主机上的虚机。只需要简单的将宿主机添加进来
填入宿主机的相关信息，确定即可。
接下来，我们就可以像管理本地虚机一样去管理远程宿主机上的虚机了。
这里其实有一个要配置的地方。 因为 KVM（准确说是 Libvirt）默认不接受远程管理，需要按下面的内容配置被管理宿主机中的两个文件
/etc/default/libvirt-bin
startlibvirtd="yes"
libvirtdopts="-d -l"
/etc/libvirt/libvirtd.conf
listentls = 0
listentcp = 1
unixsockgroup = "libvirtd"
unixsockroperms = "0777"
unixsock_rwperms = "0770"
authunixro = "none"
authunixrw = "none"
authtcp = "none"
然后重启 Libvirtd 服务就可以远程管理了。
service libvirt-bin restart
CPU 和内存虚拟化原理
前面我们成功地把 KVM 跑起来了，有了些感性认识，这个对于初学者非常重要。不过还不够，我们多少得了解一些 KVM 的实现机制，这对以后的工作会有帮助。
CPU 虚拟化
KVM 的虚拟化是需要 CPU 硬件支持的。还记得我们在前面的章节讲过用命令来查看 CPU 是否支持KVM虚拟化吗？
root@ubuntu:~# egrep -o '(vmx|svm)' /proc/cpuinfo
vmx
如果有输出 vmx 或者 svm，就说明当前的 CPU 支持 KVM。CPU 厂商 Intel 和 AMD 都支持虚拟化了，除非是非常老的 CPU。
一个 KVM 虚机在宿主机中其实是一个 qemu-kvm 进程，与其他 Linux 进程一样被调度。 比如在我的实验机上运行的虚机 kvm1 在宿主机中 ps 能看到相应的进程。
虚机中的每一个虚拟 vCPU 则对应 qemu-kvm 进程中的一个线程。看下图
在这个例子中，宿主机有两个物理 CPU，上面起了两个虚机 VM1 和 VM2。 VM1 有两个 vCPU，VM2 有 4 个 vCPU。可以看到 VM1 和 VM2 分别有两个和 4 个线程在两个物理 CPU 上调度。
这里也演示了另一个知识点，即虚机的 vCPU 总数可以超过物理 CPU 数量，这个叫 CPU overcommit（超配）。 KVM 允许 overcommit，这个特性使得虚机能够充分利用宿主机的 CPU 资源，但前提是在同一时刻，不是所有的虚机都满负荷运行。 当然，如果每个虚机都很忙，反而会影响整体性能，所以在使用 overcommit 的时候，需要对虚机的负载情况有所了解，需要测试。
内存虚拟化
KVM 通过内存虚拟化共享物理系统内存，动态分配给虚拟机。看下图
为了在一台机器上运行多个虚拟机，KVM 需要实现 VA（虚拟内存） -> PA（物理内存） -> MA（机器内存）直接的地址转换。虚机 OS 控制虚拟地址到客户内存物理地址的映射 （VA -> PA），但是虚机 OS 不能直接访问实际机器内存，因此 KVM 需要负责映射客户物理内存到实际机器内存 （PA -> MA）。具体的实现就不做过多介绍了，大家有兴趣可以查查资料。
还有一点提醒大家，内存也是可以 overcommit 的，即所有虚机的内存之和可以超过宿
KVM 存储虚拟化
KVM 的存储虚拟化是通过存储池（Storage Pool）和卷（Volume）来管理的。
Storage Pool 是宿主机上可以看到的一片存储空间，可以是多种类型，后面会详细讨论。Volume 是在 Storage Pool 中划分出的一块空间，宿主机将 Volume 分配给虚拟机，Volume 在虚拟机中看到的就是一块硬盘。
下面我们学习不同类型的 Storage Pool
目录类型的 Storage Pool
文件目录是最常用的 Storage Pool 类型。
KVM 将宿主机目录 /var/lib/libvirt/images/ 作为默认的 Storage Pool。
那么 Volume 是什么呢？
答案就是该目录下面的文件了，一个文件就是一个 Volume。
大家是否还记得我们之前创建第一个虚机 kvm1 的时候，就是将镜像文件 cirros-0.3.3-x8664-disk.img 放到了这个目录下。文件 cirros-0.3.3-x8664-disk.img 也就是Volume，对于 kvm1 来说，就是它的启动磁盘了。
那 KVM 是怎么知道要把 /var/lib/libvirt/images 这个目录当做默认 Storage Pool 的呢？ 实际上 KVM 所有可以使用的 Storage Pool 都定义在宿主机的 /etc/libvirt/storage 目录下，每个 Pool 一个 xml 文件，默认有一个 default.xml，其内容如下：
注意：Storage Pool 的类型是 “dir”，目录的路径就是 /var/lib/libvirt/images
下面我们为虚机 kvm1 添加一个新的磁盘，看看有什么变化。 在 virt-manager 中打开 kvm1 的配置页面，右键添加新硬件
在默认 Pool 中创建一个 8G 的卷。
点击 “Finish”，可以看到新磁盘的信息。
在 /var/lib/libvirt/images/ 下多了一个 8G 的文件 kvm1.img
root@ubuntu:~# ls -l /var/lib/libvirt/images/
total 14044
-rw-r--r-- 1 root root 14417920 Sep4 11:24 cirros-0.3.3-x86_64-disk.img
-rw------- 1 root root 8589934592 Sep4 21:39 kvm1.img
使用文件做 Volume 有很多优点：存储方便、移植性好、可复制、可远程访问。 前面几个优点都很好理解，这里对“可远程访问”多解释一下。
远程访问的意思是镜像文件不一定都放置到宿主机本地文件系统中，也可以存储在通过网络连接的远程文件系统，比如 NFS，或者是分布式文件系统中，比如 GlusterFS。
这样镜像文件就可以在多个宿主机之间共享，便于虚机在不同宿主机之间做 Live Migration；如果是分布式文件系统，多副本的特性还可以保证镜像文件的高可用。
KVM 支持多种 Volume 文件格式，在添加 Volume 时可以选择
raw 是默认格式，即原始磁盘镜像格式，移植性好，性能好，但大小固定，不能节省磁盘空间。
qcow2 是推荐使用的格式，cow 表示 copy on write，能够节省磁盘空间，支持 AES 加密，支持 zlib 压缩，支持多快照，功能很多。
vmdk 是 VMWare 的虚拟磁盘格式，也就是说 VMWare 虚机可以直接在 KVM上 运行。
LVM 类型的 Storage Pool
LVM 类型的 Storage Pool
不仅一个文件可以分配给客户机作为虚拟磁盘，宿主机上 VG 中的 LV 也可以作为虚拟磁盘分配给虚拟机使用。
不过，LV 由于没有磁盘的 MBR 引导记录，不能作为虚拟机的启动盘，只能作为数据盘使用。
这种配置下，宿主机上的 VG 就是一个 Storage Pool，VG 中的 LV 就是 Volume。 LV 的优点是有较好的性能；不足的地方是管理和移动性方面不如镜像文件，而且不能通过网络远程使用。
下面举个例子。
首先，在宿主机上创建了一个容量为 10G 的 VG，命名为 HostVG。
然后创建了一个 Storage Pool 的定义文件 /etc/libvirt/storage/HostVG.xml，内容为
然后通过 virsh 命令创建新的 Storage Pool “HostVG”
并启用这个 HostVG
现在我们可以在 virt-manager 中为虚机 kvm1 添加 LV 的虚拟磁盘了。
点击 Browse
可以看到 HostVG 已经在 Stroage Pool 的列表中了，选择 HostVG
为 volume 命名为 newlv 并设置大小 100MB
点击 Finish，newlv 创建成功
点击 Choose Volume
点击 Finish 确认将 newlv 作为 volume 添加到 kvm1
新 volume 添加成功 在宿主机上则多了一个命名为newlv的LV
其他类型的Storage Pool
KVM 还支持 iSCSI，Ceph 等多种类型的 Storage Pool，这里就不一一介绍了，最常用
页:
[1]