Aaron Delp’s BladeVault

Just a quick heads up that I updated my previous post, Citrix XenServer for the ESX Engineer, based on feedback from the Citrix team.  If anybody has any additional comments or concerns, please post them over there.  Thank you again for the interest and keeping me honest.

I was able to attend a session on Citrix XenServer today.  It wasn’t as technical as I would have liked but I did take away a good bit of information.  Like my Hyper-V write up , here are my notes in no particular order.

UPDATE:  I have been contacted by multiple people at Citrix regarding this post and misconceptions on my part.  First, thank you to them for contacting me!  Be gentle, I’m learning the product as quickly as I can.  I have updated the post below to reflect the latest information.  If you have any more feedback, please leave a comment or shoot me an e-mail.  Thank you!

• 6 physical NICS in a server
• XenServer supports Live Migration (think VMotion)
• XenCenter is the management GUI.  It provides the management GUI similiar to Virtual Center but is a client product that can be loaded on any server, client, etc
• Requires a 64 bit proc to run.  Supports up to 32 cores and 128GB
• Sizing of XenServer -> XenServer runs on first core (plan on it using the whole core), Xen will take an average of 580MB - 880MB (128MB at core and 200-742MB for ring 0) for XenServer,16GB for OS, one NIC for “service console”
• A “farm” of servers are called a resource pool.  This pool can have up to 16 hosts.  One server is the master and the rest are members (think PDC/BDC model in the pre-Active Directory days).  The Master holds the configuration for the entire resource pool and has the only writable copy.  Member servers are updated every minute on configuration changes
• The pool holds the configuration of all servers.  Networking must be similar but not exactly the same (although it is recommended).  Network adapters must be in the same order, on the same network, and have the same speed.
• If removing a host from a pool and VM’s are on the local storage, they will be DESTROYED!  Best practice when inserting a machine into a pool is to remove all local virtual machine storage
• If Master goes down, the members will try to reconnect for 1 minute and then go into “Emergency mode”.  New VM’s can not be created but exisiting VM’s will continue to run
• When in Emerency Mode, the members will retry every 3-5 minutes to reestablish communications
• If the Primary will be down for an extended time, a member server can be promoted to the new Master server
• NIC bonding is supported but it is Active/Passive (remember 4 maximum NICS)
• NFS Client is supported - it supports Fast Cloning and thin provisioning
• XenServer will take advantage of hardware features on a NetApp filer using iSCSI for connectivity
• XenServer has a GUI interface to apply hotfixes (think ESX Update Manager Plugin for Virtual Center)