-
Notifications
You must be signed in to change notification settings - Fork 46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Could it be possible to add a delay when starting a bunch of VMs? #64
Comments
This sounds like a good suggestion, useful when you have many VMs managed by VBoxVMService. PRs are welcome. |
+1 I have a VM running on one machine, but it relies on a network share being established to another machine that takes a while to come up. When the VM starts early, no files are accessible until a reboot. A delayed start where I can assign a 5 min pause would be ideal. |
If the host goes down for windows reboots, sometimes it will come up very briefly (a couple of minutes) before rebooting again. That short time will sometimes not be enough for VMs to restore and then resuspend. This has happened to me twice in the last week, causing some painful downtime before I noticed each time, and just recently figured out what's happening. Protecting my guests from unplanned updates of the host was my main use for this project, so I see this as a high priority issue. Any pointers on where I could start work on a pull request for this? |
I've switched the Windows service to "Automatic (Delayed Start)". Next windows reboot, I'll see if this prevents the aborted partial-restore situation. |
When starting the service, all machines are started sequentially, but with no delay among them. So if they are located in a slow HDD it could be a problem as firing them all will cause a slowdown and high HDD activity.
Is there a possibility to add some kind of delay between VMs so that in the list of automatically starting machines the next one will be started after that delay?
It could be a global argument or a per machine delay (a time counter after starting that machine) in VBoxVMService.ini. The second option could lead to a more precise starting sequence.
Any possiblities?
The text was updated successfully, but these errors were encountered: