This article originally appeared on SearchServerVirtualization.com.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
As you probably know, the IT industry is starting to migrate toward a 64-bit world. What is currently a slow movement will greatly accelerate in the near future when companies start releasing critical products in 64-bit versions only. If you jump on the bandwagon now, you have a great opportunity to reap significantly improved performance and to be at the forefront of today's scalability requirements.
Nevertheless, you'll have to balance the benefits of adopting 64-bit computing against the complexity of a migration, meaning the adoption can be an expensive challenge. To simplify the process, look to another IT phenomenon of the decade: server virtualization.
Migration to 64 bits is risky and must be planned very carefully. Why? First of all, the migration will be slow. The whole process could take up to 10 years to complete, during which time companies will have to handle mixed environments with 64-bit operating systems already available but some mission-critical applications still in 32 bits.
This process is similar to what we see on a smaller scale every time we deploy a new operating system upgrade. The full benefits from new technology enhancements are often unreachable because one business application or another is not supported in the new platform. CIOs sometimes have to wait years before starting to update infrastructures.
In the same fashion, we might have to wait for years before we embrace 64-bit technology and its benefits, until all the applications that drive our business are ported and proven to be reliable on the new architecture. The wait in this case could be much longer than waiting for an application to be ported from Windows NT 4.0 to 2000, and it could cost much more money.
A second problem comes in the hardware population. Deciding to approach 64 bits early in the industry conversion means having two different architectures to manage. But, worst of all, it means you'll have useless hardware as soon as you port applications from 32 to 64 bits.
Something you cannot avoid
Given all these issues, it's easy to think 64-bit migration is something that can be avoided until it is a de facto standard. But, even if you decide to postpone, migration is a step that you could be forced to do sooner than expected.
One after another, the biggest vendors will start offering their products exclusively in a 64-bit edition since the new architecture will be able to provide greater degrees of scalability and performance that customers have long required.
Microsoft is the first company making this step, announcing its intention to develop several products in 64 bits only, including the popular Exchange mail server, the new Windows 2003 Compute Cluster edition and one edition of its upcoming Windows Longhorn. You can expect a complete switch off of 32-bit production around 2010. Microsoft is already offering 32- and 64-bit versions for several critical products, like Windows XP and 2003, SQL Server 2005 and Visual Studio 2005.
The giant software maker is not alone; many other vendors, including market leaders like Apple Computer Inc., IBM, Novell Inc., Oracle Corp., Red Hat Inc. and Sun Microsystems Inc., are developing or already offering their products on the new architecture, claiming up to a ten-fold performance gain.
On the hardware side, both AMD Corp. and Intel Corp. count on technology being able to run 32- and 64-bit code concurrently and transparently, and both companies are selling only 64-bit processors for servers, desktops and laptops. Thanks to these vendors, the hardware side of the adoption will be complete much sooner than the software one.
How virtualization can help
To simplify managing a 32- and 64-bit mixed infrastructure, server virtualization surely appears to be the best approach during the migration process. At the time of this article, no virtualization platform has been written for the new architecture, but many are able to run 64-bit virtual machines, thanks to the new CPU capabilities mentioned above.
The market leader, VMware Inc., is able to run 64-bit guest operating systems in all its products, including the new ESX Server 3.0, the upcoming Server 1.0 and its popular Workstation 5.5.1. However, it has limitations on supported processors.
| Opteron revision E or later
Athlon 64 revision D or later
Turion 64 revision E or later
Sempron 64 revision D or later
| Intel EM64T
Note that there is no way to recognize revision of AMD CPUs until you test them, so VMware suggests contacting the vendor itself for help.
Xen 3.0 is able to run a mixed virtual infrastructure, too, and Virtual Iron (now based on Xen) will be able to run mixed virtual infrastructures as of release 3.0, which is expected at the end of the year.
Microsoft will support 64-bit host operating systems within its Virtual Server 2005 R2, thanks to the upcoming Service Pack 1, but the company has decided to await its Windows Server Virtualization before it runs 64-bit virtual machines. Because Windows Server Virtualization is expected in two years, we can safely assume Microsoft technology is not a viable solution for 64-bit early adopters.
Thanks to VMware, Xen, AMD, Intel and others that will come, we can expect a smoother and cheaper adoption of next-generation architecture.
Depending on your business needs, you could approach the migration with two opposite strategies.
The first one consists of moving existing 32-bit applications into virtual machines, while modernizing the hardware population and testing new products on the new servers. In this way, virtual machines will act as proven solutions on standby when we decide to adopt 64-bit applications, and they will do so without requiring significant extra efforts in maintaining two different machine sets. And, as a side benefit, dismantling 32-bit servers will proceed much faster.
This strategy is the most aggressive and is probably better for companies that wish to gain benefits from new architecture as soon as possible.
The opposite approach is to maintain the existing 32-bit hardware population and carefully introduce 64-bit new applications in virtual machines in which new products can be tested and verified. The huge lack of 64-bit drivers for many devices makes virtual environments a more stable platform in which to work.
This second strategy fits better in mission-critical scenarios, but it's likely to force virtualization adoption. If at a certain point the company decides to move applications back onto physical hardware, the whole process could be painful. For this reason, it's best to take this path only if server consolidation was already part of the plans.
In many cases, companies will find it useful to adopt both strategies at the same time, depending on their departments.
Whichever direction you adopt, as of today your only option is to buy a 64-bit physical host on which to install a 32-bit operating system. Luckily, this won't hurt, because at the right moment -- when virtualization firms are ready to offer 64-bit solutions -- we'll be able to change the host OS and the virtualization platform without rebuilding the existing virtual machines.
And, thanks to high-availability solutions, the operation will even occur without business interruption.
Alessandro Perilli, a self-described server virtualization evangelist, launched his influential virtualization.info blog in 2003. He is an IT security and virtualization analyst, book author, conference speaker and corporate trainer. He was awarded the Microsoft Most Valuable Professional for security technologies by that company. His certifications include Certified Information Systems Security Professional (CISSP); Microsoft Certified Trainer (MCT); Microsoft Certified System Engineer w/ Security competency (MCSES); CompTIA Linux+; Check Point Certified Security Instructor (CCSI); Check Point Certified System Expert+ (CCSE+); Cisco Certified Network Associate (CCNA); Citrix Metaframe XP Certified Administrator (CCA); and others.