search

vmware-archive / rbvmomi

Ruby interface to the VMware vSphere API.
MIT License
302 stars 174 forks source link

after update to 1.8.1: unknown VMODL type AnyType #31

Closed skywalk7 closed 10 years ago

skywalk7 commented 10 years ago

It happens while deserializing RetrieveProperties response

result =  connection.propertyCollector.RetrieveProperties(:specSet => [filter_spec]))
Response (in 0.006 s)
<?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:Body>
<RetrievePropertiesResponse xmlns="urn:vim25">
<returnval><obj type="Folder">group-d1</obj><propSet><name>name</name><val xsi:type="xsd:string">Datacenters</val></propSet></returnval>
<returnval><obj type="Folder">group-h4</obj><propSet><name>name</name><val xsi:type="xsd:string">host</val></propSet>
<propSet><name>parent</name><val type="Datacenter" xsi:type="ManagedObjectReference">datacenter-2</val></propSet></returnval>
<returnval><obj type="ClusterComputeResource">domain-c788</obj><propSet><name>name</name><val xsi:type="xsd:string">ZBX</val></propSet>
<propSet><name>parent</name><val type="Folder" xsi:type="ManagedObjectReference">group-h4</val></propSet></returnval>
<returnval><obj type="ClusterComputeResource">domain-c7</obj><propSet><name>name</name><val xsi:type="xsd:string">CL01</val></propSet>
<propSet><name>parent</name><val type="Folder" xsi:type="ManagedObjectReference">group-h4</val></propSet></returnval>
<returnval><obj type="Folder">group-h12429</obj><propSet><name>name</name><val xsi:type="xsd:string">test</val></propSet>
<propSet><name>parent</name><val type="Folder" xsi:type="ManagedObjectReference">group-h4</val></propSet></returnval></RetrievePropertiesResponse>
</soapenv:Body>
</soapenv:Envelope>

/usr/lib64/ruby/gems/1.8/gems/rbvmomi-1.8.1/lib/rbvmomi/type_loader.rb:103:in `make_type': unknown VMODL type AnyType (RuntimeError)
        from /usr/lib64/ruby/gems/1.8/gems/rbvmomi-1.8.1/lib/rbvmomi/type_loader.rb:65:in `get'
        from /usr/lib/ruby/1.8/monitor.rb:242:in `synchronize'
        from /usr/lib64/ruby/gems/1.8/gems/rbvmomi-1.8.1/lib/rbvmomi/type_loader.rb:63:in `get'
        from /usr/lib64/ruby/gems/1.8/gems/rbvmomi-1.8.1/lib/rbvmomi/deserialization.rb:78:in `deserialize'
        from /usr/lib64/ruby/gems/1.8/gems/rbvmomi-1.8.1/lib/rbvmomi/deserialization.rb:116:in `traverse_data'
        from /usr/lib64/ruby/gems/1.8/gems/rbvmomi-1.8.1/lib/rbvmomi/deserialization.rb:98:in `each'
        from /usr/lib64/ruby/gems/1.8/gems/rbvmomi-1.8.1/lib/rbvmomi/deserialization.rb:98:in `traverse_data'
        from /usr/lib64/ruby/gems/1.8/gems/rbvmomi-1.8.1/lib/rbvmomi/deserialization.rb:81:in `deserialize'
        from /usr/lib64/ruby/gems/1.8/gems/rbvmomi-1.8.1/lib/rbvmomi/deserialization.rb:111:in `traverse_data'
        from /usr/lib64/ruby/gems/1.8/gems/rbvmomi-1.8.1/lib/rbvmomi/deserialization.rb:98:in `each'
        from /usr/lib64/ruby/gems/1.8/gems/rbvmomi-1.8.1/lib/rbvmomi/deserialization.rb:98:in `traverse_data'
        from /usr/lib64/ruby/gems/1.8/gems/rbvmomi-1.8.1/lib/rbvmomi/deserialization.rb:81:in `deserialize'
        from /usr/lib64/ruby/gems/1.8/gems/rbvmomi-1.8.1/lib/rbvmomi/connection.rb:68:in `parse_response'
        from /usr/lib64/ruby/gems/1.8/gems/rbvmomi-1.8.1/lib/rbvmomi/connection.rb:68:in `map'
        from /usr/lib64/ruby/gems/1.8/gems/rbvmomi-1.8.1/lib/rbvmomi/connection.rb:68:in `parse_response'
        from /usr/lib64/ruby/gems/1.8/gems/rbvmomi-1.8.1/lib/rbvmomi/connection.rb:90:in `call'
        from /usr/lib64/ruby/gems/1.8/gems/rbvmomi-1.8.1/lib/rbvmomi/basic_types.rb:205:in `_call'
        from /usr/lib64/ruby/gems/1.8/gems/rbvmomi-1.8.1/lib/rbvmomi/basic_types.rb:74:in `RetrieveProperties'
        from ./rclib.rb:355:in `get_all_clusters'
        from ./aar.rb:135
