XenServer上开始出现不稳定的状况。在灾难中，我们积累下一些经验，在此整理一下，以资借鉴：
× 文件系统的性能是最大的瓶颈。如果性能不佳很有可能成为故障的根源
我们的虚拟池(Pool)使用NFS文件系统，架设在一台基于SATA硬盘组装的RAID上。在为多台虚拟进程提供服务时，iops捉襟见肘。甚至逐渐发 展到了一些虚拟机Guest误认为文件系统超时而导致了各种故障。而对于Host来说，我们遭遇到的最大灾难就是虚拟机Guest的硬盘掉落，如果没有之 前的配置备份或“记忆”，几乎无法找回。
× 对硬盘池的剩余空间保持高度关注
当一个Storage Repository的没有剩余空间时，在其上的虚拟机并不会立刻停止工作或者即刻报警。这样表面上保证了高可用性，但是却会让人大意，进而造成数据大量 丢失而导致不可逆的数据灾难。况且在规划虚拟机Guest时，我们通常会习惯性的超量划分硬盘分区，这种情况下，一旦一个虚拟机Guest突然产生大量数 据写入时，很有可能导致硬盘池分区满溢的情况。因此对硬盘池保持高度警惕是非常重要的。
× snapshot的极限是30个
在使用XenServer虚拟池的过程中，我们曾对使用snapshot进行断点备份寄以希望。甚至撰写了一个每天自动对所有正在运行的虚拟机Guest 制作Snapshot的脚本，停止了手动备份工作。完全没有注意到XenServer中，每个虚拟机Guest至多只能有不超过30个snapshot的 限制。直到发生灾难那一天，我们才发现snapshot已经停止多日，回滚中便丢失了大量数据。
× 虚拟池中的Master的数据安全需要全力保证
在多台XenServer组建的虚拟池中，物理主机之间是有Master/Slave之分的。其中Master的数据安全和稳定性尤其重要，容灾能力也会 比较差。当Master遭遇不可逆的故障和灾难时，尽管其他Slave上运行的虚拟机Guest进程仍然还能正常工作一段时间，但是此时重启就变成了危险 行为。Master的硬件稳定性是如此重要，现在我甚至会推荐Master上不运行任何Guest虚拟进程。
× 留心网卡兼容性问题
我的虚拟池物理主机是使用家用主板自己组装。板载RealTek RTL81xx系列的千兆网卡。幸运的是，XenServer可以识别和使用该系列芯片的千兆网卡，初期大大降低了硬件成本。但是不幸的是，我们发现 RealTek 系列网卡至少在最新的Xen 5.6+上无法保证无故障运行，严重是还会导致虚拟机Host主机死锁。最终我们又另外购买了一组TP-LINK TG-3269C 千兆网卡来保证稳定性。
× 升级XenServer版本要谨慎
不只限于前述网卡兼容问题，XenServer生产版本升级会带来诸多 不稳定问题。在Citrix论坛上也有大量的抱怨，有人几乎为此丢了工作。而且对于一组虚拟池来说，必须整组升级到相同版本，所以回退的成本也很高。面对这些问题，升级XenServer前务必要谨慎的考察。
× Guest是有可能Crash宿主机的
通常我们认为虚拟机Guest是处于隔离状态的，因此认为Guest进程中无论发生什么不会影响物理主机Host的稳定的。但是实际运行中我们发 现，运行的一些Guest操作系统是有可能导致宿主主机死锁或者崩溃的。我们是在安装运行一些FreeBSD的虚拟进程时发现这一现象的，其结果是最终会 导致所有同一物理主机下的虚拟进程死锁。而这也是我们现在不再推荐在Master上运行Guest进程的一个原因。因为一旦Master锁死会导致更大的 灾难。
× 忘记密码后跳过fsck的方法
在Linux Guest中发生严重的文件系统损坏时，会在启动时要求输入完整的root密码并进行全面的fsck。如果这时候忘记了root密码（特别是全面推进证书 登录后）是很尴尬的。碰到这种处境时，可以通过XenCenter设置该虚拟机Guest的属性 - General - Boot Options - OS boot parameters ， 改为 fastboot（跳过fsck阶段）或 single （进入单用户模式）来进入系统并进一步修复文件系统。
× 切换Master的正确方法是在线状态中，登录Master并任命虚拟池中的另一台Slave担任新的Master
正因为Master在虚拟池中的主要性，当需要对Master进行软、硬件升级或调整时，必须要在Master上执行切换操作，将另一台物理主机制定为新的Master再进行维护。否则一旦Master在维护中出现故障，将会成为新的灾难。
from http://blog.splayer.org/index.php/2011/06/xenserver-checklist/
http://blog.splayer.org/index.php/2010/07/%E5%B0%84%E6%89%8B%E7%A7%91%E6%8A%80%E7%9A%84-xenserverxendesktop-%E8%99%9A%E6%8B%9F%E5%8C%96%E5%BA%94%E7%94%A8%E6%96%B9%E6%A1%88/
× 文件系统的性能是最大的瓶颈。如果性能不佳很有可能成为故障的根源
我们的虚拟池(Pool)使用NFS文件系统，架设在一台基于SATA硬盘组装的RAID上。在为多台虚拟进程提供服务时，iops捉襟见肘。甚至逐渐发 展到了一些虚拟机Guest误认为文件系统超时而导致了各种故障。而对于Host来说，我们遭遇到的最大灾难就是虚拟机Guest的硬盘掉落，如果没有之 前的配置备份或“记忆”，几乎无法找回。
× 对硬盘池的剩余空间保持高度关注
当一个Storage Repository的没有剩余空间时，在其上的虚拟机并不会立刻停止工作或者即刻报警。这样表面上保证了高可用性，但是却会让人大意，进而造成数据大量 丢失而导致不可逆的数据灾难。况且在规划虚拟机Guest时，我们通常会习惯性的超量划分硬盘分区，这种情况下，一旦一个虚拟机Guest突然产生大量数 据写入时，很有可能导致硬盘池分区满溢的情况。因此对硬盘池保持高度警惕是非常重要的。
× snapshot的极限是30个
在使用XenServer虚拟池的过程中，我们曾对使用snapshot进行断点备份寄以希望。甚至撰写了一个每天自动对所有正在运行的虚拟机Guest 制作Snapshot的脚本，停止了手动备份工作。完全没有注意到XenServer中，每个虚拟机Guest至多只能有不超过30个snapshot的 限制。直到发生灾难那一天，我们才发现snapshot已经停止多日，回滚中便丢失了大量数据。
× 虚拟池中的Master的数据安全需要全力保证
在多台XenServer组建的虚拟池中，物理主机之间是有Master/Slave之分的。其中Master的数据安全和稳定性尤其重要，容灾能力也会 比较差。当Master遭遇不可逆的故障和灾难时，尽管其他Slave上运行的虚拟机Guest进程仍然还能正常工作一段时间，但是此时重启就变成了危险 行为。Master的硬件稳定性是如此重要，现在我甚至会推荐Master上不运行任何Guest虚拟进程。
× 留心网卡兼容性问题
我的虚拟池物理主机是使用家用主板自己组装。板载RealTek RTL81xx系列的千兆网卡。幸运的是，XenServer可以识别和使用该系列芯片的千兆网卡，初期大大降低了硬件成本。但是不幸的是，我们发现 RealTek 系列网卡至少在最新的Xen 5.6+上无法保证无故障运行，严重是还会导致虚拟机Host主机死锁。最终我们又另外购买了一组TP-LINK TG-3269C 千兆网卡来保证稳定性。
× 升级XenServer版本要谨慎
不只限于前述网卡兼容问题，XenServer生产版本升级会带来诸多 不稳定问题。在Citrix论坛上也有大量的抱怨，有人几乎为此丢了工作。而且对于一组虚拟池来说，必须整组升级到相同版本，所以回退的成本也很高。面对这些问题，升级XenServer前务必要谨慎的考察。
× Guest是有可能Crash宿主机的
通常我们认为虚拟机Guest是处于隔离状态的，因此认为Guest进程中无论发生什么不会影响物理主机Host的稳定的。但是实际运行中我们发 现，运行的一些Guest操作系统是有可能导致宿主主机死锁或者崩溃的。我们是在安装运行一些FreeBSD的虚拟进程时发现这一现象的，其结果是最终会 导致所有同一物理主机下的虚拟进程死锁。而这也是我们现在不再推荐在Master上运行Guest进程的一个原因。因为一旦Master锁死会导致更大的 灾难。
× 忘记密码后跳过fsck的方法
在Linux Guest中发生严重的文件系统损坏时，会在启动时要求输入完整的root密码并进行全面的fsck。如果这时候忘记了root密码（特别是全面推进证书 登录后）是很尴尬的。碰到这种处境时，可以通过XenCenter设置该虚拟机Guest的属性 - General - Boot Options - OS boot parameters ， 改为 fastboot（跳过fsck阶段）或 single （进入单用户模式）来进入系统并进一步修复文件系统。
× 切换Master的正确方法是在线状态中，登录Master并任命虚拟池中的另一台Slave担任新的Master
正因为Master在虚拟池中的主要性，当需要对Master进行软、硬件升级或调整时，必须要在Master上执行切换操作，将另一台物理主机制定为新的Master再进行维护。否则一旦Master在维护中出现故障，将会成为新的灾难。
from master: xe pool-ha-disable xe host-list xe pool-designate-new-master host-uuid= From XenCenter 1) Disable HA 2) Enter maintenance mode on Pool Master, will migrate all VMs to anohter host.
During the Enter Maintenance mode dialog you will be asked to elect a new Pool Master. 3) Exit maintenance mode on old master 4) Enable HA
from http://blog.splayer.org/index.php/2011/06/xenserver-checklist/
http://blog.splayer.org/index.php/2010/07/%E5%B0%84%E6%89%8B%E7%A7%91%E6%8A%80%E7%9A%84-xenserverxendesktop-%E8%99%9A%E6%8B%9F%E5%8C%96%E5%BA%94%E7%94%A8%E6%96%B9%E6%A1%88/
