Friday, April 24, 2015

KVM Across the Board

KVM Across the Board

Let's talk about hardware.
Let's talk about physical hardware versus emulated hardware.
Let's talk about virtual hardware.


Emulation is where you run a program to simulate a machine. A popular PC emulator is BOCHS. You can use BOCHS to boot any operating system which would run on I386 hardware. BOCHS can run on any hardware, I386 or other. BOCHS can run on z Series (IBM mainframe). BOCHS can run on p Series (IBM RS/6K). BOCHS can run on ARM (your cell phone).

There are many emulators for many architectures.
Mainframe aficionados commonly use Hercules to emulate a mainframe where BOCHS emulates a PC.

There is a steep performance penalty in emulation. Each emulated CPU instruction requires dozens or hundreds of physical CPU instructions. Processors this century are so fast that we sometimes don't notice. (The pain of this performance penalty varies widely for varying workloads.) 


Virtualization is better. 

Virtualization is hard to implement but easy to understand. A "guest" runs on the underlying physical machine until there is an exception (privileged operation, I/O, a page fault, or similar). Emulation does come into play (because not all devices and hardware facilities are virtualized). But virtualization is different from emulation in a big way. With virtualization, the guest runs on the bare metal most of the time, not interpreted by a program. Clearly more efficient.

Something which hosts guest operating systems via virtualization is called a hypervisor. The premier hypervisor is z/VM. z/VM only runs on IBM z Series hardware.

Let's talk about KVM

Since VMware made its debut in the late 1990s, virtualization has been more than just a mainframe phenomenon. Until that time, the only serious hypervisor was IBM's VM (variously VM/ESA, VM/XA, VM/SP, and other monickers, now z/VM). Before VMware, the best we got (in quantity) apart from z/VM was emulation. But now there are many.

We cannot know (unless we measure each, which is time consuming) how much true virtualzation each hypervisor really does. There is the concept of paravirtualization, which is beyond the scope of one little blogger post. Let's talk about that L8R.

An incomplete list (just for discussion) of hypervisors includes z/VM, VMware, Xen, KVM, and products from Sun/Oracle, Microsoft, Apple, and other vendors.

But let's talk about KVM.

KVM started life in the PC world, specifically the Linux PC arena. We had Xen, but it was paravirt at best. Advances in chip logic from AMD and INTeL allowed for more effective virtualization.So Qumranet developed KVM and managed to get it accepted into the Linux kernel. Thus it is the kernel virtual machine facility. Nice!

I got wind that KVM was being made to work on z Systems. (Being a late bloomer, the info was after-the-fact.) I also found out that KVM had been ported to p Systems. (That's the PowerPC chip.)

Now ... this is a really cool development: the same hypervisor across multiple hardware architectures. I have imagined this and longed for it for two decades! Wow. Can't do that with VMware. Can't do that with Oracle, Apple, Microsoft. Can't even do that with IBM z/VM. 

Let's talk about IBM

This little post is in response to a thread on LinkedIn. Specifically, I'm trying to answer Jon Butler's question if KVM is enabled for the mainframe hardware. The answer is yes.

The mainframe is amazing and has lots of bells and whistles. At the center is the same basic idea of a general purpose processor (variously called a CP or GP, with a Linux-specific spin called IFL, loosely "S390"). z/VM runs on it. KVM runs on it. 

KVM runs on: I386 (and X86_64), PPC, S390, and (soon) ARM

But then there's z/VM. 
IBM has this incredible hypervisor. I don't have time to describe the orders of magnitude difference between z/VM and the others.

z/VM runs on: S390

There is ample historical evidence that IBM has wanted to kill z/VM for a long long time. Maybe it threatens their cash cow (z/OS, nee MVS). 

Many respected colleagues have expressed frustration with IBM in recent months over positioning of their shiny new z13 machine. A z13 can run hundreds, nay thousands, of Linux guests without breaking a sweat. It can over-commit memory and still deliver flawless service with sub-second response time. It can do all this by the magic of z/VM.

So what's wrong?
What's wrong is that IBM marketing hints the amazing z13 does all this with the help of KVM. That's simply not true. It's like the marketing guys don't know the difference between "z/" and "K". 

z/VM is not all that expensive (to you). Might be expensive to IBM.
z/VM is, however, very different from KVM. No doubt some customers with pre-disposed warm fuzzies for KVM will embrace that and expect the results touted for z/VM. Not gonna happen.

What Shall We Do?

I love z/VM. There's nothing like it. It takes full advantage of z hardware and then adds its own incredible features.

I love KVM. It breaks out across hardware architectures. But it's a baby, just starting to crawl.

My fear is that IBM will finally lop-off their VM product (like some say they've wanted to do for decades) and leave us with only KVM.

So what shall we do?
First, be clear about the story. If an IBMer rattles on about z13 and only includes KVM, raise your hand. Call them on the carpet about it. Second, if they do proceed to ditch z/VM (which experienced engineers believe would be a major mistake), then as customers demand that they port all the features of z/VM to KVM: the monitor stream, the performance controls, DCSS, IUCV, the unquantifyable* features of CP/CMS.

*Not sure "unquantifyable" is a word, but you get the idea. 

-- R; <><

Wednesday, April 22, 2015

Bad Idea #75 - Mandatory Indentation

Bad Idea #75 - Mandatory Indentation

I've done it!
I've finally learned Python.
Could not put it off any longer and what a cool language! 

Found out about the origin of the name. Guessing Guido wanted the Holy Grail of languages. I'm also a fan of the comedy troupe, and MP/HG is one of my favorite films, so you might expect me to love the language just for that. But no. Had to continue with my bad attitude.

Anyone notice that the Dutch are taking over the computing world? And in case GvR ever runs across this, I have been to Haarlem. Beautiful town. 

I didn't like Python.
It's an aesthetics thing.
(I dislike Perl for the same reason, resulting in similar self injury.) 

Thou Shalt Bathe

Unlike my friend JEP, I have no allergy to curly braces, so for me there's no need for indentation (as far as making the compiler/interpreter happy). But I do indent. Always have. C'mon ... that's the most basic coding hygiene. (I bathe too.)

What offends me about Python is that indentation is part of the language, that indentation is mandatory. (Somewhere in the history of 'make' is a similar soggy saga w/r/t indentation. I will cite another time.)

Look ... I indent as a matter of course, so when I refrain from indenting there's a reason for it. But with Python I don't have that liberty. The language forces me to indent like a parent telling their kid to brush their teeth.

A Pearl of a Language

Now that I've dived in, this water's fine. Really. 
Writing new code is easy as shell. Yet it is much better structured (than shell) so the results are less of a hack and more like a Mack (truck). It has a strong collection of libraries, including a spiffy OS interface, and supports "the right" set of data types.

Took less than a day to port one of my Tcl scripts to Python. Easy! And fun!

Yet, like any gem, it does have flaws. 
Maybe "flaws" is too strong of a word. Call them "qualities". 
I've been so apologetic about REXX over the years. Python has similar quirks. (And MFC gets a pass on quirks because REXX was created in a vacuum before the glut of scripting languages we now carry.) Some aspects of Python take a bit of getting used to ... in a way that reminds me of REXX.

I already lost one job offer due to lack of Perl skills. 
Hopefully I won't lose any others from lack of Python prowess. 

Now looking forward to more Python. 

-- R; <><