Using VMware SDK Support

I predict this post will get a single hit over its lifetime, but if it helps at least one person desperately trying to find out how to open a VMware SDK support request, that’s good enough for me.

Quick Overview

Not everyone knows, but VMware, along with support for vSphere, NSX and all the other software products, also provides SDK and API support. If you are a partner developing a solution that integrates with a VMware product or even a customer writing your own vSphere plug-in using vSphere Management SDK, you can reach out to VMware for help.

It’s a paid service. You can find detailed description of it on its landing page here: VMware SDK and API Support

How to open SRs

One thing that is not very obvious about the SDK support is how to open support requests if you’re a customer. The goal of this short post is to demonstrate where to find it on VMware support portal:

1. Log in to My VMware portal using your account credentials
2. Under the Support section click Get Support
3. On the opened page, under “Technical” category, choose your issue type, such as “Fault/Crash”
4. In the provided list of Supported Products expand SDK Support Services
5. Select VMware SDK Support
6. Click Continue and proceed with describing your issue and opening the ticket, as usual

This is a screenshot of what it will look like, if your account has been entitled to SDK support:

If you’re working with SpringSource, there is also a range of support option under the SprinSource Open Source Support sub-category.

Conclusion

I’ve had only brief interaction with SDK Support team, but can only say good things about them. One of the examples was a question I had on parameter specifications of a particular vSphere Web Management SDK function and I not only got an answer to my question, but I was also provided with code snippets, which I didn’t even ask for. So if you are serious about using VMware SDKs and think you may require technical support, I can certainly recommend this service.

Advertisement

NetApp System Manager TLS Issue

Yesterday while working on one of the customers’ NetApp array I hit an issue which looked like an SSL misconfiguration at first.

I needed to run Network Configuration Checker to check for any inconsistencies between the active and persistent network configuration settings in the /etc/rc file. I used NetApp OnCommand System Manager 3.1.2 with Java 8. When I tried to run a network configuration check I got this error:

‘netapp.domain.local’ is not configured for secure management with TLS

When browsing to controllers management I also got this:

‘netapp.domain.local’ is not configured for secure management with TLS. Sensitive information you supply including passwords will be visible to other computers on the network.

Do you want to continue with non-secure connection ?

The second issue you can ignore by just skipping the warning, but the Network Configuration Checker error you can’t.

Potential Resolution

I googled it up and NetApp KB article 2021507 “OnCommand System Manager Java Compatibility issues” came up, which suggested that all you need to do is enable TLS on the 7-Mode controller (on Cluster Mode it is enabled by default):

options tls.enable on

This did not work for me, though.

Alternative Solution

The reason why System Manager no longer works with SSL and requires TLS instead, is because Java 7u75 (and later) implemented a change that disabled SSLv3 due to the POODLE security vulnerability.

So you either have to enable TLS for Java 7u75 and later (which didn’t work in my case) or downgrade to Java 7u72, which is the previous release from 7u75.

Once that done you should no longer get the error neither in Network Configuration Checker, nor when logging in to controllers in System Manager.

VNX Unisphere Java Issues

If you are a systems engineer, I’m sure you have to deal with Java compatibility issues all the time as I do. You install a certain Java version to fix one client and it immediately brakes another one.

I reached a new level of ridiculousness when I had a customer with two EMC storage arrays, VNX1 in production and VNX2 at DR. One Java version worked for Unsiphere client on VNX1, but broke VNX2 client and vice versa.

This was quite painful until I found a solution on EMC community forums. There is a Java version which works for both arrays and it’s Java 7u51. I have tested it on the following Block OEs and it works like a charm:

• VNX1 Block OE 05.32.000.5.209
• VNX2 Block OE 05.33.008.5.119

Let me know if this helped you as well.

Brocade Web Tools: Java Issues

This’s been discussed multiple times. I run into these issues all the time as well. The first issue is that Java won’t let Brocade Management GUI to run, because of the security key length. The error is: “Failed to validate certificate. The application will not be executed”. Solution is to change one line in “C:\Program Files (x86)\Java\jre7\lib\security\java.security” from:

jdk.certpath.disabledAlgorithms=MD2, RSA keySize < 1024

