Date: Sun, 07 Jul 2019 00:23:32 +0000 From: bugzilla-noreply@freebsd.org To: vbox@FreeBSD.org Subject: maintainer-feedback requested: [Bug 239027] emulators/virtualbox-ose: vm based delay not ties to the boot or shutdown process Message-ID: <bug-239027-26505-pWOaBVUNqZ@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-239027-26505@https.bugs.freebsd.org/bugzilla/> References: <bug-239027-26505@https.bugs.freebsd.org/bugzilla/>
index | next in thread | previous in thread | raw e-mail
Bugzilla Automation <bugzilla@FreeBSD.org> has asked vbox@FreeBSD.org for maintainer-feedback: Bug 239027: emulators/virtualbox-ose: vm based delay not ties to the boot or shutdown process https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239027 --- Description --- 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?help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-239027-26505-pWOaBVUNqZ>