如何重新部署CloudStack云计算平台环境

很多玩过 CloudStack的童鞋，或多或少在刚刚入门 CloudStack的时候，对一个搭建环境需要做N多次的创建，删除才能最终运行好一个云环境，但是在这个过程中，如果遇到问题，找不出其他方法解决的话，很多新手暂时能够想到的就是重新创建环境，在这个过程中，有几项注意点需要提醒各位，否则即使重建好了环境，也会由于某些配置的残留而导致新的环境出现新的问题。

1 CloudStack + KVM

这样的组合其实就是两个RHEL6U3系统上面CloudStack-Management服务与CloudStack-Agent的合作，当然对于Agent而言，libvirt也是一个重要的组件嘛。假设就是一个管理节点，一个代理节点一般这样的组合搭建步骤如下：

管理节点：

(1)安装 *** 作系统

(2)配置YUM源，安装cloudstack-management ,mysql-server 组件

(3)初始化cloudstack的mysql数据库文件

(4)挂载二级存储，导入系统VM模板

(5)通过cloudstack-setup-management命令完成cloustack管理服务启动以及防火墙策略配置

代理节点：

(1)安装 *** 作系统

(2)配置YUM源，安装cloudstack-agent组件

(3)配置libvirt相关配置文件，/etc/libvirt/libvirtdconf以及/etc/sysconfig/libvirtd

配置完成之后，通过cloudstack管理节点的web界面登录

>

公司很多服务都泡在微软的HpyerV虚拟机上，现要逐步将其迁移到KVM上，国内网站很多都是针对vmware进行的迁移，很难发现针对HyperV做迁移的，其实步骤也差不多比较简单，下面说一下 *** 作步骤。

注意事项：如果有快照的话注意要将原来的虚拟机快照进行合并成一个vhd文件，也许有更好的方法保留快照，但我还没有研究透。

二、实施步骤

为了更好的说明，跑hyperV的源机器叫H，跑kvm的目标机器叫做K

1在H上将要迁移的的hyperV虚拟机的静态IP改成自动获取，然后关机，将vhd硬盘通过scp或者其他方式拷贝到目标机器K上。如果有快照，需要对快照进行合并整理，左后只有一个vhd硬盘文件。

2获取virtio的windows驱动该驱动主要用于windows的网卡和硬盘

cd /var/lib/libvirt/image

wget >

3在目标机器K上进行映像格式转换,并建立一个新的磁盘文件该磁盘文件主要用于windows通过识别新硬盘来安装新的virtio驱动，否则内置只有普通IDE驱动无法进行新的驱动安装

qemu-img convert -O qcow2 /root/hypervvhd /mnt/storage/kvmqcow2   #将vhd格式转换成qcow2格式

qemu-img create /mnt/storage/diskimg 1G                #建立一个新的磁盘

4使用virt-manager或virt-install进行镜像导入，并将驱动镜像放入cdrom建议使用virt-install

virt-install \

--name server \

--ram 512 \

--os-type=windows \

--vcpus 1 \

--disk path=/mnt/storage/kvmqcow2,device=disk,bus=ide,format=qcow2 \

--disk path=/mnt/storage/diskimg,format=qcow2,bus=virtio \

--disk path=/var/lib/libvirt/image/virt-win-01-81iso,device=cdrom \

--network bridge=br0,model=virtio \

--graphics vnc \

--noautoconsole \

--import \

--noreboot \

--debug

5启动虚拟机进入windows，通过cdrom里的镜像安装网卡和硬盘驱动安装过windows驱动的人应该都会的，装好后关闭虚拟机。

6通过virt-manager或者修改kvm虚拟机的/etc/libvirt/qemu/serverxml文件，将新建的磁盘删除，将原有的硬盘bus模式改成virtio，xml方式修改如下：

<disk type='block' device='disk'>

<driver name='server' type='qcow'/>

<source dev='/mnt/storage/kvmqcow2'/>

<target dev='vda' bus='virtio'/>

<address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>

</disk>

其实通过virt-manager会更方便一些

7启动虚拟机进行ip的配置，验证IP连通性，完成迁移。

1Linux是一套免费使用和自由传播的类Unix *** 作系统，是一个基于POSIX和UNIX的多用户、多任务、支持多线程和多CPU的 *** 作系统。Liinux中的virbr0是一个虚拟的网络连接端口，默认为0号虚拟网络连接端口，通过虚拟机进行移植 *** 作系统时，默认会以nat的网络地址转移，这时就用到了virbr0。

2virbr0的链式图如下：

3virbr0的使用过程：

