Home > vSphere API > VMware Open Sourced Python Binding for vSphere API: What Limit Does It Solve

VMware Open Sourced Python Binding for vSphere API: What Limit Does It Solve

December 24th, 2013 Leave a comment Go to comments

As reported in the community, there were quite excitement about the open source of the pyVmomi, the Python equivalent of vijava API. It was heatedly debated whether to open source the API even when I was working at VMware years ago. One camp of people thought it should be open sourced and even supported as Web Service SDKs; while the other group didn’t think it’s mature and would cause a lot of trouble in so doing. So it didn’t go anywhere in the past few years.

One month ago, I posted a blog on the pyVmomi. Not sure if it had helped VMware make up its mind to open source it. Anyway, it’s not important. The fact is it’s now open sourced.

Lost VMs or Containers? Too Many Consoles? Too Slow GUI? Time to learn how to "Google" and manage your VMware and clouds in a fast and secure HTML5 App.

While you can use the pyVmomi by reading my blog. There is however a key limitation there. The pyVmomi library coming with vSphere is compiled version (.pyc, .pyo) only. That limits you from using other versions of Python. It may sound a bit unbelievable for the programmers of Java, which guarantees version compatibility. If you write a library for Java 10+ years ago, you can still use it today with Java 1.7. It’s unfortunately not the case for Python. For the compiled library, it includes something called magic numbers which is different from version to version. If the magic number does not match with Python runtime, it gives you “ImportError: magic number doesn’t match.”

In ESXi 5.1, the pyVmomi was compiled with Python 2.6.7. In ESXi 5.5, the pyVmomi was compiled with Python 2.6.8. If you are using Python 2.7.x, or Python 3, you run out of luck. You have to roll back your Python version, which may or may not be possible. Even when it’s possible, the process may not be that smooth. Furthermore, the problem is not one time deal, but comes up again when VMware upgrades its Python version in its vSphere.

You may be wondering why not de-compile the .pyc back to .py source code and use the source with other versions of Python. I actually tried one time without luck. I think it’s so close but it would need quite some work to fix the de-compiled code therefore not worthwhile to go that direction, but instead tried out the pySphere which is less mature and less complete than pyVmomi, but works.

With the source code of pyVmomi, the version limit is solved nicely and almost permanently. Now you have the freedom to use whatever version of Python. Even you need a bit of tweak for the version variation of Python language, it’s just a syntax change which is not a big deal.

I wish VMware has open sourced it long time ago. With pyVmomi becomes feasible with open source, many users may consider to change code from pysphere to pyVmomi in the future. Feature wise, pySphere has better support on virtual machine related operations like guest OS operations. Hope these two projects can combine together some day.

Categories: vSphere API Tags: ,
  1. The Browser
    December 24th, 2013 at 04:29 | #1

    Spot on…keep up the good work; although we can work around it, not ideal situation….Come on VMware get your act together.

  1. No trackbacks yet.