peter_rudolf
Contributor
Contributor

synctime is absolutly different from 2.x SDK to 2.5 SDK. impossible to write an applikation for both version

Jump to solution

Hi all,

I try to build a applikation to set Synctime with Host in SDK 2.1

in 2.1 you must set extraconfig in Virtualmachineconfiginfo "tools.synctime=TRUE" and than make a vmreconfig task

in 2.5 the variable are not written. I check that you must go to Toolsconfiginfo and set synctimewithhost=true

but in 2.1 the toolsconfiginfo have no " synctimewithost" variable.

SO IT IS NOT POSSIBLE to Write a applikation that work in both esx/VC-version 3.x and 3.5 (vc2.1 and 2.5) were i can set the guest synctime.....

I can believe that vmware make it impossible?

Any ideas ?

Peter

0 Kudos
1 Solution

Accepted Solutions
jrackliffe
Hot Shot
Hot Shot

Ok,

I think that I follow what you were saying, but I could be missing it. And since I haven't used this function I can't validate the issue.

As I understand it using the API 2.01 namespace via VC 2.01 (vim/vim.wsdl) the syncflag will change using a defined function on ESX 2.5 and ESX 3.0.

When you try an use the same function via VC 2.5 using the 2.01 compatibility namespace (vim\vim.wsdl not vim25\vim.wsdl) the syncflag is not working on ESX 3.0 and 3.5.

So basically what you are saying is there is a bug in the 2.01 compatibility namespace delivered w VC 2.5 that when you use the syncflag method it does not work?

If so you may want to contact support and they may be able to assist.

To your final comment, you should be able to use SDK 2.01 methods to interact with VC 2.5 and managed ESX hosts 2.5,3.0,3.5 via the compatibility namespace offered at vim/vim.wsdl. Now you won't be able to use the 2.5 specific object like FileManager that are only available in the 2.5 namespace (vim25\vim.wsdl), but accoring to your note that is not an issue. And since the WSDL is equivalent between the VC 2.01 and VC 2.5 compat namespace any application consuming those SOAP interfaces should have interop between speaking to a VC 2.01 and a VC 2.5.

View solution in original post

0 Kudos
11 Replies
Virtualiser
Contributor
Contributor

That sounds bad....

As far as I can tell you are supposed to be able to run an application written with the 2.0.1 SDK against ESX3.5/VC2.5

You cant however recompile 2.0.1 SDK code against 2.5 SDK as there have been changes... so as long as stick with 2.0.1 SDK should work against 3.5/2.5. If not then VMware has got some work to do!!! If we switch to 3.5/2.5 I will be fairly p****d off if my app doesnt work any more.

0 Kudos
tos2k
Expert
Expert

Hi!

Applications based on VimSdk 2.0 (for VC 2.0) should be compatible (with a few exceptions) to VC 2.5 too. Applications based on VimSdk 2.5 (for VC 2.5) are compatible with VC 2.5 only.

What error comes up when you run the 2.0 compatible app on a 3.5 ESX / VC 2.5?

Tos2k

0 Kudos
peter_rudolf
Contributor
Contributor

the problem is follow:

in 2.1 SDK you must use the extra.config option to set the tool.sync=true if you want the VM syncronized with the host.

in 2.5 sdk it do not function. He make the vmreconfigure task with complete (no error, but he ignore my option in sdk 2.5) . So i search in the sdk how i can change the syncstatus of a vm in the new sdk

in the new sdk it is a new proberty in guest-container, bit this proberty is not availbly in the sdk2.5.

so both sdk are NOT copertible

Peter

0 Kudos
jrackliffe
Hot Shot
Hot Shot

Peter,

What folks are trying to say is applications targeting the 2.0 namespace will work in VC 2.5 regardless of the changes to the 2.5 namespace.

So if you require an app to interop between 2.0 and 2.5 use the 2.0 namespace for your development. This means you won't have any nifty 2.5 features available to you, but you will have interop between both versions. Its the lowest common denominator solution.

As you discovered if you target an application at the 2.5 namespace those applications will not work against a 2.0 VC because of subtle and not so subtle changes in the object model and framework. Basically use the WSDL located at the root of vim for both 2.0 and 2.5 VCs. The 25 namespace is available via the WSDL at the vim25 subdir.

Hope that helps you work through the new release. J

0 Kudos
peter_rudolf
Contributor
Contributor

Hi all,

I am not sure if you understand me.

I mean, i have a functioncall so change the synctime in SDK2.1 and it do it on esxserver 3.0x and vc 2.1 in the right way.

The same functioncall do not change the syncflag in esx 2.5 and vc 2.5 with the sdk 2.1

