Virtual Time Freeze Broken with New Version of VMWare Workstation

[JamesConrad]

Chris Wolf's excellent article about freezing time in a vmware guest is a great way to test trial version of software so that it does not expire after a certain number of days. http://mcpmag.com/columns/rss.asp?editorialsid=1639. However, this hack appears to only work up to version 6.0.0.0 build-45731. When I upgraded to the newest version of VMWare Workstation 55017, this hack appears to become nullified and my virtual machines expired. The .vmx file does not look as if it was modified by the upgrade, and I did not upgrade vmware tools. The new release notes do not mention anything about changing guest time.

When I downgraded back to version 45731, the VMs worked fine.

If anybody has insight into this, it would be appreciated!

[KevinG]

Post the .vmx file from the virtual machine that was used with 6.0.1

Also after upgrading did you install the 6.0.1 VMware Tools in the guest OS?

[j_mosk]

James and I work together.. so, here's the VMX in question..

The lines which seem to fail to work now are..

tools.syncTime = "FALSE"

time.synchronize.continue = "FALSE"

time.synchronize.restore = "FALSE"

time.synchronize.resume.disk = "FALSE"

time.synchronize.shrink = "FALSE"

rtc.startTime = 1170953700

Whole VMX below.. (two lines deleted with floppy names and CD rom names in them)

--

config.version = "8"

virtualHW.version = "6"

scsi0.present = "TRUE"

scsi0.virtualDev = "lsilogic"

memsize = "256"

MemAllowAutoScaleDown = "FALSE"

ide0:0.present = "TRUE"

ide0:0.fileName = "disk0-000002.vmdk"

ide1:0.present = "TRUE"

ide1:0.deviceType = "cdrom-image"

floppy0.present = "FALSE"

ethernet0.present = "TRUE"

usb.present = "FALSE"

sound.present = "FALSE"

sound.virtualDev = "es1371"

sound.fileName = "-1"

sound.autodetect = "TRUE"

displayName = "Company1DC"

guestOS = "winnetenterprise"

nvram = "Windows Server 2003 Enterprise Edition.nvram"

floppy0.fileType = "file"

ide0:1.present = "TRUE"

ide0:1.fileName = "disk1-000002.vmdk"

ethernet0.connectionType = "custom"

ethernet0.vnet = "VMnet2"

ide0:0.redo = ""

ide0:1.redo = ""

ethernet0.addressType = "generated"

uuid.location = "56 4d 20 53 d2 17 67 32-63 3e c4 d3 9b bf c4 07"

uuid.bios = "56 4d 38 39 a0 4e d7 00-88 71 a8 d5 fd 7e d1 0e"

uuid.keep = "TRUE"

ethernet0.generatedAddress = "00:0c:29:7e:d1:0e"

ethernet0.generatedAddressOffset = "0"

ide1:0.startConnected = "TRUE"

ide1:1.present = "FALSE"

ide1:1.deviceType = "cdrom-image"

checkpoint.vmState = "Windows Server 2003 Enterprise Edition.vmss"

checkpoint.vmState.readOnly = "FALSE"

tools.syncTime = "FALSE"

time.synchronize.continue = "FALSE"

time.synchronize.restore = "FALSE"

time.synchronize.resume.disk = "FALSE"

time.synchronize.shrink = "FALSE"

rtc.startTime = 1170953700

virtualHW.productCompatibility = "hosted"

tools.upgrade.policy = "upgradeAtPowerCycle"

extendedConfigFile = "Windows Server 2003 Enterprise Edition.vmxf"

uuid.action = "keep"

isolation.tools.hgfs.disable = "TRUE"

pciBridge0.present = "TRUE"

svga.autodetect = "TRUE"

pciBridge0.pciSlotNumber = "17"

scsi0.pciSlotNumber = "16"

ethernet0.pciSlotNumber = "32"

[continuum]

Try this sample - works for me in 6.0.1.

(needs no additional files - just paste to a vmx and run)

