Jul
31
2008
Citrix XenServer for the ESX Engineer
Posted by: Aaron Delp in Citrix XenServer, Hyper-V, Q-Logic, VMWareI 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)
Entries (RSS)
Do they still only collect and save 15 minutes worth of performance data? that’s what really surprised me. And what also surprised me is that you could not choose which nic was used for Live Migration.
OK, misconceptions in order:
1) XenServer supports six *active* NICs in release 4.1, and each active NIC can be an active/passive bond of two NICs. The number is increased in the current beta, codenamed “Project Orlando” — though i’m not sure what it will be by the ytime the software ships.
2) The Intel/AMD issue with live migration has nothing at all to do with paravirtualization — it has to do with direct execution passing through the CPU flags so CPU optimizations can be used. If affects all hypervisors. In some you can mask off some CPU flags — but once you’ve done this you’ve potentially traded off a lot of performance for the ability to migrate across platforms.
3) The new beta incorporates HA features, including the automated failover of the master to another node.
4) It also includes active/active teaming.
5) The NetApp integration is based on iSCSI, not NFS. But NFS servers — any NFS server — will deliver fast cloning and thin provisioning. The power of the NetApp adapter is thast it does it using the hardware capabilities.
And, sorry, when I started to answer I hadn’t intended there to be so many “in the new beta” answers… so “misconceptions” was a bit string. sorry.
Another “in the beta” answer: up to a year of performance data, in standard RRD format, delivered in XML over a web service.
And: there’s more flexibility in NIC assignment, but our work has shown that there isn’t that much traffic or lag to live migration dictating the use of a dedicated NIC.
And “string” was a bit typo-y… I meant “a bit strong,” of course. Duh. Fingers not working.
Roger, I understand your comments about CPU flags preventing migration from AMD to Intel or vice versa (and you’re right, it does affect all hypervisors with regard to live migration). But how is this applicable even in a cold migration?
Cold migration is not an issue.
Roger and Matt - I have updated the post to reflect your concerns and clarifications. Thank you very much for contacting me! Please look it over and let me know if there is anything else that is inaccurate. Also, my current knowledge base only extends to the current version. I would be happy to keep this up to date as XenServer 4.2 is released. Thank you!
[...] Citrix XenServer for the ESX Engineer [...]
XenServer 5 is out now. Adds loads of features, check it out. http://www.xenserver5.com
James - Thank you very much!!