RedHat is one of the pioneers of the Open Source community with their distribution of Linux called RedHat Enterprise Linux. While the OS software packages and the Linux kernel are completely Open Source, and anyone is free to download, use, and distribute them (some disclosures required), if you want commercial support you have to pay for it. RedHat is in the business of selling support and patches, there is no software licenses, there can’t be, it’s Open Source (the OS at least). If the company that only sells support for Open Source, says they don’t want to provide you the service you’ve paid for, what do you do?

It might come as some surprise to certain customers that RedHat is telling them they can’t get support for an Open Source OS just because it’s running on a hypervisor that is based on Open Source. The hypervisor in question is Nutanix AHV, which is based on CentOS, the same line of code as RedHat. This is some top class FUD, and is entirely untrue, if you read the details.

I’ve written some things about FUD in my time, usually about Oracle. I didn’t expect I’d be writing this time about RedHat.  But here we are. I will cover some details about what RedHat Sales are saying, and link to the official documentation that you can use to fight back.

For some background you can see this RedHat Forum Post on Running RHEL on AHV. One of the RedHat employees says that Nutanix needs to work within the hardware certification program, however that isn’t relevant. Nutanix AHV isn’t hardware and Nutanix isn’t a hardware company, it’s a software company. Nutanix fully supports RedHat Enterprise Linux running on Nutanix AHV – see the compatibility matrix. Nutanix has tested and validated it’s functionality and we do not modify the guest OS in any way. The KVM that Nutanix AHV is based on is from the same place as RedHat KVM, with some important improvements in Security, Performance, and Management. Derek Seaman also wrote about RedHat Satellite Configuration.

Then there is this article about What Hypervisors are Supported for RHEL. Both VMware vSphere and Microsoft Hyper-V is listed (both can be used with Nutanix also). Nutanix AHV is not listed, even though it’s based of KVM. It’s usually at this point that RedHat Sales will point customers to this KB article about Nutanix Acropolis Hypervisor Support on RedHat Enterprise Linux. This is not relevant at all as this isn’t what the customers have been asking for and is technically not possible. Customers want to know about RHEL running on Nutanix AHV, not about Nutanix AHV (which is a hypervisor) running on RHEL (not technically possible). RedHat clearly has their wires crossed.

RedHat only sells support and patches. If RedHat fails to provide support their contract can be cancelled. If RedHat refuses to provide support for their OS, you can get support for RedHat Enterprise Linux from Suse and others. It’s Open Source software, so anyone can support it.

RedHat is a member of TSANet and therefore can be compelled to provide support under the terms of TSANet, which is a multi-vendor support organisation. RedHat even includes the details of TSANet in the third party support statement. Nutanix is also a member of TSANet. The only time Nutanix would ask a customer to engage RedHat on a support incident is if we believe the defect or fault is with the RedHat OS after a full analysis.

Nutanix routinely finds defects with various packages of RedHat, CentOS and other Open Source vendors and provides our patches to the community for use. We have contributed a ton of code to Open Source projects over the years and continue to do so. We also regularly find bugs in Open Source operating systems and fix those bugs and provide our patches upstream. This is how Open Source is meant to work.

Final Word

In summary, RedHat Enterprise Linux is supported on Nutanix AHV, by both RedHat and Nutanix, it’s in writing and it’s black and white. It is covered under RedHat’s third party support policy and where RedHat Enterprise Linux is suspected of the fault RedHat support will resolve it.

Where necessary RedHat and Nutanix can work collaboratively through TSANet. Regardless of where the fault is found, Nutanix AHV Customers are covered for Support when using RedHat Enterprise Linux under their support contracts (provided it’s a version validated on Nutanix AHV). If getting full RedHat certification was as simple as running some standard tests and submitting them to RedHat, then Nutanix would have done that already. RedHat needs to stop spreading FUD, stop punching their customers in the face,  and get on with supporting customers!

https://giphy.com/gifs/beatsbydre-l0Hlymtk1LGZTRdM4

If someone from RedHat happens to be reading this article and would like to provide a reference to the certification program for hypervisors for RHEL and any other relevant certification programs I’d be happy to get Nutanix to go through them. To date, in spite of spending hours searching RedHat.com I’ve found nothing.

This post first appeared on the Long White Virtual Clouds blog at longwhiteclouds.com. By Michael Webster +. Copyright © 2012 – 2019 – IT Solutions 2000 Ltd and Michael Webster +. All rights reserved. Not to be reproduced for commercial purposes without written permission.

When you have a crisis in your VMware environment do you like manually finding a needle in a hay stack of needles to identify the root cause? Do you love spending endless hours with your fingers walking through knowledge base articles, google searches, and scratching your head while your users suffer? Do you have so much time on your hands that you want the sky to be falling so you can spend your after hours and weekends solving problems?

Hopefully the answer to all of the above is no. Most problems you encounter in your VMware environments will already be known issues, many times with a simple solution. Hopefully testing of the patches and upgrades, and combinations of hardware and software was also tested before going into production. But it’s really hard to catch everything and to constantly audit your environment against problems and configuration drift. When an ounce of prevention can prevent an avalanche of cure being needed, Runecast might be the solution you’re looking for. I caught up with the CEO and Co-Founder of Runecast, Stanimir Markov, in Melbourne recently to get the lowdown on what it is and how it can help customers prevent trouble in their VMware environments.

I’ve known Stanimir for a long time as he got his VCDX (VMware Certified Design Expert) shortly after I did. For those that don’t know VCDX is the top VMware certification that is held by a couple of hundred people in the world, people who have proven their VMware and solution architecture expertise. Which makes the knowledge that is built into Runecast all the more interesting.

