A few weeks ago, Oracle unveiled its new virtual machine (VM) product, Oracle VM, based on the Xen hypervisor. But why is Oracle introducing its own VM when it already has the Xen VM that comes with the Red Hat code? For an answer, we turn to SearchEnterpriseLinux.com expert Don Rosenberg, who fills us in on what Oracle VM means for users, the competition and for Linux in the enterprise.

Oracle VM
Red Hat ships the Xen VM with Red Hat Enterprise Linux (RHEL), with the same Red Hat source code that Oracle uses to build its Unbreakable Linux operating system.

But Oracle chose to go directly to Xen.org to download the source code for its own Oracle VM. While Red Hat runs Xen from within an operating system, Oracle runs its VM on a server. From here the Oracle VM deploys agents or images to computers without an operating system on them, creating virtual servers.

Oracle describes its VM as a console for the management of Xen, complete with a built-in operating system, making it a software appliance. The appliance has paravirtualized drivers for RHEL 4 and 5 but currently runs Windows without paravirtualization, resulting in sluggish Windows performance. Oracle claims its VM is three times more efficient than the leading VM (presumably VMware), but this comparison does not refer to speed so much as to the use of resources on a box. On a box that needs an OS and VMware installed, running via VMware would take up roughly three times the resources; Oracle’s software appliance saves space.

Oracle’s virtualization strategy
The Oracle VM is free to download and use; those wanting support will have to sign up for a paid plan. But Oracle says that its virtualization solution is still cheaper than Red Hat’s. RHEL supports some virtualization (at no extra cost), but full-blown implementation requires an additional product: Red Hat Enterprise Linux Advanced Platform.

The Red Hat solution calls for Red Hat-certified products from third parties, but an Oracle VM will run only Oracle databases, middleware and applications. By releasing its own VM, Oracle avoids third-party complications (such as software dependencies and support finger-pointing) and third-party payments. It also ends up controlling the software stack from top to bottom, including virtualization.

One can presumably find Oracle VM customers among the 1,500 that Oracle says already pay for Unbreakable Linux support (Dell, Stanford University, McKesson and Mitsubishi, among others). The unknown number of customers already running Oracle on VMware now have to decide whether to accept Oracle support (along with the Oracle VM) or continue to run on the competitor’s product with support from Oracle. Oracle customers who already run on Xen will find the switch to Oracle VM easier, of course.

Oracle says it has 9,000 developers at work on its software products, including Linux, and points out that Red Hat’s total employees amount to only 2,000. Oracle needs all its software skills to track Red Hat as closely as possible. Red Hat is upping the ante by announcing that in 2008 it will offer software vendors the Red Hat Appliance Operating System. Applications can be written to this layer to produce a software appliance that will run on any Red Hat system, physical or virtual, no matter where it is located.

Linux has accelerated virtualization
The Age of Virtualization is upon us, and I don’t believe we would have gotten this far this fast without open source software. Virtualization and VMware originated on mainframes, and when IBM finally “got it,” it used Linux to revive a company that was sinking slowly into the past. By adopting Linux, it came up with an OS that could be used on all of its hardware. And by applying its mainframe know-how, it came up with such marvels as the mainframe that could configure itself to be multiple-server instances by day, then turn back into a mainframe at night (for order taking and order batch-processing, respectively) or any combination of mainframe and servers). Moving client/server over to mainframe virtualization eventually gave way to cloud computing. Combined with grid computing, servers and applications are now thought of as “somewhere out there” in a virtual space. Because IBM made these improvements to Linux, the code was fed back into the Linux kernel, which was meanwhile being improved from the other direction (such as hundreds of servers being linked to form a mainframe). The invisible hand of the free market supplied a wealth of code that could be freely downloaded and reworked for anyone’s use.

All this happened in a world in which the dominant computer systems in businesses were desktops that eventually (with the help of open source BSD code) managed to form networks. They used one type of processor design (Intel) and one brand of operating system (Windows). VMware caught the eye of open source developers not only because it allowed network technicians to design, build and test networks while using only a single box, but because it took on the problem of how to use both Linux and Windows on a single box without rebooting.

This achievement rattled the windows in the Wintel offices. A few years earlier, Netscape boasted prematurely about its plans to build a platform that would be OS-independent and died as a result. And IT departments, tired of having to do separate installs for each Windows box, admired the way Linux could be shot over the wire to an unconfigured machine. This was an early virtualization concept that looked ahead to a world we may yet enter, one where the end user’s processor and software may be something other than Wintel. Porting apps would be less necessary if they were written to a layer high enough above the operating system(s).

Long ago, IBM and Apple had a joint venture to develop such a layer. The plan was to use layers to effectively virtualize operating systems and processors. Taligent collapsed from the weight of its own ambitious plans, but we are a lot closer to its goal. Now even Microsoft is getting into virtualization, competing with Red Hat and Oracle to build virtual data centers that most effectively use resources in real time.