cdickmann commented 10 years ago

Thanks for the report. Can you tell me what kind of object you are retrieving so I can more easily reproduce this?

jeremythehunt commented 10 years ago

I get the from OSX Mavericks or Ubuntu 12.04 connecting to vCenter 5.5 just doing an 'ls' in a vCenter object:

0 / 1 the-vcenter01/

cd 1 /the-vcenter01> ls RuntimeError: unknown VMODL type AnyType

If I downgrade to rbvmomi1.6.0 and rvc 1.7.0 everything works as expected.

skywalk7 commented 10 years ago

In this particular case I retrieve ClusterComputeResource objects, but faced same issue with virtual machine objects as well. Here is full code:

folder_traversal_spec = RbVmomi::VIM.TraversalSpec(
    :name => 'tsFolder',
    :type => 'Folder',
    :path => 'childEntity',
    :skip => false,
    :selectSet => [
      RbVmomi::VIM.SelectionSpec(:name => 'tsFolder'),
      RbVmomi::VIM.SelectionSpec(:name => 'tsDatacenterHostFolder'),
      RbVmomi::VIM.SelectionSpec(:name => 'tsClusterHost')
    ]
  )
  datacenter_cluster_traversal_spec = RbVmomi::VIM.TraversalSpec(
    :name => 'tsClusterHost',
    :type => 'ClusterComputeResource',
    :path => 'host',
    :skip => false,
    :selectSet => []
  )
  datacenter_folder_traversal_spec = RbVmomi::VIM.TraversalSpec(
    :name => 'tsDatacenterHostFolder',
    :type => 'Datacenter',
    :path => 'hostFolder',
    :skip => false,
    :selectSet => [
      RbVmomi::VIM.SelectionSpec(:name => 'tsFolder')
    ]
  )
  obj_spec = RbVmomi::VIM.ObjectSpec(
    :obj => connection.rootFolder,
    :skip => false,
    :selectSet =>
    [
      folder_traversal_spec,
      datacenter_folder_traversal_spec,
      datacenter_cluster_traversal_spec
    ]
  )

  property_specs = [
    { :type => 'Folder', :pathSet => ['name', 'parent'] },
    { :type => 'ClusterComputeResource', :pathSet => ['name', 'parent'] }
  ]

  filter_spec =  RbVmomi::VIM.PropertyFilterSpec(:propSet => property_specs, :objectSet => [obj_spec])

  result =  connection.propertyCollector.RetrieveProperties(:specSet => [filter_spec])
cdickmann commented 10 years ago

I tried your code and can't reproduce this. With 1.8 I switched the deserializer over to a new one, which existed for a long time but for some reason was never the default in external rbvmomi releases.

Could you open deserialize.rb and in line 45 at the beginning of deserialize() add: pp ["node", node] pp ["type", type]

Btw, are you both using ruby 1.8? I notice this "/usr/lib/ruby/1.8/monitor.rb" in the backtrace.

cdickmann commented 10 years ago

I tried out ruby 1.8.7 and still didn't hit this with your sample code.

erik-megarad commented 10 years ago

I'm also getting this same issue with 1.8.

