Vmotion and time synchronization

[christianZ]

Hi Guys,

we have here two vms (windows 2003) with time going a few minutes backward (it is needed there; the vmware tools time sync. is not activated; Esx hosts are synchronized per ntp).

Unfortunately after vmotion the time in vms will be synchronized with Esx(shutdown and restart didn't do it) - what is bad in this case.

Have we any chance to interrupt it?

Any hints?

Thanks.

[larstr]

You need virtual machines that have their clock 5 minutes behind the real clock?

That's what I call a strange requirement...

Lars

[masaki]

1) Look into the VMWare tools properties for a valid option.

Under vm's options tab there are several flags to run Vmware tools in different situations. Try unflagging.

2) Uninstall VMWare Tools

2) Define a post vmotion script to change time back.

[christianZ]

Yes. These are rsa/tokens authentications servers.

[oreeh]

Tokens using a time synchronous protocol for authentication...

You really should switch to another product

Getting serious again:

There are probably undocumented VMX parameters to do this too but a script - as Andrea already mentioned - is the easiest way to do this.

[christianZ]

Next year we do it. Therefore for now we don't want to make a new synchronisation from ca. 200 tokens (when the server's time would be setuped correctly).

[oreeh · Accepted solution]

And I'm pretty sure I know which product you will use then.

Maybe one of the following VMX parameters helps

tools.syncTime

time.synchronize.continue

time.synchronize.restore

time.synchronize.resume.disk

time.synchronize.resume.memory

time.synchronize.shrink

For an explanation look here http://www.sanbarrow.com/vmx/vmx-always-start-tonight.html

[hicksj]

If you're not helped by one of those settings, and assuming you're problem is that DRS is relocating the VM's causing the time to be reset, go into the DRS settings and change the two VM's from fully automated to manual or disabled.

[skearney]

If I understand your problem correctly, the new VC 2.0.2 release addresses this problem

Time Synchronization Option Is Now Preserved During VMotion Migration

This release fixes an issue where the time synchronization option was not preserved when a virtual machine was migrated to a destination host such as an ESX Server 2.5.2 host. Now, during migration, the time synchronization option is preserved.

Note: If tools.syncTime value is changed when the virtual machine is powered on, the time synchronization option will not be preserved.

http://www.vmware.com/support/vi3/doc/releasenotes_vc202.html

[christianZ]

Maybe one of the following VMX parameters helps

tools.syncTime

time.synchronize.continue

time.synchronize.restore

time.synchronize.resume.disk

time.synchronize.resume.memory

time.synchronize.shrink

One of these did the job (I took all of them with "false").

We will see tomorrow if the time in vm slides large.

Thanks to all for the hints.

DRS is already configured to manual;

have VC 2.0.1 for now but both servers are 3.0.1 - first need to test with VC 2.0.2

Regards

Christian

[oreeh]

Glad it helped

[masaki]

This options are the same you can find in the VI client under vm's options tab (there are several flags).

We are glad to help.

[christianZ]

FYI. I tested it with VC 2.0.2 - it didn't work (w/o mentioned parameters).

[J-D]

If you are using RSA then you can use the RSA config itself to have another time.

Check the System, System parameters, you will find a button for "Clock Offset" which will offset all your tokens.

That way you don't have to mess around with any VMware settings.

In any case, every RSA SecurID setup should be synched with a time server.

[christianZ]

I can see only "Set clock offset by token" - but my colleagues are not sure here.

[J-D]

I haven't used it myself but from what I can see you have to select a token, then enter the tokencode and the RSA will calculate how "wrong" it is. The RSA will not only calculate the current tokens + and - 1 minute but for several more minutes (I think + and - 30 minutes).

It should then display a "calculated" offset. Of course you first have to put the time on the RSA Server to the correct time.

HTH

[christianZ]

And that we don't want to do - we have here ca. 200 tokens - partially not by our colleagues.

[J-D]

the computed offset is not for the one token you selected but all tokens imho.

A copy paste of the RSA help:

-

---

RSA Authentication Manager Date and Time

The Authentication Manager date and time boxes show the current date and time. You may need to change the offset on the server if the system clock is out of synchronization with the token clock by more than a few minutes.

Set clock offset to 0. When you select this option, the system clock offset is removed.

Set clock offset by token. When you click Set clock offset by token, a browser opens, listing the token serial numbers you can select from to set the offset.

After you have entered a value for the offset, the Computed offset currently applied box displays this value.

-

---

You can always reset this offset by clicking the "Set clock offset to 0" and put the VM's time backwards again. So a test is possible without doing much harm...