Now that the open source Xen project has taken on some of the functions of VMware, what will become of this proprietary product that had so much to do with the current virtualization surge? It is difficult in an expanding market to say that VMware’s sales will drop, for it is already giving away the low-end server version of their product. Because it handles many more operating systems and does more things than Xen, VMware will survive in a specialized marketplace. The question is, will Xen push down VMware prices? Or, as with the move from CentOS to RHEL, will Xen’s position at the low end of the market serve to support a high price for VMware?

I had a great call with First American Title Holding Co. about Novell Open Enterprise Server 2 the other day. Why was it so great? Because it surprised me. I went in expecting one thing and got another. For a reporter, that’s great. It’s an education. It’s like waking up thinking it’s Sunday when it’s really Saturday. Or something like that.

One of the goals I had going in was to get details about First American’s new SUSE Enterprise Linux deployment, as well as some additional bits of file serving goodness from the OES2 they installed on top of it. As it turns out, the creme de la creme was the virtualized NetWare servers they were running using Xen paravirtualizaiton. Many NetWare shops simply cannot migrate off that OS, as the applications are customized and cannot run any other way.

Xen: Ready for OES2’s launch?

With the launch of OES2, Novell is trying really hard to entice those last few NetWare shops to make the leap to Linux. They’re doing this by enticing them with virtual NetWare servers running in Xen. That said, was Xen mature enough for First American’s mission critical NetWare applications? Would it perform as well?

At first glance, things were not looking too good.

Kurt Johnston, a lead engineer on the First American migration, wasn’t optimistic. “I did not have high expectations for Xen,” Johnston told me in a call last week. “With Xen being as young as it is, I was expecting it to be very difficult to install and configure a new domU onto dom0.” Johnston and his boss, IT director Dan McDougall, were also wary of performance issues they had read about in trade magazines and had heard from other users throughout the year.

But they were soon pleasantly surprised, and so was I. Xen wasn’t VMware ESX Server, but it was close enough–at least for First American. That, at least to me, was the surprise. It’s been a 24 hour VMware lovefest for the past two years or so, and I hadn’t been up on the subject enough to see any changes in that dynamic. When I talked with analysts in 2006 and ‘07 I had always heard Xen had plenty of potential, but like any new technology it needed work. Illuminata senior analyst Gordon Haff, speaking to me for the same article, told me that much of the work needed to prove that potential had been completed throughout 2007. It was a collection of hard work and bug fies; not any single thing, he said.

“The fact is, [Xen] was rather simple to install. It was the ease of installation and configuration that surprised me. I was expecting to use quite a bit of [a command line interface],” Johnston said. Fortunately for First American, there was very little CLI, if any. No headaches, no problems–save one.

There was one issue worth noting about Xen, according to Johnson. He said one thing he would like to see in Xen is in “the paravirtualization side of things”:

“I’d like to be able to somehow mask certain virtual machines and only allow certain LUNs [logical unit numbers] on the SAN [storage area network] to serve and see certain virtual machines, via Xen.  I’d like to be able to build in a limit to the different servers to see only specific LUNs on the SAN.”

He went on to say that having the ability to visualize the host bus adapter (HBA) and use Xen to manage virtual Fibre Channel ports would allow LUN masking of these ports and give the ability to grant access to only specified LUNs.

This capability is also still an issue in VMware environments as well, but a support update for N_Port ID Virtualization (NPIV) in VMware ESX 3.5 was announced earlier this month.

Fixes from XenSource, Novell

But what about XenSource, the corporate entity behind the Xen hypervisor? Or Novell, which was the first commercial Linux OS vendor to bake Xen into its OS? Was a fix forthcoming for those Novell OES2 customers, like Johnston and McDougall, that wanted the same functionality in their environments? Simon Crosby, CTO of XenSource, responded to that question regarding support for N_Port ID Virtualization (NPIV) via email this morning. He said:

“It’s planned ASAP for XenSource products (Q1 08). The Xen project doesn’t have a storage roadmap - just the hypervisor. Whether any vendor puts a particular storage technology into its product is up to that vendor.”

Novell is working on a multi-vendor fix: “We are working on N_Port Virtualization together with Qlogic and Emulex,” said Holger Dryoff, vice president of management and marketing at Novell. “This will be available in one of the future service packs of SUSE Linux Enterprise Server 10 and therefore to OES 2 customers as well.”

I find all of this interesting because it will mean more choices. More choices means competition, and competition means happier customers. Happier customers are more apt to speak to the press and tell their stories. Whether the technology ultimately makes the customers happy, well, that’s what we’re here to find out.

Are you planning on juicing anytime soon? How about JeOSing?

Confused yet? Here’s a hint: Both those sentences sound exactly the same when you say them aloud. What’s different about them is a case of apples and oranges however, and I’m not talking about Tropicana. I’m not even talking about pro sports figures and questionable performance enhancing tactics that may or or may not lead to asterisks being placed next to stats and failed Hall of Fame bids.