So what does Runecast do? Well they have built a product called Runecast Analyzer, which they describe as follows:

Proactive VMware management solution that uses our expertise and VMware Knowledge Base articles to analyze virtual infrastructure and expose potential issues and best practice violations, before they cause major outages.

I think the last part of that sentence is the most important, i.e. doing something before it causes a major outage. Runecast uses machine learning and big data analytics and natural language processing to figure out what the VMware KB’s are saying, what the logs in your environment are saying, and what the configuration has been set to and then analyzing if the combination might lead to any issues. Anyone that has spent any time going through VMware KB’s knows this isn’t an easy task. By melding the VCDX knowledge, VMware KB, Logs, and config, and putting some very smart data scientists to work, Runecast Analyzer can continuously monitor and alert you to any irregularities that might potentially cause you a headache.

I really like the fact that Runecast Analyzer can be used in dark sites just as easily as in connected sites. It doesn’t rely on any live outside connection to do the data analysis and updates can be done offline. This is important in secure environments, such as Government organizations. Here is what the architecture looks like.

The Runecast Analyzer appliance can be deployed and operational within minutes and provides continuous compliance and monitoring across multiple vCenters. It’s a very simple and elegant solution to a very tough time consuming problem.

Final Word

If you are looking for a continuous monitoring, alerting and analysis platform to prevent problems in your VMware environment before they occur then Runecast is worth a look. It can help you reduce downtime, improve security, and reduce cost of VMware environments of any size. In the future it could well be expanded to include other parts of the VMware ecosystem including networking / switching. There are certainly a lot of opportunities for a product such as this to build on the current momentum and go into new areas.

This post first appeared on the Long White Virtual Clouds blog at longwhiteclouds.com. By Michael Webster +. Copyright © 2012 – 2017 – IT Solutions 2000 Ltd and Michael Webster +. All rights reserved. Not to be reproduced for commercial purposes without written permission.

Support from any organisation you do business with is critical, when things go wrong, you want to know you have someone to call on that can help you. With regard to VMware Support you have a great number of options available to you, so that you can get the type of support you need. Whether it’s from very basic level cover, to mission critical cover. The support you need often comes from different sources, and may include outsourced service providers, cloud service providers, IT resellers, consulting companies, and of course your hardware / software vendor, VMware’s ecosystem partners and VMware directly. One thing that many customers might not know is that VMware not only supports it’s own products, but it provides expert support for Oracle Databases and other Oracle software products that run on it’s hypervisor. This service is offered 24/7 to any customer with an existing VMware Support agreement. This article will give you some basic tips that I’ve picked up from over a decade of experience with VMware Support, in it’s many forms, and two decades dealing with IT support organisations in general. Having worked closely with many of the VMware support engineers from VMware Global Support Services in many different parts of the world and including business and mission critical support I can say that they are dedicated to resolving customer problems in a timely manner, as are all of your VMware partners and the VMware community at large. This article will give you a 5 step process to get the most out of our support interactions with VMware.

Step 1: Choosing the Right Support Level

Support really starts before a purchase is made. You need to understand your support options and purchase the support that best meets your needs, and it should be reviewed regularly as your requirements change. From VMware Support (OEM support through OEM partners is slightly different and I’ll get to that) you have four main support offerings, basic (12×5), production (24×7), business critical and mission critical (24×7 with proactive components and dedicated teams). Details of their support offerings can be found on this page. Also the VMware TAM service is incredibly valuable, and although not tied directly or just to support, can assist with important cases, escalations, and preventative actions so you don’t run into trouble in the first place.

Unless you run a very basic environment during business hours only you really should have a minimum of production level support. For any business or organization that has a reasonable size investment in VMware Technology, say more than 50 hosts or 2000 VM’s or lots of integrated products, or where you are running business critical applications, you should seriously consider business critical or mission critical support. In my experience the business benefits from business critical and mission critical support in terms of access to information, dedicated and experienced personnel,  proactive support, combined with root cause analysis, far outweighs the additional investment.  Many customers have a lower level of support than they actually need to meet their business requirements. If you have a lower level of support than you need you shouldn’t get upset when you get the level of support you’ve signed up for.

Importantly, when you buy your licenses from any VMware Partner, and pay VMware for Support and Subscription services, you are entitled to call VMware Global Support Services. In addition to this, your chosen hardware or solution vendor may also offer you support for more than just the basic hardware break fix as part of your agreement. If you have such a support agreement with your chosen hardware partner or solution provider you may ring them first and depending on their offerings they may coordinate with VMware Support on your behalf.  But this is important because it means if you have a support contract with VMware there can be no gray areas around your entitlement to use and enjoy VMware official support directly from VMware.

Your VMware partner, solution provider or hardware vendor managing your support interactions with VMware is quite common in managed service provider relationships and with the converged and hyperconverged market. As an example, I work for a hyperconverged vendor, Nutanix, we don’t sell VMware Licenses or VMware Support, although our solution is supported by VMware on the Hardware Compatibility List (HCL), our partners (who are VMware partners too) do sell the VMware licenses and support that as part of an overall solution (so customers have the option to call VMware or their OEM directly). Our support organization is set up for and prepared to help with almost any problem on our platform from application down through hypervisor, hardware and network. Nutanix will coordinate support interactions with VMware where necessary and also with other vendors. Nutanix also OEM through Dell (Dell XC Series Appliances Powered by Nutanix software) and Dell can provide support also (more on OEM in a minute). Other vendors may offer the same. You can have ‘one throat to choke’ through your solution provider or vendor while still having direct access to VMware, if you choose (The power is with you, the customer).

