SMS service raises an InvalidSession error

[sparrc]

I'm following the README defined here for the SMS service: https://github.com/Infinidat/infi.pyvmomi_wrapper/tree/develop/src/infi/pyvmomi_wrapper/sms

but I'm getting an InvalidSession error from the vCenter server (see ipython output below)

In [211]: from infi.pyvmomi_wrapper import Client

In [212]: from infi.pyvmomi_wrapper.sms import SmsClient

In [213]: # first open a "regular" client

In [214]: client = Client(server, username=username, password=password) INFO:urllib3.connectionpool:Starting new HTTPS connection (1): 172.26.75.48

In [215]: sms_client = SmsClient(client)

In [216]: storage_manager = sms_client.service_instance.QueryStorageManager()

sms.fault.InvalidSession Traceback (most recent call last)

in () ----> 1 storage_manager = sms_client.service_instance.QueryStorageManager() /usr/local/lib/python2.7/dist-packages/pyVmomi/VmomiSupport.pyc in (_args, *_kwargs) 564 # curried methods will receive 'self' _after_ any fixed arguments 565 return lambda _args, *_kwargs: \ --> 566 self.f(_(self.args + (obj,) + args), *_kwargs) 567 return self 568 /usr/local/lib/python2.7/dist-packages/pyVmomi/VmomiSupport.pyc in _InvokeMethod(info, self, _posargs, *_kwargs) 373 args[idx] = v 374 map(CheckField, info.params, args) --> 375 return self._stub.InvokeMethod(self, info, args) 376 _InvokeMethod = staticmethod(_InvokeMethod) 377 /usr/local/lib/python2.7/dist-packages/pyVmomi/SoapAdapter.pyc in InvokeMethod(self, mo, info, args, outerStub) 1299 return obj 1300 else: -> 1301 raise obj # pylint: disable-msg=E0702 1302 else: 1303 conn.close() sms.fault.InvalidSession: (sms.fault.InvalidSession) { dynamicType = , dynamicProperty = (vmodl.DynamicProperty) [], msg = '', faultCause = , faultMessage = (vmodl.LocalizableMessage) [], object = 'vim.ServiceInstance:ServiceInstance', privilegeId = 'StorageViews.View', sessionCookie = '' }

[wiggin15]

The latest version of pyvmomi (5.5.0.2014.1.1) still doesn't support our Sms Client - I'm waiting for them to pull https://github.com/vmware/pyvmomi/pull/165. If you want to use the sms client I'm afraid you'll have to use our fork of pyvmomi too in the meantime, which is ahead by a few commits. You can get it here: https://github.com/Infinidat/pyvmomi. I'm curious, though, because the traceback you should be getting is this:

     10         session_cookie = re.search('vmware_soap_session="(.*?)"', client.service_instance._stub.cookie).group(1)
     11         additional_headers = {'vcSessionCookie': session_cookie}
---> 12         stub = SoapStubAdapter(client.host, path="/sms/sdk", version="sms.version.version2", requestContext=additional_headers)
     13         self.service_instance = sms.ServiceInstance("ServiceInstance", stub)
     14

TypeError: __init__() got an unexpected keyword argument 'requestContext'

But you report a different problem... Which version of pyvmomi and pyvmomi_wrapper are you using?

[sparrc]

that makes sense, I actually removed the requestContext arg because I assumed that I was using a newer version of pyVmomi than was supported in the the SMS client.

I'll try out your fork, thanks for the guidance!

On Wed, Nov 12, 2014 at 2:50 AM, wiggin15 notifications@github.com wrote:

The latest version of pyvmomi (5.5.0.2014.1.1) still doesn't support our Sms Client - I'm waiting for them to pull vmware/pyvmomi#165 https://github.com/vmware/pyvmomi/pull/165. If you want to use the sms client I'm afraid you'll have to use our fork of pyvmomi too in the meantime, which is ahead by a few commits. You can get it here: https://github.com/Infinidat/pyvmomi. I'm curious, though, because the traceback you should be getting is this:

 10         session_cookie = re.search('vmware_soap_session="(.*?)"', client.service_instance._stub.cookie).group(1)
 11         additional_headers = {'vcSessionCookie': session_cookie}

---> 12 stub = SoapStubAdapter(client.host, path="/sms/sdk", version="sms.version.version2", requestContext=additional_headers) 13 self.service_instance = sms.ServiceInstance("ServiceInstance", stub) 14

