One of the features I am most missing (compared to vSphere, etc) is the ability to make one VM dependent on another.
For example, a database server likely would need to be up and running before another server which depends on the database service. Other likely candidates would be a file server or UTM, but the list could be long depending on specific needs.
Similar to the AUTOSTART delay, there could be a "delay after dependency" and (obviously) the ability to choose another registered VM. So as in the example above, you might want your dependent VM to start after the database server is confirmed to be running.
VM dependencies during AUTOSTART
-
- Site Moderator
- Posts: 20945
- Joined: 30. Dec 2009, 20:14
- Primary OS: MS Windows 10
- VBox Version: PUEL
- Guest OSses: Windows, Linux
Re: VM dependencies during AUTOSTART
An interesting idea!
FWIW this can be done with user-rolled scripts now.
Host script starts VM A.
Host script loops waiting for a file to appear in a global shared folder while incrementing a delay counter.
VM A is programmed via internal scripts to make a file in the global shared folder when certain desired services or states have been achieved.
If the file appears in the global shared folder, Host script knows VM A is up and running, jumps out of the loop.
If the delay counter reaches a determined amount of delay without the file appearing, Host script kills VM A and reboots it or other desired fallback procedures.
Outside first loop, Host script starts VM B...
etc.
FWIW this can be done with user-rolled scripts now.
Host script starts VM A.
Host script loops waiting for a file to appear in a global shared folder while incrementing a delay counter.
VM A is programmed via internal scripts to make a file in the global shared folder when certain desired services or states have been achieved.
If the file appears in the global shared folder, Host script knows VM A is up and running, jumps out of the loop.
If the delay counter reaches a determined amount of delay without the file appearing, Host script kills VM A and reboots it or other desired fallback procedures.
Outside first loop, Host script starts VM B...
etc.