When using VMware support you should be familiar with the terms and conditions of the VMware Support and Subscription Services (SnS) you should also take a look at the great Welcome Guide that VMware has developed.  VMware publishes their problem severity definitions on this page along with their support service level targets. I would recommend that you take a look at these and are familiar with them before purchase, but also during operations.

If you have purchased your VMware Licenses and Support through a VMware OEM partner (such as the big OEM server vendors), or a reseller of the OEM, the process is slightly different. This is explained very well in the VMware OEM Technical Support Welcome Guide. In this case you always call your OEM vendor for support directly (or your reseller / service provider sometimes takes the call and does this on your behalf) and they will be solely responsible for initial contact and level 1 and 2 support. Support Requests would be escalated to VMware if necessary at level 3, and your OEM vendor will coordinate that interaction for you. As mentioned previously with the Dell XC Series Appliances, where Dell OEM’s both VMware hypervisor and Nutanix software, they provide support for the entire solution. You can also get complete support for the networking stack also if you choose Dell Force10 or PowerConnect switches. I’ve previously written about their switches in my article Configuring Scalable Low Latency L2 Leaf-Spine Network Fabrics with Dell Networking Switches. Other OEM partners and solutions providers may have different support offerings and you should check them out.

Step 2: Make sure your chosen solution is supported on the VMware Hardware Compatibility List and Product Interoperability Matrix

The VMware Hardware Compatibility List is the first place to go to ensure that your proposed or chosen hardware and solution components are supported. The VMware HCL covers a wide variety of solutions including servers, storage, IO devices, networking and security products, and Guest OS’s for example. You can change the selections as you need.

The Product Interoperability Matrix displays the supported versions of different VMware products and Database Products and which versions work with which other versions, i.e. product interoperation.

Here is an example for Nutanix and for Dell form the VMware HCL (Click the images to see them enlarged):

Note: To find Nutanix listed on the Storage/SAN page you need to select the Storage Virtual Appliance Only radio button.

Here are some images from the Product Interop Matrix, one for interop between vCenter 6 and Horizon View, and another between vCenter 6 and MS SQL Server and Oracle, just as examples:

If you spot something missing from the HCL or the Product Interop Matrix, reach out to VMware. They do everything they can to keep them accurate, but sometimes something can slip through the cracks. It doesn’t hurt to check.

Step 3: Ensure you have a supportable solution, if it’s not in the product documentation, it may not be supported

There can be difference between something that works just fine, and something that is supported. The policy that most support orgnaizations have is that if it’s documented in either the product documentation or in their support KB articles, then it is supported. If it’s not explicitly documented, somewhere, then it’s not tested or supported. This is because there are an infinite number of combinations in customers environments and not all of them can be tested and supported. But this doesn’t mean support will drop the call and not try and help you (if it’s reasonable), but they will in all honesty probably strongly advise you to use a supported configuration, and provide guidance on how to get to the supported configuration. As an example, I can’t count the number of times I’ve seen people try to use a clustered vCenter using Microsoft failover cluster services and having it break while this configuration wasn’t supported (prior to vSphere 6).

Step 4: Use the VMware Knowledge Base, Documentation, and Community

Many of the problems you will run into are already well documented. Either in the VMware KB, the documentation or release notes, or by someone in the community. Many problems can be solved by a few minutes with your favorite search engine. However with sev 1 cases, I would recommend you use this while at the same time engaging VMware Support. The information you find through research can help Support Engineers as you can put it in your case notes and it can help narrow the field of investigation.

Step 5: Getting the most out of your support entitlements from VMware

So you’ve got your support in place and you need to raise a support request for a problem, what should you do to make the experience the best it can be? In this case we are assuming support directly with VMware Global Services.

a. Collect the Logs

Firstly, having collected the logs, which VMware Support Assistant Appliance can help with, is the first thing you should do. If you have a sev 1 incident where your systems are down it may not be possible to collect all or any logs, in this case you should use MyVMware Portal to raise a support request and also call into VMware Support at the same time, this will get you the fastest response possible. If you’ve got the logs, as soon as you raise the support request and get the case number assigned you should upload the logs to VMware’s secure portal site (See KB 2069559). When you upload the logs you’ll create a directory with the same name as the number of your support request. Only VMware support can access the information once uploaded, you won’t even be able to see it after the upload is complete.

b. Be as precise as possible

Being as precise as possible with the symptoms, when the problem arose, what has changed in the environment that may have contributed to the problem, and any other events that may correlate with the problem, really helps out your support engineer. This can help your technical support engineer quickly narrow down the problem domain and find a solution fast. Most support requests are resolved very quickly if precise information can be provided and the logs are available.

This was the case on a recent support request I logged with VMware for a problem I was working on with vCenter 6 after an upgrade. I raised the support request online, as soon as I got the reference number I uploaded the logs. I put in the case notes at the time I raised it what the symptoms were, when it occurred, what had happened in the environment, and an overview of the configuration and the environment I was working in. This combined with the logs allowed VMware support to pinpoint the problem, explain what was happening, why it was happening, and ultimately point me to the right information. Also as part of the case they raised a feature request and product improvement request to remove what caused the issue in the first place, and said it was already being worked on. All in all, very good exprience. By being precise and having the logs this support request was able to be resolved very quickly.

c. Raise the request at the right severity level

Logging a support request with the correct severity can help save a lot of time and effort for all parties concerned. If you log a call with an incorrect severity it could either get bounced down, or you could find that you don’t get the response you actually need. Both being too high, or too low would be a problem. In the example I gave in b. above I logged the request as a severity 3 and was still provided service within a very reasonable timeframe.

