[Bug 239027] emulators/virtualbox-ose: vm based delay not ties to the boot or shutdown process
bugzilla-noreply at freebsd.org
bugzilla-noreply at freebsd.org
Sun Jul 7 00:23:35 UTC 2019
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239027
Bug ID: 239027
Summary: emulators/virtualbox-ose: vm based delay not ties to
the boot or shutdown process
Product: Ports & Packages
Version: Latest
Hardware: Any
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: Individual Port(s)
Assignee: vbox at FreeBSD.org
Reporter: dereks at lifeofadishwasher.com
Flags: maintainer-feedback?(vbox at FreeBSD.org)
Assignee: vbox at FreeBSD.org
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?
--
You are receiving this mail because:
You are the assignee for the bug.
More information about the freebsd-ports-bugs
mailing list