（1）在 virt-manager 打开 VM1 的配置界面，网卡 Source device 选择 “default”，将 VM1 的网卡挂在 virbr0 上。

（2)启动 VM1，brctl show 可以查看到 vnet0 已经挂在了 virbr0 上。

(3)用 virsh 命令确认 vnet 就是 VM1 的虚拟网卡。

(4)virbr0 使用 dnsmasq 提供 DHCP 服务，可以在宿主机中查看该进程信息。

(5)在 /var/lib/libvirt/dnsmasq/ 目录下有一个 defaultleases 文件，当 VM1 成功获得 DHCP 的 IP 后，可以在该文件中查看到相应的信息。

(6)上面显示 1921681226 已经分配给 MAC 地址为 52:54:00:75:dd:1a 的网卡，这正是 vnet0 的 MAC。之后就可以使用该 IP 访问 VM1 了。

(7)Ping一下外网，可以访问外网，说明 NAT 起作用。

：

Linux是什么：

1Linux是一套免费使用和自由传播的类Unix *** 作系统，是一个基于POSIX和UNIX的多用户、多任务、支持多线程和多CPU的 *** 作系统。它能运行主要的UNIX工具软件、应用程序和网络协议。它支持32位和64位硬件。Linux继承了Unix以网络为核心的设计思想，是一个性能稳定的多用户网络 *** 作系统。

2Linux *** 作系统诞生于1991 年10 月5 日（这是第一次正式向外公布时间）。Linux存在着许多不同的Linux版本，但它们都使用了Linux内核。Linux可安装在各种计算机硬件设备中，比如手机、平板电脑、路由器、视频游戏控制台、台式计算机、大型机和超级计算机。

3严格来讲，Linux这个词本身只表示Linux内核，但实际上人们已经习惯了用Linux来形容整个基于Linux内核，并且使用GNU 工程各种工具和数据库的 *** 作系统。

Xen知识地图：

        Xen是由剑桥大学计算机实验室开发的一个开源项目，是一个开源的可直接运行于硬件层之上的虚拟化软件，它属于type-I型虚拟化系统，支持万贯虚拟化和超虚拟化，以高性能、占用资源少著称，赢得了IBM、AMD、HP、Red Hat和Novell等众多世界级软硬件厂商的高度认可和大力支持，已被国内外众多企事业用户用来搭建高性能的虚拟化平台。

        Xen仅对CPU和Memory直接接管，而其它IO硬件驱动则由其上运行的第一个虚拟机来提供支持，它能够在计算机硬件上并发的运行多个客户 *** 作系统（Guest OS）。支持x86、x86-64、安腾( Itanium)、Power PC和ARM多种处理器，因此Xen可以在大量的计算设备上运行，目前Xen支持Linux、NetBSD、FreeBSD、Solaris、 Windows和其他常用的 *** 作系统作为客户 *** 作系统在其管理程序上运行。

    Xen默认认为自己是直接运行于硬件层之上的虚拟化软件（即Xen Hypervisor层），并且可以直接驱动CPU和内存，需注意CPU和内存是所有想要运行的 *** 作系统必须能直接支持的，但Xen为保证自身的小巧，它并没有提供虚拟机的管理接口，因此它采用了一种独特的方式，先运行一台特权虚拟机（即Domain 0），且这台VM必须支持Kernel的修改，因此选择开源的Linux做为特权VM是最合适的，这样也可方便采用Linux所支持的方式来开发虚拟机管理接口，实现与Xen Hypervisor层直接交互来完成为VM分配CPU和内存资源及创建、删除、停止、启动VM的管理接口。通常这台特权虚拟机一定会采用当前比较流行的Linux发行版，因为它能支持更多IO硬件设备，如：网卡，磁盘，显卡，声卡等；到目前为止，NetBSD，GNU/Linux，FreeBSD和Plan 9，OpenSolaris等系统已经支持已半虚拟化方式运行在Xen的DomU中。目前Xen已经支持x86、x86_64和ARM等平台，并正在向IA64、PPC移植。移植到其他平台从技术上是可行的，未来有可能会实现。

        Xen虚拟机支持在不停止的情况下在多个物理主机之间实时迁移。在 *** 作过程中，虚拟机在没有停止工作的情况下内存被反复地复制到目标机器。虚拟机在最终目的地开始执行之前，会有一次60-300毫秒的非常短暂的暂停以执行最终的同步化，给人无缝迁移的感觉。类似的技术被用来暂停一台正在运行的虚拟机到磁盘，并切换到另外一台，第一台虚拟机在以后可以恢复。

如上图所示，Xen虚拟环境由三部分组件组成：