d. Let them know what troubleshooting you’ve already done

If you’ve already done a lot of troubleshooting and reviewed a lot of KB articles and none of the actions have resolved the problem then you should include the steps you’ve taken in the notes. This will allow your tech support engineer to skip all these steps, as they’ve already been tried. When troubleshooting you should try and follow a logical process of elimination and narrow own the problem domain as much as possible. This helps focus the attention on the most likely areas that could be causing a problem. But I would give a word of caution, if you are not able to narrow down the problem get support involved sooner rather than later. They will help and may be able to do this much faster.

e. Don’t piss off the support person who’s actually trying to help you

The Support Engineers are just trying to help you solve your problem. Getting their backs up is not the way to go about getting timely service. (This is for you Frank Buechsel)

f. Have your passwords ready so they can be used when needed

If you have a production down situation you are going to want to have your passwords etc at the ready so you can walk through the troubleshooting steps with your support engineer. You don’t want to waste time fumbling around trying to find them. If you have them locked away in a safe, get someone to approve and extract them prior to your call to VMware Support.

Final Word

For anyone using VMware technology there is a massive amount of support available. Through the official support channels as well as through the very well established VMware community, and the strong partner ecosystem. The power to chose the right support path for your business requirements is in your hands. VMware and it’s large number of partners provide high quality support and this is one of the reasons VMware vSphere is a great place to run Business Critical Apps and Enterprise Databases. A lot of this article should just be common sense, but a lot of times it is uncommon. I’d be happy to hear comments from people about their tips for getting the best results of our support based on their experiences.

—

This post first appeared on the Long White Virtual Clouds blog at longwhiteclouds.com. By Michael Webster +. Copyright © 2012 – 2015 – IT Solutions 2000 Ltd and Michael Webster +. All rights reserved. Not to be reproduced for commercial purposes without written permission.

The great thing about working for a company that is in the business of making software defined datacenter a reality (Nutanix) is that whenever we make a software improvement every existing customer benefits. They get all the software benefits even without changing hardware. This often includes things like performance improvements, but it also includes things such as manageability improvements and also support improvements. Let’s briefly cover some of the great enhancements to one click upgrade, and the support user experience of the revamped Nutanix customer support portal that was released tonight.

In the Nutanix OS release 4.0 we introduced One-Click upgrade, which updates the storage software on the controller of the Nutanix appliances, but soon it will do much more. The One-Click functionality is not just limited to a one-click upgrade of the storage controller, but other components of the platform including firmware of hardware components, BIOS, and even the hypervisor. In future releases we will be including non-disruptive upgrades of the hypervisor in addition to storage controller software, hardware device firmware and BIOS of the Nutanix Hosts, all with just a single click. Managing your storage environment really couldn’t get any easier. How many other platforms can offer this type of one click user experience for an entire virtual platform? This is part of the always on nature of WebScale IT architecture that Nutanix delivers that is applicable for everyone to use for any application. For more information on these features check out Andre Leibovici’s blog – Nutanix One-Click Upgrade now takes care of Firmware and Hypervisor too!

Tonight Nutanix released it’s new customers support portal, which has been completely redesigned to look and function beautifully and simply like the Nutanix Virtual Computing Platform UI – PRISM does. Now all your contract, support case, documentation, and upgrade information is in one place, available more easily and more quickly. There is links in the PRISM UI of your Nutanix Virtual Computing Platform so you are never more than a click away from support (in the unlikely event that you need it). In the future we will be including the ability to create support cases and upload the support logs directly from the PRISM UI, if the environment hasn’t already told Nutanix what is wrong using the automated Pulse support alerts, which proactively monitor the environment health so we can resolve problems before you even know about them. Below is a short video of the new Support Portal, which shows how some of the new functionality works, including when you search getting results for KB’s, Documentation, and our Reference Architectures and other tech papers.

Final Word

At Nutanix we’re not just trying to drastically simplify the infrastructure, but everything that surrounds the infrastructure, including the business and procurement processes and support processes. If we can make everything easy for you then you’ll want more of it, and you can concentrate your time on value added activities, or spend more time with your family.

—

This post first appeared on the Long White Virtual Clouds blog at longwhiteclouds.com. By Michael Webster +. Copyright © 2012 – 2014 – IT Solutions 2000 Ltd and Michael Webster +. All rights reserved. Not to be reproduced for commercial purposes without written permission.

I heard some great news yesterday from the man in charge of Oracle Solution Support at VMware Global Support Services. The Extended Oracle Support Policy that VMware provides for all customers running Oracle Software on VMware vSphere is going to be extended even further.

From Q1 2013 the VMware Oracle Solution Support will be running 24/7. This will ensure that customers can receive end to end support for the hypervisor and their Oracle software all from one place at any time of the day or night. VMware will then handle any necessary handoffs to Oracle support if software patches are required. Refer to the VMware Extended Support Policy for what is covered by the support. It’s great to see VMware continuing to invest in the support of our customers to ensure they can get the best value and experience when running on vSphere.

For additional information on virtualizing Oracle visit my Oracle Page.

—

This post first appeared on the Long White Virtual Clouds blog at longwhiteclouds.com, by Michael Webster +. Copyright © 2012 – IT Solutions 2000 Ltd and Michael Webster +. All rights reserved. Not to be reproduced for commercial purposes without written permission.

I keep hearing stories from Customers and Prospects where Oracle appears to be trying to deceive them for the purposes of extorting more license money from them than they are legally required to pay. I also keep hearing stories of Oracle telling them they would not be supported if they virtualized their Oracle systems on VMware vSphere. This has gone on now for far too long and it’s time to fight back and stop the FUD!