/Users/epeterson/.gem/ruby/1.9.3/gems/rbvmomi-1.8.0/lib/rbvmomi/type_loader.rb:103:in `make_type': unknown VMODL type AnyType (RuntimeError)
    from /Users/epeterson/.gem/ruby/1.9.3/gems/rbvmomi-1.8.0/lib/rbvmomi/type_loader.rb:65:in `block in get'
    from /Users/epeterson/.rubies/ruby-1.9.3-p448/lib/ruby/1.9.1/monitor.rb:211:in `mon_synchronize'
    from /Users/epeterson/.gem/ruby/1.9.3/gems/rbvmomi-1.8.0/lib/rbvmomi/type_loader.rb:63:in `get'
    from /Users/epeterson/.gem/ruby/1.9.3/gems/rbvmomi-1.8.0/lib/rbvmomi/deserialization.rb:78:in `deserialize'
    from /Users/epeterson/.gem/ruby/1.9.3/gems/rbvmomi-1.8.0/lib/rbvmomi/deserialization.rb:116:in `block in traverse_data'
    from /Users/epeterson/.gem/ruby/1.9.3/gems/rbvmomi-1.8.0/lib/rbvmomi/deserialization.rb:98:in `each'
    from /Users/epeterson/.gem/ruby/1.9.3/gems/rbvmomi-1.8.0/lib/rbvmomi/deserialization.rb:98:in `traverse_data'
    from /Users/epeterson/.gem/ruby/1.9.3/gems/rbvmomi-1.8.0/lib/rbvmomi/deserialization.rb:81:in `deserialize'
    from /Users/epeterson/.gem/ruby/1.9.3/gems/rbvmomi-1.8.0/lib/rbvmomi/deserialization.rb:111:in `block in traverse_data'
    from /Users/epeterson/.gem/ruby/1.9.3/gems/rbvmomi-1.8.0/lib/rbvmomi/deserialization.rb:98:in `each'
    from /Users/epeterson/.gem/ruby/1.9.3/gems/rbvmomi-1.8.0/lib/rbvmomi/deserialization.rb:98:in `traverse_data'
    from /Users/epeterson/.gem/ruby/1.9.3/gems/rbvmomi-1.8.0/lib/rbvmomi/deserialization.rb:81:in `deserialize'
    from /Users/epeterson/.gem/ruby/1.9.3/gems/rbvmomi-1.8.0/lib/rbvmomi/connection.rb:68:in `block in parse_response'
    from /Users/epeterson/.gem/ruby/1.9.3/gems/rbvmomi-1.8.0/lib/rbvmomi/connection.rb:68:in `map'
    from /Users/epeterson/.gem/ruby/1.9.3/gems/rbvmomi-1.8.0/lib/rbvmomi/connection.rb:68:in `parse_response'
    from /Users/epeterson/.gem/ruby/1.9.3/gems/rbvmomi-1.8.0/lib/rbvmomi/connection.rb:90:in `call'
    from /Users/epeterson/.gem/ruby/1.9.3/gems/rbvmomi-1.8.0/lib/rbvmomi/basic_types.rb:205:in `_call'
    from /Users/epeterson/.gem/ruby/1.9.3/gems/rbvmomi-1.8.0/lib/rbvmomi/basic_types.rb:74:in `block (2 levels) in init'
    from /Users/epeterson/.gem/ruby/1.9.3/gems/rbvmomi-1.8.0/lib/rbvmomi/basic_types.rb:183:in `_get_property'
    from /Users/epeterson/.gem/ruby/1.9.3/gems/rbvmomi-1.8.0/lib/rbvmomi/basic_types.rb:35:in `block (2 levels) in init'
    from /Users/epeterson/.gem/ruby/1.9.3/gems/damballa-cavalry-1.1/lib/cavalry/vmware_box.rb:75:in `virtual_machines'
    from /Users/epeterson/.gem/ruby/1.9.3/gems/damballa-cavalry-1.1/lib/cavalry/vmware_box.rb:130:in `virtual_machine'
    from /Users/epeterson/.gem/ruby/1.9.3/gems/damballa-cavalry-1.1/lib/cavalry/vmware_box.rb:106:in `snapshots'
    from /Users/epeterson/.gem/ruby/1.9.3/gems/damballa-cavalry-1.1/lib/cavalry/vmware_box.rb:99:in `revert_to_snapshot'
    from /Users/epeterson/.gem/ruby/1.9.3/gems/damballa-cavalry-1.1/lib/cavalry/vmware_box.rb:93:in `destroy'
    from /Users/epeterson/.gem/ruby/1.9.3/gems/damballa-smokey-1.1.0/lib/tasks.rb:45:in `destroy'
    from /Users/epeterson/.gem/ruby/1.9.3/gems/damballa-smokey-1.1.0/lib/tasks.rb:31:in `smoketest'
    from /Users/epeterson/.gem/ruby/1.9.3/gems/thor-0.18.1/lib/thor/command.rb:27:in `run'
    from /Users/epeterson/.gem/ruby/1.9.3/gems/thor-0.18.1/lib/thor/invocation.rb:120:in `invoke_command'
    from /Users/epeterson/.gem/ruby/1.9.3/gems/thor-0.18.1/lib/thor.rb:363:in `dispatch'
    from /Users/epeterson/.gem/ruby/1.9.3/gems/thor-0.18.1/lib/thor/base.rb:439:in `start'
    from /Users/epeterson/.gem/ruby/1.9.3/gems/damballa-smokey-1.1.0/lib/tasks.rb:138:in `<top (required)>'
    from /Users/epeterson/.gem/ruby/1.9.3/gems/damballa-smokey-1.1.0/bin/smokey:3:in `require_relative'
    from /Users/epeterson/.gem/ruby/1.9.3/gems/damballa-smokey-1.1.0/bin/smokey:3:in `<top (required)>'
    from /Users/epeterson/.gem/ruby/1.9.3/bin/smokey:23:in `load'
    from /Users/epeterson/.gem/ruby/1.9.3/bin/smokey:23:in `<main>'

The call that enters rbvmomi is vim.serviceInstance.content.rootFolder where vim is a RbVmomi::VIM object

cdickmann commented 10 years ago

Could you open deserialize.rb and in line 45 at the beginning of deserialize() add: pp ["node", node] pp ["type", type]

I have spent multiple hours trying to reproduce this and can't. I don't know whats different about my environment.

cdickmann commented 10 years ago

Can you paste the entire output, including the error? Maybe use pastebin :)

erik-megarad commented 10 years ago

I rescued the error in deserialization.rb and opened up a pry session: https://gist.github.com/subwindow/8100461

Let me know if you want to dig around in anything else.

skywalk7 commented 10 years ago

Thanks for digging into. Yes, I use ruby 1.8. Nokogiri is 1.5.11. Here is output with modified deserialize: http://pastebin.com/8stStppL

cdickmann commented 10 years ago

I looked at the output from subwindow:

Weird!

The method starts with: type_attr = node['type'] type = type_attr if type_attr

So based on the output, I would have expected node['type'] to be set to "ServiceContent". But instead, it appears to be nil, so anyType is not overwritten with anything and hence the issue later down in the method. Can you confirm that?

erik-megarad commented 10 years ago

Yes, node['type'] is nil.

cdickmann commented 10 years ago

Whats your nokogiri version? Mine is: nokogiri (1.5.5, 1.5.2)

erik-megarad commented 10 years ago

1.6.1, which is the latest.

cdickmann commented 10 years ago

We found it! Nokogiri 1.6.1 broke it! I just upgraded to it and now I am able to reproduce. Thanks for the help. Now I am sure I will be able to fix it.

odeits-vidder commented 10 years ago

nokogiri 1.5.10 has the same issue

skywalk7 commented 10 years ago

Nokogori > 1.5.5 breaks rbvmomi 1.8.1 Thanks for all the help, guys!

erik-megarad commented 10 years ago

Is there going to be a code fix? At the very least a temporary change should be made to the gem specification mandate a compatible version of nokogiri.

tim95030 commented 10 years ago

Is there a reason this is closed? This issue is still happening and is currently a major pain.

erik-megarad commented 10 years ago

You can work around it by specifying a compatible version of nokogiri in your Gemfile. There really needs to be a code fix in rbvmomi though.

domcleal commented 10 years ago

Could this issue be re-opened at least please?

mkuzmin commented 10 years ago

Nokogori 1.5.5 is not compatible with Ruby 2.0, so the workaround is not acceptable. Can you suggest any other solutions?

bwallis42 commented 10 years ago

I'm having the same problem and cannot find a way around it. rbvmomi is used by a vagrant plugin vagrant-vsphere (https://github.com/nsidc/vagrant-vsphere) and this plugin requires nokogiri 1.5.10 (doco says it forces use of 1.5.10). Vagrant uses Ruby 2.0.

I'm surprised this is closed without a workable solution. Any suggestions of how to work around this would be welcome. thanks

jeremythehunt commented 10 years ago

I installed Nokogori 1.5.1 and removed all other versions. Then uninstalled and re-installed rbvmomi and the error goes away.

dekz commented 10 years ago

@bwallis42 @jeremythehunt @mkuzmin Can you guys try out https://github.com/vmware/rbvmomi/pull/32

bwallis42 commented 10 years ago

That did the trick for me. I made the modification to deserialization.rb in my installed gem (in vagrant's gem directory) and now the vagrant-vsphere plugin is working.

Thanks very much for that! regards.

dekz commented 10 years ago

No worries mate, let me know if you run into any troubles, possibly over at https://github.com/dekz/rbvmomi

aramprice commented 10 years ago

Is there any chance that this will be fixed, rather than just pinning to an old version?

domcleal commented 10 years ago

@aramprice I think #32 resolves this issue, though there's no release yet.

aramprice commented 10 years ago

@domcleal - great news, thanks!