VMware

Submitting Cases to GSS

I have some experience in taking cases in GSS and I thought I’d share some simple tips on how to get your case submitted in such a way that you shouldn’t be asked twice for the same information.

 

**Firstly, logs.**

This is a contentious issue for some customers but the fact is, you’re using software and most software is set to write logs. When GSS asks for logs, they want to capture as much information as possible. The idea being that the issue may have been seen before and they can search internally for any related cases or documentation.

Additionally, if the issue has to be escalated to Engineering then they’re going to want to see as much context as possible.

 

This KB will tell you where most log files are written to:

https://kb.vmware.com/s/article/1021806

And this KB will tell you how to upload your logs to your SR:

https://kb.vmware.com/s/article/1008525

 

So, the ask from GSS is to open an SSH session to the product you are using and tail the logs.

Linode has a great guide on Tail here: https://www.linode.com/docs/quick-answers/linux/how-to-use-tail/

 

Let’s take a host for example, as all VMs live on hosts. We know that the hostd.log resides in /scratch/log so you’ll open an SSH session to that host, and start a tail. You’ll then reproduce your issue and, with a bit of luck, you’ll see WARN or ERROR flash past your eyes.

CTRL+C to cancel the tail and generate a single bundle with the command: *vm-support*

Now, you can SCP or FTP that bundle off and take a look at the hostd.log yourself. You’ll be looking for the name of the VM, the Job ID the product gives you, perhaps the ERROR or WARN keywords or you could be looking for the timestamp at which the issue occurred. Basic detective stuff, really.

This is true for all VMware logs and it’s how GSS start looking for the issue.

From here, you could probably Google the error and look for any KBs that are relevant. You may find your fix or, you might have gathered some pertinent information that GSS can use as a springboard.

 

**Screenshots**

The next most important thing are screenshots. You’ll be surprised at how useful a second pair of eyes are when it comes to looking at things.

It could be something like Tools not being installed, or an error or warning displayed in the UI you may have missed. We’ve all been there, you’re spending hours looking at something and you can’t see the wood for the trees.

Send screenshots. You can never send too many screenshots.

Make sure they’re fullscreen and they include your local date and time.

Especially important are product versions. Go to Help > About and screenshot that.

 

**Developer Tools**

VMware are phasing out the Flash client in favor of the new HTML5 UI. With that, comes the ability to spot issues with the Developer tools. On most browsers this is F12.

What GSS would like to see is if there are any entries in the Console window. If there’s an error then copy and paste the text into the SR (this makes it easier for GSS to search via text) and accompany this with a screenshot.

Take a look at the Network tab. Are you getting 503’s or 404’s? Put a check in Preserve Log and Hide Data URLs. Click on the *query?* and *task?* entries and dump the Headers and Responses into a text file.

 

**What not to do**

Don’t open an SR with a one liner as a description. You’ll get a request for more information, including logs and screenshots. More often than not, a day will be wasted arranging a suitable time for a remote session to gather aforementioned information.

Nobody likes wasting time.

Imagine you’re a mechanic. Someone has an issue with their car. They drive in to your shop, throw you the keys and say: “My engine doesn’t work”.

There’s no context. The mechanic starts on the basics but he can’t get hold of you. You’re busy in meetings all day and you’re unexpectedly called out of the office the next day. You may have gone on PTO and not left an Out of Office.

48 hours have passed and you get a call from the shop asking you for more information.

You’re livid. Why didn’t the mechanic fix your car? Aren’t they qualified? Surely the workshop only employs the best?

GSS aren’t mind-readers. They do have a wealth of knowledge at their finger tips but without context, your issue is meaningless.

 

**In closing**

GSS are aware that you pay for support. Support isn’t cheap and you expect the very best when you have an issue. You want it resolved in a timely manner.

The moral of the story is gather as much pertinent information as you can before submitting your SR.



View Reddit by sierradeltamikeView Source

 

To see the full content, share this page by clicking one of the buttons below

Related Articles

4 Comments

  1. There are tales from long ago of a mystical support rep, who could not only discern your issue w/o talking to you, but fix it w/o doing anything at all! All you had to do was breath in a panic’d manor while on the P1 line.

  2. Unfortunately, even if you do all of this, about 50% of the time you’ll get a canned email response 4 hours later asking for a description of the issue, what changes you’ve made, etc. even though a full description, screenshots, and full log bundles were included when creating the case. And, after that happens enough, you start to wonder if it’s easier to be as vague as possible so you don’t have to answer everything twice…

  3. Spoken like someone that actually has a physical lab they can get to, or training that was provided on some incredibly vague shit. For what TSE’s get paid, you should probably stop expecting TSE2 performance. When you step into a queue, you are ‘sold’ a bill of goods – what you will support and where all the documentation/training info is. After you start taking cases, you find that none of the shit you were promised exists anywhere, and all of a sudden, you have to support shit that is way outside of that arena because VMware/RP4VM/ESRS teams push shit back with incredible ease. Don’t even get me started on ‘case ownership’, because that term does not exist with L-EMC.

    That leaves the customer stuck with a TSE that genuinely wants to help, but has none of the required tools to actually fix anything.

    Moral of this story – before asking CUSTOMERS to be better customers, make yourself a better service company first.

Leave a Reply