In my opinion the best way for you to prevent this situation for your company is by knowing the right questions to ask, and by knowing what your obligations are. The aim for this article is to give you the tools to pay only what you legally owe, while making the most efficient and economic use of your licenses, and get the world class support that you are used to, even in a virtualized environment on VMware vSphere. All without sacrificing availability or performance.

I’m going to start this article by quoting Dave Welch, CTO, House of Brick – “I believe in paying every penny I owe. However, beyond that, it is my discretion to who or what I donate and in what amount. I have no patience with individuals or entities that premeditate the creation of OLSA compliance issues.  I similarly have no patience with the knowing spreading of FUD by some professionals in what could be construed as extortion of funds beyond customers’ executed contractual obligations. I will continue to vigorously promote and defend the legal rights of both software vendors and their customers even if that means I induce accelerated hair loss through rapid, frequent hat swapping.” Source Jeff Browning‘s EMC Communities article – Comments by Dave Welch of House of Brick on Oracle on VMware Licensing.

I agree with Dave on this. So I am going to show you how you can pay what you owe, while using what you pay for as efficiently and cost effectively as possible, and show you how you can still enjoy the full support you are entitled to. Without the scaremongering that sometimes accompanies discussions with Oracle Sales Reps.

For those that aren’t familiar with the term FUD, it is an acronym which stands for Fear, Uncertainty and Doubt. Something some companies and professionals seem to go to great lengths to create in the minds of customers.

FUD #1 – Oracle Licensing and Soft Partitioning

Oracle’s Server/Hardware Partitioning document outlines the different types of partitioning and how they impact licensing. Oracle may try and tell you that licensing a VMware environment will be more expensive as they don’t consider VMware Hard Partitioning. This is complete rubbish. This assertion is completely irrelevant unless you were only planning on deploying a single small database on a very small subset of a very large server. In this case you probably wouldn’t be using Enterprise Edition and may not be paying per CPU Core (Named User Plus instead). Why would you deploy such a system when you could easily purchase a server that is the right size for the job and licensed appropriately for the job? There is absolutely no requirement to run Oracle Enterprise Edition just because you are virtualizing your databases.

There is absolutely no increase in licensing costs over and above what you would have to pay for the same physical infrastructure to run your Oracle Database if you were running it in the OS without virtualization. You still have to pay what you owe, for what you use. The truth is that your costs could actually be significantly less when virtualizing on VMware vSphere as you can get more productive work done for the same amount of physical hardware, and therefore the license requirements and your costs will be significantly less. This is because you can run multiple Oracle databases on the same server and effectively share the resources, including memory, provided you take care during your design to ensure any undesirable performance impacts are avoided.  Take this image for example showing consolidating two dissimilar workloads on the same hardware (Source: VMware).

Even if you only want to deploy a single database server you are significantly better off if you right size the host server and VM and deploy it isolated out of a cluster, but still virtualized, even if it is the only VM on the host. This will allow you to still take advantage of many of the benefits of virtualization, such as significantly easier disaster recovery due to the complete hardware independence, better monitoring via your existing virtualization monitoring tools, the ability to run unlimited number of database VM’s on the fully licensed host server. If you want high availability and non-disruptive maintenance and upgrades then you just need to add a second fully licensed host server. You can still make use of all the resources of both servers.

I discussed in my article Oracle RAC 11g R2 Standard Edition on vSphere how you could deploy up to 4 VMware vSphere hosts with a single CPU socket each to run an unlimited number of Oracle Standard Edition Databases, including Oracle RAC. This is an incredibly cost effective solution, especially as Oracle Standard Edition is not memory limited, and is licensed by processor up to a maximum of 4 sockets per host, but unlimited cores. You still pay per core, but significantly less. You should make yourself familiar with the different Oracle Database Editions and their limitations.  When you virtualize on vSphere because you get HA you may be able to downgrade some Oracle Enterprise Edition licenses to Standard Edition and potentially make a significant saving, at least in maintenance costs. You also gain effective resource isolation capabilities without having to use Oracle Database Enterprise Edition. Remember what I said before, there is no requirement to run Enterprise Edition when you virtualize your databases, you can run any of the editions provided you deploy them within the license and technical restrictions. In all cases you must ensure that all processors are licensed for Standard Edition in compliance with the OLSA and Software Investment Guide.

If you are using Oracle Database Enterprise Edition there is an opportunity to save significant amounts of money if you are migrating from traditional Unix platforms to Linux or Windows running on VMware vSphere. This is due to the way that Oracle calculates the CPU Core License Factor. The Intel CPU’s have a Core License Factor of 0.5 compared with some of the higher end traditional Unix platforms Core License Factor of 1.0. This means you need half as many licenses to cover the same number of of Intel CPU Cores as you have in your traditional Unix platform. Oracle may say that’s because the Intel systems are inferior and don’t perform. However based on my experience modern x86-64 hardware will outperform most of their Unix counterparts. In some cases you can achieve up to 5x the performance compared to a traditional Unix system when utilizing the same amount of licensed hardware (One of my customers did). Not that the new SPARC T4 Processor now has a 0.5 core factor, the same as an Intel Xeon CPU. I take this to mean Oracle recognises the power of the Xeon chips, but one key thing to note is that the SPARC T4 is over twice the price per core as the Intel Xeon counter parts.