config.version = "8" virtualHW.version = "4" displayName = "I_will_always_start_9th_July_at_19:46_2004_Berlin-Time" guestOS = "winXPPro" scsi0.present = "TRUE" memsize = "256" ide0:0.present = "FALSE" ide0:0.fileName = "my.vmdk" ide1:0.present = "FALSE" ide1:0.fileName = "my.iso" ide1:0.deviceType = "cdrom-image" floppy0.fileType = "file" floppy0.fileName = "my.flp" floppy0.startConnected = "FALSE" Ethernet0.present = "TRUE" Ethernet0.addressType = "generated" sound.present = "FALSE" sound.virtualDev = "es1371" sound.fileName = "-1" usb.present = "FALSE" priority.grabbed = "normal" priority.ungrabbed = "normal" isolation.tools.hgfs.disable = "TRUE" isolation.tools.dnd.disable = "TRUE" redoLogDir = "." rtc.startTime = 1089395200 tools.syncTime = false time.synchronize.continue = false time.synchronize.restore = false time.synchronize.resume.disk = false time.synchronize.resume.memory = false time.synchronize.shrink = false

See my site

http://sanbarrow.com/vmx/vmx-always-start-tonight.html

[KevinG]

Hi ulli,

If your .vmx file is used, the user will not be able to use some of the new features of WS 6, since your .vmx file contains an older version of virtual hardware.

config.version = "8" virtualHW.version = "4"

[j_mosk]

I will try. But how is that any different than what we've got? Just curious.. Thx.

[continuum]

Kevin

my vmx also works with

config.version = "8" virtualHW.version = "6"

So I assume the problem don't lies in WS 6.0.1

[Liz]

Normally when I try and freeze time I forget to turn off windows time sync and all that, but Ive tried mine under 6.0.1 and my time wouldnt freeze either.. (Xp host, 2003 guest)

I cant think what else would be doing it - my guests not on a domain so theres no login scripts etc that maybe forcing it to do so.

[continuum]

Strange - can you try with the vmx I posted - this works for me

[Liz]

I think I know what it is. You've set the rtc.starttime.. if thats not set I think it defaults to current system rather than "where you left off"..

[j_mosk]

Liz:

I'm confused.. We're both using

rtc.starttime = <something>

So.. can you please rephrase your discovery about what you think is wrong? Thx in advance.

[Liz]

if you just turn off all the syncs using the tools provided - it doesnt set the rtc.starttime.

which is where mine differs, mine just has all the synctimes off.

[j_mosk]

Liz.. So does mine ... Here are my lines.. Still confused about why mine doesn't honor time freeze in 6.1.

tools.syncTime = "FALSE"

time.synchronize.continue = "FALSE"

time.synchronize.restore = "FALSE"

time.synchronize.resume.disk = "FALSE"

time.synchronize.shrink = "FALSE"

rtc.startTime = 1170953700

[JayBeeFrog]

Hi all,

I have the same setting too and 6.0.1. won't respect the entry. In fact, when I restart the guest OS (Windows server 2003), it deletes the entire rtc.startTime entry from the VMX file!! (??)

When I revert to 6.0.0, everything is fine ...

regards,

John

[TimMann · Accepted solution]

You need to also add

time.synchronize.tools.startup = FALSE

We added a feature where the tools also sync time once when the tools daemon is started. Sorry, this should have been updated in the knowledge base (and wherever else we may have documented these settings). We'll check into that and update the docs.

[j_mosk]

Thanks Tim.

So, is the remediation to put this line in every VMX file everywhere?

Or, must I ALSO upgrade all instanaces of all VMware tools in every instance?

Thx in advance.

[TimMann]

Thanks Tim.

So, is the remediation to put this line in every VMX file everywhere?

Or, must I ALSO upgrade all instanaces of all VMware tools in every instance?

Thx in advance.

In a VM where you're currently using the "time freeze" technique that this thread is about, where you run the VM with some time that's completely unrelated to real time -- not just a different time zone or a constant offset from real time -- yes, you need to add the new config option in addition to the existing ones that that technique already involves having, namely time.synchronize.resume = FALSE, etc. (If you're not using this technique, then nothing in this thread applies to you.)

I thought this was a rare thing to do. If it's every VM everywhere for you, sorry for the inconvenience. If all your VMs need it, you can save some work by putting the new option in the global config file on each host instead of each VM's .vmx file. On Linux hosts and on ESX Server, the global config file is /etc/vmware/config. On Windows hosts, see KB article 1754 for the exact location.

No, you don't have to both upgrade tools and add the new option.

[rob_nendel]

In the newest version of Workstation, you can't have the VMX loaded ( running or in a powered-down state ). I've noticed that if I have the VM loaded and modify the vmx configuration, VMware Workstation will delete the modifications ( it must be maintaining a memory-resident copy of the vmx and writes it back to disk ). Try making sure the VM is not running nor loaded into VMware Workstation, modify the VMX, and then load the VM and see if the problem goes away.