VMware Open Sourced Python Binding for vSphere API: What Limit Does It Solve
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.
Time to learn how to "Google" and manage your VMware and clouds in a fast and secureHTML5 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.