The real hard dollar licensing savings here will come into play when re-negotiating maintenance if you already own all the perpetual licenses you need. It will also come into play if you expand the environment as you will be able to avoid purchasing any additional licenses, seeing as you have spare licenses after the switch to the x86-64 platform.  If you are in a position where you need to expand the environment and you’re on a traditional Unix, now might be the perfect time to make the switch and put the additional license money into the cost of the migration project instead. I have outlined in a previous article what I think are the Top 10 Reasons to Migrate Oracle Databases from Traditional Unix to Linux on vSphere. License Maintenance costs are not the only cost savings by switching to x86-64 from traditional Unix, you may also save significant amounts of power, cooling, data center floor space and hardware maintenance costs. In one of my recent projects the 15 months of the cost of the traditional Unix platform hardware maintenance paid for the entire project costs to switch, services, software and hardware.

If you have an uncapped ELA (ULA in Oracle Terms – Unlimited License Agreement) you can deploy the database software wherever you like the whole discussion about soft or hard partitioning, or the number of cores, is completely irrelevant. You should deploy as many databases as possible and make the best use of your software entitlement. This will come into play quite strongly with my next FUD item below. Be careful to only use the features you are licensed for however, so you don’t get any nasty surprises come audit or ELA/ULA renewal time (provided your use is within your OLSA agreement).

FUD #2 – Oracle Sub Cluster Licensing is Not Possible

Still on the licensing topic, but this area of FUD comes into play when you want to only license a subset of hosts that make up part of a large cluster for use by Oracle. Contrary to what many might believe or try and tell you it is fairly easy to deploy and license a subset of a larger VMware vSphere Cluster. It is also perfectly acceptable under the Oracle Software License Agreement, provided you can prove that the Oracle binaries have only been executed/run on the systems that make up the subset of the cluster. Now just because you can do this doesn’t necessarily mean I would recommend it and after I explain how you can do it I’ll tell you why in many cases this might not be a good idea, and it has largely nothing to do with licensing.

If you don’t have a copy of your signed and executed Oracle License and Services Agreement (OLSA) you should get one and read it thoroughly. You should also become familiar with the Oracle Software Investment Guide and the Oracle Licensing Data Recovery Environments Guide, which is an extract from the Software Investment Guide. I would advise that you get a copy of the Software License Investment Guide and Licensing Data Recovery Environments Guide that was valid at the date you signed your Oracle Software License Agreement. This will ensure you know what the policy that applied to you at the date you signed the agreement.

Before we even get into the mechanics of this you won’t have to even worry about this if you have an uncapped ELA or ULA. If you have an uncapped ELA or ULA you can run your databases anywhere and everywhere, and it’s in your best interests to do so as it will mean come true-up or renewal time all your clusters will be covered and fully licensed (dependant on the wording of your specific OLSA). The following will only be a concern if you are licensed with a capped or limited license agreement, or you do not have an ULA. If Oracle tries to use this as an objection for virtualizing on VMware vSphere just ask them this: “Why is sub cluster licensing even a relevant reason not to virtualize given we have an uncapped ELA or ULA?”  One of my customers asked Oracle this and Oracle agreed it wasn’t relevant. The same applies if you are licensed under Named User Plus.

The following is an extract from Dave Welch’s comments with regard to the Oracle Software License Agreement and Oracle Software License Investment Guide with regard to processor based licensing:

• “Customers must license all physical cores or sockets on a host where Oracle executables are “installed and/or running” (with physical cores factored per Oracle’s published Core Factor Table, and potentially subject to the so-called 10-day rule [whose terms became more restrictive sometime during 2007]). Notice the tense. Oracle customers are contractually obligated for licensing the physical servers where the Oracle executables are and have been, not where they might go. To imply otherwise without explicit contractual inducement would not be unlike concluding that I am legally obligated to purchase transportation to or obtain a visa for destinations that I clearly have the capability of visiting but where I have neither ever been nor yet made a determination to even visit.”
• “Furthermore, customers must pay a license to cover the use of remote mirroring at the storage unit or shared disk array layer to transmit Oracle executables to a SAN whether or not that set of Oracle executables is “installed and/or running” on any physical host connected to the SAN.”

So you can tell from the above you must be able to prove where the binaries are installed and/or running or where they have been installed and/or running. Regardless if the mechanism is manual or automatic. I strongly recommend that you read the Certification of an Oracle ULA Agreement (or: Need to defuse a time bomb) article posted on the License Consulting blog. It will give you some insight into the Oracle Audit and Certification process and some really big traps you need to try and avoid.

I will discuss both manual and automated ways of ensuring license compliance, but first lets contemplate for a moment a situation in an unvirtualized environment where you’ve taken a snapshot of a production systems LUN’s and presented them to another system. Both the production system and the new system must be fully licensed. This is fine, and you would know which systems the binaries are installed and/or running on as you have had to go to a lot of effort to snapshot the LUN’s and present them. This changes a bit when you are running in a large cluster.

License Isolation Method #1 – Storage Zoning / Masking to a Subset of Cluster Hosts

VMware Best Practices recommend that you present all LUNs to every host within a cluster. Under normal circumstances this makes perfect sense and is definitely the best option. However if you wanted to license a subset of the cluster for Oracle you might choose to zone and mask the Oracle LUN’s/Datastores to only the hosts within the cluster that will run Oracle. This will prevent the virtual machines without some further manual actions to run on any other hosts within the cluster. You can still have DRS enabled in fully automated mode and it can happily migrate the Oracle VM’s around the hosts that are licensed and zoned/masked to the storage. This has an advantage of being fairly easy to administer and manage. This still allows the use of Maintenance Mode and VMware HA. One of the major downsides here is you could easily reach the maximum number of LUNs per Host if your databases consume multiple LUNs and the rest of the non-Oracle VM LUNs are also zoned/masked to the Oracle Hosts. If those non-Oracle LUNs are not zoned or masked to the Oracle hosts then I’d question why you aren’t choosing method 4 below.

