Hello,
i saw that because of a feature request the "stop" option now rsults in a "poweroff" command. Wouldn't it make more sense if "poweroff" and "acpipowerbutton" can be set by different options? In normal case, i prefer to use the "acpipowerbutton".
regards
netkjot
This is related to another feature request: https://sourceforge.net/tracker/?func=detail&aid=2395422&group_id=239993&atid=1111632
Maybe it's a good idea to get rid of the 'stop' option and replace it by the two native VBoxManage commands:
- poweroff
- acpipowerbutton
Then it's clear what the commands actually do.
But these commands take a long type, so an alternative vboxtool command schema could be this:
- stop (unchanged, issues a poweroff)
- softstop (new option, issues acpipowerbutton)
Any thoughts?
sounds good to me... :-) fits perfectly.
From the VirtualBox-forum, virtualpier says:
http://forums.virtualbox.org/viewtopic.php?f=7&t=9956&sid=1b2df254adb29dad06840367a61afafc&p=93094#p93094
"Originally, to stop a VM, the old vboxcontrol script send a "VBoxManage controlvm acpipowerbutton" which starts the right shutdown sequence on the VM OS, processes/files are stopped/closed in the "right way". Sometimes (often?), to directly send a poweroff signal it's not a problem, however, some applications could "realize" that their files has not been closed in the right way and BLOCK the following autostart process (eg. "the program has detected that this file has not been correctly closed last time..do you want to perform some check....etc."), other times, this mode could lead to data loss under some circustance...
To avoid this kind of problems, in my modified version of vboxcontrol (bash), when i call "vboxcontrol stop" a counter starts: after $TIMEOUT (120s), if the VM is still running and only after $TIMEOUT, send a poweroff signal. In my opinion it's less "brutal" than the sudden poweroff'
So basically, first do a acpipowerdown command and then after a timeout if the session has not finished, do a hard stop (poweroff) command.
Have you implemented this already? How about a configurable timeout?