1、文件系统的性能是最大的瓶颈。如果性能不佳很有可能成为故障的根源

我们的虚拟池(Pool)使用NFS文件系统，架设在一台基于SATA硬盘组装的RAID上。在为多台虚拟进程提供服务时，iops捉襟见肘。甚至逐渐发展到了一些虚拟机Guest误认为文件系统超时而导致了各种故障。而对于Host来说，我们遭遇到的最大灾难就是虚拟机Guest的硬盘掉落，如果没有之前的配置备份或“记忆”，几乎无法找回。

2、对硬盘池的剩余空间保持高度关注

当一个Storage Repository的没有剩余空间时，在其上的虚拟机并不会立刻停止工作或者即刻报警。这样表面上保证了高可用性，但是却会让人大意，进而造成数据大量丢失而导致不可逆的数据灾难。况且在规划虚拟机Guest时，我们通常会习惯性的超量划分硬盘分区，这种情况下，一旦一个虚拟机Guest突然产生大量数据写入时，很有可能导致硬盘池分区满溢的情况。因此对硬盘池保持高度警惕是非常重要的。

3、snapshot的极限是30个

在使用XenServer虚拟池的过程中，我们曾对使用snapshot进行断点备份寄以希望。甚至撰写了一个每天自动对所有正在运行的虚拟机Guest制作Snapshot的脚本，停止了手动备份工作。完全没有注意到XenServer中，每个虚拟机Guest至多只能有不超过30个snapshot的限制。直到发生灾难那一天，我们才发现snapshot已经停止多日，回滚中便丢失了大量数据。

4、虚拟池中的Master的数据安全需要全力保证

在多台XenServer组建的虚拟池中，物理主机之间是有Master/Slave之分的。其中Master的数据安全和稳定性尤其重要，容灾能力也会比较差。当Master遭遇不可逆的故障和灾难时，尽管其他Slave上运行的虚拟机Guest进程仍然还能正常工作一段时间，但是此时重启就变成了危险行为。Master的硬件稳定性是如此重要，现在我甚至会推荐Master上不运行任何Guest虚拟进程。

5、留心网卡兼容性问题

我的虚拟池物理主机是使用家用主板自己组装。板载RealTek RTL81xx系列的千兆网卡。幸运的是，XenServer可以识别和使用该系列芯片的千兆网卡，初期大大降低了硬件成本。但是不幸的是，我们发现RealTek 系列网卡至少在最新的Xen 5.6+上无法保证无故障运行，严重是还会导致虚拟机Host主机死锁。最终我们又另外购买了一组TP-LINK TG-3269C 千兆网卡来保证稳定性。

6、升级XenServer版本要谨慎

不只限于前述网卡兼容问题，XenServer生产版本升级会带来诸多不稳定问题。在Citrix论坛上也有大量的抱怨，有人几乎为此丢了工作。而且对于一组虚拟池来说，必须整组升级到相同版本，所以回退的成本也很高。面对这些问题，升级XenServer前务必要谨慎的考察。

7、Guest是有可能Crash宿主机的

通常我们认为虚拟机Guest是处于隔离状态的，因此认为Guest进程中无论发生什么不会影响物理主机Host的稳定的。但是实际运行中我们发现，运行的一些Guest操作系统是有可能导致宿主主机死锁或者崩溃的。我们是在安装运行一些FreeBSD的虚拟进程时发现这一现象的，其结果是最终会导致所有同一物理主机下的虚拟进程死锁。而这也是我们现在不再推荐在Master上运行Guest进程的一个原因。因为一旦Master锁死会导致更大的灾难。

8、忘记密码后跳过fsck的方法

在Linux Guest中发生严重的文件系统损坏时，会在启动时要求输入完整的root密码并进行全面的fsck。如果这时候忘记了root密码(特别是全面推进证书登录后)是很尴尬的。碰到这种处境时，可以通过XenCenter设置该虚拟机Guest的属性 – General – Boot Options – OS boot parameters ， 改为 fastboot(跳过fsck阶段)或 single (进入单用户模式)来进入系统并进一步修复文件系统。

9、切换Master的正确方法是在线状态中，登录Master并任命虚拟池中的另一台Slave担任新的Master

正因为Master在虚拟池中的主要性，当需要对Master进行软、硬件升级或调整时，必须要在Master上执行切换操作，将另一台物理主机制定为新的Master再进行维护。否则一旦Master在维护中出现故障，将会成为新的灾难。

来源：http://blog.splayer.org/index.php/2011/06/xenserver-checklist/