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.
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.
Some tips for VMware support:
A) Get a decent FTP server + bandwidth – 2GB worth of logs don’t upload very well on what is probably a single Windows 95 machine
B) Engage engineering in the coms calls with the customers. “We will provide feedback in 2 days after we revert with engineering” does not go well of theres a sev 1 with production outage at your 2nd biggest customer
C) Ping Pong is a great game, play it at home or in a club not during a business call.
The quality of VMware support has drastically decreased over the years. As an example I worked for a huge VM shop and we had a sev1 for 6 months with daily outages despite the fact we had business critical support. Unacceptable.