XEN Hypervisor

        Xen Hypervisor 是介于 *** 作系统和硬件之间的一个软件抽象层。它负责在各个虚拟机之间进行CPU调度和内存分配。Xen Hypervisor不仅抽象出虚拟机的硬件，同时还控制着各个虚拟机的执行。Xen Hypervisor不会处理网络、存储设备、视频以及其他 I/O。

Domain 0 Guest

        Domain 0是特权域，是一个修改过的Linux kernel，是唯一运行在 Xen Hypervisor之上的虚拟机，它拥有访问物理 I/O 资源的权限，同时和系统上运行的其他虚拟机（Domain U: PV and HVM Guest）进行交互。Domain 0需要在其它Domain启动之前启动。

        Domain 0 中有两个驱动 Network Backend Driver 和 Block Backend Driver，它们分别用来处理来自 Domain U 的网络和本地磁盘请求。 Network Backend Driver与本地网络硬件直接通信，以此来处理来自于Domain U所有虚拟机访问网络设备的请求；Block Backend Drive与本地存储设备进行通信，以此来处理来自于Domain U的磁盘数据读写的请求。

Domain U Guest(Dom U)

        Domain U没有直接访问物理硬件的权限（Domain U的"U"是来自于英文单词 unprivileged，是指没有权限的），但Domain 0有。

        运行在 Xen Hypervisor 上的所有半虚拟化（paravirtualized）虚拟机被称为“Domain U PV Guests”，其上运行着被修改过内核的 *** 作系统，如 Linux、Solaris、FreeBSD 等其它 UNIX *** 作系统。

        所有的全虚拟化虚拟机被称为“Domain U HVM Guests”，其上运行着不用修改内核的 *** 作系统，如 Windows 等。

        Domain U PV Guest 中也包括两个驱动“PV Network Driver”和“PV Block Driver”，它们分别也是用来处理发送网络和本地磁盘请求用的，这与 Domain 0 中的两个驱动是相对应的。

     Xen对虚拟机的虚拟化分为两大类，半虚拟化（Para virtualization）和完全虚拟化（Hardware VirtualMachine）。

       半虚拟化（Paravirtualization）有些资料称为“超虚拟化”，简称为PV，是Xen主导的虚拟化技术。这种技术允许虚拟机 *** 作系统感知到自己运行在Xen Hypervisor上而不是直接运行在硬件上，同时也可以识别出其他运行在相同环境中的客户虚拟机。

       在Xen Hypervisor上运行的半虚拟化的 *** 作系统，为了调用系统管理程序（Xen Hypervisor），要有选择地修改 *** 作系统，然而却不需要修改 *** 作系统上运行的应用程序。由于 Xen 需要修改 *** 作系统内核，所以您不能直接让当前的 Linux 内核在 Xen 系统管理程序中运行，除非它已经移植到了Xen 架构。不过，如果当前系统可以使用新的已经移植到 Xen 架构的Linux 内核，那么您就可以不加修改地运行现有的系统。

       完全虚拟化（Hardware Virtual Machine）又称“硬件虚拟化”，简称HVM，是指运行在虚拟环境上的虚拟机在运行过程中始终感觉自己是直接运行在硬件之上的，并且感知不到在相同硬件环境下运行着其他虚拟机的虚拟技术。此种虚拟化需要借助于Intel的VT-x 或 AMD的AMD-v 等硬件辅助虚拟化技术（详细技术原理参见151节）及Qemu的IO硬件模拟技术，才能支持GuestOS的kernel不修改,就可直接被DomU支持。

       在Xen Hypervisor运行的完全虚拟化虚拟机，所运行的 *** 作系统都是标准的 *** 作系统，即：无需任何修改的 *** 作系统版本。同时也需要提供特殊的硬件设备。

       值的注意的是，在Xen上虚拟的Windows虚拟机必须采用完全虚拟化技术。

       为了提高性能，完全虚拟化的Guests可以使用特殊的半虚拟设备驱动程序（PVHVM或PV-on-HVM驱动）。这些驱动程序在HVM环境下优化你的 PV驱动，模拟的磁盘和网络IO旁路运行，从而让你的PV在HVM中有更好的性能。这意味着你在用户窗口 *** 作方面可以得到最佳的性能。

       注意，Xen项目PV（半虚拟化）的Guest自动使用PV驱动，因此不需要这些驱动程序，因为你已经自动使用优化的驱动程序。PVHVM只会在HVM（全虚拟化）guest虚拟机中需要。

       Xen 的 VMM ( Xen Hypervisor ) 位于 *** 作系统和硬件之间，负责为上层运行的 *** 作系统内核提供虚拟化的硬件资源，负责管理和分配这些资源，并确保上层虚拟机（称为域 Domain）之间的相互隔离。Xen采用混合模式，因而设定了一个特权域用以辅助Xen管理其他的域，并提供虚拟的资源服务，该特权域称为Domain 0，而其余的域则称为Domain U。

       Xen向Domain提供了一个抽象层，其中包含了管理和虚拟硬件的API。Domain 0内部包含了真实的设备驱动（原生设备驱动），可直接访问物理硬件，负责与 Xen 提供的管理 API 交互，并通过用户模式下的管理工具来管理 Xen 的虚拟机环境。

       Xen20之后，引入了分离设备驱动模式。该模式在每个用户域中建立前端（front end）设备，在特权域(Dom0)中建立后端(back end)设备。所有的用户域 *** 作系统像使用普通设备一样向前端设备发送请求，而前端设备通过IO请求描述符(IO descripror ring)和设备通道（device channel）将这些请求以及用户域的身份信息发送到处于特权域中的后端设备。这种体系将控制信息传递和数据传递分开处理。

       在Xen体系结构设计中，后端设备运行的特权域被赋予一个特有的名字---隔离设备域(Isolation Device Domain, IDD)，而在实际设计中，IDD 就处在Dom0中。所有的真实硬件访问都由特权域的后端设备调用本地设备驱动 (native device driver)发起。前端设备的设计十分简单，只需要完成数据的转发 *** 作，由于它们不是真实的设备驱动程序，所以也不用进行请求调度 *** 作。而运行在IDD中的后端设备，可以利用Linux的现有设备驱动来完成硬件访问，需要增加的只是IO请求的桥接功能---能完成任务的分发和回送。

