kvm虚拟化操作




本节演示如何使用 virt-manager 启动 KVM 虚机。

首先通过命令 virt-manager 启动图形界面

# virt-manager

点上面的图标创建虚机

给虚机命名为 kvm1,这里选择从哪里启动虚机。如果是安装新的 OS,可以选择第一项。如果已经有安装好的镜像文件,选最后一项(如上图)

接下来需要告诉 virt-manager 镜像的位置。

点击 “Browser”

在我的系统中存放了一个 cirros-0.3.3-x86_64-disk.img 镜像文件 。cirros 是一个很小的 linux 镜像,非常适合测试用,大家可以到 http://download.cirros-cloud.net/ 下载,然后放到 /var/lib/libvirt/images/ 目录下,这是 KVM 默认查找镜像文件的地方。

为虚拟机分配 CPU 和内存

点击 “Forward”, 再确认一下信息,就可以启动虚机了。

virt-manager 会打开虚机 kvm1 的控制台窗口,可以看到启动情况

virt-manager 可以对虚机进行各种管理操作,界面直观友好,很容易上手。 同时我们也可以用命令 virsh 管理虚机,比如查看宿主机上的虚机 

root@ubuntu :~# virsh list
Id    Name              State
--------------------------------
8     kvm1              running

至此,第一个虚机已经跑起来了,采用的都是默认设置,后面我们会逐步讨论有关虚机更细节的内容,比如存储和网卡的设置。


 

上一节我们通过 virt-manager 在本地主机上创建并管理 KVM 虚机。其实 virt-manager 也可以管理其他宿主机上的虚机。只需要简单的将宿主机添加进来

   

   填入宿主机的相关信息,确定即可。

   

   接下来,我们就可以像管理本地虚机一样去管理远程宿主机上的虚机了。

   

这里其实有一个要配置的地方。 因为 KVM(准确说是 Libvirt)默认不接受远程管理,需要按下面的内容配置被管理宿主机中的两个文件

/etc/default/libvirt-bin

start_libvirtd="yes"
libvirtd_opts="-d -l"  

/etc/libvirt/libvirtd.conf

listen_tls = 0
listen_tcp = 1
unix_sock_group = "libvirtd"
unix_sock_ro_perms = "0777"
unix_sock_rw_perms = "0770"
auth_unix_ro = "none"
auth_unix_rw = "none"
auth_tcp = "none"  

然后重启 Libvirtd 服务就可以远程管理了。

service libvirt-bin restart  

前面我们成功地把 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 的,即所有虚机的内存之和可以超过宿主机的物理内存。但使用时也需要充分测试,否则性能会受影响。

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,这里就不一一介绍了,最常用的就是目录类型,其他类型可以参考文档 http://libvirt.org/storage.html

原文地址:https://www.cnblogs.com/nongchaoer/p/6297575.html