Just completed 8 city roadshow with Dell and Red Hat, talking to customers face to face over lunch about how a migration should be planned and done from UNIX/RISC to RHEL/Intel/Dell. 

I had opportunities to attend two of the seminars in different cities, meeting few different customers.  Customers came to our seminar to look for a template to quickly develop a plan that could also be approved quickly and get the project going to counter the enormous management pressure they get to do more with less. 

Most of the customers I had conversations with were from medium size business. 

One customer clearly said, it is no brainer, there is no reason to advocate to purchase new AIX/Power or Solaris/SPARC machines any more. 

The other customer said, much of the knowledge accumulated to manage UNIX servers can immediately applied for migration activities while he saw the needs to get the UNIX administrators trained on RHEL through the training programs offered by Red Hat. 

Consistently, there were the nuance that customers needed to act now, for a short term result. 

For those who needs to get going on planning, Red Hat has put together a very good migration guide. The document helps you start thinking about and resourcing your migration.   Register, to get started.  Also, a lighter version to get an idea. 

Please contact RHEL, Dell, or Intel representative for the next steps, and if you don’t have such resource, let me know.  I’ll help dispatch one to you. 

Looking for an excuse to sneak out of the office for a RISC migration seminar?  Here's one for you which you can't resist.  How about a seminar associated with a spectacular lunch at a great Greek restaurant in the city of San Francisco? 

Dell, Red Hat, and Intel are hosting a RISC migration seminar over lunch, during Oracle Open World next week. 

Register here for the seminar held at the Kokkari restaurant, 12pm, Wednesday, October 14.  It is not too late.  Small number of seats still available. 

Don't miss this opportunity to learn when and how the migration should be done and ask questions to Dell/ Red Hat/ Intel team members present on site.  I am hoping the hosting members do their job not just busy enjoying lunch. 

There has always been a Linux option for enterprise workloads.  But today, with greater uncertainty and greater pressure for cost reduction, the option, these days, is now THE course to take.  But how? 

Here are two whitepapers we developed with our friends in the industry, giving data center managers guidance and directions on what to look for and what actions could be taken for UNIX/RISC to Linux/Intel migration. 

With Ziff Davis, Dell, Red Hat...  http://communities.intel.com/docs/DOC-3631;jsessionid=BF37C65ED3F67E934DD8DB579D28898E.node3COMS

With Red Hat...  http://communities.intel.com/docs/DOC-3642;jsessionid=BF37C65ED3F67E934DD8DB579D28898E.node3COMS

Also, visit http://www.redhat.com/intelligence/ for more information on the RISC migration program we run with Red Hat.

Steve Phillips with Cisco gives us a tour of "The Datacenter of the Future". Check out this short video:

What does your Datacenter of the Future look like? How can Intel and Cisco help?

Here is another happy customer, YPF Gas, successfully reducing cost by migrating Oracle, SAP, and other workload from multiple proprietary UNIX environments to open, industry standard-based.  The choice was Red Hat Enterprise Linux with virtualization, running on Intel Xeon processor-based servers.  We can see from the number of times the word “cost” is used in also published press release, it is the major challenge for IT mangers and we have solution for it.  YPF Gas declares “now, more than 80 percent of (our) Oracle databases and 90 percent of (our) SAP applications run on Red Hat Enterprise Linux 5 with integrated virtualization on Intel Xeon processor-based servers…” 

Also, don’t forget to register and participate in the Red Hat-Intel joint webinar, How and When to Migrate to Red Hat Enterprise Linux on Intel Xeon processors, tomorrow at 2pm eastern. 

This past April, as Intel was releasing their new Xeon E5500 series processors, we showed you some remarkable test results demonstrating a solid 53% performance improvement between E5400 and E5500 based servers when running a DBHammer SQL Server 2008 workload http://community.citrix.com/pages/viewpage.action?pageId=73564465. We now wanted to move onto a workload that represents the largest segment of the Citrix user community, XenApp. More specifically, XenApp 5.0 virtualized with the new XenServer 5.5. As we've seen in previous similar virtualization performance tests with XenApp on XenServer, when the XenApp guests are 32 bit (the majority of XenApp users still use use 32-bit applications), the opportunity for server consolidation can be significant. We wanted to see just how good the server consolidation opportunity is when an Intel Xeon E5500-based server is used as a XenServer host. In this case, we looked at how the server consolidation might look when going from 2.93 GHz Xeon X7350 physical XenApp servers to 2.93 GHz Xeon E5570 XenServer hosts.