Because VMware changed the way to change the synctime Methode from extraconfig to guest.info with a proberty thaat i not have in sdk 2.1.

so my understanding is that it is not possible to write a application with sdk2.1 that support (standard api not enhanced 2.5 api) esx 3.0x and 3.5 ....

Can you unterstand me ?

regards

Peter

0 Kudos
jrackliffe
Hot Shot
Hot Shot

Ok,

I think that I follow what you were saying, but I could be missing it. And since I haven't used this function I can't validate the issue.

As I understand it using the API 2.01 namespace via VC 2.01 (vim/vim.wsdl) the syncflag will change using a defined function on ESX 2.5 and ESX 3.0.

When you try an use the same function via VC 2.5 using the 2.01 compatibility namespace (vim\vim.wsdl not vim25\vim.wsdl) the syncflag is not working on ESX 3.0 and 3.5.

So basically what you are saying is there is a bug in the 2.01 compatibility namespace delivered w VC 2.5 that when you use the syncflag method it does not work?

If so you may want to contact support and they may be able to assist.

To your final comment, you should be able to use SDK 2.01 methods to interact with VC 2.5 and managed ESX hosts 2.5,3.0,3.5 via the compatibility namespace offered at vim/vim.wsdl. Now you won't be able to use the 2.5 specific object like FileManager that are only available in the 2.5 namespace (vim25\vim.wsdl), but accoring to your note that is not an issue. And since the WSDL is equivalent between the VC 2.01 and VC 2.5 compat namespace any application consuming those SOAP interfaces should have interop between speaking to a VC 2.01 and a VC 2.5.

View solution in original post

0 Kudos
peter_rudolf
Contributor
Contributor

hi jrackliffe,

You are understood right.

I think it is a bug and i must open a call

thx

Peter

0 Kudos
scorpio843110
Contributor
Contributor

demo reply...

0 Kudos
peter_rudolf
Contributor
Contributor

Try this in SDK 2.1 it is running , the same code under sdk 2.5 is running too, but the Extraconfig is not set (vc 2.5 ignore the settings

Dim vmspec As VirtualMachineConfigSpec = New VirtualMachineConfigSpec

Dim vmconfiginfo As VirtualMachineConfigInfo = Client.GetObjectProperty(vmRef, "config")

Dim vmconfiginfo_neu As VirtualMachineConfigInfo = New VirtualMachineConfigInfo

Dim newtoolconfiginfo As ToolsConfigInfo = New ToolsConfigInfo

Dim newOption(0) As OptionValue

newOption(0) = New OptionValue()

newOption(0).key = "tools.syncTime"

newOption(0).value = Sync.ToString

vmspec.extraConfig = newOption

TaskRef = Client.ReConfig_VM(vmRef, vmspec)

Under Sdk 2.5 you need to do following:

newtoolconfiginfo.syncTimeWithHost = Sync

newtoolconfiginfo.syncTimeWithHostSpecified = True

vmspec.tools = newtoolconfiginfo

TaskRef = Client.ReConfig_VM(vmRef, vmspec)

regards

Peter

0 Kudos
jrackliffe
Hot Shot
Hot Shot

Hey Peter don't have a VC 2.5 to go against so I can't really test the code, but I would definately get an incident opened and maybe one the engineers can give some insight into the code and if there is a way to force the synTimeWithHost using the 2.01 namespace for 2.5 managed guests. Unless anyone from VMware has some insight I am guessing the thread is dead.

0 Kudos
Steve_Jin
Expert
Expert

Hi Folks,

The new VI Java API 2.0 handles different namespaces with the same set of API. If you know your target is 2.0, then you just start like this:

ServiceInstance si = *new* ServiceInstance(*new* URL(), "user", "password", *true, ServiceInstance.**VIM_NAMESPACE);*

Folder rootFolder = si.getRootFolder();

For the 2.5 target, you can just do the same using *VIM25_NAMESPACE,* or simple ignore this parameter as:

ServiceInstance si = *new* ServiceInstance(*new* URL(), "user", "password", *true);*

*Note: when you use older namespace, you have to watch out -- not to pass in new parameters/properties in the new version. The API does NOT check it for you.*

Give it a try and you will be surprised by the fast speed and small size. Download it here!

Steve JIN, VMware Engineering

Creator of VMware Infrastructure Java API. VI Java API 2.0 --- 15 times faster than AXIS in loading, 4+ faster in deserialization; only 1/4 of the size required by AXIS. More importantly, the freedom to redistribute your applications. (Download, Samples, DocWiki, RSS Feed)

Get Connected with Other Developers in the Community?

Steve JIN Author of VMware VI and vSphere SDK; Creator of open source VI Java API (http://vijava.sf.net); Blogger at http://www.doublecloud.org
0 Kudos