1）半虚拟化技术实现原理

       采用半虚拟化技术的虚拟机 *** 作系统能够识别到自己是运行在Xen Hypervisor而非直接运行于硬件之上，并且也可以识别到在相同的机器上运行的其他虚拟机系统。而且运行的 *** 作系统都需要进行相应的修改。

       半虚拟化客户机（Domain U PV Guests）包含两个用于 *** 作网络和磁盘的驱动程序，PV Network Driver 和PV Block Driver。

       PV Network Driver负责为Domain U提供网络访问功能。PV Block Driver负责为Domain U提供磁盘 *** 作功能。

2）完全虚拟化技术实现原理

       完全虚拟化客户机（Domain U HVM Guests）运行的是标准版本的 *** 作系统，因此其 *** 作系统中不存在半虚拟化驱动程序（PV Driver），但是在每个完全虚拟化客户机都会在Domain 0中存在一个特殊的精灵程序，称作：Qemu-DM，Qemu-DM帮助完全虚拟化客户机（Domain U HVM Guest）获取网络和磁盘的访问 *** 作。

       完全虚拟化客户机必须和在普通硬件环境下一样进行初始化，所以需要在其中加入一个特殊的软件Xen virtual firmware，来模拟 *** 作系统启动时所需要的BIOS。

       开源社区中将一系列的Linux精灵程序分类为“管理”和“控制”两大类。这些服务支撑着整个虚拟环境的管理和控制 *** 作，并且存在于Domain 0虚拟机中。

       下面将对直接服务进行详细的描述。

       注：为了清晰的描述Xen的运行流程，画图时将精灵程序放在Domain 0外部来描述，但事实上所有精灵程序都存在于Domain 0 之中。

1）Xend

       Xend精灵线程是一个Python应用程序，它作为Xen环境的系统管理员。它利用Libxenctrl类库向Xen Hypervisor发出请求。

       所有Xend处理的请求都是由XM工具使用XML RPC接口发送过来的。

2）Xm

       用于将用户输入通过XML RPC接口传递到Xend中的命令行工具。

3）Xenstored

       Xenstored精灵程序用于维护注册信息，这些信息包括内存和在连接Domain 0和所有其他Domain U之间的事件通道。Domain 0虚拟机利用这些注册信息来与系统中其他虚拟机建立设备通道，即帮助Domain U虚拟机访问硬件资源。

4）Libxenctrl

       Libxenctrl是C程序类库，用于让Xend具有通过Domain 0与Xen Hypervisor进行交互的能力。在Domain 0中存在一个特殊的驱动程序称作privcmd，它将请求发送给Hypervisor。

5）Qemu-DM

       在Xen环境下，每个完全虚拟化虚拟机都需要拥有自己的Qemu精灵程序。Qemu-DM处理在Xen环境下完全虚拟化客户机所能允许执行的所有关于网络 和磁盘请求和 *** 作。Qemu程序必须存在于Hypervisor之外同时又需要访问网络和I/O，所以Qemu-DM必须存在于Domain 0 中（参见前面章节对Domain 0 的描述）。

       未来版本的Xen中，一种新的工具Stub-DM将会提供一系列对所有完全虚拟化客户机都可用的服务，以此来替代需要在每个虚拟机上都生成一个Qemu的逻辑。

6）Xen Virtual Firmware

       Xen Virtual Firmware是被嵌入到所有完全虚拟化客户机中的虚拟BIOS系统，来确保所有客户 *** 作系统在正常启动 *** 作中接收到标准的启动指令集并提供标准的软件兼容环境。

       根据前几章节所述，Xen Hypervisor不负责处理网络和磁盘请求，因此半虚拟化客户机（Domain U PV）必须通过Domain 0 与Xen Hypervisor进行通信，从而完成网络和磁盘的 *** 作请求。下面以半虚拟化客户机（Domain U PV）执行向本地磁盘写入数据为例描述Domain 0与Domain U PV的交互过程。

       半虚拟化客户机（Domain U PV）的PV Block Driver接收到要向本地磁盘写入数据的请求，然后通过Xen Hypervisor将与Domain 0共享的本地内存中的数据写入到本地磁盘中。在Domain 0 和半虚拟化Domain U之间存在事件通道，这个通道允许它们之间通过存在于Xen Hypervisor内的异步中断来进行通信。Domain 0将会接收到一个来自于Xen Hypervisor的系统中断，并触发Domain 0中的Block Backend驱动程序去访问本地系统内容，并从与半虚拟化客户机的共享内存中读取适合的数据块。从共享内存中读取的数据随后被写入到本地磁盘的指定位置中。

     上图中所显示的事件通道是直接连接Domain 0 和Domain U PV是为了清晰和简单的描述系统是如何运行的。但事实上，事件通道（Event Channel）运行于Xen Hypervisor中，并在Xenstored中注册特定的系统中断，以此来让Domain 0 和Domain U PV能够通过本地内存快速的共享信息。

Xen在给VM提供CPU的虚拟化时，它采用的也是在Xen hypervisor层启动一个线程，并将这些线程映射到某个物理核心上，当然通过DomU的配置文件中的cpus可以指定将这些模拟CPU的线程绑定到某几个物理核心上；而内存的虚拟化则是内存页的映射，将物理内存上多个连续或不连续的内存页映射给VM，让VM看来这就是一个完整的连续的内存空间。

当启动一个用户VM(DomU)时，该VM所需的CPU和内存都由Xen Hypervisor提供，而它若需要使用IO设备时，则向特权VM(即Dom0)发起请求，特权VM会为该用户VM创建一个模拟的硬件设备线程，并运行于特权VM的用户空间，当用户VM向该IO硬件发起调用时，特权VM上相应的模拟设备接收请求并将其转化为特权VM对IO硬件的 *** 作，交给特权VM的内核来代为完成其 *** 作。这里需注意这些虚拟IO硬件需要由Qemu来模拟，Xen本身并没有提供相应的模拟功能。（注：特权VM的CPU和内存也是有Xen Hypervisor提供）

1）Qemu模拟IO设备(完全虚拟化方式)

Qemu模拟IO设备(完全虚拟化方式)：假如用户VM向特权VM请求磁盘，特权VM可以将一个分区、文件等，通过Qemu将其模拟成一个磁盘设备，就拿文件来说，特权VM先创建一个映像文件，再通过Qemu为该文件模拟一个磁盘控制器芯片；然后，将其映射到用户VM上，当然模拟的这个磁盘控制器芯片一定是一个最常见的，用户VM的Kernel一定支持的，但需注意：模拟的磁盘可能会与实际的物理磁盘不同，因为要尽可能兼容。这样一来用户VM假如要写数据到磁盘的过程如下：

用户VM-APP--->用户VM-Kernel调用虚拟磁盘的驱动进行写数据前的准备(如：数据写入到磁盘中的扇区位置/数据编码等)--->

用户VM-Kernel将编码后的信息发给特权VM的模拟磁盘进程--->

特权VM的模拟磁盘进程再将编号信息还原后发给特权VM-kernel--->

特权VM-kernel调用真实物理磁盘的驱动对数据进行写前准备--->最后磁盘驱动调度磁盘完成写入

摘录补充:（ >

以上就是关于如何重新部署CloudStack云计算平台环境全部的内容，包括:如何重新部署CloudStack云计算平台环境、怎么把hyperv迁移到kvm、linux virbr0是什么等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！