Virtuelles System immer mit dem gleichen Datum starten

[bipbipbob]

Hallo,

ich möchte das mein virtuelles System immer mit dem gleichen Datum bootet z.B. 01.07.2004. Kann ich das in der log datei einstellen?

mfg

bipbipbob

[continuum]

Hi
das geht aber ....
Das ganze Verfahren ist alles andere als trivial ... ich suche es dir raus - dauert allerdings etwas.

Ulli

[bipbipbob]

dann schonmal danke

[continuum]

Eh ich das vergesse:
Die Stumpf-ist-Trumpf Variante: Vor dem Hochbooten gehst du ins VMware-BIOS und stellst die Zeit von Hand ein.

Ulli

[gsx²]

hi

du kannst im bios deine einstellungen als "default" speichern
wenn du das bios-datum so einstellst dass es für dich passt, sollte das virtuelle bios sich das merken und die maschine bootet immer mit dem "alten" (default) datum

hth

[continuum]

Wie bitte speicherst du denn ein Default?

Du meinst doch wohl nicht die Setup Defaults per F9?
Das hat mit dem Datum absolut nichts zu tun.

[continuum]

So - hier hab ichs wieder.

Die Anleitung stammt von DaveP und ist von Tim Mann ueberprueft - sollte also stimmen.

Achtung: das ist starker Tobak

I posted this some time ago in the VMware newsgroups. I use it when testing our software when we need specific dates to test date functionality. It still works with 4.5.1.

Regards

Dave


Subject: Re: Disabling guest BIOS update with current host date/time
Date: 17 December 2002 17:20

Hi

OK this has been bugging me as well. So after grepping the strings in VMware, and about a bajillion reboots of a DOS image I have found a solution. However, it is complicated so hold tight.

First off, this is obviously undocumented for very good reasons, get it wrong and VMware will GPF. Use it at your own risk, I won't take any responsibilty for it, and you can be sure VMware will not and should not be responsible either. This was only done with VMware 3.2.0 Build 2230 on a Windows 2000 Professional Host + SP3. Whilst I have the Linux version I haven't tested it there.

Use the following settings in your .vmx file:

1. These lines just ensure that nothing messes up the time you have set in the configuration file.

# Stop VMware tools from updating
tools.syncTime = false
# Stop time syncs once running/suspended
time.synchronize.continue = false
time.synchronize.restore = false
time.synchronize.resume.disk = false
time.synchronize.resume.memory = false
time.synchronize.shrink = false

2. Optionally make the nvram file read only. Do this after configuring the virtual machine and after the first boot. Add the following line which works on Windows host:

# Stop writes to nvram file
nvram.mode = nonpersistent

3. Now add the time you want to have the virtual RTC start:

# Start date & time
rtc.startTime = <seconds since 01/01/1970 00:00:00> or -1

This is where it gets complex. To explain the background:

a. C functions use time as the number of seconds from 01/01/1970 00:00:00
b. PC BIOS uses seconds from 01/01/1980 00:00:00

The rtc.startConnected setting uses the time as used in C functions, presumably because VMware itself is using standard C function calls; e.g. gmtime etc. However, because of the BIOS requirements it must also be within
the limits of its values. This gives us a data range we can set of:

BIOS Start Date C Functions End Date (Y2038 problem!)
01/01/1980 00:00:00 --> 01/18/2038 03:14:07

So in theory we have to use a setting between 315532800 -> 2147483647
seconds.

Hopefully clear?

Now there is a gotcha, the time is adjusted by the time zone you are in. So I am in the UK and we are currently on GMT. The difference is based on PST as a base line NOT GMT. So as I am +8 hours from PST I have to add 8 hours
to get the correct time. So for:

01/01/1980 00:00:00 = 315532800 + (8 * 60 * 60) = 315561600

When I set the host clock to a date in BST (GMT +1) I have to use 7 hours for the calculation. Confused; I was!!!!

Finally setting rtc.startConnected to -1 causes the clock to sync as normal.

This works for me but be aware that OSes may have problems, and it may just be simpler to use the guest OS facilities to set the time during startup.

Regards

Dave

[continuum]

Weitere Erkenntnisse: frisch auf den Tisch

