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.

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.

This entry was posted in vSphere API and tagged , . Bookmark the permalink. Post a comment or leave a trackback: Trackback URL.

One Comment

  1. The Browser
    Posted December 24, 2013 at 4:29 am | Permalink

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

Post a Comment

Your email is never published nor shared. Required fields are marked *

*
*

You may use these HTML tags and attributes <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

  • NEED HELP?


    My consulting helps clients with virtualization and cloud computing, including VMware infrastructure automation and orchestration, vSphere management APIs, and deep product integration with hypervisors. Current training offerings include vSphere APIs training, vCenter Orchestrator training, and etc. Should you, or someone you know, need these consulting services or training, please feel free to contact me: steve __AT__ doublecloud.org.

    Me: Steve Jin, VMware vExpert who authored the VMware VI and vSphere SDK by Prentice Hall, and created the de factor open source vSphere Java API while working at VMware engineering. Companies like Cisco, EMC, NetApp, HP, Dell, VMware, are among the users of the API and other tools I developed for their products, internal IT orchestration, and test automation.