Blog posts tagged with 'xenserver'

The new XenApp template for XenServer has generated a great deal of interest. There have been a several posts about XenApp on XenServer on the Citrix Blog (read Dan Feller's posts here, here, here and here). You can listen to an interview with Dan about this topic as part of the Citrix Delivery Center podcast here.

Recently Laura Whalen in our Solutions Marketing team put together an excellent slide presentation that covers the reasons why you would want to virtualize XenApp on XenServer.

One of the first few slides of the presentation reviews the business case for virtualization based on data from IDC and Gartner. It occurred to me as I reviewed this slide that this might be a good opportunity to add in some slides I recently put together for a different purpose.

A couple of months ago I was asked to give a presentation to some non-technical business leaders in my area about virtualization. As I thought about how to explain to these CEO's and CFO's why virtualization gets so much buzz, it seemed obvious to focus on the costs savings. In my opinion, the server consolidation and costs savings created by server virtualization are a primary driver in most companies first foray into server virtualization. Rapid deployment, high availability and disaster recovery obviously play a huge role in expanding the reach of virtualization, but in my experience the costs savings of consolidation are the biggest initial factor. The ridiculously high costs of energy these days make this costs savings even more important.

After making that decision, I decided to take some data I saw in a webinar by John Humphries of IDC and Simon Crosby of Citrix (archive here) to use as the basis for the presentation to these business leaders.

Of course, a slide presentation full of numbers is no more effective than a presentation filled with technology jargon. I decided to use as many visuals as I possibly could so I did not put the audience to sleep in the first two minutes. I added in numerous stock photos (mostly from istockphoto.com), some public domain pictures from USA.gov and a few photos and screen shots of my own to make a very visual presentation. I have taken a few slides from that deck and added them into the deck built by Laura Whalen.

The template for the other slide deck included a black background. I was not able to get the graphics to work properly in the standard Citrix template (with a white background) without many hours of pixel by pixel editing. I was able to use the transparent re-color feature of PowerPoint 2007 to convert the graphics from Laura's presentation to work with a black background, however.

My Frankenstein presentation creation is embedded below.

(click here to see the presentation in full screen)

Scalability of XenApp on other virtualization products has prevented many from using server virtualization with XenApp. One of the highest priorities after the acquisition of XenSource was to improve this scalability. The new XenApp template does this. You can virtualize the management components of your XenApp farm and individual XenApp servers to gain the availability, management and disaster recovery benefits. We have found that for many resource intensive applications a one vm to physical server provides the best scalability. You can still gain the availability, management and recovery benefits for those servers.

Since there are many notes included with this presentation (mostly from Laura) I have uploaded a pdf of the notes pages (in a zip file to shrink the size a bit).

Provisioning Server 5.0 was recently released. Provisioning Server 5 is included in the Platinum versions of XenServer 5 and XenDesktop.

See earlier posts (here here and here) for other deep dive presentations.

Over at Shannon Ma Virtualized I've recently blogged about using the XenServer 5.0 SDK to take and revert snapshots. Check out the post here.

There is an interesting debate going on over on the Google cloud computing group that also helps point out some of the appropriate use cases for cloud computing. The example used is a simple comparison of Amazon EC2 vs. purchasing a set of servers for development purposes ( I have added some additional costs and scenarios below ) This example also assumes the servers fit in existing space and either environment would be managed by existing staff.

 On the surface it's apparent that EC2 is significantly more expensive if the set up is utilized 24x7x365, even a 40 hour week yields a slightly higher cost. So where is all the savings ? What's all the hype about ? This simple example does point out that the Cloud is not always a more cost effective solution it really comes down to what is the particular use case and alternative costs. For example if there is no space available or the existing space has reached the power limits of the facility ( a more common occurrence ). That means that the likely scenario is finding a Colo facility to provide space power and bandwidth. Depending on location and bandwidth usage this could easily cost $8,000+ per year plus additional remote administration hardware and service fees, effectively increasing the annual cost of purchased equipment to near $ 14,000. Although this option is still less than Amazon if utilized 24x7x365, it now is significantly more than the cost of the 40 hour week at EC2 which may be reality for a development environment. And if you only need the setup for a month of dev or testing Amazon becomes a no brainier.. put on your credit card !
What both examples point out are the fact that there is single answer. In fact the right answer for many companies might be premise plus cloud. In order for this to work for a single workload however a seamless connection would be required, recognizing this has led to the Citrix Cloud Bridge based on our WANScaler acceleration technology. In fact, Citrix is in the unique position to be able to assemble the prerequisite technologies that make the C3 Citrix Cloud Center an optimized solution for many scenarios.

There are many other pro's, con's and hidden costs of each option, I am interested to hear what the community has considered regarding Cloud economics and/or other factors.

It's that time in the XenApp world again... Migration.  With the release of XenApp 5, many of you are contemplating a migration.  Why is migration such a big deal? I've heard numerous reasons like "It takes a long time to test my applications with the new XenApp (especially true if there is a new operating system involved)", "It takes a long time to rebuild my servers as I have to update my server build scripts" or "My current XenApp environment works fine, so why change it".

Those were all good points a few years ago.  But with the enhancements and optimizations made on XenServer for XenApp virtual machines, it is a great time to test server virtualization for XenApp to simplify migration.  And if we virtualize the XenApp servers, migration to XenApp 5, 6, 9, 11 or even XenApp 243 will be even easier (of course we will have changed the product name a few times. Let me hear a Hallelujah for HomerFrame or XenHomer).

But if we are going to migrate to XenApp 5, why not make the migration easier. Just how will XenServer make migration easier?  That is a great question, and I'm glad I asked it

Hardware
First, part of a new XenApp version means organizations will have to update their server builds.  Many of the server builds I've seen are complex scripts or require many manual changes once the build is complete.  Many times, there are multiple builds because of differences in the underlying hardware.  With XenServer , the links between the OS and the hardware are cut resulting in the ability to create a single build that can span multiple hardware variations.  How many fewer images will you now have to maintain?  Simplified

Optimization
With XenApp, you want to get the most users out of  your hardware.  This has been true with previous versions, is true with XenApp 5 and will be true in the future versions.  With a new OS and a new XenApp, do you have any idea how much hardware you need to support your users for the different application sets?  This is a challenge, especially when trying to design the new environment.  When you designate a server for a certain function, it is awfully hard to change the server's function, unless you virtualize.  With XenServer, you can make a virtual machine into anything you want.  You can move the running virtual machine to another physical server without the users ever knowing.  With XenServer and XenApp, you are no longer stuck in your static environment; instead, you are dynamically changing the environment based on the needs of the business. Simplified

Maintenance
How many of you like spending your days patching servers?  Not many.  Unfortunately, with each piece of software, there will undoubtedly be patches. With physical servers, you have to patch each server. With server virtualization, you still have to patch each virtual server.  But with XenServer Platinum, you only have to patch your base image, which is delivered to the virtual server via Provisioning Server.  If I have one XenApp image for SAP and another XenApp image for all of my other applications, I only have to patch both of those images.  Those images are then streamed to hundreds of physical or virtual servers.  Simplified

Evaluate
How could we do a migration without evaluating the apps and OS and XenApp configuration? This is critically important, especially if you are upgrading to a new OS like Windows Server 2008. With XenServer Platinum, the evaluation and testing phase is simplified.  How do you typically do this?  Well, you build the environment in a test lab.  You run test, modify, re-test. The cycle continues until a golden image is created.  That image must be used as a guide for rolling into production.  If you use scripts, you have to figure out how to script the build process to mimic your image.  If you use cloning solutions, you have to modify based on hardware.  If you use Provisioning Server, which is part of XenServer, you take your server, create a Provisioning Server image, and copy the image to production for delivery.  Simplified.   

Rollback
Let's say you upgraded without doing a proper test (shame on you).  As it turns out, one of the applications, which unlucky for you, is mission critical and is not working correctly.  What do you do?  Well, you have a few options:

• Try to troubleshoot and fix. You will be under the gun to get it fixed quickly as the business needs the application.
• Rebuild the physical server with the old setup. This will take a few hours for the build to complete and configure the applications.
  

Neither of those options sounds good to me.  Instead, if the environment was virtualized with XenServer Platinum, you would easily be able to change the version of XenApp delivered based on the Provisioning Server image you associated with each target device.  Simplified

XenServer for XenApp can simplify migrations by focusing on the areas of Hardware, Optimization, Maintenance, Evaluation and Rollback (This is what I like to call the HOMER Criteria).   It's a great way to get more done without working harder.  You get the migration done faster while providing a more dynamic environment for the business. 

Daniel

Well, the big launch of XenServer 5 has gone smoothly, and with it have arrived a flood of questions about how exactly the new High Availability functionality works.  I'll use this post to explain the overall architecture of HA in XenServer 5, and also how some of the fault detection and failure planning works.

Fundamentally, HA is about making sure important VMs are always running on a resource pool. There are two aspects to this: reliably detecting host failure, and computing a failure plan to deal with swift recovery.

Detecting host failure reliably is difficult since you need to remotely distinguish between a host disappearing for a while versus exploding in a ball of flames.  If we mistakenly decide that a master host has broken down and elect a new master in its place, there may be unpredictable results if the original host were to make a comeback!   Similarly, if there is a network issue and a resource pool splits into two equal halves, we need to ensure that only one half accesses the shared storage and not both simultaneously.

Heartbeating for availability

We solve all these problems in XenServer by having two mechanisms: a storage heartbeat and a network heartbeat. When you enable HA in a pool, you must nominate an iSCSI or FC storage repository to be the heartbeat SR. XenServer automatically creates a couple of small virtual disks in this SR. The first disk is used by every physical host in the resource pool as a shared quorum disk. Each host allocates itself a unique block in the shared disk and regularly writes to the block to indicate that it is alive.

I asked Dave 'highly available' Scott, the principal engineer behind HA about the startup process:

"When HA starts up, all hosts exchange data over both network and storage channels, indicating which hosts *they* can see over both channels; i.e. which I/O paths are working and which are not.  This liveness information is exchanged until a fixed point is reached and all of the hosts are satisfied that they are in agreement about what they can see.  When this happens, the HA functionality is 'armed' and the pool is protected."

This HA arming process can take a few minutes to settle for larger pools, but is only required when HA is first enabled.

Once HA is active, each host regularly writes storage updates to the heartbeat virtual disk, and network packets over the management interface.  It is vital to ensure that network adapters are bonded for resilience, and that storage interfaces are using dynamic multipathing where supported.  This will ensure that any single adapter or wiring failures do not result in any availability issues.

The worst-case scenario for HA is the situation where a host is thought to be off-line but is actually still writing to the shared storage, since this can result in corruption of persistent data.  In order to prevent this situation without requiring active power strip control, we implemented hypervisor-level fencing.  This is a Xen modification which will hard-power the host off at a very low-level if it doesn't hear regularly from a watchdog process running in the control domain.  Since it is implemented at a very low-level, this also covers the case where the control domain becomes unresponsive for any reason.

Hosts will self-fence (i.e. power off and restart) in the event of any heartbeat failure unless any of the following hold true:

• The storage heartbeat is present for all hosts but the network has partitioned (so that there are now two groups of hosts).  In this case, all of the hosts which are members of the largest network partition stay running, and the hosts in the smaller network partition self-fence.  The assumption here is that the network outage has isolated the VMs, and they ought to be restarted on a host with working networking.  If the network partitions are exactly the same size, then only one of them will self-fence according to a stable selection function.
• If the storage heartbeat goes away but the network heartbeat remains, then the hosts check to see if they can see all other hosts over the network.  If this condition holds true, then the hosts remain running on the assumption that the storage heartbeat server has gone away.  This doesn't compromise VM safety, but any network glitches will result in fencing since that would mean both heartbeats have disappeared.

Planning for failure

The heartbeat system gives us reliable notification of host failure, and so we move onto the second step of HA: capacity planning for failure.

A resource pool consists of several physical hosts (say, 16), each with potentially different amounts of host memory and a different number of running VMs.  In order to ensure that no single host failure will result in the VMs on that host being unrestartable (e.g. due to insufficient memory on any other host), the XenServer pool dynamically computes a failure plan which calculates the actions that would be taken on any host failure.

But there's one more complexity... a single host failure plan does not cover more advanced cases such as network partitions which take out entire groups of hosts.  It would be very useful to be able to create a plan that could tolerate more than a single host failure, so that administrators could ignore the first host failure and be safe in the knowledge that (for example) three more hosts could fail before the pool runs out of spare capacity.

That's exactly what we do in XenServer... the resource pool dynamically computes a failure plan which considers the "number of host failures to tolerate" (or nhtol).  This represents the number of disposable servers in a pool for a given set of protected VMs.

The planning algorithms are pretty complex, since doing a brute force search of all possible failures across all hosts across all VMs is an exponential problem.  We apply heuristics to ensure we can compute a plan in a reasonably small time:

• for up to 3 host failures, we do a comprehensive search which tries almost all permutations.  This covers corner cases such as having hosts or VMs with very different amounts of memory (e.g. 4GB vs 128GB).  Rather than calculate memory slots or otherwise approximate results, we just deal with them individually and give very accurate plans.
• for greater than 3 host failures, we make conservative decisions by approximating every VM to be as large as the largest, and considering each host to be the same as the most densely packed host.  We do not approximate the host memory, and so having pools with uneven amounts of host memory will be fine.  However, in approximate planning mode having a single very large VM will result in a low nhtol value.  If this is a problem, then try to reduce the nhtol or try to have a more even spread of VM memory sizes.

Since planning algorithms are designed for unexpected host failures, we only consider absolutely essential resource reservations which would prevent the VM from starting on the alternative host (e.g. storage is visible, and enough memory is present).  We do not perform CPU reservation on the basis that it can be optimised at a later stage via live relocation once the VM is back up and running.

Overcommit protection

We now have HA armed and a failover plan for our VMs.  But what if you want to make changes to your configuration after HA is enabled?  This is dealt with via overcommit protection.

The XenServer pool dynamically calculates a new failover plan in response to every XenAPI call which would affect it (e.g. starting a new VM).  If a new plan cannot be calculated due to insufficient resources across the pool, the XenServer will return an overcommitment error message to the client which blocks the operation.

The "What if?" Machine

This overcommit protection would be quite irritating if you have to keep trying things and seeing if a plan exists or not, and so we built in a "What If?" machine into XenServer to facilitate counter-factual reasoning.

When reconfiguring HA via XenCenter, you can supply a hypothetical series of VM priorities, and XenServer will return a number of host failures which would be tolerated under this scheme.  This lets you try various combinations of VM protections depending on your business needs, and see if the number of host failures is appropriate to the level of paranoia you desire.

This can even be done via the CLI, using the snappily named "xe pool-ha-compute-max-host-failures-to-tolerate" when HA is enabled.

The nice thing about XenServer HA is that it is done at the XenAPI level, and so  any of the standard clients (such as the xe CLI or XenCenter) or any third-party clients which use the XenAPI will all interoperate just fine.  The XenServer pool dynamically recalculates plans in response to the client requests, and so no special "oracle" is required outside of the pool to figure out HA plans.

Finally, HA makes master election completely invisible.  Any host in a pool can be a master host, and the pool database is constantly replicated across all nodes and also backed up to shared storage on the heartbeat SR for additional safety.  Any XenAPI client can connect to any host, and a redirect is issued to the current master host.

Protection Levels

Each VM in an HA pool can be either fully protected, best-effort or unprotected. VMs which are protected are all included in the failover planning, and if no plan exists for which they can all be reliably restarted then the pool is considered to be overcommitted.

Hugh Warrington (who implemented the XenCenter HA support) explained what use protection levels are:

"Best-effort VMs are not considered when calculating a failover plan, but the pool will still try to start them as a one-off if a host that is running them fails.  This restart is attempted after all protected VMs are restarted, and if the attempt to start them fails then it will not be retried.  This is a useful setting for test/dev VMs which aren't critical to keep running, but would be nice to do so in a pool which also has some important VMs which absolutely must run."

There are some advanced features which are only available via the CLI.   Each protected VM in an HA pool can be assigned a numeric ha-restart-priority.  If a pool is well-resourced with a high nhtol, then these restart priorities are not relevant: the VMs are all guaranteed to be started.

If more hosts fail than have been planned for, then the priorities are used to determine the order in which VMs are restarted.  This ensures that in over-committed pools, the most important VMs are restarted first.  Although the pool will start priority 1 VMs first, they might not finish booting before the priority 2 VMs, and so this should not be used as the basis for service ordering.

Note that it's very important to ensure that a VM is agile when protecting it by HA.  If the VM is not agile (e.g has a physical CD drive mapped in from a host), then it can only be assigned Best Effort restart since it is tied to one host!

XenCenter support for HA

The best practice for HA is not to make configuration changes while it is enabled.  Instead, it is intended to be the "2am safeguard" which will restart hosts in the event of a problem when there isn't a human administrator nearby.  If you are actively making configuration changes such as applying patches, then HA should be disabled for the duration of these changes.

XenCenter makes some common changes under HA much more user-friendly, which I asked Ewan Mellor (the principal GUI engineer) about:

• Normally a protected VM cannot be shut down via the CLI or from within the guest (a shutdown from within the guest will automatically restart it).  If you try to shutdown from XenCenter, it will give you the option of unprotecting the VM and then shutting it down first.  Thus, accidental in-guest shutdowns wont result in downtime, but administrators can still stop a protected guest if they really want to.
• If you want to reboot a host when HA is enabled, XenCenter automatically uses the hypothetical planning calculation to determine if this would invalidate the failover plan.  If it doesn't affect it, then the host is shut down normally.  If the plan would be violated, but the nhtol is greater than 1, XenCenter will give the administrator the option of lowering the nhtol value by 1.  This reduces the overall resilience of the pool, but always ensures that at least one host failure will be tolerated.  When the host comes back up, the plan is automatically recalculated and the original nhtol value restored if appropriate.
• If you try to apply a hotfix, then XenCenter will disable HA for the duration of the pool patching wizard.  It is important to manually keep an eye on hotfix application to ensure that host failures do not disrupt the operation of the pool.

So, I hope this short article has given you a taster... just kidding! This post is almost as long as my PhD thesis, but then, HA is a complex topic. Please do feel free to get back to me with comments and feedback about how we can improve it in the future releases, or if you just love it the way it is.  Many thanks to Dave Scott, Richard Sharp, Ewan Mellor and Hugh Warrington for their input to this article.

XenServer 5 has just been released, and now we can talk about experiencing zero downtime with live migration. With XenMotion, virtual machines can be moved from server to server without service interruption for zero-downtime server maintenance or to seamlessly balance available compute power within a pool of physical servers.

Here's a cool demo of this new XenServer 5 Feature:

Get your weekends back by managing and maintaining your physical hardware during business hours...

For more on XenServer 5 check out XenServer5.com

You can also download a copy of XenServer 5 right here.

And what a release it is. When we started this journey several years ago, the goal of the XenServer team was to create the industry's most comprehensive and open, bare metal virtualization solution on the planet. By nearly every measure, the XenServer 5 release meets or exceeds this objective. It's an entirely new approach to virtualization that makes the first-generation solutions look a bit complex, expensive and kludgy by contrast... kind of like comparing one of those 6-lb cell phones from the 1980s with a sleek new 3G iPhone.

Before I get into all the reasons you have to check out XenServer, I want to personally thank our fantastic team at Citrix who put in endless hours getting this release to market, as well as the hundreds of incredible customers who have discovered a better way to do virtualization and are passionate about helping us make it better with every release. Since the acquisition of XenSource by Citrix, we have grown the capabilities of the XenServer organization and have combined several existing Citrix groups into a tremendous new organization with some of the most talented engineers in the world. I am also pleased to report that every person who came to Citrix as part of the XenSource acquisition is still at Citrix and diligently working on fantastic new innovations. Citrix employs all of the original Xen inventors, so we continue to maintain a technical and leadership advantage when it comes to releasing new products. (As you know from watching all the recent top level departures from that other virtualization company in recent weeks, keeping top talent is no easy task). Software companies are based on people and a core few make all the difference. Tribal knowledge and expertise is very difficult to replace.

XenServer 5 is built on the Xen open source hypervisor, the industry's best, next generation bare metal hypervisor. We are pleased to have a robust community of over 50 major organizations that contribute to the innovation and continued development of this key technology, including all of the biggest names in server and microprocessor design. This incredibly powerful model ensures that the features in today's shipping version of Xen are already optimized to take advantage of next-generation capabilities in chips and servers that won't ship until next year, an advantage that will only increase over time. Xen has been available for many years and can be found in everything from supercomputers to cell phones. Xen is also the building block to most of the world's cloud computing vendors, including Amazon. The technology is robust, innovative, and freely available.

At Citrix, we take a snapshot of the open source Xen "engine" and build a great "automobile" around it called XenServer. With XenServer 5, this "automobile" contains a complete virtualization infrastructure with comprehensive management capabilities. We have designed this latest product to not only meet the competition in key areas, but exceed them in many dimensions. We've always said that the community development of Xen, along with the innovations and open ecosystem around XenServer, would eventually allow us to leapfrog a closed and proprietary first generation architecture. I am pleased to say that XenServer 5 accomplishes exactly that along so many dimensions.

When I talk with customers about XenServer and Citrix, they use words like innovative, open, partner-driven, and value. These characteristics have helped us double revenue every quarter, enter into strategic agreements with the largest server vendors in the world, and most recently, starting to win major enterprise deployments against a very entrenched competitor. Recent data shows that we are gaining market share even before the general release of XenServer 5. With our major OEMs, ISVs and channel partners trained and ready to deliver, it's going to be one heck of a year.

So, what's so great about XenServer 5? To begin with, it's amazingly easy to use, has unparalleled performance, is highly available, and has all the management bells and whistles an enterprise could envision. We've even taken things one-step further and enabled the product to provision both physical and virtual servers in a snap, saving up to 80% on storage costs over other solutions.

Here are some of the things that I am particularly excited about in this release:

Availability - We've added incredible new high availability and disaster recovery capabilities to this release. The new HA function allows for automated placement and restart of VMs in the event of a system failure. In addition, we've partnered with Marathon, giving us a seamless upgrade to the industry's best fault tolerance ("best of show winner at VMworld"), whereby applications can remain completely online and "compute through" any failure. No other server virtualization technology offers this level of availability and fault tolerance.

Performance - XenServer has the best performance of any product on the market, and this release builds on that by providing better Windows performance and enhanced memory management for improved performance of resource intensive workloads like Exchange and our own XenApp.

XenCenter Management - We've made many, many improvements to XenCenter, our easy-to-use management system. We've added a super cool Web 2.0 style search tool, performance monitoring, alerting and the new XenConvert utility for easy P2V and V2V conversions.

Storage Management Enhancements - This is an area I am particularly excited about. We've partnered with storage vendors to leverage native storage array capabilities by XenServer. This integration eliminates CPU-intensive storage operations to be performed by the host server and enables maximum use of array-based storage capabilities. We don't treat feature-rich storage arrays as just a dumb set of disks and load the host CPU with expensive storage operations as our competition does. In a word, we've done storage right.

While XenServer 5 can certainly stand on its own as a great server virtualization product, at Citrix, we've taken the game to the next level. XenServer is a fundamental component to the Citrix Delivery Center product family, enabling integrated application delivery from the datacenter to the desktop. The dynamic capability of XenServer provides the foundation for turning the static data center into a flexible and agile "delivery center". In addition to XenServer, Citrix Delivery Center contains XenApp, XenDesktop, NetScaler and the upcoming Workflow Studio tool for orchestrating it all together and making it easy to integrate our solutions with products you already have in your environment. The products are all designed to complement each other and we will continue to innovate around the integration of these products, always providing the best application delivery solution in the market. When it comes to application delivery, Citrix has it covered, and XenServer is a basic building block in the solution.

Finally, with the release of Microsoft Windows Server 2008 Hyper-V, some have suggested that Citrix and Microsoft are now competing head-to-head in the server virtualization space. Nothing could be further from the truth. The fact is that Citrix (and XenSource before the acquisition) have been collaborating with Microsoft for years to ensure that XenServer and Hyper-V are complementary solutions. The first thing you need to understand is that XenServer is a bare metal (Operating System agnostic) virtualization product while Hyper-V is a built-in part of the Windows Server operating system. We believe there are two types of users: those who want to perform virtualization as a bare metal extension of their hardware running multiple types of OS guests, and those who want to consume it as part of the operating system. Together, Citrix and Microsoft meet both of these market needs in a way that is flexible and interoperable - giving customers the best of both worlds

XenServer will always be bare metal, will always have great performance and leading-edge features, and will always be open. Additionally, we will take advantage of Hyper-V deployments in the future by delivering advanced XenServer capabilities on top of the Hyper-V installed base. This is a playbook Citrix and Microsoft have run successfully for years. Our philosophy at Citrix is all about customer choice and market coverage - it's a customer-first strategy we believe in and are excited about bringing to the rapidly-evolving server virtualization market.

XenServer is here and ready to deliver. Before you lock yourselves in to a proprietary system, I encourage you to try XenServer. If you're anything like the growing list of CIOs and IT managers who fill my in-basket each week, you're going to love what you see. But hey, I know I'm a bit biased. Why don't you download a copy today and try it out for yourself. I'd love to hear what you think!

Peter Levine

Executive SVP & GM, Virtualization & Management  Division

Learn more at  http://www.xenserver5.com/

One of the attractions of virtualization is the ability to deploy applications as pre-built virtual appliances. An article in CIO Magazine describes a virtual appliance as "an application is designed, certified and delivered, with its own little OS, to run as a virtual machine on your existing physical server, or to run in a VM via a "cloud computing" service like Amazon's." Virtual Appliances are expected to provide rapid deployment, simplified support, improved performance (OS and Application Tuned by ISV), and increased security. There are many advantages to virtual appliances. But is this deployment method the best solution to your deployment issues?

With all the buzz about virtualization and cloud computing, the interest level from both IT departments and vendors in virtual appliances is rising rapidly. Citrix has offered an Evaluation Virtual Appliance of XenApp for over a year. It has been downloaded over 11,000 times, according to Kurt Moody. Microsoft nows has virtual appliances for Windows Server 2008, System Center Configuration Manager, SharePoint Server 2007, Exchange Server 2007, and more.  Many virtualization vendors like Marathon Technologies, Platform Computing, Fortisphere, VMLogix, deliver their product as a virtual appliance.

Some application vendors have also jumped on the virtual appliance bandwagon, such as Business Objects and Satori. Several virtual appliance sites have been launched, included rPath, VirtualAppliances.net and JumpBox.com in addition the the existing VMWare Virtual Appliance Marketplace. Even Paralells has started offering virtual appliances from their website.

There are some concerns about this new model. As this article points out, there are questions about licensing of the OS and application (especially for Windows based applications) as well as export and security issues.

With all these new virtual appliances becoming available, I am curious to know if you use virtual appliances, and, if so, for what purposes? What do you see as the advantages and disadvantages of virtual appliances?


Please vote in the polls below. Once you have voted, please post in the comments if there is anything else you would liek to see from virtual appliances.-

Have you ever used any virtual appliance?	Choose
Yes
No

If you have used a virtual appliance, did you use it in test, production or both??	Choose
Test
Production
Both Test and Production

Dan Feller on my team contributed at least two posts on the topic of virtualizing XenApp servers on XenServer. Dan makes some excellent points and gives you plenty of business reasons why XA on XS is a good idea.

I am not going to re-iterate Dan's points here, but rather focus on another burning question in this context: How much of a scalability overhead can I really expect with my specific application? The typical consulting answer would be "it depends" and "we'll have to do a scalability / performance assessment to determine the specifics and best practices". So, we have done just that and used two popular enterprise class Applications: Siebel 8.0 and PeopleSoft 9.0. The Solution Center is one of the teams under the umbrella of Worldwide Consulting Solutions (Dan Feller's Integrated Solutions team is another) and focuses on these types of projects, which often involve third party applications and/or hardware platforms from our technology partners.
Recently, we looked at running the front-end of Oracle's PeopleSoft and Siebel applications on XenApp (both 32-bit and 64-bit platforms) and focused on comparing the user densities we could achieve on "bare metal" servers compared to running them on XenServer.
The results are published in two separate whitepapers (PeopleSoft, Siebel), which describe the test bed, test methodology, detailed results and interpretation. As Dan stated in his May 15th posting, the virtualization overhead can be as low as 6% for XenApp virtualization on XenServer, and our tests confirm this number. Of course, the numbers vary between the applications and platforms, and we describe all the details in the whitepapers.
Generally speaking, kernel memory limitations constitute the first bottleneck on 32-bit platforms, and our tests verified that behavior. Even with the popular /PAE switch, the kernel memory limitation remains at 2 GB. Therefore, you can expect a higher user density per physical server if you're running multiple 32-bit XenApp servers on a XenServer. You'd have to be cautious not to consume too many CPU cycles, which often become the next bottleneck once memory is no longer a major concern. Prices of multi-core, multi socket servers with plenty of RAM have come down significantly, so chances are that your latest servers have plenty of resources to run reliably in that configuration at a reasonable price:

According to this 1988 article, prices of 1 MB memory chips were as high as $60 (or $105 in today's money), while you can buy a barebones server with 64 GB of RAM for roughly $5,000 today. While I am on the topic of computer nostalgia: a 150 MB hard drive set you back over $8k in today's dollars way back when... 1988 was also the year Dan Feller was looking forward to seeing his favorite TV show getting its own slot in the line up and he is still enjoying it to this day, as you can see from the quotes in his postings on this site. But I am digressing...

The Solution Center also conducted detailed validation tests with Oracle to obtain validation status for running virtual images of the Web-, Application-, and Database servers of Siebel 8.0 , PeopleSoft 9.0, and Oracle E-Business Suite 12 on XenServer 4.1, so you can now be confident that the entire environment can be successfully virtualized on XenServer, allowing you to take advantage of XenMotion in case of hardware failure and other benefits.