I want to create a script that react on guest restore state (restart some jobs, cuase of time sync reasons they fail).
Restore event became after you start this machine back.
I search this site and try to google for, but can not find any info.
My understandig, that for guest VM this event is transparet.
VM could not catch it "in nature", but there should be inderect events for make assumption about this event...
Does anyone did this?
Catch restore state in guest by script
-
scottgus1
- Site Moderator
- Posts: 20945
- Joined: 30. Dec 2009, 20:14
- Primary OS: MS Windows 10
- VBox Version: VirtualBox+Oracle ExtPack
- Guest OSses: Windows, Linux
Re: Catch restore state in guest by script
If I understand you correctly, you want your guest to be able to tell that it was save-stated and restored. I helped someone through this once. All I can say below is for Windows guests. I assume Linux has similar functions.
The experiments I did tell me that there is no flag or event shown to Windows guests that the guest was save-stated and restored. I see nothing in Event Viewer. The only suggestion I have is to write a vbscript started every few seconds or minutes by the Task Scheduler. You'd choose how often you need to test. The script records the system time to a file on the disk. The next time the script runs it checks the recorded time and sees how much time has elapsed since it ran the last time. If more than your desired amount of time has passed, the script assumes a save-state and restarts your desired programs.
This setup as given would not be able to tell the difference between save-state-restores and shutdowns or reboots. However there are Event Viewer events for shutdowns and reboots. Vbscript can read the Event Viewer logs and with proper filtering pick out the shutdowns and reboots, and change what it does if there was a shutdown or reboot since the last time the script ran, if such testing proves necessary.
The experiments I did tell me that there is no flag or event shown to Windows guests that the guest was save-stated and restored. I see nothing in Event Viewer. The only suggestion I have is to write a vbscript started every few seconds or minutes by the Task Scheduler. You'd choose how often you need to test. The script records the system time to a file on the disk. The next time the script runs it checks the recorded time and sees how much time has elapsed since it ran the last time. If more than your desired amount of time has passed, the script assumes a save-state and restarts your desired programs.
This setup as given would not be able to tell the difference between save-state-restores and shutdowns or reboots. However there are Event Viewer events for shutdowns and reboots. Vbscript can read the Event Viewer logs and with proper filtering pick out the shutdowns and reboots, and change what it does if there was a shutdown or reboot since the last time the script ran, if such testing proves necessary.
Re: Catch restore state in guest by script
Thank you very mush. This is exactly what I want.
1) I can put another script in start up to fix "pure start" detection.
2) There could be I/O lagg, cause I have disk encrypted on my host. I have to think about it also...
My 2 cents:scottgus1 wrote:The only suggestion I have is to write a vbscript started every few seconds or minutes by the Task Scheduler. You'd choose how often you need to test. The script records the system time to a file on the disk. The next time the script runs it checks the recorded time and sees how much time has elapsed since it ran the last time. If more than your desired amount of time has passed, the script assumes a save-state and restarts your desired programs.
This setup as given would not be able to tell the difference between save-state-restores and shutdowns or reboots. However there are Event Viewer events for shutdowns and reboots. Vbscript can read the Event Viewer logs and with proper filtering pick out the shutdowns and reboots, and change what it does if there was a shutdown or reboot since the last time the script ran, if such testing proves necessary.
1) I can put another script in start up to fix "pure start" detection.
2) There could be I/O lagg, cause I have disk encrypted on my host. I have to think about it also...