On PowerVM, Lx86 and virtualization of Windows

Yesterday saw the announcement of a re-packaging, re-branding and new technology drive for POWER™ Virtualization now PowerVM™. You can see the full announcement here. It is good to be back working on VM, sorta.

Over on virtualiztion.info, Alessandro Perilli, says we are “missing the market in any case because its platform is unable to virtualize Windows operating systems”. I say not.

POWER isn’t Windows, it’s not x86 hardware. We scale much, much higher, perform much better and generally offer high availability features and function as standard or an add-on, way ahead of Windows. Running Windows on PowerVM and Power hardware would pick-up some of the reliability features of the hardware transparently, and the workload consolodation potential would be very attractive. What it comes down to though, is what it would take to virtualize Windows on PowerVM?

We could do it. We could add either hardware simulation or emulation or more likely translation that would allow the x86 architecture or Windows itself to be supported on PowerVM. There would be ongoing issues with the wide variety of h/w drivers and related issues, but lets put those aside for now.

We could have gone down a similar route to the old Bristol Technologies WIND/U WIN32 licensing and technology route, porting and running a subset of WIN32 or even via mono or .net. We might even call it PowerVM Wx86. Just reverse engineering MS technology is neither the right idea from a technology or business perspective.

So technically it could be done one way or another. The real question though is the same as the discussion about supporting Solaris on Power. Yes, it would be great to have the mother of all binary or source compatibility virtualization platforms. However, as always the real issue is not if it could be done, but how would you support your applications? After all isn’t it about “applications, applications, applications“?

And there’s the rub. If you wanted to run middleware and x86 binary applications on POWER hardware, then you’d need support for the binaries. For middleware, most of the industries leading middleware is already available on either of AIX, i5/OS or Linux on Power, some is available on all three. What would software vendors prefer to do in this case? Would they be asked to support an existing binary stack on Windows on PowerVM, or would they prefer to just continue to support the native middleware stacks that benefit directly from the Power features?

Most would rather go with the native software and not incur the complexities and additional support costs of running in an emulated or simulated environment. The same is true of most customer applications, especially those for which the customer doesn’t have easy or ready access to the source code for Windows applications.

In the x86 market, the same isn’t true, there’s less risk supporting virtualization such as Xen or VMware

The same isn’t true with PowerVM Lx86 applications. First because of the close affinity between Linux and Linux on POWER. There are already existing Linux on Power distributions, the source code is available, and most system calls are transparent and can be easily mapped into Linux on POWER. Second, drivers, device support etc. is handled natively within either the POWER hardware, PowerVM or within the Linux operating system, running in the PowerVM partition. Thirdly, IBM has worked with SuSe and RedHat to make the x86 runtime libraries available on Linux on POWER. Finally, many middleware packages already run on Linux on POWER, or it is available as open source and can be compiled to run on Linux on POWER.

All of which makes it a very different value proposition. Using NAS or SAN storage, it is perfectly possible to run the same binaries currently or as needed on x86 and PowerVM. The compilcations of doing this, the software stack required, as well as the legal conditions for running Windows binaries just don’t make it worth the effort.

Although not identical, many of the same issues arise running Solaris, either Solaris x86, or OpenSolaris PowerPC port. So, thats a wrap for now, still many interesting things going on here in Austin, I really well get back to the topic of Amazon, EC2 and loud computing, memo to self.

Like this:

Related

4 Responses to “On PowerVM, Lx86 and virtualization of Windows”

What would you advise an enterprise having applications (40% of which are mission critical) running on AIX P6,P7 and Windows with different versions, and an application or two running on Red Hat.
it we think of virtualization, would it be a good idea to have both PowerVM and VMWare or Xen?