License Isolation Method #2 – DRS Set to Manual or Disabled for Oracle VM’s

This method will allow you to run all the hosts in a DRS cluster fully automated while restricting the movement of the Oracle VM’s. Administrators would have to manually move the VM’s, which would add administrative and management overheads. License compliance would be maintained provided the administrators only moved the VM’s to licensed hosts. You would need vMotion logs or an audit trail to prove which systems the Oracle software were/are installed and/or running. You may need to disable these VM’s from VMware HA to ensure there was no possibility of the Oracle software being installed and/or running on an unlicensed host. Given the chances of error and the difficulty introduced in managing the cluster this method is not recommended, even though it will meet the license conditions provided it is configured and administered correctly. Suffers from the same limitation as method 1 with regard to likelihood of reaching max number of LUNs per host.

License Isolation Method #3 – DRS Host Groups

This method allows you to ensure the Oracle VM’s are only installed and/or running on a subset of the hosts within a cluster without any special storage configuration and also with the DRS cluster remaining fully automatic when used in combination with DRS Must Rules. This is fairly easy to administer and allows for the use of maintenance mode and VMware HA. You can use the advanced option ForceAffinePoweron to ensure the VM’s will only be restarted by HA on a fully licensed host when there is a host failure. You will need vMotion Logs, or an audit trial of some sort to be able to prove where the Oracle software was/is installed and/or running. Suffers from the same limitation as method 1 with regard to likelihood of reaching max number of LUNs per host. There was a video recorded with Richard Garsthagen of Oracle on VMworld TV during VMworld US 2012. The video can be viewed in this article on the License Consulting Blog – VMworld – Richard Garsthagen (Oracle) on licensing VMware / virtualized environments.

License Isolation Method #4 – Dedicated Oracle Cluster

While not technically a way of deploying a sub cluster of hosts for Oracle inside of a larger cluster this is often my preferred method of deployment. The main reason this is generally my preferred deployment method is because of it’s simplicity. Other reasons include:

• You know the VM’s will only be running within this cluster, so you can license the whole cluster and be done with it.
• You can ensure you make optimal use of your licensed hardware without any non-Oracle VM’s consuming valuable infrastructure that is licensed for use by Oracle.
• This allows an easier isolation of resources, as you will not have any non-Oracle VM’s consuming resources as would be the case with method 1, 2 and 3.
• You can run a different consolidation or overcommitment ratio for the Oracle Cluster, which you might want to do for availability and performance reasons.
• You can right size the infrastructure for your exact Oracle requirements (smaller or larger hosts and NUMA node sizes).
• No complicated settings for VMware HA and no risk of a VM restarting on an unlicensed host in the case of a host failure.
• Much easier from an audit and compliance perspective.
• Less likely to reach the limit of the maximum number of LUNs per Host compared to method 1, 2 or 3.
• Much lower likelihood of human error causing a licensing compliance issue.

With a properly designed dedicated cluster for Oracle you can make efficient and optimal use of your physical licensed hardware while still allowing maintenance and failure capacity. I disagree that this is significantly harder to manage than having a subset of hosts in a larger cluster. I actually argue that this is far more efficient to manage, especially given the need to ensure license compliance and the financial consequences of getting it wrong and the much lower likelihood of human error. Even if your dedicated cluster has only 2 or 3 hosts it still has a number of benefits. Probably one of the most significant benefits is the reduced likelihood of reaching the maximum number of LUNs per host. If you are running a big Oracle environment this is a very real possibility especially if your databases demand maximum performance and are therefore configured with multiple LUNs each.

Audit and Compliance Made Easy

Although vMotion Logs may be an acceptable way to provide proof of where Oracle software was/is installed and/or running my preferred method would be to use vCenter Configuration Manager (vCM). vCM is a tool that is purpose built to ensure audit and compliance and configuration management. It will track every modification to configuration items including vMotion Migrations. It is also used to ensure regulatory compliance with standards such as HIPPA, SOX, PCI DSS, DISA STIG and others. vCM is accredited as a SCAP 1.0 tool. It is relatively easy to get up and running and produces all the necessary reports once it has been configured. It can be purchased in isolation or as part of the vCenter Operations Enterprise or Enterprise Plus Edition Suites. vCM is not limited to compliance of virtual machines and VMware environments, it also supports physical systems, including workstations and traditional Unix systems. I would strongly recommend you consider this given the direct integration with the VMware vSphere environment and the tremendous value it can add to your entire virtual and physical infrastructures.

If you didn’t want to use vCM you may want to consider another tool such as SPLUNK, which allows for secure storage of log records and easy visualization of those logs.

FUD #3 – Oracle is NOT Certified to Run on VMware vSphere

This isn’t FUD, it’s true. Oracle isn’t certified to run on VMware vSphere. This is because Oracle does not certify below the Operating Systems. So your system isn’t certified to run on Dell, HP, or IBM hardware either. Oracle instead certifies the operating systems that run their software. So provided you are running a fully certified and supported version of the OS then you are covered. This is because VMware does not modify the OS. This topic is covered in the Understanding Oracle Certification, Support and Licensing for VMware Environments white paper published by VMware.

FUD #4 – Oracle Does NOT Support Running on VMware vSphere

