Contents:
(3.1) understand the cgroup mechanism
(3.2) KVM environments restrictions on CPU resources
(3.3) KVM environment restrictions to network resources
(3.4) P2V
(3.5) V2V
(3.1) to understand the working mechanism cgroup
cgroup, its name derived from the control group (control groups) shorthand, is a function of the Linux kernel, used to limit, resource control and a separate process group (such as CPU, memory, disk input output, etc.). The project was first launched in 2006 by the Google engineers, the earliest name for the process container. In 2007, as in the Linux kernel, container (container) this term has many different meanings, in order to avoid confusion, is renamed cgroup, and is incorporated into the version of the kernel to 2.6.24. Since then, they add a lot of features. cgroup a design goal is to provide a unified interface to different applications, from process control to a single operating system level virtualization. cgroup provide:
resource constraints: the group can be set memory limit does not exceed the set, including virtual memory
priority: Some groups may get a lot of CPU or disk IO throughput
Settlement: does the system used to measure the amount of resources used the purpose of the appropriate
control: freeze or group checkpoint and restart
cgroup is a very important resource control mechanisms, sometimes we need to limit the CPU, the network restriction, memory or disk IO to limit, if not done limit it may be because of a program or process consume a lot of resources and cause the system to crash, this time we use cgroup resource management will be very effective.
(3.1.1) CPU controller in kerner tube was started by default, which allows the same amount of all the available CPU system service, and it contains nothing to do with the number of processes. This default setting can be used defaultControllers parameters /etc/systemd/system.conf configuration file to modify. To manage the allocation of CPU, using the configuration file units [-Service] section following commands: CPUShares = value, please use the number of CPU instead Share value. The default value is 1024, you can increase this value to allocate more CPU to the unit. Generally, we limit the CPU resources are mainly operated through the command line or by modifying the configuration file so in two ways. Now let's install the Apache service on vms002 host. 
(3.1.2) then we find by systemd-cgtop command at this time does not make any restrictions on the httpd service. Generally, we service startup script is placed in / usr / lib / systemd / system / httpd.service file in the directory. 
(3.1.3) and we need to set the property services, mainly through the command # systemctl set-property httpd.service CPUShares = 2048 to complete, and this time will be in the / etc / systemd / system / directory generate a directory of files on httpd.service. And will produce 90-CPUShares.conf information we file command line settings, when viewed through # systemd-cgtop command, it has also produced a line of information in httpd. 
(3.1.4) of CPU time and other resources constraints, only the resource constraints of time, this assignment will take effect when such resources are not strained when settings are invalid. We found that at this time vms002 host system is running in the CPU 2, then we enter the / sys / devices / system / cpu / directory see Numerical cpu1 / online is an ON state, we can cpu1 / online is set to 0 to disable Close
(3.1.5) Then we install the software on a cpuload vms002 host and copy the executable file cpuload two separate files cpuload1 and cpuload2. At the same time create cpuload1.service and cpuload2.service two custom service files and configuration files are copied to / usr / lib / systemd / system / directory. Custom service, custom service 
(3.1.6) in the system at this time we can see two service cpuload1.service and cpuload2.service, and are not activated state. We will start the two services together, this time # ps mo pid by the following command, comm, psr `pgrep cpuload`, you can see cpuload1 and cpuload2 are run on the No. 0 CPU. At this point we can find two cpuload resource usage of almost all the same services, you can use the command # systemd-cgtop viewed through the top command.
PS Mo pid #, COMM, PSR `pgrep cpuload`
# 1 Top -d 
(3.1.7) We then use the command line to cpuload1 resource constraints, this time in the etc / systemd / system / the / directory will be created a cpuload1.service.d directory. Then we use a modified configuration file way to create cpuload2.service.d, and change the value in 1024 will be 90-CPUShares.conf configuration file in the directory CPUShares cpuload2.service.d of 
(3.1.8) and then we will re service load it, then cpuload2 the service starts up, this time cpuload2 normal service has been running.
Systemctl-daemon reload #
# systemctl restart cpuload2.service
Status cpuload2 systemctl #
# top -d 1 
(3.1.9) In this case we found that the top command cpuload1 services CPU usage is basically twice the CPU usage cpuload2 service, consistent with the expectations we set. We also found that service has been largely cpuload1 CPU usage cpuload2 services twice by # systemd-cgtop command
# 1 Top -d
# systemd-cgtop 
(3.1.10) and then we managed to memory limitations, we install a memory tool testing memload, while creating a custom profile service memtest.service 1024M memory consumption under / usr / lib / systemd / system directory. Custom service, a custom service, custom service 
(3.1.11) we will start up memtest service, before and after this time will find the available memory is approximately less about 1024M 
(3.1.12) We then use to modify the configuration file of the way do to limit the operation of the memory resources, we entered into the / etc / systemd / system / directory, create a directory memtest.service.d, then create a configuration file 90-MemoryLimit.conf used memtest.service.d directory limiting maximum memory use 512M. 
(3.1.13) service is set 1024M memory consumption, but in fact after a cgroup resource constraints, we found that the system consumes only a 512M memory
(3.1.14) Then do we set limitations on CPU affinity, the so-called CPU affinity (affinity) is to specify which particular processes running on the CPU. Service httpd process under normal circumstances is (Figure 3-32) on the arbitrary will randomly run on the system CPU. Now suppose we have a system 4 core CPU, a plurality of services at this time if we have run, we specify the number 1 CPU can run Apache, No. 2 CPU running the Nginx, No. 3 CPU running MySQL, No. 4 CPU separately specify do not run any services, so that different services running on different CPU, this time if the MySQL service appeared abnormal, CPU usage has reached 100%, then only No. 3 CPU resource depletion will not affect other services running on the CPU, this time we will be able to use the No. 4 CPU management to do as an administrator, the administrator can log in to the normal processes in the system to kill off abnormal. 
(3.1.15) We at /etc/systemd/system/httpd.service.d directory, create a file resource limitations of 90-CPUAffinity.conf, use cgroup set the CPU affinity for resources in the configuration file to 0 the CPU 
(3.1.16) and then we will service all re-load it, and then restart the httpd service. After this time found httpd process through resource constraints, we have all run in the No. 0 CPU.
(3.2)KVM环境中对CPU资源的限制
(3.2.1)我们先在vms002主机的KVM环境中创建一个rhel7-1的虚拟机。发现这台rhel7-1虚拟机的线程是同时任意运行在当前vms002主机的0号和1号CPU上的。
# ps mo pid,lwp,comm,psr,args `pgrep qemu-kvm`
(3.2.2)我们可以在virt-manager的界面配置rhel7-1虚拟机的亲和性为1号CPU。此时rhel7-1虚拟机的所有进程都默认是在1号CPU上运行
# virsh edit rhel7-1
# ps mo pid,lwp,comm,psr,args `pgrep qemu-kvm`
(3.2.3)接着我们再创建一个虚拟机rhel7-2，并且设置rhel7-2虚拟机也是运行在1号CPU上，此时我们发现rhel7-1和rhel7-2两台虚拟机都运行在1号CPU上了。而且使用# top -d 1命令发现，两台虚拟机的CPU使用率基本是持平的。
# ps mo pid,lwp,comm,psr,args `pgrep qemu-kvm`
# top -d 1
(3.2.4)接着我们来调整KVM环境里两台虚拟机的CPU消耗的属性，我们先将两台虚拟机关机，然后再分别编辑rhel7-1和rhel7-2，通过命令# virsh edit rhel7-1对rhel7-1虚拟机进行设置，cputune表示调优，我们设置CPUShares的值为2048，设置rhel7-2虚拟机的CPUShares的值为1024
(3.2.5)接着我们将两台虚拟机关机后在重新开机启动，并执行# cat /dev/zero > /dev/null的命令，通过# top -d 1命令查询到rhel7-1虚拟机的CPU使用率基本是rhel7-2虚拟机使用率的2倍，使用# systemd-cgtop命令也基本可以看出两台虚拟机在0号CPU运行，且rhel7-1的使用率是rhel7-2的使用率的2倍
(3.3)KVM环境中对网络资源的限制
(3.3.1)注意：如果我们在vms002（192.168.26.102）主机上搭建了一个FTP服务，并且在/var/ftp目录下床架了一个dvd的目录，此时使用挂载将vms002主机上的光盘镜像挂载到/var/ftp/dvd目录上，此时如果在KVM环境中有一台虚拟机rhel7-1（192.168.122.65）主机，那么这个rhel7-1虚拟机是可以通过ftp://192.168.122.1/dvd 访问到光盘镜像的内容的。
(3.3.2)我们可以通过修改配置文件的方式对KVM环境中的虚拟机的网络资源进行限制。在rhel7-1（192.168.122.65）虚拟机上设置进流量和出流量最大都是128k，而rhel7-2（192.168.122.115）虚拟机不作任何的网络流量限制。
# virsh edit rhel7-1
(3.3.3)然后我们在vms002主机上创建一个200M的文件，并通过scp的方式拷贝到两台虚拟机，以便比较其传输速度的快慢。测试发现200M的文件拷贝到rhel7-2主机用了7秒，而将200M的文件拷贝到rhel7-1主机上至少用了7分钟，从而说明了我们的网络资源限制的配置生效了。
(3.4)P2V
(3.4.1)注意：如果出现了以下报错“状态 ：睡眠中，进程ID：3475”，可以通过执行如下的命令处理。
# rm -rf /var/run/yum.pid
(3.4.2)物理到虚拟，即Physical to virtual，简称P2V。它是指将操作系统、应用程序或者数据从计算机的物理硬盘中迁移到一个虚拟化环境中或是磁盘分区中。P2V可以手工创建或定义一个虚拟环境，并在此环境中安装操作系统、应用程序或者数据，这可能会是一个冗长或不确定的过程，尤其是在一个包含大量旧的硬件条件的新环境中。为了简化操作，会有一些支持全部或者部分虚拟化的自动软件工具，也就是我们所熟识的迁移工具。通常P2V就是创建虚拟的应用服务器环境，如在IBM服务器上搭建虚拟环境从而运行Windows系统。
(3.4.3)现在我们准备完成的P2V迁移的拓扑图如下所示，物理机被迁移的系统使用的是rhel7.1的版本，同时物理机需要使用virt-p2v-0.9.1-2.1.el6.centos.noarch镜像盘来引导，虚拟化环境的宿主机使用的是rhel6.6的系统，且在我们的虚拟化环境中需要安装virt-v2v软件。
(3.4.4)我们使用KVMhost（192.168.26.131）作为宿主机，安装rhel6.6的系统，然后使用TestRhel7作为被迁移的物理机，安装的是rhel7.1的系统。我们将virt-p2v-0.9.1-2.20130730.1.el6.centos.noarch.rpm软件放置到KVMhost宿主机上，并将virt-p2v使用rpm安装起来，随后我们便得到了一个virt-p2v-0.9.1-2.20130730.1.el6.centos.iso的镜像文件，这个文件我们将作为TestRhel7系统在被迁移时的引导盘。
(3.4.5)接着我们设置TestRhel7物理机在开机时，使用virt-p2v-0.9.1-2.20130730.1.el6.centos.iso这个引导盘进入系统。
(3.4.6)接着我们设置KVMhost主机，将rhel6.6的光盘镜像挂载到/mnt目录下，并且设置好aa.repo的YUM源。并在KVMhost主机的系统中将虚拟化的环境安装一下，同时将KVMhost主机的CPU虚拟化功能打开。
(3.4.7)由于需要打开图形化功能，所以我们需要保证KVMhost主机上的xorg-x11-xauth.x86_64这个软件包安装起来。配置完成后将系统重启一下即可。
(3.4.8)接着我们还要在KVMhost主机上安装virt-v2v软件，并在/etc/fstab文件中进行光盘自动挂载的配置（/dev/cdrom光盘镜像挂载到/mnt目录下）
/dev/cdrom /mnt iso9660 defaults,ro,loop 0 0
(3.4.9)接着我们在KVMhost主机上的/etc/virt-v2v.conf配置文件中进行配置，我们设置默认的存储storage生效，并设置默认的网络network生效，并将virt-manager打开
(3.4.10)接着我们将TestRhel7主机启动并使用光盘镜像引导，进入到了virt-p2v的界面，选择连接网络，然后输入KVMhost主机的IP地址和密码
(3.4.11)此时作为物理机的TestRhel7此时便已经迁移到了我们KVMhost主机的虚拟机上了，设置好网卡、硬盘、显示的相关协议后，由物理机迁移过来的虚拟机便可以正常的启动了。
(3.5)V2V
(3.5.1)V2V（Virtual-to-Virtual）迁移是在虚拟机之间移动操作系统和数据，照顾主机级别的差异和处理不同的虚拟硬件。虚拟机从一个物理机上的VMM迁移到另一个物理机的VMM，这两个VMM的类型可以相同，也可以不同。如VMware迁移到KVM，KVM迁移到KVM。可以通过多种方式将虚拟机从一个VM Host系统移动到另一个VM Host系统
(3.5.2)现在我们准备完成的V2V迁移的拓扑图如下所示，被迁移的虚拟机是vmware环境中的一台rhel7.1的虚拟机，虚拟化环境中使用的宿主机是rhel6.6的系统，其中rhel7.1的虚拟机是TestRhel7，rhel6.6主机是KVMhost。我们需要将TestRhel7作为虚拟机迁移到KVMhost宿主机中作为虚拟机运行。
注意：如果是要把物理机的Windows系统P2V到KVM里的话，不要忘记了要在Windows系统安装半虚拟化驱动
(3.5.2)其中vmdk文件是TestRhel7虚拟机的硬盘文件，vmx文件是TestRhel7虚拟机的配置文件，我们将这两个文件拷贝到KVMhost宿主机中
(3.5.3)首先我们要将vmware的硬盘文件转换成KVM所能读取的硬盘格式。
# qemu-img convert -O qcow2 -f vmdk TestRhel7.vmdk TestRhel7.qcow2
(3.5.4) Since the format of the configuration file is vmware virtual machine format, one per line text entry, and configuration file formats KVM virtual machine is xml format, two configuration files are not common, so we need to vmware configuration KVM can convert files to read the configuration file, we use the virt-goodies_0.4.tar.gz software, find vmware2libvirt executable file and generate TestRhel7.xml file.
Note: failure troubleshooting, TestRhel7.xml and TestRhel7.vmdk need to be in the same folder and then execute the conversion operation xml file
# ./vmware2libvirt -f /root/TestRhel7.vmx> /root/TestRhel7.xml 
(3.5 .5) modify the name v_TestRhel7, the simulator will modify the value of / usr / libexec / qemu-kvm , while the need to set the disk storage format vda, and a hard disk location / var / lib / libvirt / images / TestRhel7 .qcow2 
(3.5.6) TestRhel7.xml then copy the configuration file to / etc / libvirt / qemu directory, copy TestRhel7.qcow2 hard disk files to the storage pool, and then create a migration to KVMhost host virtual machine v_TestRhel7
# virsh the DEFINE TestRhel7.xml --- here refers to the file name
# virsh start v_TestRhel7 --- here refers to the name of the virtual machine 
(3.5.7) and change v_TestRhel7 virtual machine's hard disk format to format qcow2 and then start the virtual machine, the virtual machine will be able to normal at this time of the start.
------ This concludes the article, thanks for reading ------