Category: XenServer
XenServer中Windows 7与XP多vCPU支持配置
在服务器虚拟化项目或者虚拟桌面项目中，经常会碰到这样的问题，虚机为高负载类型的业务，对CPU的要求很高的时候，我们希望为这些虚拟桌面分配更多的CPU资源，但是我们也发现，部分系统对CPU数量的支持有数量的限制，超过以后，即使分配，也没法利用到。也有一些软件会依据CPU的数量（socket的数量）来收费，所以也需要对CPU进行一些调整来减少费用。 首先说一下，在CPU中有几个概念：Socket、Core、Hyper-Threading（HT）。首先得搞清楚这些。 Socket：wikipedia的解释是连接到主板的一个CPU，通俗讲就是一个物理CPU Core：wikipedia的解释同一个CPU芯片上集成的多个核心，也就是所谓的多核的核 Hyer-Threading：wikipedia的解释模拟的多线程，通俗讲在一个核心上模拟出两个CPU执行线程，能够提高多任务的性能
XenServer中LVM的性能
在XenServer 5.5以后，提供了snapshot和fast clone的功能，这些功能，具有一定的性能开销，但能够带来一定的灵活性。纯粹为了性能，在基于LVM的存储上支持创建RAW格式的VDI，而默认创建的VDI为VHD格式。RAW格式，虽然能够带来性能的提升，但XenServer不支持RAW格式 VDI的快照。
XenServer中VM的启动行为
在XenServer中，VM使用的VDI在VM启动的时候，具有两种行为模式： Shared Desktop Mode（共享桌面模式） 在共享桌面模式下，当VM启动的时候，VM所赌赢的VDI将会恢复到原始状态，也就是VM运行过程中所产生的所有变化都不会保留，也就是每次启动都会恢复。 Private Desktop Mode（私有桌面模式） 在私有桌面模式下，VM启动的时候，对应VDI中，VM运行过程中的所有对VDI的修改都会保留，并持久化到存储上，也就是数据更改将会保存到桌面
XenServer中VM的存储格式对空间以及性能的影响
在XenServer中，基本的存储库（SR）、物理块设备、虚拟磁盘映像、虚拟块设备之间的关系如下图： 其中，PBD为物理存储设备的抽象，基本无法改变，SR为XenServer对物理存储设备的抽象，起到组织管理的作用，SR的类型对虚机VDI的格式以及性能有一定的影响，但是SR的类型受限制于物理存储的形式，所以，暂停也跳过，VBD与VDI对应，而最终VM拿到的虚拟块设备VBD，则为VDI的虚拟，所以，SR中VDI的格式对存储空间消耗以及性能产生比较重要的影响。
XenServer 5.6 SP2开启Intellicache
XenServer在启用Intellicache功能以后，作为虚拟桌面的基础架构服务器部署，能够有效的利用本地存储和共享存储，减少共享存储的压力。特别对单一镜像的虚机带来的存储性能要求大大降低，缓存减少了网络的压力同时，降低了存储的压力。 Intellicache在启动时，会缓存VM的Parent VDI（父VDI，主VDI）的数据。Local Cache（本地缓存）将作为Parent VDI的数据在以后的读的缓存，这样，当大量的VM共享一个parent VDI（比如MCS在同一个SR中，共享同一个master image），一个虚机的数据请求会被local cache缓存，这样，在其他VM再次访问的时候，就能提供数据访问速度，减少对共享存储上的parent VDI的访问。 另外，为了启用Intellicache，在安装的时候需要开启thin provisioning。Thin Provisioning可以增加可用的存储空间，相比于LVM，更加适合作为共享存储的本地缓存，因为EXT形式的SR，VM是以VHD格式保存，按需分配，而Intellicache需要再本地有一个VDI-UUIS.vhdcache的VDI，如果使用LVM，那么对容量的需求将大大超过预期，所以，Citrix选择了在EXT3文件系统上启用Intellicache功能。
XenServer为VM指定使用特定物理CPU
首先，我们先来看看XenServer中Socket、Core、以及超线程后的核心之间在XenServer中CPU的排序关系，请参考下表： CPU排序（以2路4核具有超线程功能CPU示范） Socket1 Socket2 Core1 Core2 Core3 Core4 Core1 Core2 Core3 Core4 HT1 HT2 HT1 HT2 HT1 HT2 HT1 HT2 HT1 HT2 HT1 HT2 HT1 HT2 HT1 HT2 #0 #1 #2 #3 #4 #5 #6 #7 #8 #9 #10 #11 #12 #13 #14 #15 上表反应了XenServer中CPU的排序规则。
XenDesktop 5.5和XenApp 6.5三季度发布
Citrix将在第三季度发布XenDesktop和XenApp的下一个版本XenDesktop 5.5和XenApp 6.5。发布这两个版本，主要是HDX技术有了重大升级，极大增强和稳固了citrix在桌面虚拟化市场的领先地位。
禁用VM与Hypervisor之间的时间同步功能
基本主流的企业级虚拟化产品，安装完虚机以后，都要在虚机中安装各种Tools，用来增强虚机的性能，以及与主机的交互。而时间同步功能，在目前主流的三家产品中，默认都是启用的。安装完Tools以后，虚机会自动和Host之间同步时间，保持时间与底层主机的一致，但是这种机制在某些情况下会导致上层虚机的时间混乱，比如时区设置，时间准确定，多时区等等。 所在在某些情况下，可能需要禁用该功能。
XenServer默认存储设置丢失导致XenConvert失败
今天一朋友在做XenConvert的时候，报告说一直提示失败，导致无法进行XenConvert，听了描述，半天没搞明白怎么回事，于是远程连过去看了下，结果网速太慢，结果和收集日志文件，终于发现了问题所在，所以日志文件还是很强大地。
服务器虚拟化的MAC地址分配
在全是物理机的环境中，我们不需要考虑MAC地址的问题，因为每个物理机的网卡都是真实，其MAC地址由网卡提供商来分配独一无二的MAC ADDRESS，所以在物理环境规范的情况下是不会出现MAC地址冲突的问题，除非有山寨。 先普及下MAC地址的相关知识，以下会用到。 MAC地址最开始由XEROR研究出来，后来由IEEE组织管理。IEEE会为每个厂商提供唯一的一个MAC地址前缀，称之为OUI（Organizationally Unique Identifier），用来区别不同的厂商，例如：aa-bb-cc-xx-xx-xx，其中aa-bb-cc就是OUI，每个厂商会根据自己的喜欢来编码剩下的24bit。 再来说下Universally administered和 locally administered addresses，前者是全局分配，后者有本地分配，比较随意。两者的区别在于，前者使用从IEEE分配到的OUI来分配MAC地址，而locally administered address则是有本地分配的地址。不受OUI的影响。但是两者不冲突，universally和locally在第一个第一个16位的倒数第二字节，如果是0，那么该MAC地址为universally，如果是1，则是locally地址。例如：06-00-00-00-00-00，06的二进制为00000110，倒数第二位是1，所以，该MAC地址为本地管理地址，而所有的OUI分配地址，该检测位都是0。如：xensource的OUI为：00-16-3E，00很明显，倒数第二位是0，所以这是一个universally地址。
XenServer模拟器
大家在刚接触XenServer的时候，苦于硬件的限制和投入，感觉实验环境是个很大的问题。 最开始学习XenServer的时候，就只能拿一台家里自用的PC机来测试安装XenServer，这个还得一台管理机，比如笔记本等等，而且内存也有一定的要求，家里的机器一般也就个2G内存（Maybe已经成为历史了），而且内存也比较贵，扩展起来肉疼，当然现在内存已经白菜价了。就这样的条件，勉勉强强开始了实验，发现只能做一些基本的实验，后很多高级功能又没法测试，比如HA等功能。 有时候也会需要一个干净的XenServer环境，测试一下XenServer的命令，比如我们需要看看某个命令的参数，使用方式，文档毕竟介绍的不是很全面。 很多时候我们都需要一些环境，而这些环境又不是马上可以接入的，比如技术支持的时候，这个时候我们要是有自己的，能够方便接入的环境，就很舒服了。
调整XenServer中VM的内存上下限
在XenServer中，我们可以发现，创建虚机的时候，VM的最大最小值都有规定值，内存无法设置太低，也没法设置的更高，比如选择Windows Server 2003 32bit模版来安装的时候，我们会发现，2003 R2 32bit的模版最多只能设置4GB内存，最少不能少于256M内存。超过范围，XenCenter工具会帮您自动调整为范围内的最接近值。
资源池开启HA后主机保护机制分析
在前端时间曾今写过一篇文章分析过XenServer Resources Pool中开启HA机制后，导致的主机重启，Citrix称之为Host Fencing，也就是所谓的主机保护机制，用于确保存储中VM数据的安全性，具体参考另外一篇文章：XenServer Host Self-fense（主机保护） 今天发现了关于在HA情况下，当发生心跳丢失或者管理口连接丢失情况下究竟哪台主机会重启的官方说明。
查看XenServer服务器安装信息
前端时间，我们介绍了如何查看XenServer中Xen的版本信息的方法，可以参考： 如何查看XenServer中Xen内核版本 今天再来介绍一些如何查看XenServer本身版本的方法，我们直接通过XenServer控制台（xsconsole）能够看到绝大多数信息，但是我们能通过另外一个文件查看XenServer的信息。
配置XenServer VM Crashdump行为
在物理机中，操作系统崩溃后，一般会有Crashdump文件保存，用于分析导致系统崩溃的原因，而在XenServer中，也提供了这样一种机制用于保存Crashdump文件，并且相对于物理机，针对虚机的保护增加了Crashdump（宕机）后的保护操作，用于尽快的恢复业务的运行，保持业务连续性，比如，在VM崩溃以后，自动重启，或者为了稳定，暂时性的关闭虚机，再或者为了保存崩溃的上下文，保持崩溃状态等等操作。
Citrix Production Features by Edition
经常会有人问，Citrix的产品中各版本（普通版、高级版、企业版、白金版等等）之间究竟有些什么区别？ 看看Citrix官方的Feature List即可。 登录Citrix官网，然后找到产品，然后在每个产品的How It Works里面可以找到Edition相关的信息。
XenServer中为虚机添加多个光驱
XenServer默认为每个虚机（VM）创建一个虚拟光驱（DVD Drive1），这样的话，我们就只能挂载一个镜像，但是如果想同时挂载N个镜像怎么办？ 我们可以为虚机添加多个虚拟光驱设备，这样，就可以同时挂载多个ISO镜像了。
XenServer关闭电源以后部分虚机无法启动
前天在DDMD测试环境中，为了快速恢复环境，我们在DEMO环境搭建完成以后，对所有的虚机测试完成以后进行了暂停操作，然后关闭XenServer，然后第二天启动完成XenServer以后，打开恢复虚机的过程中发现了一些问题，提示：This VM needs storage that cannot be seen from that server。
XenServer XAPI简介
什么是XAPI，或者说XAPI在XenServer中有什么作用？ XAPI（或者XenAPI）是XenServer中的一组管理接口的统称，是XenServer管理的核心，由一系列的toolstack组成。 XAPI主要提供XenCenter以及pool中各主机通信的接口。XenCenter通过XAPI来读取XenServer的配置、管理、License的管理、数据库的维护等等，同时也包括如存储（SR）、虚机、虚拟网卡、HA等等所有的功能控制。而Pool中的所有XenServer的操作请求也是通过XAPI传递给dom0，同时在池中的所有主机中间通信，例如：Pool中数据库（配置数据库，由XenServer维护的一个小型数据库）会通过XAPI在所有的主机之间同步，以便在Master服务器宕机以后，其他机器能够正确而迅速的取代Master，并维持Pool的功能和服务。 简而言之，XAPI就是个和底层通信的中间层、接口层。