Recently I've had a chance to partake in Partner Training for Citrix XenServer 4.0 (passed the certification test with a 87%) and to be honest... I was simultaneously impressed and disappointed in XenServer 4.0. Yes, I know it has only had a hand full of developers working on the XenSource code prior and now with the Citrix acquisition, they will greatly increase the numbers of developers. But I can't review what hasn't been publicly released or is currently the "roadmap" for future release.
Background for this article: I've been working with VMware since ESX 1.5.x (sometime in 2002), and I've loved it ever since. I've setup a few Microsoft Virtual Server 2005 R2 boxes (against my will). I've read articles on Virtual Iron and SWsoft Virtuozzo, but never set either up.
I'm not trying to make this document a feature comparison or a "XenServer vs. VMware" ESX article. You can google for that or do your own bake off of their technologies. I'm trying to relate the XenServer technology as to how it would be used in an IT Infrastructure using my background in Virtual Infrastructure design and implementations.
If you want a brief history of XenServer (with its roots in Xen and XenSource), check out this article by Gabe Knuth. If you are looking for more information on XenServer, here are some links to the documentation:
Installation
The installation is fairly simple. The installer is still a text based interface and the only real options are the network configurations (IP, Gateway, Subnet, DNS, NTP etc). There is no disk partitioning screen as XenServer automatically sets the partition table. The "10 minutes to virtual" motto is pretty accurate. During the training, you also boot of a CD and then connect to a HTTP site to install. They also allow NFS and FTP for installation points. You can also use XML to create an answerfile.
XenServer's claim to fame is performance of its paravirtualization model especially in Linux based VMs. I really didn't have time to compare performance or to put a heavy load on the servers, but I thought I would put this out there for someone credible (not paid by Citrix or VMware or MS) to do some performance testing.
Management
All management is performed via XenCenter. XenCenter comes automatically with the product at no additional cost and is a Windows-based application. There is no need for a database server as the configurations are held within the XenServer host(s) or the Resource Pools (master/slaves model). Resource Pools are how XenServer groups hosts for shared storage and identical network configurations to allow for XenMotion (Vmotion for Xen).
XenServer allows you to create templates (Gripe: for Windows you have to perform the sysprep./newsid steps in the Virtual Machine for the new identity on the network) and ships with some Debian pre-built templates for quick deployment. Networks, Storage Repositories, Console access (host and virtual machine), some basic logging, very basic reporting, and of course the management of the Virtual Machines are all performed within XenCenter.
Not requiring a database means the data is stored on the XenServer hosts in a master/slave model (when using Resource Pools). This sounds very familiar... like the early days of Master and Backup Browsers in MetaFrame. There are automated steps and manual steps to recover from a master host failure or temporary outage, but during the outage you will only be able to perform certain emergency tasks. There is currently a recommended maximum of 16 XenServers in one resource pool. I do really like that as XenServer hosts are added to the Resource Pool, they inherit lots of shared configuration information (like Shared Repositories and Network). Citrix should keep expanding on this feature of automating shared configuration to ensure consistent server builds and configuration (very common mistake in Virtual Infrastructure).
To manage the XenServer's via XenCenter, you must have an account on the XenServer hosts. More work for Windows administrators (face it - this is the largest target of users) as they must manage via the command line interfaces to perform many tasks.
Storage Repositories
Storage Repositories are a location to store Virtual Machine disks or ISOs for your XenServer infrastructure. The Storage Repositories for Virtual Machines can reside on local disk, NFS, or SAN (iSCSI Software, iSCSI hardware, or Fiber). ISO Storage Repositories can reside on Windows shares (CIFS) or NFS. I loved having one ISO library available to my VMs and via UNC path without having to configure each host for a SMB connection.
So here is the weird part. It is understandable that certain types of storage result in different features (VMware ESX has the same thing), but XenServer's favors software based connectivity over hardware based connectivity.
- iSCSI Software initiators and NFS have more features (both support XenMotion while NFS also support Fast cloning - differential disk of a base disk basically). XenSource calls these connections Enhanced Storage connections.
- iSCSI Hardware initiators (TOE cards) and Fiber have less features and neither supports XenMotion. XenSource calls these connections Basic Storage.
After thinking about it for awhile, it makes a little more sense. XenSource has way more control over software based connectivity and therefore the features can be 100% software based. However, this is something to think about when designing a Virtual Infrastructure for a client and whether XenServer makes sense.
Another interesting one is the lack of support for multi-pathing (redundant connectivity to the same storage location). This creates a single point of failure for any design. Reading some of the forums points to this being handled by the console via command line; it isn't support and can be a pain to configure. (Rumor: a white paper will be addressing this, but it is not built-in to the current release and 4.1 is rumored to have the capability.).
Networking
Networking is fairly straightforward but limited. One physical NIC equates to single virtual NIC or multiple virtual NICs that are VLANed. There is no binding or load balancing of multiple NICs. The host servers are limited to only 4 physical NICs.
Consider the following scenario (which seems to be the recommendation from the admin guide and training course)
- Dedicate one NIC to the XenServer's Console
- Dedicate one NIC for connection to the VM Storage Repository (since enhanced storage is recommended and that means NFS or iSCSI software).
- Leaving one NIC for Production VM network and maybe one for the DMZ or Test VM Network. (assuming no VLANing)
Without VLANing, you run out of physical NICs real quick. Plus either way (VLAN or no VLAN), there is not binding of multiple physical NICs to a virtual NIC. These are additional reasons to consider when designing a Virtual Infrastructure and whether XenServer makes sense.
Templates
XenCenter allows for Templates to be deployed and created. An existing OS can be converted to a Template for future deployment, but XenCenter requires any customization to the OS for the new identity be performed manually. (Example: You need to sysprep Windows 2003 to get a new SID, change its name in the OS, change its IP address, join to the domain, etc). Not automating this is risky and could result in a lot of human error in these steps. Make sure that is known during implementation and is documented thoroughly.
XenCenter does ship with some Debian templates (called Full Templates) that include the entire Operating System and a wizard to perform the new identity (Name Server, IP, etc). That is pretty cool. Wish there were a few more but that is pretty cool. I'd like to see them allow you to also link directly to some sort of web site where additional Full Templates (or virtual appliances can be downloaded). Would Microsoft allow a Full Template with a new identity wizard to be made available for its Operating Systems? A person can dream can't they?
Logs
Logging is very basic. Error logs can only be seen via the console and looking at the end of /var/logs/xensource.log via less or tail. They also have some command lines for exporting support information (xen-bugtool -yestoall) which can then either be copied to a local server or sent to XenServer support when requested (xe host-bugreport-upload host=SERVERNAME)
Logs can also be viewed for XenServer, the Resource Pool or the VM. Don't expect a whole ton of information at this time.
Reporting
Resource Utilization is the only thing that can be gathered for any reporting, but it only keeps the information for 15 minutes. Better hope you get there quick or your stats might be gone. I didn't expect much here, but 15 minutes is really low.
What does Citrix need to add to XenServer to be part of more Virtual Infrastructure Designs
- Production Data Center Readiness
- High Availability (I hear this a Coming Soon feature)
- XenCenter Management
- No Security Management rights - There is no way to control what user has access to what VMs, XenServers, or Resource Pools or what they can do to each of the resources.
- No Security Integration with Active Directory - This makes an IT Administrators life much simpler when rights can be assigned via AD. The target audiences for virtualization are Windows environments. Let make their job easier.
- No multi-user capabilities to XenCenter - No notification when anyone else is on the console. This could make for lots of headaches as environments get larger. At least "Notify" the new user when someone else is using already XenCenter.
- Logs/Reporting need to be improved for troubleshooting, event correlation and for identifying bottlenecks.
- XenCenter's Master/Slave recovery needs to be designed better.
- Networking
- More than 4 NICs on the Host - Not everyone has VLANs or knows how to use them. It also limits designs where the client wants to support multiple physical networks (Production, DMZ and Test/Lab all completely separate switches) from one host. Add on top the redundant connections they may wish to use, and 4 isn't going to cut it.
- Redundancy - Need redundancy for Networking or to allow greater network performance to the Virtual Machines
- Storage Repositories
- Redundancy - Need redundancy for path to the storage repositories (multi-path).
- Even out the features between Enhanced and Basic - Too many clients have made their choices on storage. It seems odd to clients that they pay the most money for the storage and then find out XenServer doesn't work as well with that type of storage.
- Supportability
- XenCenter Capabilities
- Network Configuration of XenServer Hosts from within XenCenter - Linux has too many files to modify to change networking. At least a wizard from the console command would help here.
- Automated Windows Template Procedure - Automatically sysprep a server to give it a new identity. I see this one causing lots of support headaches.
- More Guess Operating System Support - I would still would love to see NT (mostly gone but still hanging on) and upcoming major releases like Windows 2008 (even if it might be "experimental" as VMware calls the features)
- Get more 3rd party support - This may require opening up the API a bit more or working with more existing "virtualization friendly" partners to develop for the XenServer platform.
Summary
Like I said earlier, I was impressed with product during the training. As I gathered more information, I started see design questions that may lead the client or my design for a client down a XenServer path (or away from it for that matter). And that is what really matters most. Making proper technology decisions for a client that meets their technology and business needs. No questions on that one.
Citrix has a lot of work ahead of itself and VMware has a pretty good jump on them. There is room for many players in this market, but I don't see companies planning on buying multiple virtualization products. Clients are looking to standardize on one platform, get their people trained, and then findings ways to optimize. Adding an additional technology means there better be a darn good reason for it.
May all the racers approach the starting line.
Ready...
Set...
Virtualize!!!
It's going to be a fun next few years.