du koenntest folgendes machen:
setz diese Eintraege in deine vmx:
tools.syncTime = false
time.synchronize.continue = FALSE
time.synchronize.restore = FALSE
time.synchronize.resume.disk = FALSE
time.synchronize.shrink = FALSE

Dann machst du dir ein Dos-floppy mit einer batch die nach dem Bootvorgang direkt "date 01.07.2004" eingibt und neustartet - diesmal in das OS was du brauchst ....

Die VMX eintraege brauchst du um zu verhindern das die Zeit von VMware sofort synchronisiert wird.

Ulli

[bipbipbob]

danke ulli
das in der vmx datei habe ich schon gemacht damit die zeit nicht vom Host genommen wird, wenn es jetzt noch ein set date=01.07.2004 geben würde!
Ich werde alles mal morgen ausprobieren und mich dann mal melden

mfg bipbipbob

[gsx²]

Wie bitte speicherst du denn ein Default?

Du meinst doch wohl nicht die Setup Defaults per F9?

ich hätts so getestet:

01.01.2001 als datum eingestellt - im bios gespeichert
nächstes mal starten - systemdatum im bios -> 01.01.2001

denkfehler meinerseits ?

[zaptac]

Hi,

Wie bitte speicherst du denn ein Default?

Du meinst doch wohl nicht die Setup Defaults per F9?

ich hätts so getestet:

01.01.2001 als datum eingestellt - im bios gespeichert
nächstes mal starten - systemdatum im bios -> 01.01.2001

Du solltest schon 'nen Tag später auch noch mal schauen, der OP will da auch den 01.01.2001 sehen.

denkfehler meinerseits ?

Vermutlich.

Zaptac

[gsx²]

Du solltest schon 'nen Tag später auch noch mal schauen, der OP will da auch den 01.01.2001 sehen.

ok werd ich machen danke

gibts da auch ned virtuelle batterie :wink:

lG

[continuum]

Ja - es gibt quasi eine virtuelle batterie - wenn man per vmx-Eintrag dafuer sorgt dass die Zeit nicht mit dem Host syncronisiiert wird - dann laeuft trotzdem die BIOS-Zeit mit einem gewissen Offset parallel zur Echtzeit.

Nur durch den Trick von DaveP ist es wohl moeglich immer mit der selben Zeit zu starten.

Vielleicht aendert sich das aber bald - gestern bei meinen Nachforschungen bin ich auf 2 interessante Dinge gestossen die ich demnaechst mal ausprobieren will.

Ulli

[gsx²]

Ja - es gibt quasi eine virtuelle batterie

jetzt wo ich mir das genauer überlegt hab ists mir klar

wenns so wäre wie von mir beschrieben würden meine virtuellen rechner immer am 01.01.2001 starten was zur folge hätte das sämtliche systemzeiten falsch wären

gut, das es eine virtuelle batterie gibt

zu schnell geschossen ,danke ulli

lg

[HartmutSchaumburg]

Hallo,


Inhalt der Batchdatei Betrug.cmd
DATE 01.07.1900
start \servername\was starten soll
stutdown /r \servername\was stoppen soll
DATE 05.07.2004

Ist ziemlich simpel.

[zaptac]

Hi,

DATE 01.07.1900
start \servername\was starten soll
stutdown /r \servername\was stoppen soll
DATE 05.07.2004

Versteh ich nicht. Wo läuft dieses Batch?

Zaptac

[HartmutSchaumburg]

Hallo,

das schreibst Du dir.

Was passiert beim start dieses Batches?

Die Systemzeit wird auf den Termin gesetzt, den Du haben willst.
Dann startest Du, was Du starten willst.
Dann stoppst Du was Du stoppen willst.
Dann stellst Du das Datum wieder korrekt ein.

[continuum]

Also ich hatte das eigentlich so gedacht:

wahrscheinlich soll das OS das immer zu einem fixen Termin starten soll davon nichts mitbekommen.
Also um nicht lange im BIOS rumzu wurschteln startet man von Floppy-image mit einer Handvoll DOS. Hier ist in der autoexec.bat ein Aufruf fuer besagte batch die ein festes Datum einstellt und direkt neustartet. Dieses mal dann in das gewuenschte OS.
Wenn man sich dann noch GAG in den MBR installiert kann man ganz locker Starten von HD oder von Floppy auswaehlen.