to

jdk.certpath.disabledAlgorithms=MD2, RSA keySize < 256

The second problem is not signed certificate. The error would read as follows: “Application Blocked by Java Security. Your security settings have blocked an application signed with an expired or not-yet-valid certificate from running”. To work around that lower the security from High to Medium in Java Control Panel on Securtiy tab.

An the third trouble is Java itself. Java 8 is not supported as of Feb 2015. I wasn’t able to get this working even with the link in the exception list on the latest Java release. So I had to downgrade to version 7. It might have changed by the time you’re reading it.

Scalasca and trace conversion tools

In my “UPC related” project I tightly worked with tool called Scalasca. I utilized Cube GUI (as well as APIs) from Scalasca and performed conversion from my own tracing format to Cube’s (or Scalasca’s) EPILOG format to be able to use Cube.

Scalasca has several tracing format conversion tools integrated into it, which are handy to allow analysis of EPILOG traces in other tools like Jumpshot, Vampir, Paraver and others. Here I’ll describe how to install Scalasca with converters support. I worked with Scalasca 1.3, so keep in mind that this blog entry can be rather outdated.

Basic Scalasca installation

I prefer to install Scalasca without Cube, and then install Cube separately. Because Scalasca usually includes outdated version of Cube.

# ./configure --prefix=/opt/scalasca-1.3 --disable-gui

You need to install binutils-devel, otherwise you won’t be able to compile and will get the following error:

cannot find -liberty

Cube installation

You need qt4 and qt4-devel RPMs for Cube installation. Then go with:

# PATH=$PATH:/usr/lib64/qt4/bin ./configure --prefix=~fred/cube-3.3
# make
# make install

Scalasca with OTF, SLOG2 and Paraver support

The most interesting part starts here. To make conversion functionality available in Scalasca you need to perform several additional steps. You don’t need to install extra packages to get Paraver support. Just get and install Paraver from the official site. You will also need to install wxWigets library (wxGTK for example), wxPropertyGrid and Boost.

OTF and VTF3 are formats of Vampir performance analysis instrument. VTF3 is predecessor of OTF and isn’t needed. You can get OTF at the official site.

To get SLOG2 support, download Oracle Java JDK and JRE from the Oracle site and install rpms. I also needed to uninstall Compat Java:

yum remove openoffice.org-core-2.3.0-6.5.el5.x86_64 \
tomcat5-servlet-2.4-api-5.5.23-0jpp.7.el5.x86_64 \
xml-commons-apis-1.3.02-0.b2.7jpp.10.x86_64 \
hsqldb-1.8.0.9-1jpp.2.x86_64 \
tomcat5-jsp-2.0-api-5.5.23-0jpp.7.el5.x86_64 \
gjdoc-0.7.7-12.el5.x86_64 antlr-2.7.6-4jpp.2.x86_64 \
xerces-j2-2.7.1-7jpp.2.x86_64 xalan-j2-2.7.0-6jpp.1.x86_64 \
bsf-2.3.0-11jpp.1.x86_64 bsh-1.3.0-9jpp.1.x86_64 \
xml-commons-resolver-1.1-1jpp.12.x86_64 java java-gcj-compat

After OTF and Java are installed invoke configure script with the following flags and install Scalasca:

# CFLAGS=”-I/usr/java/latest/include -I/usr/java/latest/include/linux” ./configure --prefix=/opt/scalasca-1.3 --with-otf=/opt/otf-1.7 --with-slog2=~/install/slog2sdk-1.2.6

As the last step go to SLOG2 sources and type:

# ./configure --prefix=/opt/slog2sdk-1.2.6 --with-java=/usr/java/latest --with-trace-libdir=`scalasca --config --prefix`/lib --with-trace-name=elg --disable-build CC=`scalasca --config --cc`
# make
# make install

Errors during installation

If you try to compile the code right away you can potentially get an error:

gcc -m64 -I. -I../../config -I../../utils -I../../episode -OpenMPnotAvailable -c epk_omplock.c
cc1: error: invalid option argument ‘-OpenMPnotAvailable’

