Calling the below code multiple times in a row causes an exception. Can anyone verify this?
Private Sub TestConnect() Dim _host As New VMWareVirtualHost _host.ConnectToVMWareVIServer(New Uri("https://172.16.2.5:8333/sdk", "user", "pass", 30) _host.Disconnect() _host = Nothing End Sub
Tested against vmware Server 2 // version=2.0.0, build=build-122956 using VMwareTasks 1.3 over VIX 1.7
I tested against 4 different Server 2.0.0 hosts with similar results.
We recently found and fixed a bug here. What triggers it is doing the Connect/Disconnect very quickly, so that the Disconnect is started while we're still getting data from the server. There was some bad code dealing with throwing the late responses away. It shouldn't matter if the server is Server 2.0 or an ESX flavor. But its very dependent on timing, so its quite possible that you see it on Server 2.0 because that system is slower than your ESX boxes (esp since Server 2.0 has to share.)
If your problem vanishes with a short sleep between, then its probably the same bug.
Same result w/o vmwaretasks lib:
Dim m_lib As New VixLib Dim m_hostJob As VixCOM.IJob = Nothing m_hostJob = m_lib.Connect( _ VixCOM.Constants.VIX_API_VERSION, _ VixCOM.Constants.VIX_SERVICEPROVIDER_VMWARE_VI_SERVER, _ New System.Uri(txtconnString.Text).ToString(), _ 0, _ txtUser.Text, _ txtPass.Text, _ 0, _ Nothing, _ Nothing) Dim m_propertyIds() As Integer = {VixCOM.Constants.VIX_PROPERTY_JOB_RESULT_HANDLE} Dim m_results() As Object = Nothing Dim m_vixError As ULong m_vixError = m_hostJob.Wait(m_propertyIds, m_results) Dim m_hostHandle As VixCOM.IHost = Nothing If m_vixError = VixCOM.Constants.VIX_OK Then m_hostHandle = CType(m_results(0), VixCOM.IHost) End If If m_lib.ErrorIndicatesFailure(m_vixError) Then Console.WriteLine("ERR: Failed to Connect to Host: " & m_lib.GetErrorText(m_vixError, Nothing)) Else m_hostHandle.Disconnect()
I'm forced to go back to 1.6 to work with Server2!
We recently found and fixed a bug here. What triggers it is doing the Connect/Disconnect very quickly, so that the Disconnect is started while we're still getting data from the server. There was some bad code dealing with throwing the late responses away. It shouldn't matter if the server is Server 2.0 or an ESX flavor. But its very dependent on timing, so its quite possible that you see it on Server 2.0 because that system is slower than your ESX boxes (esp since Server 2.0 has to share.)
If your problem vanishes with a short sleep between, then its probably the same bug.
Excellent, is an interim release available for testing?