Virtualbox does NOT shutdown VMs gracefully when OMV host goes down (eg. power failure or "shutdown command" from WebUI

    • OMV 3.x
    • Resolved

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Virtualbox does NOT shutdown VMs gracefully when OMV host goes down (eg. power failure or "shutdown command" from WebUI

      Hi Folks,

      I try to switch the behavior of Virtualbox Plugin for how it terminates VMs in case of the host shutting down.

      Most OS do not take well, if you just pull the plug. The OS usually then trys to think: 8o and on next start it says: ?( <X

      Windows VMs (unlike Linux machines), that are currently not logged in, do need to get hit twice by "acpibutton", the first time kind of "wakes them up" =O , the second time shuts them down || .

      In the past I used this string su -c "vboxmanage list runningvms | sed -r 's/.*\{(.*)\}/\1/' | xargs -L1 -I {} VBoxManage controlvm {} acpipowerbutton" vbox from root CLI of OMV with a shutdown shell script repeating the string twice with a 10 seconds wait and then waiting an other 60 sekonds before shutting down the host.

      Take note that the vobxmanage command to list running VMs only works with the user that runs the VMs, in OMV this is the user vbox. if you issue this as root, the return is empty. Took me a while back when i started to build that command, to figure this one out.
      But then, I need to run that before the host shuts down, that obviously IS a problem with power failures :) :whistling:

      Now I lost a VM ;( it got corrupted by the hard kill. :cursing:

      I tried to edit /etc/default/virtualbox from the standard entry "SHUTDOWN=poweroff" to two times SHUTDOWN=acpibutton and for safety reasons followed by SHUTDOWN=savestate. To no result, my test Windows VM still gets hard killed, as if the virtualbox daemon does not know the host is going down, or the host wont wait for the virtualbox service to report back VMs shutdown successfully.

      Do I work the wrong file, or does the OMV Plugin has the shutdown routine not implemented into the host routine? Does it even know the host going down per WebUI or by remote command from UPS?

      somebody any clue

      Thanks
      Manne

      edit: I found that in /etc/rc6.d there is a link to /..init.d/virtualbox, so my question if virtualbox does know about the shutdown, is obsolet.

      edit2: /etc/init.d/virtualbox stop_vms doese indeed switch off the VMs accorindg to /etc/default/virtualbox

      new question: why is /etc/init.d/virutalbox not or not propperly called on shutdown with the case stop_vms (I susspect it IS indeed called but with case stop

      I just had the server shut down from root CLI with shutdown -r 1

      But I have no clue as there where to look to troubleshoot that further.

      Cheers Manne

      The post was edited 6 times, last by mannebk: added informations ().

    • I found a bug in the init.d script virtualbox.

      the original one is this:
      code not present, as forum tells me my posting is to long.




      my bash syntax highlighting told me that with the stop section is something wrong, it was colored diferent than the other sections.

      so i fooled around with it.

      i renamed it to hstop() and modified all refferees

      then shutdown is sucessfull

      also i have no clue as to what is wrong with the original syntax....

      the sucessfull one:
      code not present, as forum tells me my posting is to long.

      after the change you need to run systemctl daemon-reload

      then everything is fine

      The post was edited 1 time, last by mannebk ().

    • greetings to all,
      I have the same exact problem. OMV 4.x installed successfully the virtualbox plugin and phpvirtualbox and everything's appears to be fine, except for the "shutdown" phase of any running VM. Even through VBoxManage CLI command seems impossible to shutdown VM gracefully.
      Could you please explain in details (with code editings) what did you do to solve this? Any mod to init.d script? thanks.
    • just open /etc/init.d/virutalbox in an code high lighting editior.

      in line 117 youll find stop()

      but the code highligting shows that something is a miss with the syntax. Im no expert in this, i just notice small details. so the code high lighting will tell you that this is not the same than line 49 running() or line 54 start()


      so what I did is this: I changed line 117 stop() to hstop() so with this change it changed the color in the syntax high lighting in my case from yello to cyan :)

      but then you need to change also the end of the file. stop is called twice. you have to add the h to it.

      i chose h with no reason. but I did later try c (for custom) and it die NOT work as with h. no clue as to why.

      Shell-Script: /etc/init.d/virtualbox

      1. case "$1" in
      2. start)
      3. start
      4. ;;
      5. stop)
      6. stop_vms && hstop
      7. ;;
      8. stop_vms)
      9. stop_vms
      10. ;;
      11. restart|force-reload)
      12. stop_vms && hstop && start
      13. ;;
      14. status)
      15. dmnstatus
      16. ;;
      17. *)
      18. echo "Usage: $0 {start|stop|stop_vms|restart|force-reload|status}"
      19. exit 1
      20. esac
      Display All
      have fun
    • also keep in mind, that Windows VMs do need to geht hit by ACPI Button twice to realy shut down, while a linux box just ignors the second ACPI kick. So I modified my config for shutdown to run stop_vms twice, while the stock code does it only once. but I also forced my virtualbox to always shut down the VM by ACPI, not just suspend or "freez" the VM, as Windows needs rebooting once in a while.
    • I know almost nothing about virtual box. Proxmox and other vm hosts have a way to shut down vm's. Proxmox uses qemu-guest-agent. Esx uses something like guest tools. Maybe vb has something like this? Could either be used with vb?

      qemu-guest-agent is a debian so could be apt-get installed. There is a windows program in the qemu virtio driver iso to install it. No idea if that would help tho.


      If your vm's are important, you may want to think about upgrading your vm host. OMV runs very well as a vm. You can pass some hardware and disks to OMV to use with plugins or whatever.
      If you make it idiot proof, somebody will build a better idiot.
    • donh wrote:

      I know almost nothing about virtual box. Proxmox and other vm hosts have a way to shut down vm's. Proxmox uses qemu-guest-agent. Esx uses something like guest tools. Maybe vb has something like this? Could either be used with vb?

      qemu-guest-agent is a debian so could be apt-get installed. There is a windows program in the qemu virtio driver iso to install it. No idea if that would help tho.


      If your vm's are important, you may want to think about upgrading your vm host. OMV runs very well as a vm. You can pass some hardware and disks to OMV to use with plugins or whatever.
      Indeed so does virtualbox. It indeed does work if you call it from CLI. But if you built an error into the syntax of the shutdown section of the relevant Init.d script, all related software will fail. (by nature of the design)

      before I made it to OMV i was with proxmox runing my fat and happy HP ProLiant DL380 Gen 5 with lots of VMs and an QNAP 6disc nas storage, consuming somewhere 600watts per hour. Ideling for about 16 hours a day at 550Watts, and doing nightly backups to an other 4disc QNAP for hours, as the 410 via ssh only sucks like 5mb/s and my sensitiv data runs at about 3TB currently.

      For Lifetime and energy reasons i then changed to the HP micro gen 8. After I did spend almost 2grande on hardware, mostly for my 10tb survilance discs, I discovered that, to pass through my HP 410 HW raid card to my NAS-VM, I need to use the same IRQ, HP uses for the intrenal iLo server health communication. No way to get that working, so no direct hardware acces for my NAS-VM. Support on proxmox forum was non existend, I am no Linux freak or scripting kid, so I dumped proxmox for good. If I cant get it to work inside one week, its not suitable for my production enviroment.

      I looked into ESXi, but discoverd that I was required to buy some license. And Im OpenSource to the max. I donate, but I dont buy license. Then I checked freenass and OMV if they would be suitable OS for my host and finally stayed with OMV as Volker is next door, a 15 min drive, the idea was, that if I somehow screw it up, I could take that box and two purple eur banknotes and knok on his door winking with that purple convincing thing ... :) But then OMV is a stable and well maintained system with lots and formost fast support on the forum AND very good reviews. I never had to knok on Volkers door :-D. I also got turned on by omv-extra with virtualbox. I dont want to compail my own stuff. Im but a moonlighting admin.

      Indeed I did have some problems with OMV and virtualbox in the beginning, but then it was up and running flawlessly since over a year, soon to be 2, exept for that shutdown behavior.

      so after i did loos a VM i conviced myself that I indeed should track it down. Now I did trackt it down and fixed it locally, im done with this thing for good. I just had to report it here for others to not have to investigat this too, it actually did cost me some time to figour it out, lucky me I did NOT loose any data, as my accountand did honor my rule to backup the database and do not safe anything on the desctop of that VM. But other guys may not be so lucky. Also i wannted it reported to the packet maintainer, so I dont have to fix this again after the next update. and I wanted it documented, so If I had to do it again, because the packet maintainer does not want to fix it, I could follow my own guide. no need to remember details, just look up the bash history or omv fourm or my GIT wiki.

      no harm done, my first bug report :D filed and now back to daily work.
      cheers

      The post was edited 3 times, last by mannebk: typos ().