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/>
next in thread | previous in thread | raw e-mail | index | archive | help
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=3D239027 --- 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 w= hen 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 sy= stem with cause the host system to randomly panic/freeze. Removing these VMs fr= om vboxheadless I do not see the issue and these VMs can be started post start= up.=20 However, now these need to started/stopped manually. Currently I'm only looking for a startup delay on a VM basis that isn't tie= d 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=3D"\${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?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-239027-26505-pWOaBVUNqZ>