What I’m not going to talk about today is the Cream or the Clear; what I am going to talk about is virtualization, virtual appliances, and a little Linux distro called Ubuntu. As of this month they’re all being blended into a concoction the folks at Canonical Ltd. and VMware are affectionately calling JeOS.

Each of those topics are pretty well known now (virtual appliances still being a bit “new car smell,” but whatever), so how does JeOS bring something new to the table? Is it a product to be sold, or is it an architecture with which to build new exiting things that my colleagues and I will be writing about for years to come? One executive I’ve read recently who’s been at this a while has a rough idea.

By taking a short Internet boat ride over to rPath CEO Billy Marshall’s blog today, we find him addressing that very question.

JeOS (pronounced “juice̶ is a concept first described in writing by Srinivas Krishnamurti of VMware in this blog entry. With the pronouncement this week by Canonical that the Ubuntu distribution of Linux is now a JeOS product, I thought I would make the argument that JeOS is a packaging architecture, not an operating system product. I also believe that the hypervisor is the replacement for the product formerly labeled as the general purpose operating system.

[…]

Now that the hypervisor is going to become the new operating system that supports the hardware, should the JeOS that supports any given application be a product with the same architecture as the legacy general purpose operating system? i.e. a collection of components defined by the operating system vendor as supportable and maintainable? so long as you don’t change the assumptions the operating system vendor made when the collection was assembled and tested and released? so long as you don’t change any of the components because that makes the collection unsupportable? How is that possible, when by definition, the collection of components that the application vendor is going to use is going to change depending on the needs of the application? Think about it.

And off we go. By Marshall’s reasoning, and I’m inclined to believe him, the JeOS cannot be squeezed into an operating system product role because it must become a packaging or testing architecture. In lieu of any other approach, JeOS must be assembled by ISVs around an application with the smallest possible footprint. This is because, you’ll remember, VMware is promoting JeOS (and Virtual Appliances in general) as an opertaing system sans system interfaces, functions, and libraries; and without the unnecessary services that the application does not require. “By tailoring it to the needs of the application,” Krishnamurti said on his blog, “you are now down to a lithe, high performing, secure operating system - Just Enough of the Operating System, that is, or JeOS.”

But Marshall then argues that the appliance must also confirm that this “closed loop set” is reasonable based upon the testing scenario for the application. “It must subsequently enable the integration of the various maintenance streams for the components with the server set to provide an elegant life cycle experience for the application vendor and its customers. In this scenario, the application provider takes on a much broader responsibility for the support of the operating system, and at the surface level this can seem very scary,” he said.

Before you go scurrying behind a UPS unit in fear, just wait a second. Seems that you might have been living with this approach for some time already. Marshall, a former Red Hat employee, explains that “the application vendor or their customer was already assuming this burden in the legacy model where the general purpose OS was modified on premise to support the application.”

Add to that equation JeOS — as a packaging architecture (instead of a “one size fits all” product, Marshall says) — the component set that must be maintained is much smaller and much more intimately related to the application than even what VMware described at VMWorld for tHe launch of JeOS (due out October 12).

“By definition, the application vendor will be in a good position to determine and resolve problems given this tight definition and technical affinity with the application, Marshall said. “No doubt they will still want the technical expertise of a vendor with deep operating system skills as a backstop, but the product they acquire from that vendor will look very different than the product historically labeled as a general purpose operating system.”

In conclusion (I sound like an 8th grade research paper here, but oh well), JeOS is, always has been, and will be a packaging architecture. Marshall states JeOS should be billed as a system software reference platform with a build/test methodology. “Anything else defies logic in a world where every server has a hypervisor and every application arrives as a virtual appliance with JeOS,” he said.

What really fascinates me in all this is the role Linux will play in driving the adoption of VA’s by ISVs, who will then provide them to customers to run virtually in the tens of dozens on multi-core, super powerful servers that, in a hat tip to my colleagues at SearchDataCenter.com, are spaced correctly with adequate cooling. It’s a low cost, secure operating system and that seems to be working perfectly for vendors like rPath, VMware, Canonical and many more. We’re only on the cusp of this vast virtualization precipice, and as a writer I like that. But now I’m thirsty.

Question authority, yes; but, more importantly, question your vendors. This advice is critically important if you’re a Windows shop migrating to VMware ESX or VI3. said Andrew Kutz, former University of Texas systems analyst and now a Burton Group analyst. Kutz offered this advice during a session at last week’s Server Blade Summit in Anaheim.

“Although VMware sales representatives pitch the idea that IT professionals do not need to know Linux to run ESX, this is a fallacy. It would behoove any shop thinking of running VI3 to have a good understanding of ESX’s console operating system (OS), and it is Red Hat Enterprise Linux 3.0.”

Linux users have an advantage in the virtualization market, because they’re probably more familiar with using online mailing lists and forums for tech support, says Kutz. Online resources and the peer support available there will be life savers during virtualization implementations.

“It seems to be the case that the technology has out-paced the vendors’ ability to support it. There have been instances of 5-month long open support tickets that the vendor is never able to solve. Rely on forums, your own wits, but not vendors.”