Ulli

[zaptac]

Was passiert beim start dieses Batches?

Die Systemzeit wird auf den Termin gesetzt, den Du haben willst.
Dann startest Du, was Du starten willst.
Dann stoppst Du was Du stoppen willst.
Dann stellst Du das Datum wieder korrekt ein.

Das ist schon klar, genau das steht ja in dem Batch. Ich verstehe allerdings (in Bezug auf den Thread) nicht, wo du dieses BAtch laufen lassen willst.
1) Zum Starten der VMware? Ich vermute (probiert habe ich es nicht), dass sich die VMware nicht so leicht täuschen lässt und die Zeit nach der Rückkorrektur wieder synchronisiert. Da sich dieses Verhalten wohl mit

Code: Alles auswählen

tools.syncTime = false,time.synchronize.continue = FALSE und time.synchronize.restore = FALSE

unterdrücken lässt (s.o.) evtl. schon ein Ansatz für bestimmte Zwecke. Laufen allerdings auf den Host noch irgendwelche Dienste auf die man sich Verlassen will oder andere VMs, würde ich vor Drehereien an der Uhr dringend abraten...
2) Innerhalb der VM hätte es ja wohl auch nicht zwingend den gewünschten Effekt, der Prozess, den der OP mit einer bestimmten Systemzeit täuschen will kann ja jederzeit die Uhrzeit abfragen und würde dann die Rückkorrektur feststellen.

Dann machst du dir ein Dos-floppy mit einer batch die nach dem Bootvorgang direkt "date 01.07.2004" eingibt und neustartet - diesmal in das OS was du brauchst ....

Dieser Ansatz (am besten als Floppyimage von dem die VM bootet) erscheint mir deutlich vielversprechender.

Zaptac

[HartmutSchaumburg]

Hallo,

hast Du danach gefragt,
eine VM immer zum gleichen Datum oder zur gleichen Zeit zu starten?
Zum gleichen Datum.
Also läuft Dein Hinweis mit der Zeitsynchronisierung ins leere.
Pobier es doch aus, es geht.

Mein Hinweis auf die Systemzeit ist natürlich falsch, es muss Datum heissen.

[continuum]

Datum oder Zeit?
Wo ist denn da der Unterschied? Beides wird in Sekunden nach 1980 gerechnet.

Hat eigentlich niemand den englischen Text gelesen?
Dieser Ansatz ist vielversprechend ...

Ich habs mal nachgebaut so dass jeder es kopieren kann ...

Diese VMX kopieren - in einen Ordner packen und doppelklicken

Code: Alles auswählen

config.version = "7"
virtualHW.version = "3"
displayName = "ich_starte_immer_am_9ten_Juli_um_19_Uhr_46"
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


Ulli

[continuum]

Kann vielleicht mal jemand mit Linuxhost die oben genannte vmx ausprobieren und ansagen ob das Starten mit einer festen Zeit unter Linux auch funktioniert?

Ulli

[zaptac]

Hi Ulli,

Kann vielleicht mal jemand mit Linuxhost die oben genannte vmx ausprobieren und ansagen ob das Starten mit einer festen Zeit unter Linux auch funktioniert?

Yes, it works (Workstation 4.5.2 auf Fedora Core 1).

Gruß, Zaptac

[CLSsupport]

Starten mit fester Zeit -

Ich habe es soeben unter VMware Workstation 6.5 getestet.

Die Eingabe 1.215.000.000 sec seit 1.1.1970 startet das WinXP System mit dem 3.Juli.2008 um 14:01 - aber nach einigen Sekunden wird die Zeit und das Datum aktualisiert.
Ich bin nun testweise noch um 30 Tage zurückgegangen (30x86.400 sec), damit ich nicht in der Zukunft starte.

Die VMX Einträge sind alle so wie beschrieben.
Auch im Windows ist derzeit noch kein Internet Timeserver erreichbar und die Aktualisierung via VMware Tools oder Internet abgeschaltet.

Trotzdem aktualisiert sich das System von irgendwoher.

mfg Michael

[continuum]

Bei mir auf der vmx-seite steht welchen Parameter man seit 6.0.* hinzufuegen muss damit es geht