Archive for category Oracle
Heterogeneous virtualization has been a hot topic among clients and last week at the Gartner Data Center conference in Las Vegas I presented a session on the subject. During the session, I polled the audience on their heterogeneous virtualization plans. Fifty participants responded to each polling question.
The first question I asked was about the current hypervisors that were deployed (note that the values are the number of respondents and not a percentage).
As you can see, most participants used VMware vSphere as expected, and there was a good mix of Hyper-V, XenServer, and some RHEV and Oracle VM.
It’s (Read more...)
Today EMC’s Chad Sakac blogged about a significant update to Oracle’s support policy for VMware ESX environments – Oracle no longer explicitly excludes Oracle RAC from being virtualized. It should also be noted that Oracle’s support is limited to “issues that either are known to occur on the native OS, or can be demonstrated not to be as a result of running on VMware.” In other words, if it’s not a known bug, customers may be asked to reproduce problems on the bare metal.
Like Chad, this is an issue I have blogged about repeatedly over the last couple of (Read more...)
Today the Wall Street Journal reported “VMware in Talks to Buy Novell Unit.” The rumor likely comes as no surprise to those who have followed the recent VMware/Novell OEM agreement. The agreement resulted in VMware including a SUSE Linux Enterprise Server (SLES) subscription with vSphere licenses. VMware and Novell first started talking about an extended partnership in June. At the time, VMware noted that it would include SUSE Linux with its vSphere hypervisor as well as train its support organization to offer SUSE Linux support. The fact that VMware was making an investment in its support organization (Read more...)
Yesterday Microsoft announced what I believe was a brilliant move – Hyper-V paravirtualized drivers (Microsoft calls them Integration Components) released under GPL 2.0. This announcement reflects Microsoft’s long term Linux strategy, in my opinion, and is the first step toward positioning Hyper-V as a platform for hosting Linux workloads. Getting Hyper-V paravirtualized device drivers in the mainline Linux kernel will simplify deployment of Linux-based VMs on the Hyper-V platform in coming years. In the short term, it’s important for Microsoft’s key partners (Novell and Red Hat) to backport the paravirtualilzed drivers so that their currently shipping Linux distros will run more efficiently on Hyper-V. Given Microsoft’s close partnerships with Novell and Red Hat, I see SUSE Linux Enterprise Server 10/11 and Red Hat Enterprise Linux 5 support as foregone conclusions.
With this move, I think that Microsoft has acknowledged that Linux is here to stay, and has provided additional momentum to the growing number of Linux-based VM appliances. A growth in Linux-based VM appliances benefits everyone, including the Linux community and VMware (who hosts the Virtual Appliance Marketplace). Microsoft still has more work to do on this Linux front. Open sourcing Hyper-V paravirtualized drivers was a great first step. Next up, I would like to see Microsoft support Linux VMs with multiple virtual CPUs on Hyper-V. This opens the door for Microsoft to tout Hyper-V as a platform for production-class Linux workloads.
To take this a step further, let’s turn back the clock to October 2008. At Catalyst Europe, I asked Steve Herrod and Ian Pratt about VMware and Citrix collaborating on an exchange of device driver libraries to further reduce VM compatibility issues between hypervisors, and both agreed to continue the conversation (more details here). Citrix XenServer and Microsoft Hyper-V share device driver libraries and include the driver libraries for each platform as part of their paravirtualized driver installation (i.e., XenServer Tools and Hyper-V Integration Components). With Microsoft releasing Hyper-V paravirtualized Linux drivers, I think it’s a good time to revisit the idea of an open source driver framework that supports the core paravirtualized driver libraries of each major hypervisor platform (ESX, Xen, Hyper-V, and KVM). Sure, we’ll need a community/standards body (or whatever you want to call it) to manage driver library updates, but I can’t see why it isn’t possible. Such collaboration would make life easier for everyone. Imagine being able to run a few tests on one of your VMs “in the cloud,” and not having to care what the hypervisor is. Isn’t that what cloud’s supposed to be about anyway? Here’s my service level and security requirements. Can you give me the service I need?
Yes I understand that my cloud analogy is overly simplistic and there will always be some benefits to having a consistent virtual infrastructure both internally and with external providers. Still there are times when such consistency isn’t needed, and that’s why shared driver libraries make a lot of sense (besides removing another barrier to vendor lock-in). VM configuration metadata is addressed with Open Virtualization Format (OVF). From a technology perspective, nothing is preventing collaboration on a common VM device driver framework and shared driver libraries (that is something I’d love to see in the mainline Linux kernel). And finally, hypervisor vendor support for both .vmdk and .vhd virtual hard disk formats is the last major hurdle blocking VM compatibility (without the necessary conversions) between hypervisors. Vendors – let’s not talk about cloud openness, open architectures, etc. Let’s do something about it. Microsoft made a great move yesterday. Next I’d like to see collaboration between all virtualization vendors that further promotes choice among users, IT departments, and service providers. VMware, Microsoft, Citrix, Novell, Red Hat, Oracle – what do you say?
I’ll have four sessions at the upcoming VMworld Conference. If you’re interested, here are the details…
BC2541 – Re-architecting Backup and Recovery for Virtual Environments: Best Practices
Server virtualization is one of the fundamental building blocks of the dynamic data center and with it brings new management challenges, especially in the area of data protection and recovery. Existing data protection architectures may provide a short term serviceable solution, but lack the scalability to be a mainstay in tomorrow’s data center. Continued data growth is also compounding data protection complexity, as enterprises must accommodate data growth by increasing backup system performance in order to stay within backup windows for data protection. We are at a time where organizations should reevaluate existing data protection practices and leverage new technologies to improve data recovery and lessen or eliminate the performance tax posed by many existing data protection architectures. This session breaks down modern VM data protection solutions, including VMware Consolidated Backup (VCB), array-level snapshots, and third party enterprise backup software solutions. Attendees will be exposed to common data protection pitfalls as well as successful blueprints for modern VMware data protection architectures. Chris Wolf has been architecting data protection solutions for enterprise virtualization environments since 2002 and includes an abundance of lessons learned and best practices drawn from real world implementations in this session.
DV2439 – Breaking Down Desktop Virtualization Alternatives
Numerous methods exist for delivering applications to endpoint devices today: virtual desktop infrastructure (VDI), application streaming, presentation virtualization, and hybrid approaches. The session breaks down the use cases that drive client virtualization choices and highlights future developments such as desktop hypervisors that will likely impact long term client virtualization architectures.
EA2442 – Software Licensing in the Virtual Enterprise: Current Problems and Future Trends
Virtual environments present new challenges for software license management across an enterprise. In this session, Burton Group senior analyst Chris Wolf breaks down the current state of software licensing and support for both server and desktop virtualization environments, while highlighting the technical elements of the virtual infrastructure that impact product licensing. He will also describe the licensing and support model best suited for modern virtualization platforms, with examples of vendors that provide best-in-class virtualization licensing policies today. All major enterprise application and OS vendors will be covered, including Microsoft, Sun, Red Hat, Novell, Oracle, HP, IBM, CA, SAP, Symantec, and Citrix. The session concludes with guidance on how to leverage RFPs to obtain licensing and software support clarity.
TA2400: Hypervisor Competitive Differences: What the Vendors Aren’t Telling You
In this session, Chris Wolf and Richard Jones dissect the competitive differences that exist with today’s leading hypervisors, with a special focus on the under-the-hood features that don’t make it onto vendor data sheets. Attendees of this session will see firsthand the differences that exist with all major virtualization hypervisor vendors (e.g. VMware, Microsoft, Citrix, and Oracle) and will leave with a list of pointed questions to ask prospective hypervisor vendors regarding their current solutions and future plans. Vendor scorecards will also be presented, allowing attendees to see how each major hypervisor ranks against Burton Group’s enterprise production-class hypervisor evaluation criteria. Areas where hypervisors fall short of production readiness will be clearly highlighted as well.
I’ve been covering Oracle licensing and support issues in x86 virtualized environments for quite some time, beginning with the January 2008 report “Virtualization Licensing and Support Lethargy: Curing the Disease That Stalls Virtualization Adoption.” You can also view these earlier blog posts for additional background:
- Oracle and the Big Elephant (August 2008)
- A New Year’s Resolution for Oracle (December 2008)
- Oracle Honors its New Year’s Resolution: Non-Oracle x86 Hypervisors are Now Supported (May 2009)
A few weeks ago one of our clients pointed me to a recently published Oracle support article (Metalink 794016.1 published March 27, 2009), which prompted me to write my previous post. That’s when the fun really began. After my last post on May 6th, Oracle published a completely revised version of the Metalink document on May 8th. The document was referenced by the same document ID (794016.1), but had a completely different title and content.
For context, the March 27th version of the Metalink document was titled “Platform Vendor Virtualization Technologies and Oracle E-Business Suite” while the revised May 8th edition of the document was titled “Hardware Vendor Virtualization Technologies on non x86/x86-64 Architectures and Oracle E-Business Suite.” If you recall, the first iteration of the document described how x86 virtualization technologies were supported with the following statement:
The use of platform vendors’ virtualization technologies (both software and hardware based) to host Oracle E-Business Suite 11i and R12 is covered by Oracle’s policy with regards to 3rd-party products – that is, they are ‘not explicitly certified, but supported’.
The support document listed Microsoft, VMware, and Citrix as examples. In the May 8th edition of the support document, the above statement was revised to:
The use of hardware vendors’ virtualization technologies to host Oracle E-Business Suite 11i and R12 follows the same policy as Oracle’s policy with regards to customizations – that is, they are ‘not explicitly certified, but supported’.
Examples of x86 virtualization hypervisors were replaced by the following statement:
This document provides a statement regarding Oracle E-Business Suite (11i, R12) support of Hardware Vendor Virtualization technologies on non x86/x86-64 systems.
The bottom line – the revised support document went from describing support for x86 hypervisors to ignoring them altogether, with the exception of Oracle’s hypervisor Oracle Virtual Machine (OVM). I was told that the revisions were needed to address confusion, but feedback I received from numerous Burton Group clients made it clear that there was no confusion until the May 8th revision was published.
Since early last week, I have had numerous calls with Oracle on the subjects of both licensing and support, and unfortunately the news isn’t all good. Let’s start with the positive. According to Oracle, VMware’s ESX hypervisor “has been supported since November 2007.” As proof, you can view Oracle Metalink document 249212.1 (note that you’ll need an Oracle support account to view the doc). The document states the following:
Oracle has not certified any of its products on VMware virtualized environments. Oracle Support will assist customers running Oracle products on VMware in the following manner: Oracle will only provide support for issues that either are known to occur on the native OS, or can be demonstrated not to be as a result of running on VMware.
If a problem is a known Oracle issue, Oracle support will recommend the appropriate solution on the native OS. If that solution does not work in the VMware virtualized environment, the customer will be referred to VMware for support. When the customer can demonstrate that the Oracle solution does not work when running on the native OS, Oracle will resume support, including logging a bug with Oracle Development for investigation if required.
The statement goes on to say that Oracle RAC is not supported on VMware environments. If you’re looking for additional background on Oracle support for VMware environments, I suggest reading the following other perspectives:
- “What the Oracle / VMware support statement really means…and why” (Jeff Browning)
- “Oracle on VMware – a manifesto…” (Chad Sakac)
- “EMC attacks Oracle on its VMware support policy” (Alessandro Perilli)
Regarding VMware support, here’s the translation – if you call for support and you have a known bug, you’re good to go. If you’ve found a new (previously unknown) bug, you’re first going to have to reproduce the fault on physical hardware before Oracle will help you. Compared to other vendors that support enterprise applications on VMware or x86 virtualization environments, this is one of the most restrictive policies out there. Most enterprise software vendors only require faults to be reproduced on the bare metal if they are directly related to performance that could be attributed to the virtualization layer.
The recent Virtual Iron acquisition further cements the fact that Oracle is serious about virtualization. Microsoft and Citrix both have clear public support statements about virtualization and the hypervisors they support (I’m mentioning these two vendors because they’re both virtualization vendors and enterprise software vendors). Oracle needs to loosen its support restrictions for VMware and all x86 virtualization environments, and needs to broaden its list of supported (but not certified) hypervisors to include Microsoft, Citrix, Novell, and Red Hat.
Finally, as I previously mentioned, the larger problem here is licensing. Oracle is requiring customers who wish to deploy Oracle products on x86 hypervisors to license Oracle software by physical server CPUs. Suppose you had two Oracle Database VMs (each with two virtual CPUs) running on a two-node ESX cluster that uses two four-socket servers. Since it’s possible that you’d have a VM on each node, you’d need to purchase licensing to cover the 8 total sockets. If you ran Oracle’s hypervisor, you could license by virtual CPU, however this is only allowed if you pin the VM to fixed CPU cores by hard coding CPU bindings. You can read more about that here. This does create a slight advantage for OVM over competing products, but by binding a VM to one or more physical CPU cores, you have to give up advanced virtualization functionality such as live migration. If I’m using application-level high availability features, this configuration may not be a big deal and would in turn favor Oracle; however it is far from ideal.
Oracle’s competitors in the database arena allow their products to be licensed by virtual CPU without requiring physical bindings (see Microsoft’s and IBM’s policies), and so should Oracle. Doing so allows VMs to move about the physical infrastructure as required to support IT operations. Binding enterprise software licenses to physical assets is a legacy licensing model, and Oracle is practically alone in their licensing policies.
Oracle’s strategy with regard to licensing is one that I’ve seen before. Oracle is effectively taxing organizations for running Oracle Database in a VM. In most cases, organizations will have to pay increased licensing fees. This policy hurts the customer, and in my opinion is an attempt to stall market adoption while Oracle finishes building out its own x86 virtualization platform.
Oracle, it’s time to classify all x86 hypervisors as “hard partitioning.” Our clients are increasingly deploying enterprise applications on x86 virtualization hypervisors. You’re putting them in a tough position, and many consider the virtual infrastructure the foundation for their cloud architecture. Some clients have told me they are now considering moving forward with DB2 or SQL Server because they are unwilling to pay a penalty to run Oracle on any x86 hypervisor. In the end, our clients shouldn’t have to make that choice. They should have the freedom to run the applications they want on the platform they want. This licensing policy is affecting the bottom line of our clients and could ultimately affect your bottom line too. It shouldn’t have to come to that. Let’s just "right the wrong.” Besides, your “Partitioning” document which describes software licensing for virtual environments was last updated in January 2008. In response to my last blog post, you were able to revise a support statement within two days. How about taking the time to revise a licensing policy that is clearly outdated and places an unnecessary burden on our clients?
In case you haven’t seen, Oracle issued a major product support update last month – Platform Vendor Virtualization Technologies and Oracle E-Business Suite – Metalink Note 794016.1 (note that an Oracle support account is needed to view the update). The bottom line – Oracle now offers best effort support for all of its E-Business Suite applications on any x86 hypervisor. Shocked? Here’s a snippet of the support statement:
The use of platform vendors’ virtualization technologies (both software and hardware based) to host Oracle E-Business Suite 11i and R12 is covered by Oracle’s policy with regards to 3rd-party products – that is, they are ‘not explicitly certified, but supported’.
What this means is that while these technologies are not certified, Oracle will not turn away a customer reporting an issue solely due to the use of these technologies. When possible Oracle will triage and attempt to diagnose the issue reported – Oracle support may attempt to replicate the issue in a non-virtualized environment and work with the customer to verify if the problem exhibits in such an environment.
Any specific problem isolated to the virtualization software (i.e. a problem that cannot be reproduced in a standard, non-virtualized environment) will need to be referred to the specific vendor for resolution.
Customers should review all relevant Oracle documentation on the use of such virtualization technologies for known issues and limitations with respect to EBS technology components such as the database, RAC, etc.
Customers intending to use 3rd-party products covered under this policy in production environments should conduct appropriate levels of testing and also have contingency plans to revert to a standard certified configuration (that is, non-virtualized environment)…
So there you have it. Back in December I suggested that Oracle make two New Year’s resolutions:
- Offer best effort support for all major x86 server virtualization hypervisors
- Offer virtual CPU-based licensing for all of its server applications
The year isn’t even half way over, and Oracle can cross the first resolution off its list. Next up has to be software licensing. Oracle considers its own x86 hypervisor, Oracle VM (OVM), a platform capable of supporting hard partitioning (see the Oracle “Partitioning” document for more information). By its definition of “hard partitioning” Oracle allows virtual CPU-based licensing on OVM, but does not allow it on other popular x86 hypervisors such as VMware ESX, Microsoft Hyper-V, or Citrix XenServer. Oracle also allows virtual CPU-based licensing on Amazon EC2, which runs the open source Xen hypervisor (you can read more about that policy here). Updating the support policy was a great first step, and Oracle should be commended for responding to the needs of its customers.
Now how about knocking out New Year’s resolution #2 before the end of June? Oracle, I know you can do it. Your friends in the enterprise software space that offer CPU-based licensing, such as IBM and Microsoft, both allow licensing to virtual CPUs on any major hypervisor. Binding a license to a physical CPU is “so 2007.” Oracle, no doubt you’re in the middle of a major makeover, and acquiring Sun was a good move. I must say, with the Sun portfolio, I love your wardrobe. However, your licensing policy doesn’t reflect your new look or attitude. To stay with the wardrobe analogy, you’re wearing some great clothes, but you need to lose the mullet.
Oracle, let’s complete the makeover. Modernize your licensing policies and your body of actions will show that you are a company that is truly one with the times.
Note: Within two days of this post’s publication, Oracle made a massive revision to the support document “Platform Vendor Virtualization Technologies and Oracle E-Business Suite – Metalink Note 794016.1. Please see my latest post for the most up to date analysis of Oracle licensing and support.
As the year winds down, I thought it would be a good time to think about New Year’s resolutions. Let’s face it. A lot of us come up with New Year’s Resolutions each year. Sometimes we see them through, and sometimes we don’t. I don’t think it would be very interesting to blog about my personal New Year’s Resolutions, so instead I thought it would be good to make some New Year’s Resolutions for vendors. Today I’m going to start with Oracle, and plan to blog on resolutions for a couple of more vendors in the coming weeks.
I don’t have enough fingers and toes to count the number of times that I have spoken to a client or given a seminar this year and the topic of Oracle licensing or support for x86 virtualization came up. Oftentimes, these sessions would borderline on group therapy. Many of our clients have become utterly frustrated in their efforts to get Oracle to officially support their x86 virtualization environments (namely VMware today). Getting what they see as fair licensing for these environments has been a struggle as well. The pain felt by our clients has led me to vendor New Year’s Resolution #1:
Oracle: Publicly define official support and offer virtual CPU-based licensing for all prominent x86 virtualization environments.
Oracle’s role in x86 virtualization is not black and white. Not all Oracle database implementations require massive amounts of compute and I/O, and those are often well-suited for x86 virtualization today. In fact, multiple Burton Group clients are already running lower tier Oracle databases in VMware VMs. Some of them have even been able to negotiate support with Oracle. If you’re a large enough client and have the leverage of a software license or support contract renewal, it’s amazing what you can achieve. Still, this shouldn’t be the case. Oracle should have a public support policy for all major x86 virtualization platforms.
It’s not just the end user organizations that are frustrated by Oracle’s support stance. Many vendors share in this frustration. Case in point is Citrix CTO Simon Crosby’s recent blog, where he states:
…it is well known that Oracle only supports Oracle apps virtualized on Oracle VM, which is, as I said earlier, all but identical to mainline Xen. Is this a reasonable position? No, it’s ridiculous.
By only supporting their own OVM (Xen-based) virtualization platform, Oracle has thus far shown that they are purposefully not willing to integrate with other infrastructure vendors, something which clearly is not good for their customers.
Now let’s move on to licensing. Oracle defines licensing for virtual environments in its “Partitioning” document. This document defines most x86 virtualization hypervisors (note there are exceptions only for Oracle’s OVM hypervisor) as soft partitioning. With regards to licensing, the document states:
…soft partitioning is not permitted as a means to determine or limit the number of software licenses required for any given server.
What does this mean? If you’re running Oracle applications such as Oracle Database in a VM, licensing is determined by the number of active processors on the physical host. Burton Group has maintained that Oracle should offer a virtual CPU-based licensing model. In one case, Oracle agrees. To see this, take a look at the Oracle document “Licensing Oracle Software in the Cloud Computing Environment.” In the document you will see that Oracle allows virtual CPU-based licensing on Amazon cloud platforms. This is stated in the second paragraph:
For the purposes of licensing Oracle programs in the Cloud environment, customers are required to count each virtual core as equivalent to a physical core.
Amazon EC2 runs Xen. So there’s one example of virtual CPU-based licensing on an x86 hypervisor. If this model is OK for Amazon EC2, why not offer it for VMware ESX, XenServer, or Hyper-V? All of these platforms can provide the necessary accounting to ensure that customers are not trying to bind a virtual CPU to multiple physical CPUs as a way to dilute licensing costs. So if this model is acceptable for Xen on EC2, why is it not for other hypervisors?
Oracle – I think the New Year’s Resolution I’m asking you to achieve can be accomplished with minimal effort. I’m not asking you to lose 50 pounds or quit smoking. I just want you to fix one of the issues that give our clients a great deal of pain. What do you say?
Note: Originally published on Burton Group’s Data Center Strategies blog.