A couple weeks ago, someone sent me a link from the developerWorks PowerVM forum about installing Debian on a POWER7 box. The post was created by Tux11 (Dennis Schneck) who graciously agreed to create a developerWorks wiki.
News around the Linux on Power Community
By: Jeff Scheel.
A couple weeks ago, someone sent me a link from the developerWorks PowerVM forum about installing Debian on a POWER7 box. The post was created by Tux11 (Dennis Schneck) who graciously agreed to create a developerWorks wiki.
Here is the new Debian 6 on Power7 LPAR wiki. I strongly encourage that if you have interest, if you're running Debian today on POWER, or if you would like to doing so in the future, please help Dennis and the community keep this wiki alive and accurate. I cannot THANK him enough for his efforts in creating this and for his willingness to share!!!
By: Jeff Scheel.
It's been a few weeks since I have posted. I was on-the-road, doing what I affectionately call "dog on pony shows" where I am "just a dog." The trip started with 4 days of business meetings in Birmingham, UK. Most of these included presentations at the IBM STU on PowerLinux Trends and Direction as well as the IBM Software Development Toolkit. Following the event, we met with various customers, business partners, and system integrators in Bracknell, UK; Amsterdam, NL; and Brussells, Belgium.
Let me show my engineering background and provide my thoughts as a list (Sorry, Mom, I know paragraphs are preferred forms of writing, but as you know, I didn't did better in Engineering than English classes):
By: Jeff Scheel.
Life as the PowerLinux Chief Architect involves answering many questions, some of which need lengthy explanations. One such example is whether PowerLinux is a Power operating system or a Linux operating system. In some ways this discussion reminds me of the campfire scene from the 1986 movie Stand by Me where the boys deeply contemplate Disney characters. Essentially the discussion went this way: Mickey's a mouse, Donald's a duck, Pluto's a dog, what is Goofy? The discussion about PowerLinux generally follows similar flow: IBM i OS is a business operating system, AIX is a UNIX operating system, Linux is an open source (x86) operating system, what is PowerLinux?
Ironically, one of the answers to the "What is Goofy?" question, is "He can't be a dog. He drives a car and wears a hat." That sounds like some reactions we get to PowerLinux: it can't be industry standard because it runs on the Power platform. It must be IBM's own Linux. Pardon the pun, but many people believe that PowerLinux must be "Goofy".
Simply put, PowerLinux strives to be "a Linux" first. To break this premise would invalidate the core value of Linux as the most prolific, cross-platform operating system. PowerLinux supports this premise so confidently that we've included it in our value proposition: Industry standard Linux, tuned to the task. As I've discussed in previous blog entries, PowerLinux is the same Linux operating system by Red Hat and SUSE, built from the same source, comprised of the same package versions, and delivered on the same schedule. IBM embraces this commonality and further works to actively eliminate as many barriers as practically possible. For example, we are actively working in the grub2 community to enable Power as a supported platform. This will enable us to use the same bootloader as x86 in future Linux releases. While most end users will never see the bootloader, PowerLinux remains committed to keeping Linux standard.
In some specific instances we extend Linux capabilities with Power operating system capabilities. Examples of this scenario include tools which are common to other Power operating systems like the rsct tools for HMC-client OS communication, drmgr for dynamic LPAR operations, and lsvpd for reporting device information. Most of these tools have software that is enabled more efficiently by having a common interface. None of these tools replace existing Linux tools.
Where I draw the line in being a Power operating system is in areas which clearly have Linux equivalents. For example, installation from NIM servers is an area where PowerLinux has traditionally not invested. While it is possible to perform such installs and some folks have graciously documented how to do so, IBM invests very little in ensuring this capabilities work. Instead, we focus on Linux installation through kickstart, yast, and anaconda as enabled by the Linux vendors.
So, with those examples, I hope you now have a greater appreciation for PowerLinux and agree that we are a "Linux," not a "Goofy".
By: Jeff Scheel.
I hope you "Think" our Power Linux community is starting to come together. It's taking some time to bring the pieces together, but we're making progress. Since Rome wasn't built in a day, hopefully you'll understand if the Think Power Linux community takes a couple months.
Speaking of Rome and building, did you know that IBM's effort with Power Linux is over 10 years old. Yes, I was one of the original team members focused on putting Linux on the iSeries. That mission grew into the ppc64 kernel and glibc that ultimately became the core of today's shipping RHEL and SLES distributions. During that time, I've held lots of leadership roles, including manager, release architect, and various other IBM-speak titles which won't mean much to most people. I even managed to get one patch accepted into the kernel, quite an accomplishment for an IBM Manager. About 5 years ago, the Linux for Power mission merged into IBM's larger Linux Technology Center where we now work. This move combined our team with teams focused on doing platform independent Linux work as well as enabling IBM's System x and System z platforms -- effectively giving us access to a worldwide extended team of over 400 developers in over 40 countries. It's been lots of working getting this far, but also alot of fun working with a terrific team.
I've been with IBM 20 years. I started working on I/O adapters writing microcode for SCSI bus controller chips. Then, I joined the team which brought logical partitions (LPARs) to the iSeries (formerly AS/400) systems. This code base eventually became the design point for what we now call PowerVM on Power Systems. After getting our LPAR function under control, the next logical step was to add Linux to a partition and despite my doubts about the project, it's turned into quite the opportunity to impact the business. With one exception, a 2 year 'sabbatical" where I worked with the Blue Gene team on their Blue Gene /P product, I've been working with Power Linux.
Today, as the Chief Architect, I wear a variety of different hats. I like to tell folks that "architect equals fireman, traffic cop, politician, salesman, referee, switchboard operator, janitor, or as my colleagues affectionately call me, just a 'basic slug.'" Seriously, my day-to-day role is deciding how we spend our resource and setting technical direction. That means I help decide where the code gets written, but not actually writing the code. It also means that you'll find me filling in around the outside of the projects, giving presentations, answering questions, helping out where I can.
My personal focus this year is on our ecosystem. I'm helping where I can to get the Think Power Linux community off and running. Therefore, you'll find me creating wiki pages like the "Knowledge is Power" topic, writing blogs like this one, and answering posts to the message board. If you need help, check out the information in the community and then post to the message board if you can't find the needed information. I'm watching all posts and working to ensure that they get answered. If that doesn't work or if you want a more personal dialogue, feel free to drop me an email at the address in my profile (see the "General info" tab).
In the spirit of "ecosystem", I'd like to leave you with a couple useful Power Linux links:
Hopefully, you'll find at least one to be worthwhile.
Thanks for taking the time to read our blog. Hopefully, I've put a little more of a virtual "face" behind the name. Look for more posting from other Experts in the coming months.
Common questions around application binaries: What exactly does IBM mean by "Industry standard Linux"?
By: Jeff Scheel.
As I've often mentioned in my blogs, I like to answer questions which I've been very asked frequently. Today's topic provides more details about our marketing slogan "Industry standard, Tuned to the task". We've worked so hard to eliminate the myth that PowerLinux is different (see my blog What does IBM mean when it says, "PowerLinux?") that we're now getting questions like:
The short answer to all of these questions is the same, "No".
The technical explanation, stems from a fundamental component of computer architecture -- the processor. Every processor architecture has a different machine language (command set) that it supports. So, even though Linux is built from the same source code, using the same compiler, the final executable system code is different because the compiler "targets" (builds for, generates machine instructions for) the specific processor type.
For some people, this may make perfect sense if we talk simple "Hello world" application. If I compile it on my x86 PC at home, I understand that it would not naturally expect it to run on the Power System at work. In fact, if I build the application in both places, x86 PC and Power System, I will see that even the resulting binary is a different size, demonstrating the machine language between processor architectures are likely different.
Since the Linux operating systems is simply a large collection of programs, the same explanation applies to the operating system. Red Hat and SUSE build their distributions from the same source using the same compiler,s but generate different programs for each processor architecture. Then, they bundle and distribute all the programs for the operating systems on a specific processor architecture into different DVDs -- one set for x86, one for PowerLinux, etc.
Now, let's look at an installed image. Once I get that operating system running with the programs compiled for my architecture, the answer to the final bullet above should become obvious. The executable program is unique to the processor architecture. So, the migration of VMs must naturally stay on the same processor architecture. PowerVM can move VMs (or LPARs as I grew up knowing them) from different versions of the architecture such as POWER6 to POWER7, but it cannot be moved from POWER7 to Nehalem because the executable binaries only understandable to the processor for which they were built.
Hopefully, this now makes perfect sense. But if not, let me try one more analogy. If you and I were identical twins, dressed identically by our mother, and were trained to play the violin for the same number of years by the same teacher, we would play the same piece of music (say Fritz Kriessler's Praeludium and Allegro) differently. Why? Because our brains are different. Even though the source code (written music) is the same, the executable program (our playing of the music) would be different because our processors (brains) have a different architecture even though the computer systems has all the same components like I/O (violin) and chassis (clothes and body structure).
I couldn't resist the urge to use TLAs (three letter acronyms) to dispel the FUD (fear, uncertainty, and doubt) on my favorite topic, LE (little endian).
If you are like most customers (and my mother), the concept of data endianness rarely, if ever, enters your mind. You buy applications, operating systems, and computers. All you care is that the operating systems run your applications on the computer to accomplish your goals. If you have heard that Linux on Power is moving to little endian and are worried, your approach to survival is simple: focus on release planning details for your systems – applications, operating system, and hardware.
Who does care then about data endianness? Programmers, software vendors, hardware vendors and those 1% technology geeks who do development in the IT industry. These are the people who have noticed that the POWER8 hardware can operate with data in either big or little endian mode and for whom I wrote the “Just the FAQs about Little Endian” blog back in June. They appreciate how little endian simplifies their Linux applications running on both x86 and Power systems; they understand how little endian simplifies data sharing on disk or over the network between x86 and Power systems; and they drool over the potential of running GPUs (graphics processing units, sorry couldn't resist another TLA) on their Power Systems to create highly optimized applications common to scientific or analytic workloads.
But for the remaining 99%, what you need to know about LE can be simplified to the following key points:
Hopefully you now understand that you need not learn about esoteric programming concepts as we head into the brave new world of little endian Linux on Power. Instead, as we progress through this transition, if you simply spend a little more time in planning to double check support for your applications, operating systems, and hardware during each step, you will have success. That's what I'd recommend to my mother – just a little due diligence.
By: Jeff Scheel.
Two weeks ago, I blogged about my thoughts after attending Power Technical University in Miami. This week, I bring you my thoughts from our event in Copenhagen, Denmark.
It never ceases to amaze me what I learn at these events. While the topics I presented were identical to the session in Miami two weeks ago, I still learned a bundle from the Power Linux customers who attended in Copenhagen.
Here are my thoughts from this week:
If I met you in Copenhagen and you joined because of presentation, feel free to comment against this blog and provide feedback. Welcome to our community! Help make us better.
If you just follow along and my postings spur any thoughts or comments, feel free to comment as well. Did I spur any thoughts, comments, or questions?
Well, that's all. Thanks for Thinking Power Linux today.
By: Jeff Scheel.
What an exciting week in Miami, FL!!! I spent last week at Power Technical University, helping people Think Power Linux. We had lots of great discussions. A big "thank you" goes out to all who attended sessions, a bigger "THANK YOU" to those who asked questions and participated in the discussion.
Here are some my key thoughts from the event:
By: Jeff Scheel, PowerLinux Chief Engineer
A software provider recently said, point blank, at the beginning of our discussion, “Convince me that PowerLinux is not a new platform.”
The core of my answer went like this: the value of Linux is the same for software providers as it is for customers – Linux provides a single operating system environment across different hardware platforms. Customers and partners who have both x86 Linux skills and Power System skills have all the knowledge they need to run Linux on IBM Power Systems and PowerLinux servers. Customers and partners who only have x86 skills will need some training in PowerVM and the platform, but will quickly find commonality in the operating system.
This software provider's simple request strikes at the heart of the IT challenge – managing expense for the data center. Everyone is struggling to control software deployments in the enterprise. One can visualize this challenge as being depicted by a two-dimensional matrix (spreadsheet) of applications (across the top) against platforms (down the left side).
This complexity of this problem becomes most daunting when one considers two key factors:
The good news for all of us in the IT industry is that Linux and open source are driving commonality into software and redefining the “platform” to be the most basic components of the hardware platform. To fully understand this conclusion, we need to look at how the definition of “platform” has evolved over time.
Software Engineers typically draw the software stack with hardware on the bottom of the stack and applications on top, as shown below.
Applications run on operating systems, hosted by hypervisors, which virtualize the hardware architecture.
For the sake of simplicity, I have grouped several categories together. For example, middleware is really an enabling component of applications and as such could be a separate layer below “Applications.” Additionally, runtime environments like Java or Perl have been lumped into the operating systems level instead of being placed as an unique layer on top of “Operating Systems.” One could just as easily include hypervisors as part of the hardware architecture. To enable a technology trends discussion later in this blog entry, I have elected to explicitly separate “Hypervisors” as a distinct layer.
You must consider the visibility to users in the IT infrastructure of each software stack component to appreciate the impacts on the business. With a little insight, you can see that most people in the enterprise touch the application layer, while fewest touch the hardware. This observation suggests a roughly graduated pyramid, as depicted below.
The implication of this graduated visibility means that changing an application causes more expense for an enterprise than does changing hardware architectures, especially when changes in a top layer drive changes in the foundational layers below it.
Does anyone remember the day when applications ran on only one platform? Not too long ago, “platform” meant the whole software stack, a silo top-to-bottom. If I wanted to run the AmiPro word processor, I did so on my DOS-based personal computer. To do word processing at work, I used BookMaster on the mainframe. Applications were the “platform."
Over time, application providers began to write applications that could handle the disparate operating system environments. Applications (middleware) like IBM's DB2 database are available for Windows and UNIX operating systems. The advent of interpreted languages like Java further helped application portability. In this time frame, people began to think of the “platform” as the layers from the operating system downward.
With the adoption of the Linux operating system, the definition of “platform” continues to move further down the stack. When customers run RHEL 6.3 or SLES 11 SP3 in their environment, they get the same kernel version, built with the same compiler (which of course generated different binaries for the each processor instruction set), running the same libraries, leveraging the same file systems, and including the same levels of many common applications such as the Apache webserver. In this structure, properly written applications can expect common application environments, even though they may be running in different hypervisors on different hardware platforms. For well written applications, “porting” to a new platform generally becomes a recompile and a regression test.
The value of Linux to the enterprise comes from commonality. Differences drive expense. Commonality saves money. The greater the “visibility” for a component of the software stack, the larger the potential for savings from commonality. So, it should not surprise us that the historical trend of convergence has been top-down in our software stack.
While the majority of commonality has been with applications and operating systems, some convergence has occurred within the hardware architecture layer. I/O has developed standards like PCI. Networking converged to Ethernet, despite a competing standard of Token Ring. Likewise, storage area networking selected the Fibre-channel protocol over SSA. While these gains have been beneficial, they likely are limited in opportunity because processor architectures will likely never converge to a single architecture. Every processor type and system architecture focuses on solving a different challenge.
As we look forward toward the future, opportunity exists for continued convergence in the software stack with hypervisors. Today's enterprises have their virtualization options dictated by the hardware platform. Power systems virtualize with PowerVM, mainframes use z/VM and PR/SM, x86 systems use VMWare, HyperV, Xen, or KVM. Enterprises with heterogeneous hardware platforms run different hypervisors on each platform -- not by choice, but by mandate.
With Linux embracing KVM, the potential for a single, cross-platform hypervisor emerges. In the not too distant future, enterprises should be able to leverage KVM to reduce their virtualization expense, again changing the definition of “platform.” In this final picture, commonality has driven the definition of “platform” to simply being a new hardware architecture, reducing the impact (and resulting expense) to the most minimal definition.
Now that we have completed the analysis of the software stack convergence, we can provide a deeper answer to the original question: Is PowerLinux a new platform? Not really. Linux on Power is “just Linux”, RHEL 6.5 or SLES 11 SP3. For a software provider such as the one who posed the original challenge, their x86 Linux expertise combined with their Power System skills facilitate support of Linux on Power in a very cost effective fashion. As Power embraces KVM, even the hypervisor differences will be eliminated and the impact of adopting Linux on Power has truly been isolated to a few people for both software providers and customers alike.
While this convergence can be viewed from a historical perspective, one could also view these steps as phases of application maturity. New applications typically begin on a single operating system and hardware stack. Over time time, applications wishing to support multiple hardware platforms, will port. Modern applications, such as those written in interpreted languages like Java or Python or those compiled with using open source compilers like gcc, will migrate to new hardware platforms quickly. Linux and open source tools enable software vendors to maximize their addressable market by writing to common libraries and compiling using standard tools common to all platforms who run the Linux operating system.
The evolution of the software stack has been on an exciting trend. Open source software has driven and will continue to drive a convergence of the software stack as the IT industry evolves. We have come a long way from the days of “application silos.” Today's runtime environment with the Linux operating system provides a common architecture that enables cross-platform application support. With the emergence of KVM as a virtualization technology, convergence will continue into the hypervisor layer. Once this transformation is complete, platform differences will be reduced to the fundamentals of the processor architecture, enabling IT customers to minimize expense while leveraging the fundamental advantages each platform can provide to their solution. What enterprise would not want to be allowed the flexibility of selecting the best platform for their solution while minimizing expenses?
By: Jeff Scheel.
Ever wondered what IBM means when they say "Power Linux"? I get questions all the time like, "How does Power Linux differ from RHEL or SLES?" So, I thought perhaps it might be time to address this in writing, in a common place.
Here's the simple answer: Power Linux generally refers to all supported Linux distributions that run on IBM Power Systems servers. This means that Power Linux includes all Red Hat Enterprise Linux (RHEL) and SUSE Linux Enterprise Server (SLES) versions. We simply say "Power Linux" instead of "RHEL and SLES" each time we wish to refer collectively to these Linux distributions. (What would one expect from us, the master of 3 letter acronyms and abbreviations?)
While this simplification sounds reasonable on the surface, in practice it has created some confusion. People believe that Power Linux is somehow different from SLES and RHEL on other platforms. It is not. Further, RHEL 6.2 for Power Systems is built from common source code, tested at the same time across platforms, made generally available on the same date, and supported the same way as RHEL 6.2 for x86 platforms. These same commonalities apply to other RHEL releases/versions, as well as SLES releases/versions. It is this standardization across multiple hardware platforms that elevates Linux from just another operating system to a multi-platform operating system that enables customers, business partners, and software providers to leverage hardware platform strengths without having to invest in new operating systems.
As my college physics professor used to say: "Is it as transparent as mud?"
jscheel 0600025BWM Tags:  openpower firmware linux power ppc64le powerlinux jscheel 10,497 Views
If you were like me and enjoyed the July 4th holiday week, you likely missed a very subtle – yet significant – event: the July 2nd release of firmware by IBM for use in the OpenPOWER Ecosystem under the Apache license, version 2.0. This action further signifies IBM's commitment to opening up the Power architecture and fulfills an IBM's promise to the OpenPOWER Foundation. It also demonstrates cross-company innovation with the inclusion of significant code contributions from Google.
The OpenPOWER Foundation, established in 2013 by IBM, Google, Tyan, Mellanox, and NVIDIA, represents a growing alliance of over 40 organizations committed to building new technology based on the POWER microprocessor architecture. Plans to form the organization were first revealed in this IBM Press release stating that “The move makes POWER hardware and software available to open development...”
But, honestly, what makes the release of open source firmware so significant for OpenPOWER? In a nutshell, it enables collaboration around hardware. As OpenPOWER Foundation members innovate around the processor and system architecture, having a freely available, easily extensible, and simple to re-distribute firmware becomes a critical requirement. The release of this firmware under the Apache license provides a solid base around which a community can be built to support the OpenPOWER Ecosystem and to enable future hardware and software innovation. While a community could have created a new code base from scratch, IBM has shortened the time to innovation by tens to a hundred of person years through this contribution.
If you would like to get involved in this emerging firmware community or simply want to follow along, the project list is currently available on github at https://github.com/open-power. If you want to be involved in the larger OpenPOWER Foundation group responsible for the firmware, keep you eye open for information on the proposed System Software Work Group. A draft charter is presently being reviewed that allows for an open work group in which anyone can participate.
So, let the innovation begin. Come help us put the “Open” in OpenPOWER!
by Jeff Scheel, IBM Linux on Power Chief Engineer
Never before in my almost 25 year history with IBM have I anticipated a launch like that of our latest POWER8 systems. This launch releases the next generation of POWER processors in 1- and 2-socket scale-out servers with a focus on delivering new Linux solutions, especially in the area of open source clouds built on KVM – a dream come true for this “Chief Engineer.”
For me, the most important announcement is the release of an IBM KVM product, PowerKVM, on our POWER8 Linux-only servers, the S812L and S822L. For the past year, we have worked very hard in the open source communities to enable this open virtualization technology. Even though IBM is the first to offer KVM on Power Systems with our own product, rest assured that it has been enabled in a way such that any Linux partner can provide their own product. In fact, key open source community distributions such as Fedora 20 and openSUSE 13.2 have already been enabled. IBM remains committed to enabling Power Systems as a platform for open innovation.
The launch of this product marks the start of a new era in virtualization—convergence of hypervisors. As I've stated explicitly in my last blog, “Is PowerLinux a New Platform? Not really...” and have talked about in multiple forums for the past couple years, hypervisor commonality will be the next place enterprises save money. KVM unleashes the potential for a a single hypervisor to run all platforms in the Enterprise as it continues to mature over the next 5-7 years, just as the Linux operating system has done so in the past 10 years. In the meantime, PowerKVM provides an excellent opportunity for customers to leverage synergies with KVM and OpenStack to build light weight, flexible, highly virtualized cloud solutions. KVM on Power (from IBM or anyone else wishing to release a version) will look and act just like KVM on x86, making it an excellent choice for new customers on the platform to exploit POWER8 benefits while greatly reducing the learning curve to a bare minimum.
My excitement about this launch continues with the POWER8 processor. This generation of processors will thrive in the data-centric generation of cloud computing. Growth of the maximum number of cores per socket from 8 to 12, increases in the hardware threads per core from 4 to 8, significant improvement in the single thread performance over previous generations, and integration of a PCIe Gen3 controller into the chip will provide applications plenty of resources for big data and analytic workloads. In addition to the traditional “bigger, better, faster, stronger” enhancements associated with a new processor generation, the POWER8 processor also adds two exciting new technologies—CAPI (Coherent Accelerator Processor Interface) for connecting accelerators directly into the system and a new processor mode to access memory in a little endian format. These processors technologies will fuel software innovation for years to come.
CAPI enables POWER8 processors and out-of-core accelerators like GPUs (graphics processing units) and FPGAs (field-programmable gate arrays) to cache-coherently share memory with the applications running on the main processors as if they were “in-core”. This greatly simplifies application acceleration design which has traditionally required meticulously planing of shared memory usage through techniques such as pinned memory. Look for nVidia, our new OpenPOWER partner, to leverage this technology as they help bring GPU-based solutions to Power Systems in the coming months. Meanwhile, IBM will combine CAPI with FPGAs and emerging software applications like Redis to overcome traditional performance limitations.
Support for little endian mode in the POWER8 processor enables a new generation of applications. While I plan to devote future blog entries to this topic, let me take a moment to address some basic facts about the technology. First, the traditional POWER operating systems (AIX, and IBM i) are big endian and will continue to run as such on POWER8 and future systems. Second, Linux operating systems over time will be migrating from being big endian to little endian in an organized way that by no means compromises the support cycles for their existing releases. Third, as little endian operating systems come to market, a new little endian application ecosystem will grow. Given that most applications today support one or more little endian operating systems (Windows or x86 Linux) and at least one big endian operating system (Linux on Power, AIX, or z/OS), this ecosystem should grow quickly. Finally, little endian mode on POWER8 is not a magic bullet: compiled x86 Linux applications will still require a recompile at a minimum because the x86 and Power instruction set architectures are still different. With this new support, Power will simplify on step in the porting process for new applications, but to develop the whole ecosystem will take time.
Finally, as I look at this first set of POWER8 systems, my excitement peaks over the form factor in these initial offerings and the solutions they will enable. For the first time in as long as I can remember, we are bringing our newest technology to the entry, scale-out servers with 1- and 2-socket servers in 2u and 4u footprints. Complement the offering with a continuation of the total cost of acquisition (TCA) competitive “Linux-only” servers, the S812L, S822L, and S824L models, and the Linux market can benefit immediately. Add a new Linux operating systems from Canonical, Ubuntu version 14.04, and new applications from SugarCRM, CFEngine, Redis Labs and Zend and the platform takes a huge leap forward in open innovation.
PowerKVM, POWER8, scale-out servers, and new Linux solutions. Wow! This POWER8 launch delivers so many new technologies from the processor through the software offerings enabled with KVM. It's truly hard not to sound like Buzz Lightyear from the movie Toy Story who frequently hollers, “To infinity and beyond!” If you are a POWER customer, you should be excited about the new solutions these new servers provide for you. If you are new to POWER, combine Linux with KVM to explore the benefits of the platform. The future is here. What will you do with it?
jscheel 0600025BWM Tags:  power powerlinux linux le applications jscheel 2 Comments 11,861 Views
In June of last year, I started publicly discussing the role that little endian (LE) plays in our Linux on Power strategy with the blog, Just the FAQs about Little Endian. Then, in August I attempted to eliminate uncertainty in my Removing the FUD and Demystifying LE (little endian) article. With the announcement of the Red Hat Enterprise Linux 7.1 beta delivering an LE version, it is time to revisit little endian from the perspective of an application developer.
The release of RHEL 7.1 LE completes the offerings of little endian operating systems. Canonical had Ubuntu 14.04 ready for POWER8 launch in May. SUSE supported the launch with public statements by Michael Miller about SLES 12 being LE in May, and publicly released in October. It is now time for application developers to get busy: little endian Linux on Power is here!
One thing that being a developer by training has taught me, is that “we” often need to be convinced that work is worth doing. Little endian Linux on Power is about reducing the cost of migrating an application AND providing additional value of the end application.
Being able to run Linux on Power in LE mode means that applications have one less thing – data endianness – to worry about in the port. While technical differences such as assembler language, page size, and cache size still exist, developers and architects tend to worry most about data endianness because the finding and fixing all the problems can be very time consuming. By enabling Power to run in the same endian mode as x86 (the defacto Linux platform of choice for developers), applications can simply be recompiled without having to worry about endianness. Further, if one is going to build a solution mixed with x86 and POWER systems, exchanging data on disk or across the network in the same endian mode greatly simplifies the application as well. Then, add in the ability to accelerate Power applications with (inherently little endian) GPUs and the benefits of little endian become “a no brainer”.
So, hopefully, we're past the “why should I do this?” phase and now we address the list of technical resources for migrating to Linux on Power. My favorite list of resources include:
Now let us take a look at “where can I get started?” The answers to this question depend on your role in the software ecosystem. If you are a software provider, my colleague Bob Dick, recently published he thoughts on how to get started in a the Using the IBM Power Development Cloud for Red Hat Enterprise Linux 7.1 (little endian) Beta application testing blog posting. Programs like IBM PartnerWorld provide this and more resources to facilitate porting. Check them out.
If you are a “in house” owner of an application in your enterprise, finding a system on which to port your application could be challenging. Of course, your IBM Sales contact or your business partner can provide alternatives such as try-and-buy or proof-of-concept systems. Do not hesitate to start with them. If you do not know them, or if this does not work out, go to the cloud! Site Ox offers a two week free trial for development purposes. Visit their website for details. As we move forward, I remain hopeful that other vendors will provide public offerings of Linux on Power images. Further, if you do not at first see the particular release for which you are looking, reach out to the service provider and request it. They might just surprise you and have a plan to provide it. If not, it helps them to hear your needs.
For open source developers, the access to free cloud images increases. The Open Source Labs at Oregon State University hosts Power development images (VMs). University of Campinas (UNICAMP) also hosts a minicloud in Brazil. In China, the SuperVessel Cloud provides a similar service to developers. In addition to these three locations, we are hoping to extend our offerings in both Europe and India in the near future. Again, the particular releases hosted at these sites may vary, but will generally include the little endian versions of Fedora, openSUSE, and Debian. If none of these sites or offerings work for you, feel free to reach out to me on Google+ (loaner post) to explore a dedicated loaner system.
With a complete set of little endian Linux on Power distributions, a robust list of technical resources, and plenty of resources for porting applications, the future is here. Take the first step. Seize the moment. Let's see what you can do with Linux on Power!
As you likely have heard, Arvind Krishna, IBM General Manager for Development and Manufacturing in the IBM Systems & Technology Group, announced that Power Systems would be supporting KVM. This is an exciting announcement for numerous reasons that I'll defer for another posting. For this blog entry, I thought I'd do some question/answer session based on common questions I've been asked in the past couple weeks. However, before I do so, I need to remind you that these are our current thoughts at this time: things may change.
Q: When will KVM be available on Power?
A: The outlook for general availability is next year. However, IBM has already started releasing patches to various KVM communities to support the POWER platform.
Q: On what systems does IBM intend to support KVM?
A: IBM intends to initially support KVM on a limited set of models, targeted at the entry end of the system servers. This strategy supports IBM's efforts to capture the largest growing market, x86 Linux servers in the 2-socket and smaller space.
Q: How does IBM plan to position KVM against PowerVM?
A: IBM remains committed to the PowerVM being the premier enterprise virtualization software in the industry. With KVM on Power, IBM will be targeting x86 customers on entry servers but will offer both KVM and PowerVM to meet the varying virtualization needs PowerLinux customers. However, KVM virtualization technology represents an opportunity to simplify customer's virtualization infrastructure with a single hypervisor and management software across multiple platforms.
Q: What Linux versions from Red Hat and SUSE will provide KVM hosts support on Power?
A: The decision to provide KVM on PowerLinux will be made by Red Hat and SUSE. IBM will be working with them in the months to come and would welcome their support.
Q: What management and cloud software will support KVM on Power?
A: For KVM node management, IBM intends to work with multiple vendors, including Red Hat and SUSE to certify KVM on Power into their system management software offerings. Additionally, IBM plans to contribute any patches necessary to OpenStack to extend the KVM driver to Power. Using this foundation, additional IBM and third-party software should provide a diverse set of management software.
Q: What will software providers need to do to support KVM on Power?
A: Most software provides have become comfortable with some form of virtualization such as PowerVM, VMWare, and KVM. Just like with applications on Linux, software providers should find that applications in the KVM environment behave similarly on x86 and Power platforms. As such, each vendor should understand any challenge KVM on Power would provide.
Q: What operating systems will be supported as guests in KVM on Power?
A: Given that KVM is initially targetted to be released on Linux-only servers, only Linux is planned at this time. IBM plans to certify the latest updates of RHEL 6 and SLES 11 as KVM guests.
Q: How will KVM run on the Power Systems?
A: The design goal of KVM on Power is to be just another hardware platform supporting KVM. As such, the KVM on Power will be true to the KVM design point of a KVM host image that supports one or more guests. PowerVM constructs such as the HMC, IVM, and VIOS will not exist in KVM. Management and virtualization will occur through the KVM host image.
Q: Will KVM run in a PowerVM logical partition (LPAR)?
A: While KVM supports a user-mode virtualization that can run on any Linux operating system, KVM on Power is being developed to run natively on the system, not nested in PowerVM. This is done to enable KVM to run optimally using the POWER processor Hypervisor Mode. As such, the system will make a decision very early in the boot process to run KVM or PowerVM. This is envisioned as a selectable option managed by the Service Processor (FSP)?
Q: Will it be possible to migrate from KVM on Power to PowerVM or vice versa?
A: While the virtualization mode will be selectable on systems, the process of migrating from KVM and PowerVM will require additional steps such that frequent migrations will be unlikely. However, in the case where a customer wishes to upgrade to PowerVM to acquire advanced virtualization capabilities, this migration should be supported. Steps to backup and restore the VM image will be required when migrating in either direction.
Q: Will AIX or IBM I run in KVM on Power?
A: Given that KVM initially runs on Linux-only platforms, support for non-Linux operatings systems has not been planned at this time.
Q: Will Windows run in KVM on Power?
A: Windows does not run on Power Systems. As such, supporting it in a KVM guest VM will not work.
Hopefully, these questions were helpful to folks. As usual, follow-up questions/comments appreciated.
by Jeff Scheel, IBM Linux on Power Chief Engineer
As promised, here is my first blog post on little endian or "LE" as we call it. Where better place to start than with a list of frequently ask questions (FAQs)? Hopefully, you'll find this helpful. Let me know if you have any questions I missed.
What is big endian and little endian, anyway?
In order to perform operations on data, computers routinely load and store bytes of data from and to memory, the network, and disk. This data management generally follows one of two schemes: little endian or big endian.
Imagine the number one hundred twenty three. When representing this number with numerals, we typically write it with the most significant digit first and the least significant digit last: 123. This is big endian. Mainframes and RISC architectures like POWER default to big endian when manipulating data.
Some microprocessor architectures store the numbers representing one hundred twenty three in reverse – the least significant digit first and the most significant digit last: 321. This is little endian. x86 architectures use little endian when storing data.
Why do people care about what endian mode their platform runs?
Most users do not care which endian mode their platform is using. They simply care about what applications are supported by their Linux operating systems. Only application providers care about endianess. For example:
Why is Linux on Power transitioning from big endian to little endian?
The Power architecture is bi-endian in that it supports accessing data in both little endian and big endian modes. Although Power already has Linux distributions and supporting applications that run in big endian mode, the Linux application ecosystem for x86 platforms is much larger and Linux on x86 uses little endian mode. Numerous clients, software partners, and IBM’s own software developers have told us that porting their software to Power becomes simpler if the Linux environment on Power supports little endian mode, more closely matching the environment provided by Linux on x86. This new level of support will lower the barrier to entry for porting Linux on x86 software to Linux on Power.
Which Linux distributions will support little endian on Power?
Additionally, SUSE has stated publicly that SLES 12 will be little endian when it becomes available. See SUSE Conversations for more information.
Red Hat has not yet publicly disclosed their plans around a little endian operating systems However, work to create a ppc64le architecture has started in the Fedora.
Which Linux distributions will support big endian on Power?
It is IBM's understanding that Red Hat and SUSE will continue to support their existing big endian releases on Power for their full product lifecycles.
While SUSE has announced their plans to transition their distribution to little endian (see above), Red Hat has not disclosed anything. The newly available Red Hat Enterprise Linux 7 operates in big endian mode on Power. Specifics about the transition to little endian will be decided and disclosed by Red Hat.
What about Linux applications that have already been optimized for big endian on Power?
The existing PowerLinux application portfolio supports only big endian modes today. Open source applications have begun extending their support to little endian mode on Power Systems. Existing third party and IBM applications will likely migrate more slowly and deliberately. As such, Power hardware will support both endian modes for the foreseeable future so that existing Linux applications optimized for a big endian platform will continue to run unchanged while new applications optimized to little endian mode are added.
Can applications compiled for x86 (Windows or Linux) run without change on little endian Power?
Because the x86 and Power processors use different instruction set architectures (ISAs) – the binary executable known to the processor – compiled applications will need at least a recompile on the new platform. Whether source code changes are required depends on how many optimizations have been made in the application source – such as the use of assembler language and any assumptions about page size or cache line size, etc.
However, interpreted applications such as those in Java, perl, python, php, ruby and others should be capable of migrating with little to no change.
Does this transition affect application ecosystems for AIX or IBM i?
No, there will be no effect on AIX or IBM i application environments as a result of this change.
What if I want to run a mix of big endian and little endian applications on the same Power System?
Each Linux distribution will support a particular endian mode, little or big. Applications always certify to specific distributions. As such, endian mode decisions should be transparent to the end user. Customers should not have to consider endianess in their application choice.
If one requires different Linux distributions or the same distribution at different releases on a single server, then Power Systems virtualization (LPARs or VMs) allows customers to run applications supported by a big endian Linux distribution like RHEL6 as well as applications supported by a little endian distribution like Canonical’s Ubuntu Server at the same time. However, concurrent little endian and big endian support on the same server will not be available until a future date. See more details in the questions below.
Which POWER processors support little endian mode?
The POWER8 processor is the first processor to support little endian and big endian modes equivalently. Although previous generations of the POWER processors had basic little endian functionality, they did not fully implement the necessary instructions in such a way to enable enterprise operating system offerings.
Where can little endian distributions run on Power?
When IBM announced POWER8 in April 2014, little endian (LE) operating systems were initially supported as KVM guests. Further, KVM support was limited to only include all LE or all big endian (BE) guests. In coming releases, IBM expects to support concurrent LE and BE guests in KVM, as well as the support of LE guests on PowerVM.
Do POWER systems support the running of mixed environments of big and little endian operating systems?
The POWER8 processor supports mixing of big and little endian memory accesses at the core level, through the use of SPR (special purpose register) settings. While this could technically support the running of both big and little endian software threads, the complexity of implementing such a design point would be high. Therefore, IBM has elected to enable operating system versions as completely big endian or little endian by design.
The virtualization capabilities of the POWER platform have allowed for mixed environments of operating system levels and types. This same isolation mechanism applies to big and little endian operating systems. However, in implementing the initial releases of little endian, IBM has introduced some short-term limitations on where LE operating systems can run. Over time, these will be removed and both KVM and PowerVM will support concurrent mixing of LE and BE operating systems.
See the previous question for more information.
Does PowerVM support little endian operating systems?
While the POWER8 systems support little endian (LE) mode, IBM has not yet completed the software development and testing to enable LE operating systems on PowerVM. The outlook is that this function will be delivered around mid-2015. When this capability is delivered, PowerVM will support the mixing of both big endian (BE) and LE operating systems. This enablement will also enable the running of LE operating systems on the Power Integrated Facilities for Linux (IFLs).
Does PowerKVM support mixing of little endian and big endian operating systems?
Testing has not yet completed to enable the mixing of little endian (LE) and big endian (BE) guests for KVM. Until this completes, IBM supports guests of the same type – all LE or all BE.
IBM hopes to support mixing of guest types around mid-2015.
Can I run big endian applications on a little endian operating system or vice versa?
No, the operating system enablement only supports applications of the same type. As such, a little endian operating system (ppc64le or ppc64el) can only run little endian applications built for this software platform. Likewise, big endian operating systems (ppc64) only support software built for big endian.
January 23, 2015 - Author's update
A couple noteworthy activities have occurred since this blog was originally published.
Additionally, the following question keeps being asked and needs it's own FAQ:
Can I run x86 Linux applications on LE Linux on Power operating systems unchanged?
If your application was written in a dynamic language, it is highly portable and often migrates to BE and LE Linux on Power operating system environments without change. Examples include applications written in Java, php, perl, python, etc.
If your application was written in a compiled language like C/C++, it must be recompiled on Power in both the BE and LE operating systems. Applications migrating from x86 Linux onto an LE Linux operating system on Power will migrate without concern for data layout (endianness). Applications migrating onto BE operating systems need to be reviewed for consist data access, especially if they will share data using disk or networking with LE systems.