Bug 239027 - emulators/virtualbox-ose: vm based delay not tied to the boot or shutdown process
Summary: emulators/virtualbox-ose: vm based delay not tied to the boot or shutdown pro...
Status: Open
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Virtualbox Team (Nobody)
URL:
Keywords: crash, needs-qa
Depends on:
Blocks:
 
Reported: 2019-07-07 00:23 UTC by Derek Schrock
Modified: 2023-08-18 20:16 UTC (History)
1 user (show)

See Also:
bugzilla: maintainer-feedback? (vbox)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Derek Schrock 2019-07-07 00:23:32 UTC
Using vboxheadless_<machine>_delay in rc.conf will delay the start/stop of a given VM however this delays the whole boot or shutdown process depending when headless starts/stops or the order of vboxheadless_machines.

Due to what appears to be an issue, at least on my system, with starting Windows VMs on zfs via vboxheadless along with other VMs, jails, and the system with cause the host system to randomly panic/freeze.  Removing these VMs from vboxheadless I do not see the issue and these VMs can be started post startup.   However, now these need to started/stopped manually.

Currently I'm only looking for a startup delay on a VM basis that isn't tied to the boot process.

It appears this could be solved if a new variable is introduced and an sh compound statement is given to the daemon command in vboxheadless.in:70 rc file.


  eval vmdelay_start="\${vboxheadless_${machine}_delay_start:-0}"

  ...
    daemon -f ... ${vmuser} sh -c "{ /bin/sleep ${vmdelay_start}; ...; }
  ...

Creating a stop delay doesn't seem practical unless if it is used as the current delay.  If a stop is introduce should the current delay be renamed/removed?