To get rid of it go to scalasca-1.3.0/build-linux-gnu-nompi and change line 63 in Makefile.defs from

OMPFLAG    = -OpenMPnotAvailable

to

OMPFLAG    = -fopenmp

If you get an error:

gcc gen_slogconf.c -o gen_slogconf
gen_slogconf.c: In function ‘main’:
gen_slogconf.c:14: error: ‘__int64’ undeclared (first use in this function)
gen_
slogconf.c:14: error: (Each undeclared identifier is reported only once
gen_slogconf.c:14: error: for each function it appears in.)

then add the following two lines to gen_slogconf.c:

#include <sys/types.h>
#define __int64 int64_t

Another possible error, which I got, has the following output:

/usr/java/latest/include -I/usr/java/latest/include/linux ../../../utils/epk_archive.c -c -o so_epk_archive.o
gcc gen_slogconf.c -o gen_slogconf
./gen_slogconf > trace_impl.h
make[5]: *** [trace_impl.h] Error 25
make[5]: Leaving directory `/root/Install/scalasca-1.3.0/build-linux-gnu-nompi/build/epik/epilog/tools/elg2slog2′
make[4]: *** [all] Error 2
make[4]: Leaving directory `/root/Install/scalasca-1.3.0/build-linux-gnu-nompi/build/epik/epilog/tools’
make[3]: *** [all] Error 2
make[3]: Leaving directory `/root/Install/scalasca-1.3.0/build-linux-gnu-nompi/build/epik’
make[2]: *** [all-epik] Error 2
make[2]: Leaving directory `/root/Install/scalasca-1.3.0/build-linux-gnu-nompi/build’
make[1]: *** [all] Error 2
make[1]: Leaving directory `/root/Install/scalasca-1.3.0/build-linux-gnu-nompi’
make: *** [all] Error 2

Solution here is to substitute gen_slogconf.c from distribution with the following code:

#include <stdio.h>
#include <stdint.h>

int main() {
  printf("/* -- DO NOT CHANGE ---------------------------- */\n");
  printf("/* -- AUTOMATICALLY GENERATED BY gen_slogconf -- */\n\n");
  printf("#define HAVE_JNI_H 1\n");
  printf("#define STDC_HEADERS 1\n");
  printf("#define SIZEOF_INT %zd\n", sizeof(int));
  printf("#define SIZEOF_LONG %zd\n", sizeof(long));
  printf("#define SIZEOF_LONG_LONG %zd\n", sizeof(long long));
  printf("#define SIZEOF_VOID_P %zd\n", sizeof(void*));
  printf("#define SIZEOF___INT64 %zd\n", sizeof(int64_t));

  return 0;
}

After that just enter directory /root/Install/scalasca-1.3.0/build-linux-gnu-nompi/build/epik/epilog/tools/elg2slog2 and run make manually by yourself.

Usage examples

To convert EPILOG trace gathered by Scalasca to OTF use the following command:

# LD_LIBRARY_PATH=/opt/otf-1.7/lib elg2otf trace.elg

Convertion to Paraver format is done using elg2prv:

# elg2prv trace.elg

Then to view converted trace in Paraver GUI run:

# LD_LIBRARY_PATH=/opt/boost-1.43.0/lib:/opt/wxGTK-2.8.11/lib:/opt/wxpropgrid-1.4.12/lib:/opt/paraver-kernel-1.0/lib/paraver-kernel /opt/wxparaver-3.99/bin/wxparaver trace.elg

Out of memory issues in Openfire

We are constantly getting following errors in Openfire 3.6.4 installation:

java.lang.OutOfMemoryError: GC overhead limit exceeded

java.lang.OutOfMemoryError: Java heap space

It turns out that it’s a common error for 3.6.4.  Read this announcement Suffering from memory-related issues in Openfire? Read this! and this forum thread Openfire 3.6.4 memory leak with Empathy.

This error is related to memory leak in PEP which implements extended statuses. Since we don’t use them we just switched PEP off. Go to your Openfire admin console, select Server->Server Manager->System Properties at the bottom add property xmpp.pep.enabled value false. Restart server.

Update: this actually didn’t help us. Probably the only way is to upgrade to the latest stable version.