精华内容
参与话题
问答
  • Xen基本原理

    千次阅读 2014-05-18 16:31:25
    Xen概述 1.1 简介  Xen是由剑桥大学计算机实验室开发的一个开源项目。是一个直接运行在计算机硬件之上的用以替代操作系统的软件层,它能够在计算机硬件上并发的运行多个客户操作系统(Guest OS)。...

    1   Xen概述


    1.1    简介

         Xen是由剑桥大学计算机实验室开发的一个开源项目。是一个直接运行在计算机硬件之上的用以替代操作系统的软件层,它能够在计算机硬件上并发的运行多个客户操作系统(Guest OS)。目前已经在开源社区中得到了极大的推动。

           Xen支持x86x86-64、安腾( Itanium)Power PCARM多种处理器,因此Xen可以在大量的计算设备上运行,目前Xen支持LinuxNetBSDFreeBSDSolarisWindows和其他常用的操作系统作为客户操作系统在其管理程序上运行。

    1.2   Xen虚拟化类型

           Xen对虚拟机的虚拟化分为两大类,半虚拟化(Paravirtualization)和完全虚拟化(Hardware VirtualMachine)。


    1.2.1    半虚拟化

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

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

                      半虚拟化虚拟机示意图

    1.2.2  完全虚拟化

           完全虚拟化(Hardware Virtual Machine)又称“硬件虚拟化”,简称HVM,是指运行在虚拟环境上的虚拟机在运行过程中始终感觉自己是直接运行在硬件之上的,并且感知不到在相同硬件环境下运行着其他虚拟机的虚拟技术。

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

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

    1.3   基本组件

           Xen包含三大部分:

    Xen Hypervisor:直接运行于硬件之上是Xen客户操作系统与硬件资源之间的访问接口(如:)。通过将客户操作系统与硬件进行分类,Xen管理系统可以允许客户操作系统安全,独立的运行在相同硬件环境之上。

    Domain 0运行在Xen管理程序之上,具有直接访问硬件和管理其他客户操作系统的特权的客户操作系统。

    DomainU运行在Xen管理程序之上的普通客户操作系统或业务操作系统,不能直接访问硬件资源(如:内存,硬盘等),但可以独立并行的存在多个。

                                            Xen组件结构图

    1.3.1   Xen Hypervisor

           Xen Hypervisor是直接运行在硬件与所有操作系统之间的基本软件层。它负责为运行在硬件设备上的不同种类的虚拟机(不同操作系统)进行CPU调度和内存分配。Xen Hypervisor对虚拟机来说不单单是硬件的抽象接口,同时也控制虚拟机的执行,让他们之间共享通用的处理环境。

           Xen Hypervisor不负责处理诸如网络、外部存储设备、视频或其他通用的I/O处理。

    1.3.2   Domain 0

           Domain 0 是经过修改的Linux内核,是运行在Xen Hypervisor之上独一无二的虚拟机,拥有访问物理I/O资源的特权,并且可以与其他运行在Xen Hypervisor之上的其他虚拟机进行交互。所有的Xen虚拟环境都需要先运行Domain 0,然后才能运行其他的虚拟客户机。

           Domain 0 Xen中担任管理员的角色,它负责管理其他虚拟客户机。

           Domain 0中包含两个驱动程序,用于支持其他客户虚拟机对于网络和硬盘的访问请求。这两个驱动分别是Network Backend DriverBlock Backend Driver

           Network Backend Driver直接与本地的网络硬件进行通信,用于处理来自Domain U客户机的所有关于网络的虚拟机请求。根据Domain U发出的请求Block Backend Driver直接与本地的存储设备进行通信然后,将数据读写到存储设备上。

                        Domain 0虚拟机

    1.3.3   Domain U

           Domain U客户虚拟机没有直接访问物理硬件的权限。所有在Xen Hypervisor上运行的半虚拟化客户虚拟机(简称:Domain U PV Guests)都是被修改过的基于Linux的操作系统、SolarisFreeBSD和其他基于UNIX的操作系统。所有完全虚拟化客户虚拟机(简称:Domain U HVM Guests)则是标准的Windows和其他任何一种未被修改过的操作系统。

           无论是半虚拟化Domain U还是完全虚拟化Domain U,作为客户虚拟机系统,Domain UXen Hypervisor上运行并行的存在多个,他们之间相互独立,每个Domain U都拥有自己所能操作的虚拟资源(如:内存,磁盘等)。而且允许单独一个Domain U进行重启和关机操作而不影响其他Domain U

                                          Xen虚拟化示意图

    2   Xen基本体系架构及运行原理

    2.1.1  Xen体系架构

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

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

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

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

                                                        Xen 的体系架构

    2.1.2  不同虚拟技术的运行机制

    半虚拟化技术:

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

         半虚拟化客户机(Domain U PV Guests)包含两个用于操作网络和磁盘的驱动程序,PV Network Driver PV Block Driver

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

                         半虚拟化客户机

    完全虚拟化技术:

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

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

                                                完全虚拟化客户机

    2.1.3  Domain 管理和控制

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

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

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

    2.1.3.1   Xend

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

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

                                                               Xend运行示意图

    2.1.3.2   Xm

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

    2.1.3.3   Xenstored

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

    2.1.3.4   Libxenctrl

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

                                                            Libxenctrl示意图

    2.1.3.5   Qemu-DM

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

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

    2.1.3.6   Xen Virtual Firmware

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

    2.1.4   半虚拟化环境下Domain 0Domain U通信

           根据前几章节所述,Xen Hypervisor不负责处理网络和磁盘请求,因此半虚拟化客户机(Domain U PV)必须通过Domain 0 Xen Hypervisor进行通信,从而完成网络和磁盘的操作请求。下面以半虚拟化客户机(Domain U PV)执行向本地磁盘写入数据为例描述Domain 0Domain 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 U PV执行磁盘操作实例

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

                                                          Domain 0与Domain U PV启动交互图

    3   Xen的网络架构

    3.1    Xen支持三种网络工作模式

    1.       Bridge 安装虚拟机时默认使用 Bridge模式

    2.       Route

    3.       NAT

    各工作模式下虚拟机启动流程:

    Bridge模式

    Xend启动时流程:

    1)  创建虚拟网桥 xenbr0

    2)  停止物理网卡 eth0

    3)  物理网卡 eth0  MAC 地址和 IP 地址被复制到虚拟网卡 veth0

    4)  物理网卡 eth0 重命名为 peth0

    5)  Veth0 重命名为 eth0

    6)  Peth0  MAC 地址更改( FE:FF:FF:FF:FF:FF ),ARP 功能关闭。

    7)  连接 peth0vif0.0 到网桥 xenbr0

    8)  启动 peth0vif0.0xenbr0

    Domain U 启动时的流程:

    1)  vif<domainID>.0 连接到 xenbr0

    2)  启动vif<domainID>.0

    Route 模式

    Xend启动时的流程:

    1)  开启Domain 0IP Forward

    Domain U启动时的流程:

    1)  创建 vif<domainID>.0 dom U eth0IP地址被拷贝到vif<domainID>

    2)  启动 vif<domainID>.0

    3)  domU的配置文件中指向虚拟接口vif.0分配的IP地址增加静态路由。

    NAT模式

    NAT 模式会使用虚拟局域网 virbr0

    3.2    Xen Domain U Guests 发送数据包处理流程

                                         Xen Domain U Guests发送数据包处理流程

    3.3    Xen中虚拟网卡与物理网卡之间的关系

    安装了XenLinux机器,在Dom 0中能看到以下几类网卡(网络接口设备 ):

    (X ,Y都为数字)

    pethY

    ethY

    xenbrY

    virbrY

    vifX.YXDomaiIDY表示该虚拟网卡是该Domain的第几块虚拟网卡)

    vethY (一般在Xend启动完成以后就不存在了)

    展开全文
  • XEN简介

    千次阅读 2018-11-09 22:42:44
    一、 xen概述 Xen是由剑桥大学计算机实验室开发的一个开源项目。是一个直接运行在计算机硬件之上的用以替代操作系统的软件层,它能够在计算机硬件上并发的运行多个客户操作系统(Guest OS)。目前Xen支持Linux、...

    一、 xen概述

    Xen是由剑桥大学计算机实验室开发的一个开源项目。是一个直接运行在计算机硬件之上的用以替代操作系统的软件层,它能够在计算机硬件上并发的运行多个客户操作系统(Guest OS)。目前Xen支持Linux、NetBSD、FreeBSD、Solaris、 Windows和其他常用的操作系统作为客户操作系统在其管理程序上运行。

    二、Xen基本组件

    • Xen Hypervisor:直接运行于硬件之上是Xen客户操作系统与硬件资源之间的访问接口(如:)。通过将客户操作系统与硬件进行分类,Xen管理系统可以允许客户操作系统安全,独立的运行在相同硬件环境之上。

    • Domain 0:运行在Xen管理程序之上,具有直接访问硬件和管理其他客户操作系统的特权的客户操作系统。

    • DomainU:运行在Xen管理程序之上的普通客户操作系统或业务操作系统,不能直接访问硬件资源(如:内存,硬盘等),但可以独立并行的存在多个。

                                                     wKioL1Z4wP6zG5XZAABoXq8aIq0613.png

    1、Xen Hypervisor

        Xen Hypervisor是直接运行在硬件与所有操作系统之间的基本软件层。它负责为运行在硬件设备上的不同种类的虚拟机(不同操作系统)进行CPU调度和内 存分配。Xen Hypervisor对虚拟机来说不单单是硬件的抽象接口,同时也控制虚拟机的执行,让他们之间共享通用的处理环境。

        Xen Hypervisor不负责处理诸如网络、外部存储设备、视频或其他通用的I/O处理。

    2、Domain 0

     Domain 0 是经过修改的Linux内核,是运行在Xen Hypervisor之上独一无二的虚拟机,拥有访问物理I/O资源的特权,并且可以与其他运行在Xen Hypervisor之上的其他虚拟机进行交互。所有的Xen虚拟环境都需要先运行Domain 0,然后才能运行其他的虚拟客户机。

         Domain 0 在Xen中担任管理员的角色,它负责管理其他虚拟客户机。

         在Domain 0中包含两个驱动程序,用于支持其他客户虚拟机对于网络和硬盘的访问请求。这两个驱动分别是Network Backend Driver和Block Backend Driver。  Network Backend Driver直接与本地的网络硬件进行通信,用于处理来自Domain U客户机的所有关于网络的虚拟机请求。根据Domain U发出的请求Block Backend Driver直接与本地的存储设备进行通信然后将数据读写到存储设备上。

    wKiom1aEnXrABiIsAACoGvcrjlU684.jpg

    3、Domain U

     Domain U客户虚拟机没有直接访问物理硬件的权限。所有在Xen Hypervisor上运行的半虚拟化客户虚拟机(简称:Domain U PV Guests)都是被修改过的基于Linux的操作系统、Solaris、FreeBSD和其他基于UNIX的操作系统。所有完全虚拟化客户虚拟机(简 称:Domain U HVM Guests)则是标准的Windows和其他任何一种未被修改过的操作系统。

    无论是半虚拟化Domain U还是完全虚拟化Domain U,作为客户虚拟机系统,Domain U在Xen Hypervisor上运行并行的存在多个,他们之间相互独立,每个Domain U都拥有自己所能操作的虚拟资源(如:内存,磁盘等)。而且允许单独一个Domain U进行重启和关机操作而不影响其他Domain U。

                                                      wKiom1Z4wU2xJVPyAAF8T1xvdn4339.png

     

    三、xen虚拟化类型

    Xen对虚拟机的虚拟化分为两大类,半虚拟化(Para virtualization)和完全虚拟化(Hardware VirtualMachine)。

    1、半虚拟化(PV)

    半虚拟化(Paravirtualization)简称为PV,是Xen主导的虚拟化技术。

    这种技术允许虚拟机操作系统感知到 自己运行在Xen 管理程序上而不是直接运行在硬件上,同时也可以识别出其他运行在相同环境中的客户虚拟机。

    wKiom1Z4wHeRyg0YAADxLwu77E4551.jpg

    2、完全虚拟化(HVM)

        完全虚拟化(Hardware Virtual Machine)又称“硬件虚拟化”,简称HVM,是指运行在虚拟环境上的虚拟机在运行过程中始终感觉自己是直接运行在硬件之上的,并且感知不到在相同硬件环境下运行着其他虚拟机的虚拟技术。

    wKioL1aFTAvyN4lWAAJrZzsLU0k578.png

    四、Xen基本体系架构及运行原理

    1、Xen体系架构

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

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

    展开全文
  • XEN 与 VMware ESXi,Hyper-V 以及 KVM 特点比较:XEN 有简化虚拟模式,不需要设备驱动,能够保证每个虚拟用户系统相互独立,依赖于 service domains 来完成一些功能;Vmware ESXI 与 XEN 比较类似,包含设备驱动...

    XEN 与 VMware ESXi,Hyper-V 以及 KVM 特点比较:

    XEN 有简化虚拟模式,不需要设备驱动,能够保证每个虚拟用户系统相互独立,依赖于 service domains 来完成一些功能;

    Vmware ESXI 与 XEN 比较类似,包含设备驱动以及管理栈等基本要素,硬件支持依赖于 VMware 创建的驱动;

    Hyper-V 是基于 XEN 管理栈的修改;

    KVM 与 XEN 方式不同,KVM 是以 Linux 内核作为管理工具得。

    虚拟机的体系结构

    XEN 体系结构


    图 3. XEN 体系结构图
    图 3. XEN 体系结构图

    一个 XEN 虚拟机环境主要由以下几部分组成:

    XEN Hypervisor;

    Domain 0 —— Domain Management and Control(XEN DM&C);

    Domain U Guest(Dom U)

    下图 4 显示除了各部分之间的关系:


    图 4. Xen 三部分组成之间关系图
    图 4. Xen 三部分组成之间关系图

    XEN Hypervisor :

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

    Domain 0:

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

    Domain U:

    运行在 Xen Hypervisor 上的所有半虚拟化(paravirtualized)虚拟机被称为“Domain U PV Guests”,其上运行着被修改过内核的操作系统,如 Linux、Solaris、FreeBSD 等其它 UNIX 操作系统。所有的全虚拟化虚拟机被称为“Domain U HVM Guests”,其上运行着不用修改内核的操作系统,如 Windows 等。

    2.Hyper-V 体系结构


    图 5. Hyper-V 体系结构图
    图 5. Hyper-V 体系结构图

    Hyper-V 是微软提出的一种系统管理程序虚拟化技术,采用微内核的架构,兼顾了安全性和性能的要求。Hyper-V 底层的 Hypervisor 运行在最高的特权级别下,微软将其称为 ring -1(而 Intel 则将其称为 root mode),而虚机的 OS 内核和驱动运行在 ring 0,应用程序运行在 ring 3 下,这种架构就不需要采用复杂的 BT(二进制特权指令翻译)技术,可以进一步提高安全性。从架构上讲 Hyper-V 只有“硬件-Hyper-V-虚拟机”三层,本身非常小巧,代码简单,且不包含任何第三方驱动,所以安全可靠、执行效率高,能充分利用硬件资源,使虚拟机系统性能更接近真实系统性能。

    Hyper-V 支持分区层面的隔离。分区是逻辑隔离单位,受虚拟机监控程序支持,并且操作系统在其中执行。Microsoft 虚拟机监控程序必须至少有一个父 / 根分区,用于运行 64 位版本的 Windows Server 2008 操作系统。虚拟化堆栈在父分区中运行,并且可以直接访问硬件设备。随后,根分区会创建子分区用于承载来宾操作系统。根分区使用虚拟化调用应用程序编程接口 (API) 来创建子分区。

    分区对物理处理器没有访问权限,也不能处理处理器中断。相反,它们具有处理器的虚拟视图,并运行于每个来宾分区专用的虚拟内存地址区域。虚拟机监控程序负责处理处理器中断,并将其重定向到相应的分区。Hyper-V 还可以通过输入输出内存管理单元 (IOMMU) 利用硬件加速来加快各个来宾虚拟地址空间相互之间的地址转换。IOMMU 独立于 CPU 使用的内存管理硬件运行,并用于将物理内存地址重新映射到子分区使用的地址。从系统的结构图,我们可以看出来 Hyper-V 与 Xen 的架构很相似。


    图 6. Vmware ESXI 体系结构图
    图 6. Vmware ESXI 体系结构图

    由上图我们可以看出来管理工具也是直接嵌入到了 ESXi vmKernel 中,没有再分化出单独的管理工具,这一点与 Xen 是相区别的。


    图 7. KVM 体系结构图
    图 7. KVM 体系结构图

    KVM 是一个独特的管理程序,通过将 KVM 作为一个内核模块实现,在虚拟环境下 Linux 内核集成管理程序将其作为一个可加载的模块可以简化管理和提升性能。在这种模式下,每个虚拟机都是一个常规的 Linux 进程,通过 Linux 调度程序进行调度。

    通过以上四种虚拟机的体系结构图,我们可以看出他们在整个系统中的位置,以及相互之间的区别。

    回页首

    XEN 工作原理

    上面我们针对 Xen 的体系结构进行了简单的描述,我们知道 Xen 主要由 Xen Hypervisor,Domain0,DomainU 三部分组成。下面通过 Domain 0 与 Domain U 的通信以及这三部分的交互来探讨一下 Xen 的工作原理。

    之前我们已经提到过 Domain U 分为 PV 客户系统和 HVM 客户系统两种,我们首先讨论一下 PV 客户系统,也就是半虚拟化操作系统工作原理。

    首先我们需要知道在 Domain 0 中有两个驱动 Network Backend Driver 和 Block Backend Driver,它们分别用来处理来自 Domain U 的网络和本地磁盘请求。由于 Xen Hypervisor 不会支持网络和磁盘请求的,因此一个 PV(半虚拟化)客户系统必须通过和 Xen Hypervisor、Domain 0 通信,从而来实现网络和磁盘请求。由于 Xen 文档中已经探讨过 PV 客户系统如何将一个数据写到本地硬盘,下面我们就来讨论一下 PV 客户系统如何将一个数据发送到网络中去。在这之前我们首先要了解到一点,那就是 Domain U PV Guest 中也包括两个驱动“PV Network Driver”和“PV Block Driver”,它们分别也是用来处理发送网络和本地磁盘请求用的,这与 Domain 0 中的两个驱动是相对应的。

    当一个 PV 客户系统的网络设备驱动程序接收到一个发送数据请求的时候,并且通过 Xen Hypervisor 发送数据到本地网络设备(网卡之类的设备)中,这个网络设备是和 Domain 0 共享的。在 Domain 0 和 Domain U 之间存在一个事件通道(event channel),通过该通道二者进行异步的域间中断通信。Domain 0 会接收到一个来自 Xen Hypervisor 的中断,触发 PV Network Backend Driver 访问上述网络设备,读取来自 PV 客户系统的数据,然后将这些数据发送出去。

    下图中事件通道表示为连接 Domain 0 与 Domain U 的一个区域,这是系统工作流的一个简化。事实上事件通道运行在 Xen Hypervisor 中,通过 Xenstored(Xenstored 维护一个信息档案,包括内存和建立在 Domain 0 与 Domain U 之间的事件通道。Domain 0 通过改变这个档案来设置和其他虚拟机的设备通道)中的特定中断实现,提供 Domain 0 与 Domain U 之间的快速共享网络设备,见图 8。


    图 8. Domain 0 与 Domain U PV Guest 通信示意图
    图 8. Domain 0 与 Domain U PV Guest 通信示意图

    上面我们已经分析了 PV 客户系统的工作原理,下面我们再简要的介绍一下 HVM 客户系统的工作原理。

    由于一个 HVM Guests 虚拟机中没有上面提到得 PV driver,所以 Xen 在 Domain 0 中为每一个 HVM Guest 都启动一个守护进程 Qemu-dm 处理来自客户系统的网络和磁盘请求,所以当一个 HVM Guest 有相应的网络和 I/O 请求的时候,它就会直接与 Domain0 中和它相对应的 Qemu-dm 来进行交互,通过 Domain 0 最终达到访问网络设备或者磁盘的目的。见下图 9:


    图 9. Domain 0 与 Domain U HVM Guest 通信示意图
    图 9. Domain 0 与 Domain U HVM Guest 通信示意图

    结束语

    通过这一部分的介绍,我们了解了 Xen 目前的发展及现状,另外我们详细的说明了如何在 Fedora13 下安装 Xen,以及 Xen 下一些基本操作,再这之后我们又讨论了一下 Xen 与 VMware ESXi,Hyper-V 以及 KVM 异同点,最后我们通过示例来讲解了一下 Xen 的工作原理。本系列的第二部分我们将阐述如何搭建 Xen 的开发环境、Xen 下开发需要具备的相关技术以及 Xen 下的如何利用 XenAPI 做开发,最后通过一个例子来演示。

    出处:https://www.server110.com/xen/201404/10378.html

    https://wenku.baidu.com/view/548ccc46bb1aa8114431b90d6c85ec3a87c28bf5.html

    展开全文
  • Xen 安装与配置

    2019-11-13 17:04:57
    Xen 安装与配置 Xen 分为 Xen Hypervisor、Dom 0 和 Dom U。针对 Xen Hypervisor 需要提供引导配置,针对 Dom U 需要提供虚拟机配置。 安装 在 ArchLinux/Manjaro 上通过 yaourt 进行安装。 yaourt -S xen ...

    Xen 安装与配置

    Xen 分为 Xen Hypervisor、Dom 0 和 Dom U。针对 Xen Hypervisor 需要提供引导配置,针对 Dom U 需要提供虚拟机配置。

    安装

    在 ArchLinux/Manjaro 上通过 yaourt 进行安装。

    yaourt -S xen
    

    提示需要 83FE14C957E82BD9 密钥:

    # 注意不要加 sudo,因为 root 和每个普通账户的密钥是分别存储的
    gpg --recv-keys 83FE14C957E82BD9
    gpg --lsign-key 83FE14C957E82BD9
    gpg --finger 83FE14C957E82BD9
    

    还需要装一些额外的软件包:

    pacman -S seabios ovmf mesa bluez-libs
    

    Grub 引导配置

    Grub 参考引导配置文件

    在 ArchLinux/Manjaro 上安装完 Xen 后,在 /etc/grub.d/09_xen 为 Xen Hypervisor 的参考引导配置文件(基于 Grub),内容如下:

    #!/usr/bin/env bash
    
    ##
    ## grub-mkconfig helper script specific to Arch Linux
    ## Contributed by "Keshav Amburay" <the ddoott ridikulus ddoott rat aatt geemmayil ddoott ccoomm>
    ## Updated on 08 February 2014
    ##
    ## Script based on do_grub_config() function in Arch Linux Archboot ISO Installer/Setup script
    ## Some parts taken from /etc/grub.d/10_linux script shipped by GRUB(2) upstream
    ##
    ## This script can be freely distributed and/or modified
    ## under the terms of the GNU General Public License as published by
    ## the Free Software Foundation, either version 3 of the License, or
    ## (at your option) any later version.
    ##
    ## This script is distributed in the hope that it will be useful,
    ## but WITHOUT ANY WARRANTY; without even the implied warranty of
    ## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
    ## GNU General Public License for more details.
    ##
    
    ## Adapted for use with the xen AUR package, to ensure feature comparity
    ## Modified by "David Sutton" <kantras - gmail com>
    
    _FUNC_GRUB_FILE_PRESENT() {
    
        [[ -z "${GRUB_PLATFORM}" ]] && GRUB_PLATFORM="x86"
    
        if [[ "${GRUB_PLATFORM}" == "x86" ]]; then
            check="--is-x86-linux32"
        elif [[ "${GRUB_PLATFORM}" == "i386-xen-pae" ]]; then
            check="--is-i386-xen-pae-domu"
        elif [[ "${GRUB_PLATFORM}" == "x86_64-xen" ]]; then
            check="--is-x86_64-xen-domu"
        else
            check="--is-${GRUB_PLATFORM}-linux"
        fi
    
        case "${GRUB_PLATFORM}" in
            x86)
                list="$(for i in "${GRUB_ROOT}"/boot/vmlinuz-linux* ; do
                            if grub_file_is_not_garbage "${i}" && "${grub_file}" ${check} "${i}" ; then echo -n "${i} " ; fi
                        done)" ;;
            *)
              list="$(for i in "${GRUB_ROOT}"/boot/vmlinuz-linux* ; do
                          if grub_file_is_not_garbage "${i}" && "${grub_file}" ${check} "${i}" ; then echo -n "${i} " ; fi
                      done)" ;;
        esac
    }
    
    set -e
    
    prefix="/usr"
    exec_prefix="${prefix}"
    datarootdir="/usr/share"
    datadir="${datarootdir}"
    sysconfdir="/etc"
    
    . "${datarootdir}/grub/grub-mkconfig_lib"
    
    . "${sysconfdir}/default/grub"
    
    export XEN_HYPERVISOR_CMDLINE="xsave=1"
    export XEN_LINUX_CMDLINE="console=tty0"
    
    [[ -r "${sysconfdir}/xen/grub.conf" ]] && . "${sysconfdir}/xen/grub.conf"
    
    [[ -z "${XEN_LINUX_CMDLINE_OVERRIDE}" ]] && XEN_LINUX_CMDLINE_OVERRIDE="0"
    
    export TEXTDOMAIN="grub"
    export TEXTDOMAINDIR="${datarootdir}/locale"
    
    CLASS="--class xen --class arch-linux --class arch --class gnu-linux --class gnu --class os"
    
    [[ "${grub_file}" != "" ]] && _FUNC_GRUB_FILE_PRESENT
    
    BOOT_PART_FS_UUID="$(${grub_probe} --target="fs_uuid" "/boot" 2>/dev/null)"
    BOOT_PART_HINTS_STRING="$(${grub_probe} --target="hints_string" "/boot" 2>/dev/null || true)"
    BOOT_PART_FS="$(${grub_probe} --target="fs" "/boot" 2>/dev/null)"
    
    ROOT_PART_GRUB_DEVICE="$(${grub_probe} --target=device / || true)"
    ROOT_PART_FS="$(${grub_probe} --device ${ROOT_PART_GRUB_DEVICE} --target=fs 2> /dev/null || echo "unknown")"
    
    if [[ "${GRUB_LINUX_ROOT_DEVICE}" == "" ]]; then
    
        case "${ROOT_PART_FS}" in
            btrfs)
                rootsubvol="$(make_system_path_relative_to_its_root /)"
                rootsubvol="${rootsubvol#/}"
                if [[ "${rootsubvol}" != "" ]]; then
                    GRUB_LINUX_ROOT_DEVICE="subvol=${rootsubvol}"
                fi
            ;;
            zfs)
                rpool="$(${grub_probe} --device ${GRUB_DEVICE} --target=fs_label 2>/dev/null || true)"
                bootfs="$(make_system_path_relative_to_its_root / | sed -e "s,@$,,")"
                GRUB_LINUX_ROOT_DEVICE="ZFS=${rpool}${bootfs}"
            ;;
        esac
    
        if [[ "${GRUB_DEVICE_UUID}" == "" ]] || \
           [[ "${GRUB_DISABLE_LINUX_UUID}" == "true" ]] || \
           [[ ! -e "/dev/disk/by-uuid/${GRUB_DEVICE_UUID}" ]] || \
           uses_abstraction "${GRUB_DEVICE}" lvm ; then
               GRUB_LINUX_ROOT_DEVICE="${GRUB_DEVICE}"
        else
           GRUB_LINUX_ROOT_DEVICE="UUID=${GRUB_DEVICE_UUID}"
        fi
    fi
    
    [[ "${GRUB_LINUX_PARAMS}" == "" ]] && GRUB_LINUX_PARAMS="${GRUB_CMDLINE_LINUX} ${GRUB_CMDLINE_LINUX_DEFAULT}"
    if [[ "${XEN_LINUX_CMDLINE_OVERRIDE}" == "0" ]]; then
        GRUB_LINUX_PARAMS="${GRUB_LINUX_PARAMS} ${XEN_LINUX_CMDLINE}"
    else
        GRUB_LINUX_PARAMS="${XEN_LINUX_CMDLINE}"
    fi
    
    xen_list=`for i in /boot/xen-*.gz /xen-*.gz ; do
           if grub_file_is_not_garbage "$i" ; then echo -n "$i "; fi
    done`
    
    while [ "x$xen_list" != "x" ] ; do
        xen=`version_find_latest $xen_list`
        echo "Found Xen hypervisor image: $xen" >&2
        XEN_BASENAME=`basename $xen`
        XEN_VERSION=`echo $XEN_BASENAME | sed -e "s,^[^0-9]*-,,g" | sed -e "s,.gz,,g"`
    
        for _KERNEL_ in ${list} ; do
    
            echo "Found linux image: ${_KERNEL_}" >&2
    
            basename="$(basename "${_KERNEL_}")"
            dirname="$(dirname "${_KERNEL_}")"
            REAL_DIR="$(make_system_path_relative_to_its_root "${dirname}")"
      
            _KERNEL_FILE_="$(echo ${_KERNEL_} | sed 's,/boot/,,g')"
            _KERNEL_PKG_="pkg-$(echo ${_KERNEL_FILE_} | sed 's,vmlinuz-,,g')"
    
            _INITRAMFS_="${_KERNEL_FILE_/vmlinuz-/initramfs-}.img"
    
            if [[ -e "/boot/${_INITRAMFS_}" ]]; then
    
                echo "Found initramfs image: /boot/${_INITRAMFS_}" >&2
    
                cat << EOF
    
    menuentry "Xen ${XEN_VERSION} / Arch Linux ${_KERNEL_PKG_} kernel" ${CLASS} {
        $(save_default_entry)
        if [ x\$feature_all_video_module = xy ]; then
            insmod all_video
        fi
        set gfxpayload=keep
        insmod ${BOOT_PART_FS}
        if [ x\$feature_platform_search_hint = xy ]; then
            search --no-floppy --fs-uuid  --set=root ${BOOT_PART_HINTS_STRING} ${BOOT_PART_FS_UUID}
        else
            search --no-floppy --fs-uuid  --set=root ${BOOT_PART_FS_UUID}
        fi
        echo '$(printf "Loading Xen %s ..." ${XEN_VERSION})'
        multiboot2 ${REAL_DIR}/${XEN_BASENAME} ${XEN_HYPERVISOR_CMDLINE}
        echo 'Loading Arch Linux ${_KERNEL_PKG_} kernel ...'
        module2 ${REAL_DIR}/${_KERNEL_FILE_} root=${GRUB_LINUX_ROOT_DEVICE} rw ${GRUB_LINUX_PARAMS}
        echo 'Loading Arch Linux ${_KERNEL_PKG_} kernel initramfs ...'
        module2 ${REAL_DIR}/${_INITRAMFS_}
    }
    
    EOF
            fi
    
            _INITRAMFS_FALLBACK_="${_KERNEL_FILE_/vmlinuz-/initramfs-}-fallback.img"
    
            if [[ -e "/boot/${_INITRAMFS_FALLBACK_}" ]]; then
    
                echo "Found fallback initramfs image: /boot/${_INITRAMFS_FALLBACK_}" >&2
    
                cat << EOF
    
    menuentry "Xen ${XEN_VERSION} / Arch Linux ${_KERNEL_PKG_} kernel (fallback initramfs)" ${CLASS} {
        $(save_default_entry)
        if [ x\$feature_all_video_module = xy ]; then
            insmod all_video
        fi
        set gfxpayload=keep
        insmod ${BOOT_PART_FS}
        if [ x\$feature_platform_search_hint = xy ]; then
            search --no-floppy --fs-uuid  --set=root ${BOOT_PART_HINTS_STRING} ${BOOT_PART_FS_UUID}
        else
            search --no-floppy --fs-uuid  --set=root ${BOOT_PART_FS_UUID}
        fi
        echo '$(printf "Loading Xen %s ..." ${XEN_VERSION})'
        multiboot2 ${REAL_DIR}/${XEN_BASENAME} ${XEN_HYPERVISOR_CMDLINE}
        echo 'Loading Arch Linux ${_KERNEL_PKG_} kernel ...'
        module2 ${REAL_DIR}/${_KERNEL_FILE_} root=${GRUB_LINUX_ROOT_DEVICE} rw ${GRUB_LINUX_PARAMS}
        echo 'Loading Arch Linux ${_KERNEL_PKG_} kernel fallback initramfs ...'
        module2 ${REAL_DIR}/${_INITRAMFS_FALLBACK_}
    }
    
    EOF
            fi
    
            if [[ ! -e "/boot/${_INITRAMFS_}" ]] && [[ ! -e "/boot/${_INITRAMFS_FALLBACK_}" ]]; then
                cat << EOF
    
    menuentry "Xen ${XEN_VERSION} / Arch Linux ${_KERNEL_PKG_} kernel (no initramfs)" ${CLASS} {
        $(save_default_entry)
        if [ x\$feature_all_video_module = xy ]; then
            insmod all_video
        fi
        set gfxpayload=keep
        insmod ${BOOT_PART_FS}
        if [ x\$feature_platform_search_hint = xy ]; then
            search --no-floppy --fs-uuid  --set=root ${BOOT_PART_HINTS_STRING} ${BOOT_PART_FS_UUID}
        else
            search --no-floppy --fs-uuid  --set=root ${BOOT_PART_FS_UUID}
        fi
        echo '$(printf "Loading Xen %s ..." ${XEN_VERSION})'
        multiboot2 ${REAL_DIR}/${XEN_BASENAME} ${XEN_HYPERVISOR_CMDLINE}
        echo 'Loading Arch Linux ${_KERNEL_PKG_} kernel ...'
        module2 ${REAL_DIR}/${_KERNEL_FILE_} root=${GRUB_LINUX_ROOT_DEVICE} rw ${GRUB_LINUX_PARAMS}
    }
    
    EOF
            fi
    
        done
    
        xen_list=`echo $xen_list | tr ' ' '\n' | grep -vx $xen | tr '\n' ' '`
    done
    

    一个简化的 Grub 配置参考

    一个简化的 Grup 引导配置文件如下,其中 xen-4.12.1.gz 为 Xen Hypervisor,vmlinuz-4.9-x86_64 为支持 Xen 的 Dom 0 Linux Kernel,initramfs-4.9-x86_64.img 为 RAM Disk。注意当前的根为“/boot”而非“/”。“xsave=1” “dom0_max_vcpus=1” “dom0_mem=1024M” 为 Xen Hypervisor,vmlinuz 的 Command Line Options。root=UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx rw quiet udev.log_priority=3 为 Dom 0 Kernel Command Line Options。

    menuentry "Xen / Arch Linux kernel" --class manjaro --class gnu-linux --class gnu --class os {
        savedefault
        load_video
        set gfxpayload=keep
        insmod gzio
        insmod part_msdos
        insmod ext2
        set root='hd0,msdos1'
        if [ x$feature_platform_search_hint = xy ]; then
            search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1  xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
        else
            search --no-floppy --fs-uuid --set=root xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
        fi
        multiboot2 /xen-4.12.1.gz "xsave=1" "dom0_max_vcpus=1" "dom0_mem=1024M"
        echo  'Loading kernel ...'
        module2 /vmlinuz-4.9-x86_64 root=UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx rw  quiet udev.log_priority=3
        echo  'Loading initial ramdisk ...'
        module2 --nounzip /initramfs-4.9-x86_64.img
    }
    

    Systemd-boot 引导配置

    Systemd-boot 无法直接引导 xen-4.12.1.gz,并且配置其参数。但是 Systemd-boot 可以引导 efi 文件,因此可以先引导 xen-4.12.1.efi,再由 xen-4.12.1.efi 引导 Dom0 内核进行启动。xen-4.12.1.efi 需要一个配置文件用于配置 Dom0。但在此之前,先要编写 Systemd-boot 的 entry 文件 /boot/loader/entries/10-xen.conf 文件,用于引导 xen-4.12.1.efi:

    title   Xen Hypervisor
    efi     /xen-4.12.1.efi
    

    之后在 /boot 目录下创建 xen-4.12.1.cfg 文件用于配置 Dom0:

    [global]
    default=xen
    
    [xen]
    options=loglvl=all noreboot=true reboot=no dom0_max_vcpus=3 dom0_mem=6000M
    ucode=intel-ucode.img
    kernel=vmlinuz-5.3-x86_64 root=PARTUUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx rw
    ramdisk=initramfs-5.3-x86_64.img
    

    xen-4.12.1.efi 会按照一定规则查找 cfg 文件,首先会查找与自身同名但是扩展名为 cfg 的文件,最后会查找 xen.cfg 文件。更详细的规则可以参考官方帮助。

    DomU

    DomU 的使用和配置请参考 Xen DomU 配置与使用

    参考

    https://xenbits.xen.org/docs/unstable/misc/efi.html

    https://wiki.archlinux.org/index.php/Xen

    展开全文
  •   阅读目录 总结: 这一篇我要体验的虚拟机系统是 Xen。在虚拟机领域,Xen 具有非常高的知名度,其名字经常在各类文章中出现。...之所以如此,那是因为 Xen 采用了和我前面介绍的那几个虚拟机完全不...
  • xen虚拟化技术

    2018-11-12 22:59:31
    虚拟化技术的分类:(1) 模拟:Emulation:Qemu,PearPC,Bochs(2) 完全虚拟化:Full Virtualization,Native VirtualizationHVMVMware Workstation,VirtualBox,VMWare Server,Parallels Desktop,KVM,XEN(3) 半...
  • Xen的入门到放弃

    2017-09-25 23:15:00
    Xen的入门到放弃  作者:尹正杰  版权声明:原创作品,谢绝转载!否则将追究法律责任。      Xen 是一个开放源代码虚拟机监视器(VMM),由剑桥大学的"Ina Pratt"和"Keir Fraser"的2个研究员...
  • Xen - 安装

    2019-02-20 14:56:00
    Xen - 安装 1,一台64位的主机 + debain 9 (scrath,也就是稳定版) + xen 4.11.0 Note1:经过无数次测试,debian系统源码编译安装xen会遇到的问题很少,所以推荐,当然如果你熟悉其他操作系统你也可以尝试。而xen...
  • Xen的简介 1.1 Xen的大体结构 1.2 Xen对VM的称呼 1.3 Xen对CPU和内存的虚拟化过程 1.4 Xen对IO设备的虚拟化过程 1.5 Linux Kernel对Xen的支持 1.6 Xen版本发布简史 1.7 Xen的工具栈 1.8 XenS...
  • xen 简介

    千次阅读 2013-08-11 16:16:12
    Xen 是一个开放源代码虚拟机监视器,由剑桥大学开发。它打算在单个计算机上运行多达100个满特征的操作系统。操作系统必须进行显式地修改(“移植”)以在Xen上运行(但是提供对用户应用的兼容性)。这使得Xen无需...
  • Xen与XenServer的区别

    千次阅读 2016-11-10 10:58:49
    说到XenServer,总是离不开Xen,所以我要说他们的区别,得首先从Xen开始说起!    Xen体系架构   Xen hypervisor体系架构  Xen 的 VMM ( Xen Hypervisor ) 位于操作系统和硬件之间,负责为上层运行的...
  • Xen

    2016-10-04 20:10:00
    在旧(无虚拟硬件)的处理器上执行Xen,操作系统必须进行显式地修改(“移植”)以在Xen上运行(但是提供对用户应用的兼容性)。这使得Xen无需特殊硬件支持,就能达到高性能的虚拟化。 2013年4月,Linux基金会宣布...
  • XEN

    2012-10-26 20:44:26
    XEN 的发展与现状 XEN 最初是作为剑桥大学的一个项目,目前 XEN.ORG 社区在负责它的开发及维护,它已经在开源社区中得到了极大的发展。XEN 是一种直接运行在硬件上一层软件,它可以让电脑硬件上同时跑多个用户的...
  • Xen

    2009-08-01 01:21:00
    Xen Xen 是一个开放源代码虚拟机监视器,由剑桥大学 开发。它打算在单个计算机 上运行多达100个满特征的操作系统。操作系统必须进行显式地修改(“移植”)以在Xen上运行(但是提供对用户应用的兼容性)。这使得Xen...
  • Xen

    千次阅读 2014-09-17 14:36:10
    Xen HVM Guest configuration for Windows Vista I will try to sumarize the step needed to run a HVM Vista machine on a Ubuntu 9.04 distribution, 2.6.31.5 Dom0 paravirt-ops kernel under Xen 3.4.1. I w
  • Xen

    2016-10-04 20:10:00
    Xen是一个开放源代码虚拟机监视器,由剑桥大学开发。它打算在单个计算机上运行多达128个有完全功能的操作系统。 在旧(无虚拟硬件)的处理器上执行Xen,操作系统必须进行显式地修改(“移植”)以在Xen上运行(但是...
  • Xen

    2016-05-26 10:58:16
    XEN 虚拟化 Xen 虚拟化概述 Xen 是业界速度最快、 最安全的基础设施虚拟 化软件技术,并已得到 20 多家业界主要供应 商的支持,其中包括 Novell。   XEN 简介 XEN 是一个基于X86架构、...
  • xen

    千次阅读 2014-06-05 00:32:14
    XenAPI方式: #!/usr/bin/python from xen.xm.XenAPI import Session session=Session('httpu:///var/run/xend/xen-api.sock') try:  session.login_with_password('', '')  xenapi=session.xen...
  • xen架构

    千次阅读 2012-08-08 15:51:07
    Xen是一个虚拟机监视器(Virtual machine monitor),针对X86系列计算机设计,它能够支持多个客户计算机的同时运行,并且能够达到较好的一个性能水平和资源隔离。Xen是一个开放源代码软件,在GNU General Public ...
  • Xen

    2007-05-31 15:05:00
    在一台机器上运行多个操作系统挑战在于:1 操作系统相互之间不能互相影响2 需要支持不同的操作系统同时运行3 虚拟化带来的性能上的影响应该尽可能的小 Xen设计的目标是:1 修改应用程序对于用户来说是不能接受的。...

空空如也

1 2 3 4 5 ... 20
收藏数 26,719
精华内容 10,687
关键字:

Xen