Is Oracle trying to tell you that if you virtualize on VMware vSphere that you won’t get support? Are they saying that they will fail to meet their contractual obligations and support the software that you’ve potentially paid millions of dollars for? That although your running on a certified and supported OS, that because you’ve changed the underlying hardware that they won’t support you any longer? Or are they just saying you will have to move your databases back to physical if there is a support problem?

I’ve heard all of the above, and still do sometimes. It’s very surprising given that Oracle has been supported on VMware since 2007 and Oracle RAC 11g R2 (11.2.0.2) has been supported on VMware vSphere 4 and above since November 2010. Oracle has a very explicit support statement when it comes to operating in a VMware environment. The support statement is covered in Metalink 249212.1 and an extract is below:

“Support Status for VMware Virtualized Environments
————————————————–
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 an 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.
 
If the problem is determined not to be a known Oracle issue, we will refer the customer to VMware for support.   When the customer can demonstrate that the issue occurs when running on the native OS, Oracle will resume support, including logging a bug with Oracle Development for investigation if required.
 
NOTE:  Oracle has not certified any of its products on VMware.  For Oracle RAC, Oracle will only accept Service Requests as described in this note on Oracle RAC 11.2.0.2 and later releases.”

So we’ve had that ‘Not Certified” statement come up in this, so refer to FUD #3. Let’s break this down.

1. The above is very clear. Oracle support will recommend an appropriate solution on the native OS for any known issues. This makes perfect sense and as VMware does not modify the native OS this is absolutely fine.
2. If the solution does not work in a VMware virtualized environment the customer will be referred to VMware for support. This is perfectly understandable and acceptable. If there is a problem with the VMware software then VMware will need to support it, I’ll discuss the VMware extended support policy below.
3. If the problem is an unknown issue then the customer will be referred to VMware Support and when it’s demonstrated to be an issue on the native OS Oracle will resume support. Again this is perfectly understandable. If the problem is with VMware software that VMware should fix it. However VMware does not modify the OS therefore the problem if it’s not directly related to the VMware vSphere software will is being experienced and would be experienced by the native OS.

So the above means for any Oracle problems with the Oracle software Oracle will support you. End of story. You potentially have to prove it’s an Oracle software problem, but that is no different to the system being run on a native OS. If it’s an unknown problem to Oracle they may ask you to reproduce on a different hardware platform.

If the above isn’t enough to satisfy you that you are supported when running on a VMware vSphere platform and on a supported and certified OS then the VMware Extended Support Policy should. Under the VMware Extended Support Policy for Oracle Databases VMware Technical Support will take total ownership of any Oracle Database problems reported to them, as well as providing access to a team of Oracle DBA resources, and working with Oracle support until resolution.

I have to say that the Oracle Support team is world class and I’ve always had a good experience dealing with them. I have had the same world class experience when dealing with VMware Global Support Services, and especially the Oracle Technical Support Engineers.

In addition to the above it wouldn’t do any harm to get Oracle to confirm in writing that your environment will be supported.  Oracle backed down after they knew a customer of mine was serious and put in writing that they would fully support the environment in accordance with the terms of the contractual obligations and their support policy.  So now there is absolutely no ambiguity about the situation. It is supported, end of story.

Key Questions to Ask Oracle to Fight the FUD

• Where does it say in my OLSA, which is our legally binding contract, that I must purchase licenses over and above the licenses I require for all of the CPU cores or Sockets where the Oracle Software is running and/or installed?
• Where does it say in the OLSA, which is our legally binding contract, that I am not able to run on a subset of cluster hosts provided I can prove where the Oracle Software is installed and/or running in accordance with the contracted terms and conditions?
• How is licensing a complete cluster with the required number of hosts any different from licensing the required number of standalone native physical servers?
• Does Oracle Certify the underlying hardware platforms below the OS that run Oracle software such as IBM, HP or Dell servers?
• Given that you don’t certify below the OS why would running a fully certified and supported OS on top of VMware vSphere be unsupported or be any different from a support perspective than running on native given that VMware does not modify the OS?

Final Word

I have added two more items to this list of FUD in another article called Return of the FUD – Oracle Licensing on VMware vSphere.

I hope this article has been some help and has empowered you to stand up for your rights under your legally binding contracts. You can find more commentary from Jeff Browning and Dave Welch at the following locations: Oracle Storage Guy – Dave Welch of House of Brick on Oracle on VMware Licensing, Comments by Dave Welch of House of Brick on Oracle on VMware Licensing and Oracle Licensing on VMware – Reprise.

Read Certification of an Oracle ULA Agreement (or: Need to defuse a time bomb). It will help you understand where you might end up during an Oracle audit / certification process and how to use the process to your best advantage and avoid some traps. Follow this up with this article by the same authors – The impartial objective of Oracle’s compliance auditors: A 5 Million Dollar target.

A great reference for Oracle Licensing and Support has been written and published by VMware titled Understanding Oracle Certification, Support and Licensing for VMware Environments.   Some of what I’m about to describe is covered in this document and I would definitely recommend you read it.

Maybe a reason Oracle appears to be trying to perpetuate these myths around licensing and support is because the traditional Unix hardware business and Solaris is on a major downward trend. See IT Candor’s Server Market Report for the details.

For guidance and ides for design and architecture for your Oracle Databases on vSphere here are two great articles. Deploying Enterprise Oracle Databases on vSphere, Blueprint for Successful Large Scale Oracle Virtualization on vSphere.

For additional information on virtualizing Oracle visit my Oracle Page.

—

This post first appeared on the Long White Virtual Clouds blog at longwhiteclouds.com, by Michael Webster +. Copyright © 2012 – IT Solutions 2000 Ltd and Michael Webster +. All rights reserved. Not to be reproduced for commercial purposes without written permission.