Hi Mark,
Your article is very interesting, but I wonder if it’s a little out of date with the times. I understand that since you are no longer with IBM, you may no longer be interested in IBM’s PowerPC platform. IBM’s solution to running Windows integration on Power was to install Windows on xServers attached to Power servers via SCSI or iSCSI. This introduces a clutter of HW which many customers want to do away with. I also learned recently with the release of IBM i V7R1, many customers had to move Windows off of the Power platform altogether due to performance issues, and give the xServers and xBlades their own SAN, instead of connecting to the Power IBM i or AIX operating systems.
.
As an ex-IBMer myself, I now do consulting/contracting and I am more sensitive to customer’s needs rather than vendor product availability. I was asked recently by a PowerVM (System i) customer to investigate the possibility of running Windows Terminal Server on Linux for Power (ie. RedHat Linux or Novell’s SuSE Enterprise Linux 11, which both run on Power HW platforms). This customer replaced all of their Win desktops to Ubuntu Linux, with CentOS Linux servers (Intel platforms). They run their licensed Windows Terminal Server as a hosted environment on their Linux servers using VirtualBox (Sun’s product, now owned by Oracle). This customer’s idea of consolidation and integration means removing the need for multiple different HW platforms. Since Power is the most stable of the two (Power vs. Intel/AMD), he’d really like to get rid of Intel based HW altogether, and run IBM i, AIX, Linux and Windows on Power.
I have contacted IBM, Oracle, Redhat and Novell, asking the same question. Will VirtualBox work on a Linux OS running on Power? So far noone has been able to answer (or they are afraid to answer).

My take on it is as follows:
– With the new Power 7, IBM’s answer to Windows integration performance issues seems to be stop using Power platform as a SAN box and give the xBlades and xServers their own SAN disks.c So much for integration and virualization…
– If this is IBM’s direction, then there is little to no need to continue with Windows integration as we knew it in the past. The solution is to run virtual Windows on Power directly (PowerVM), or within a hosted environment running on IBM i, AIX, or Linux.
– Sun’s VirtualBox, even though it’s an old idea – ie.WABI, with a new twist, seems to be the best possible solution…as long as it works fine as a hosted environment inside one of those OS’s on Power HW. What do you think?

Good to hear from your Gerry, agreed, I’m out of date now and it’s almost 3-years since I wrote that post. As always, and not specific to Power VM or IBM, the problem any virtualization layer or hypervisor has in supporting non-native apps is convincing users that it’s ok to go without formal support from the app/middleware/db vendor. Doesn’t matter how you provide that, through architecture emulation so the non-native OS can be run, or through a ABI where the calls the apps make, plus the instruction set are emulated.

As soon as you get into architecture emulation you are in a legal minefield as well. Someone owns the architecture(in most cases) and certainly Intel, Microsoft and IBM all assert their rights to licensing of their IP. So, for example, the early Intel architecture was to a great deal open and free. However, as Intel became increasingly successful, they matched that with protection of their investment. If you want to do anything with any Intel x86 instruction sets Pentium and beyond you have to pay Intel a license. The same is true for Power and mainframes, except you pay IBM.

In the case of Intel, because they ship so many chips and make their money from the longtail, their licensing terms can be reasonable per unit. That would give you one step. For the Windows API’s the same is less true. Getting permission aka a license to emulate their technology aka API’s would probably be difficult and expensive. There have been examples for short periods of time, witness Bristol Technology that I had dealings with over 15-years ago, there are many others that have fared similarly.

To this date, only the Mono initiative has had any durable success in providing MS Windows interfaces without Windows. I’m guessing this is for defensive purposes for Microsoft, ie they can say .Net apps run x-platform when challenged, usually followed by “but they run best natively”. We certainly used to say the same about the UNIX interfaces and runtime libraries we provided on OS/390 (a mainframe OS) to support UNIX apps. The big difference being that IBM developed a lot but not all the OpenMVS interfaces, and IBM itself wrote apps to those interfaces.

So, net net, it’s entirely possible to do any of your suggestions, the right answer is indeed the one the customer wants, which in most cases is the one that requires least change and disruption. The problem with this is that it often comes at a cost that is too high when it comes to running in non-native platform environments, not from a performance perspective, not from a function perspective, it’s all down to ownership and licensing.

About & Contact

I'm Mark Cathcart, formally a Senior Distinguished Engineer, in Dells Software Group; before that Director of Systems Engineering in the Enterprise Solutions Group at Dell. Prior to that, I was IBM Distinguished Engineer and member of the IBM Academy of Technology. I am a Fellow of the British Computer Society (bsc.org) I'm an information technology optimist.

I was a member of the Linux Foundation Core Infrastructure Initiative Steering committee. Read more about it here.