DoubleCloud Proxy
Welcome to Code Generator for vSphere Java API, as known as DoubleCloud Proxy.
Download and Setup
The code generator is a single executable Java jar file. You can simple download the jar file here to your local computer. If you already have Java Runtime (JRE) 1.6 or higher installed, all you need to do is to double click on the executable file steveproxy.jar.
If you are new to Java, you want to check out the download page of JRE (http://www.java.com/en/download/index.jsp) and install JRE onto your computer first. The installation should be straight-forward. If you need help on installing Java, just check out the links on the page.
Getting Started
After you starting the application, you should see the following GUI.
To start proxy, you click on the File-New… menu item. A dialog box will show up as follows:
You want to change the IP address to your vCenter or ESXi address. You can leave the port mapping as it is unless you find a port conflict. After clicking OK button, the proxy will start.
Now start the vSphere Client. In the following dialog box, enter IP as shown in follows, and then username and password. Please don’t use doublecloud username unless you do have such a username.
After that, the vSphere Client will work as if you were connecting to a real vCenter server. You will see messages being added to the table while vSphere Client getting started.
You can drive the vSphere Client for more messages. At the same time, you can select one or many request messages to generate Java code. You can also check out other tabs for SOAP XML or even raw HTTP messages. With the generated code, you can run as other VI Java Applications. Check out the 5 minutes Getting Started Tutorial.
Along the way, you can save the messages to a local file for any number of times you want. You can read them back later on.
But once you open a previously recorded message file, the proxy is going to stop. So the software will warn you whether you want to move forward.
Well, I guess that is pretty much all about this tool: powerful yet simple to use. Please come back for more updates and releases.





Great work. Is it also able to generate Java code using the official vSphere SDK for Java?
Thanks Guido,
The generated code conforms to the offical vSphere API spec. No plan to support the official SDK. Why do you not want this de facto API?
Steve
Amazing work Steve !
I’m so thrilled to try this out
When I trying to connect to a server, it return a “Bad request” error. What’s the problem?
That’s Excellent Work!!!Amazing
Can you provide more detail on the “Bad request” error?
@Steve Jin
********http://www.doublecloud.org********
GET /client/clients.xml HTTP/1.1
User-Agent: VMware VI Client/4.0.0
Host: fish-tp:1545
Connection: Keep-Alive
********http://www.doublecloud.org********
HTTP/1.1 200 OK
Date: Tue, 31 Jan 2012 05:32:12 GMT
Connection: Keep-Alive
Content-Type: text/xml
Content-Length: 255
4.1.02.0.044.1https://*:443/client/VMware-viclient.exe
********http://www.doublecloud.org********
POST /sdk HTTP/1.1
User-Agent: VMware VI Client/4.0.0
Content-Type: text/xml; charset=”utf-8″
SOAPAction: “urn:internalvim25/4.1″
Host: fish-tp:1545
Content-Length: 502
Connection: Keep-Alive
???
55A77464-00000001
ServiceInstance
********http://www.doublecloud.org********
HTTP/1.1 400 Bad Request
Date: Tue, 31 Jan 2012 05:32:13 GMT
Set-Cookie: vmware_soap_session=”257CA3AB-62D0-4BEE-BD69-30F1C3B850CC”; Path=/;
Cache-Control: no-cache
Connection: close
Content-Type: text; charset=plain
Content-Length: 0
@Steve Jin
Call “ServiceInstance.RetrieveContent” for object “ServiceInstance” on Server “xxxx” failed.
@Steve Jin
I think there is a risk using vijava, because there is only one active developer in the project (you) and it is not officially supported by vmware. My fear is someone using your vijava API (much cleaner and faster than the official one) and one day vmware decides to release a new vsphere 6 and a new version of their vsphere SDK for Java. I know it is opensource, but…
@yzj
The messages before Bad Request seem fine to me. Does it work while connecting to the vCenter directly? The reversed proxy just pass messages back and forth. It shouldn’t cause the Bad Request by itself.
@Guido
Thanks for sharing your concern. I think you are neither only nor the first one who has this concern. Many companies that use vijava API in their products had thought about it and made decisions to use it anyway. One of them told me, “we decided to go with vijava because this layer of abstraction is needed, and even it’s no longer maintained it at least gives us a better starting point than otherwise.” Enough being said, you got to make your own call on this because every case is different.
Steve
@Steve Jin
I can connect to vmware server directly. It also works when I connect through onyx. But the diference if the communication between client and onyx is not encrypted.
Out of box, neither vCenter nor ESXi supports HTTP. Did you change the configuration? The DoubleCloud proxy does not support HTTP today.
Steve
@Steve Jin
I mean that the communication between vi client and onyx proxy is unencrypted, the proxy connect to server by https
Great work. But I have encountered the same error like yzj.
What exact version of your vCenter server? Also, is it a localized version?
Steve
Hi Steve. A little off-topic, but do you have any code you can share for pass-through authentication with SSPI (Kerberos preferred)? I am trying to move to using pass-through authentication via the legacy web service, but I think I’ll need to abandon that since it breaks from the root ServiceInstance top-level class, making me unable to leverage the VI Java SDK and looks like I’d only be able to run this from a Windows client to use Win32 JNA calls barring installing Wine.
Hi John, I don’t have the code you wanted. But you can check Andrew Kutz’s blog and open source code (the .Net binding in particular).
Steve
@Steve Jin
Thanks Steve, I saw that but I’ll pass. I’m too committed to the Java SDK.
Hi, Steve, Thanks a lot for your great job, it’s really useful. But now I encounter a problem:
When I using the DoubleClound Proxy to connect my vCenter (vsphere 5.0) , this tool cannot success with these following errors:
ClientFaultCode
Error returned by expat parser: not well-formed (invalid token)
while parsing HTTP request before method was determined
at line 1, column 0
can you help me? thanks.
I cant wait to check this, however, the link the jar is not working. Any tips on getting a hold of it?
I just tried the link and it worked fine. Here is the explicit link: http://vijava.sf.net/download/doublecloudproxy/steveproxy.jar. Good luck.
Steve
@Daniel
Hi,I encountered the same problem, you find a solution?
Thanks for providing such a great tool!
Unfortunately, I’m not able to connect to a vCenter 5.0 installation after trying various combinations of settings, turning off firewalls, etc.
The message I get from the vSphere Client is: ‘vsphere Client could not connect to “196.168.1.101″. An unknown connection error occured. (The request failed because the remote server took too long to respond. (The operation has timed out))’
Is DoubleCloud Proxy compatible with 5.0? Thanks!
The DoubleCloud Proxy does not care about the version of vCenter/vSphere, and it should work with 5.0. Do you run it on the same machine as your vCenter?
Steve
@Steve Jin
Hi Steve,
Thanks for your quick response!
The setup is two different systems. vCenter is running on a production server and vSphere Client is on a laptop. Connecting to vCenter directly with the Client works fine (and has for a long time) from the laptop. I’m pretty confident I set up the Proxy correctly as you know, it’s pretty simple. For the heck of it I turned off the laptop’s firewall. If you have any suggestions of ways to debug this, it would be most appreciated!
Many Thanks,
Jim…
Hi,
Can’t connect to vCenter.
In DoubleCloud Proxy I get:
POST /sdk HTTP/1.1
User-Agent: VMware VI Client/4.0.0
Content-Type: text/xml; charset=”utf-8″
SOAPAction: “urn:internalvim25/5.0″
Host: vc.ts.telekom.si:1545
Content-Length: 502
Connection: Keep-Alive

1CA10DC3-00000001
ServiceInstance
++++++++++++++++++++++++++++++++++++++++++++
and response:
HTTP/1.1 500 Internal Server Error
Date: Fri, 15 Jun 2012 14:22:39 GMT
Set-Cookie: vmware_soap_session=”52ccee65-9f31-e314-3c4a-742f95542b83″; Path=/; HttpOnly;
Cache-Control: no-cache
Connection: Keep-Alive
Content-Type: text/xml; charset=utf-8
Content-Length: 571
ClientFaultCode
Error returned by expat parser: not well-formed (invalid token)
while parsing HTTP request before method was determined
at line 1, column 0
Notice 3 bytes brefore <soap…
vSphere Server version is 5.0.0
Please help. Thx.
It seems like your vSphere Client is 4.0.0, which does not match the server 5.0.0. You may want to upgrade your client to match the server. The proxy is simply a middleman, passing messages back and forth.
Steve
@Steve Jin
Checked and both are version 5.0. Connecting directly works just fine, but via proxy I get the error.
Did you get exactly the same error as you posted before or something slightly different? Please post the messages.
Steve
Hi
This is the error message:
“Error returned by expat parser: not well-formated (invalid token)
while parsing HTTP request before method was determined
at line 1, column 0″
And this is log saved with DoubleCloud Proxy:
“********http://www.doublecloud.org********
GET /client/clients.xml HTTP/1.1
User-Agent: VMware VI Client/4.0.0
Host: dezurni:1545
Connection: Keep-Alive
********http://www.doublecloud.org********
HTTP/1.1 200 OK
Date: Tue, 19 Jun 2012 11:18:15 GMT
Connection: Keep-Alive
Content-Type: text/xml
Content-Length: 299
5.0.05.0.01.0.055.0https://*:443/client/VMware-viclient.exe
********http://www.doublecloud.org********
POST /sdk HTTP/1.1
User-Agent: VMware VI Client/4.0.0
Content-Type: text/xml; charset=”utf-8″
SOAPAction: “urn:internalvim25/5.0″
Host: dezurni:1545
Content-Length: 502
Connection: Keep-Alive
?»?
1479B859-00000001
ServiceInstance
********http://www.doublecloud.org********
HTTP/1.1 500 Internal Server Error
Date: Tue, 19 Jun 2012 11:18:19 GMT
Set-Cookie: vmware_soap_session=”52f41bc5-ea9f-59e2-3b0d-1bb20b46f3ac”; Path=/; HttpOnly;
Cache-Control: no-cache
Connection: Keep-Alive
Content-Type: text/xml; charset=utf-8
Content-Length: 571
ClientFaultCode
Error returned by expat parser: not well-formed (invalid token)
while parsing HTTP request before method was determined
at line 1, column 0
”
Thx for help.
@JimGee
Tried a closer 5.0 geographical system and it worked fine. Thinking distance from USA to Middle East is tickling errors.
@Steve Jin
My answer #31
I tested on 3 different VC installations. Always the same error.
@Janez
The fix for me was to uninstall JRE 1.7 and reinstall 1.6 on the machine the proxy is running on.
@Evgeni
my java version is:
Java(TM) SE Runtime Environment (build 1.6.0_20-b02)
This is funny. I tried with and without Windows credentials. No difference. Even when I type wrong password I get the same error.
Awesome! Thanks Steve
Can’t wait for the Perl part to be added. Keep up the good work.
Thanks Boraq, great to know you like it. -Steve
Hey, when I try this it always times out.
Error : “vSphere Client could not connect
@Ariel
Nevermind. It works, thanks!
I am working on an application which talks to Vsphere using vijava library.
This tool has made my life so easy. Thank you so much for this tool Steve !!!
I had run your program (steveproxy.jar) on a machine installed 64-bit Win7, but it seems not working. I have no idea what was going wrong.
Whenever I used vSphere Client to connect to my host (Datacenter), no codes are generated by your program. My vSphere Client and vCenter Server are both version 5.0. JRE 1.6 and 1.7 had been tried. I obtained no errors or warnings during the whole process, just no codes are generated. Please advise. Thanks.
Hi,
We want to register a Storage Vendor Provider through the API, but we can’t find any documentation about it.
While we’re looking up the appropriate channels to ask VMware, we’d though to use this proxy to intercept the calls the vCenter client uses to register such provider, but we don’t see these calls in the proxy.
However, when we capture the TCP packets, we see some communication on port 8443, but we just don’t see in your proxy.
Is there a debug mode for the proxy that dumps everything that it fails to parse into a file? or does someone has another idea/clue that could help us out?
Thanks in advance,
Guy
Never mind, we figured it out — we took the SSL key from the vCenter server, set in it wireshark, and voila
Cool. Thanks for the update. What did you find out?
Steve
Hi Steve,
Thanks for this great tool!
Unfortunately, it is not working for me. After entering the vCenter IP, clicking OK and connecting to vCenter via vSphere Client, nothing happens. No Errors, No Logs, nothing
My machine is Windows 7 64bit, vCenter & Client version 5.1.
Can you please help?
thanks!
Hi Frodo, I developed the proxy on Win7 64bit so the OS should be fine. Have you checked JRE version, network delay as reported by others above? Frankly I should have done a better job in reporting errors, had I had more time.
Steve