TypeError: init() got an unexpected keyword argument 'requestContext'

But you report a different problem... Which version of pyvmomi and pyvmomi_wrapper are you using?

— Reply to this email directly or view it on GitHub https://github.com/Infinidat/infi.pyvmomi_wrapper/issues/1#issuecomment-62693718 .

[sparrc]

I also hadn't seen that pull request yet, I'm glad that someone else is having the same problems as me with the SMS service ^_^

Out of curiosity, how did you find out the information below, about the way that VMware SMS expects to receive their vcSessionCookie header? I've been banging my head against this for over a week now... VMware seems to have a very unique paradigm for authenticating their SMS sessions.

POST /sms/sdk HTTP/1.1 Host: host Content-Length: 542 SOAPAction: "urn:sms/4.0" Content-Type: text/xml; charset=UTF-8 Cookie: Accept-Encoding: gzip, deflate

<?xml version="1.0" encoding="UTF-8"?> <soapenv:Envelope xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <<<< soapenv:Header5219961a-a9b7-afc4-5884-4c1f56fb0b97/soapenv:Header

soapenv:Body<_this type="SmsServiceInstance">ServiceInstance/soapenv:Body /soapenv:Envelope

On Wed, Nov 12, 2014 at 10:59 AM, Cameron Sparr cameronsparr@gmail.com wrote:

that makes sense, I actually removed the requestContext arg because I assumed that I was using a newer version of pyVmomi than was supported in the the SMS client.

I'll try out your fork, thanks for the guidance!

On Wed, Nov 12, 2014 at 2:50 AM, wiggin15 notifications@github.com wrote:

The latest version of pyvmomi (5.5.0.2014.1.1) still doesn't support our Sms Client - I'm waiting for them to pull vmware/pyvmomi#165 https://github.com/vmware/pyvmomi/pull/165. If you want to use the sms client I'm afraid you'll have to use our fork of pyvmomi too in the meantime, which is ahead by a few commits. You can get it here: https://github.com/Infinidat/pyvmomi. I'm curious, though, because the traceback you should be getting is this:

 10         session_cookie = re.search('vmware_soap_session="(.*?)"', client.service_instance._stub.cookie).group(1)
 11         additional_headers = {'vcSessionCookie': session_cookie}

---> 12 stub = SoapStubAdapter(client.host, path="/sms/sdk", version="sms.version.version2", requestContext=additional_headers) 13 self.service_instance = sms.ServiceInstance("ServiceInstance", stub) 14

TypeError: init() got an unexpected keyword argument 'requestContext'

But you report a different problem... Which version of pyvmomi and pyvmomi_wrapper are you using?

— Reply to this email directly or view it on GitHub https://github.com/Infinidat/infi.pyvmomi_wrapper/issues/1#issuecomment-62693718 .

[sparrc]

ie, how did you turn on this log level? Is this something that can be done within pyVmomi or is this using something like wireshark?

On Wed, Nov 12, 2014 at 11:15 AM, Cameron Sparr cameronsparr@gmail.com wrote:

I also hadn't seen that pull request yet, I'm glad that someone else is having the same problems as me with the SMS service ^_^

Out of curiosity, how did you find out the information below, about the way that VMware SMS expects to receive their vcSessionCookie header? I've been banging my head against this for over a week now... VMware seems to have a very unique paradigm for authenticating their SMS sessions.

POST /sms/sdk HTTP/1.1 Host: host Content-Length: 542 SOAPAction: "urn:sms/4.0" Content-Type: text/xml; charset=UTF-8 Cookie: Accept-Encoding: gzip, deflate

<?xml version="1.0" encoding="UTF-8"?>