For the purpose of this test, we ran the physical XenApp server with a single 32-bit workload (Windows 2003 SP2 with MS Office). It was given 2 CPUs and 4GB RAM, typical for this XenApp server workload. Using EdgeSight for Load Test (ESLT) version 3.5 we established a baseline of 25 seconds for users to login, run a standard MSOffice task script, and then logout (including network connect time). We added users until the threshold to run this sequence reached a latency of 30%, at which point the server was deemed to be at capacity. Using this configuration and test program, the maximum number of users was 47. This was a relatively small, single physical XenApp server, so 47 concurrent users was considered respectable.

Since we were testing with a Xeon E5570 server with dual quad core CPUs and 32 GB of RAM, we wanted to see how many users we could get onto a single host using multiple XenApp VMs, each with the same resource configuration as we used in the physical server test. We built 2 vCPU, 3.5 GB RAM XenApp virtual servers on the E5570 and ran two tests using the same ESLT workload. The difference between the 4 GB of RAM used in the physical server test and 3.5 in the virtual server test is due to the need for memory overhead when running multiple VMs. In the XenServer setup screen, we selected the option of running XenApp which automatically configured the VMs with the appropriate amount of shadow memory for XenApp workloads.

We also wanted to see the impact of hyperthreading to VM density per host as well as the number of concurrent users per VM. Intel describes hyperthreading as “delivering thread-level parallelism on each processor resulting in more efficient use of processor resources, higher processing throughput and improved performance.” It would be interesting to see how many more concurrent XenApp users we could get with an upgrade to the E5570 and by virtualizing with XenServer 5.5 and then see how many more users we might get once hyperthreading was enabled. Would hyperthreading allow us to run twice as many VMs on a single host? To find out, we ran our first virtualized XenApp test with hyperthreading activated and then repeated the test again with it turned off. With hyperthreading, the first thing we noticed was that even though there were only 8 CPU cores on the E5570 host server, XenServer was able to see 16 vCPU cores as resources available to be assigned to VMs. As a result, we were able to successfully run a maximum of eight VMs, each with the necessary 2 vCPU cores, generating an average of 69.25 users per VM for a total of 554 users.

When we ran the second test, this time with hyperthreading turned off, and noticed that the number of users per VM increased slightly to 88. However, the maximum number of VMs was now only four, due to the fact that we now only had 8 vCPU cores to work with. As a result, the total number of users for the host was now only 352.

In the end, we discovered that while hyperthreading doubled the number of assignable vCPU resources, it didn’t directly translate to a 2:1 increase in the number of users per VM. That’s a reasonable trade-off, since hyperthreading effectively doubled the number of VMs that we could create with the same number of CPU cores. So, while were able to generate 6.5x the number of concurrent XenApp users onto a single Xeon E5570 host server without hyperthreading as compared to a single X7350 physical XenApp test server, the number of concurrent users increased to an incredible 10.8x with hyperthreading. That’s a remarkable server consolidation opportunity for any 32-bit XenApp administrator. And while XenApp will virtualize very nicely with XenServer on that same dual quad core X7350 server, remember that the number of users per VM when using this test schema will be 47. Since hyperthreading isn’t available on the X7350, the maximum number of VMs on the X7350 host would be 4 making the maximum number of concurrent users 188. Not bad, but nowhere near the 544 concurrent users we get on the E5570 with hyperthreading. That’s an increase of 356 users, almost three times the number of concurrent XenApp users.

Pretty hard to ignore.

As we’ve seen here, the promise of Intel’s Nehalem technology is being realized in some very practical ways. As a result, the performance bar for XenApp, when virtualized with XenServer, is now higher than ever.

Here's the 5th video in my VMWorld Chalk Talk Series. In this one, Gerhard Schlabschi, Systems and Storage Marketing with Sun Microsystems gives a chalk talk on various virtualization systems and discusses some of the trade-offs in a virtualized environment. Enjoy .