<<<< soapenv:Header5219961a-a9b7-afc4-5884-4c1f56fb0b97/soapenv:Header > > > > soapenv:Body<_this type="SmsServiceInstance">ServiceInstance/soapenv:Body > > > > /soapenv:Envelope On Wed, Nov 12, 2014 at 10:59 AM, Cameron Sparr cameronsparr@gmail.com wrote: > that makes sense, I actually removed the requestContext arg because I > assumed that I was using a _newer_ version of pyVmomi than was supported > in the the SMS client. > > I'll try out your fork, thanks for the guidance! > > On Wed, Nov 12, 2014 at 2:50 AM, wiggin15 notifications@github.com > wrote: > > > The latest version of pyvmomi (5.5.0.2014.1.1) still doesn't support our > > Sms Client - I'm waiting for them to pull vmware/pyvmomi#165 > > https://github.com/vmware/pyvmomi/pull/165. If you want to use the > > sms client I'm afraid you'll have to use our fork of pyvmomi too in the > > meantime, which is ahead by a few commits. You can get it here: > > https://github.com/Infinidat/pyvmomi. > > I'm curious, though, because the traceback you should be getting is this: > > > > ``` > > 10 session_cookie = re.search('vmware_soap_session="(.*?)"', client.service_instance._stub.cookie).group(1) > > 11 additional_headers = {'vcSessionCookie': session_cookie} > > ``` > > > > ---> 12 stub = SoapStubAdapter(client.host, path="/sms/sdk", version="sms.version.version2", requestContext=additional_headers) > > 13 self.service_instance = sms.ServiceInstance("ServiceInstance", stub) > > 14 > > > > TypeError: **init**() got an unexpected keyword argument 'requestContext' > > > > But you report a different problem... Which version of pyvmomi and > > pyvmomi_wrapper are you using? > > > > — > > Reply to this email directly or view it on GitHub > > https://github.com/Infinidat/infi.pyvmomi_wrapper/issues/1#issuecomment-62693718 > > .

[wiggin15]

I'm using a tool called DoubleCloud proxy, which is, well, a proxy (so you connect to it from pyvmomi_wrapper and it connects to the actual vcenter server) and it logs all the SOAP requests and responses (a little more like wireshark and less like logging). Here: http://www.doublecloud.org/doublecloud-proxy/ (you just download steveproxy.jar and run it)

[michaelrice]

Onyx also works when the double cloud misses things. For some reason I have had to use both in the past to find some of the hidden gems. https://labs.vmware.com/flings/onyx

[sparrc]

Thanks a bunch guys, this helped a lot, I've been trying to connect with the SMS service using psphere (https://github.com/jkinred/psphere) and this has finally showed me how I need to format the vcSessionCookie header (I also had the same experience of being told that passing the cookie is enough to authenticate with SMS, even though that's not the case)

We'll probably use psphere because it has a fairly easy way of adding new objects and functions for a beta version of vsphere we're working with. They are just python classes ( https://github.com/jkinred/psphere/blob/master/psphere/managedobjects.py) as opposed to pyVmomi, which uses that internally generated lazy Module stuff.

@wiggin15: how did you generate the SmsObjects.py file for the SMS service? was that provided to you from VMware? ( https://github.com/Infinidat/infi.pyvmomi_wrapper/blob/develop/src/infi/pyvmomi_wrapper/sms/SmsObjects.py )

On Wed, Nov 12, 2014 at 11:49 AM, Michael Rice notifications@github.com wrote:

Onyx also works when the double cloud misses things. For some reason I have had to use both in the past to find some of the hidden gems.

— Reply to this email directly or view it on GitHub https://github.com/Infinidat/infi.pyvmomi_wrapper/issues/1#issuecomment-62771232 .

[wiggin15]

The ESX server itself comes with an internal, proprietary (and a little bit older) implementation of pyvmomi, with only the pyc files available. We took the pyc files from the vmware product and decompiled it for the internal object definitions.

[sparrc]

Hi, I'm now trying to use your fork of pyvmomi, however, I get errors when trying to import 'vim' from pyVmomi:

In [5]: from pyVmomi import vim

ImportError Traceback (most recent call last)

in () ----> 1 from pyVmomi import vim ImportError: cannot import name vim When using the pip-installed version of pyVmomi available in pypi, this works: In [1]: from pyVmomi import vim In [2]: after installing pyVmomi using "python setup.py install" in the infinidat fork, I get an error.

[wiggin15]

I just tried this on a clean environment (using virtualenv) and the command and import work... The extra commits shouldn't cause a problem related to the imports so I can only assume it's a problem with paths or something else related to your environment. Can you please check the same steps in a new virtualenv environment?

[sparrc]

To close the loop on this, I was using a new version of ServerObjects.py that I pulled off of a beta ESX version (ESX 2015)

Apparently something has changed there that is not compatible with current revisions of pyvmomi. I didn't have time to track it all the way down, but I guess good to know that that's coming.