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

    6 Mal editiert, zuletzt von mannebk () aus folgendem Grund: 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

  • I would guess that every single (not manually patched) omv distro with virtualbox is affected by this syntax error in the init.d script


    What i could gather from the virtualbox and ubuntu forum, its not only OMV.

  • 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.


    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.

    • Offizieller Beitrag

    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.

  • 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

    3 Mal editiert, zuletzt von mannebk () aus folgendem Grund: typos

  • in 4 versions, Virtualbox is perhaps configured normally, a problem that the system is switched off instantly (3-4 seconds) earlier than scripts complete the works,
    virtualbox and another services which should be switched off accurately cannot do it if the main system services were switched off before them.
    the server cannot be switched off in 3-4 seconds, it is impossible, possibly many services are switched off incorrectly, not only virtualbox
    ---------------
    in version 2.1 everything is solved quite normally:

  • i got the same problem but sorry i haven't understand which are the proper step to solve it,

    in 4 version problem (system turn off before virtualbox service, only in default settings some chance to "savestate" vm, in fast systems),
    you can install UPS in client-server mode, and reboot/shutdown from UPS util, for gracefully vm stop:
    "apcpsd"for all old APC models (apt-get install apcupsd)
    "powerchute network shutdown" for all APC ups with network insterface (download package from apc site , installer for 32 or 64 bit linux, console installation)
    "plugin nut" for many UPS (not all ups models compatible)
    all of 3 util compatible with 2,3,4 versions OMV, can work in master\slave mode, and from command line util/ups interface normal work reboot\shutdown of system, and VM-s.



    for 2.1 version (updated to 2.14) have solution to solve problem:
    1)
    check file /etc/defaults/virtualbox :
    -----text in file: -----------------------------
    # Defaults for VirtualBox.
    # Sourced by vboxweb-service on startup
    VBOXWEB_USER=vbox
    VBOXWEB_HOST=127.0.0.1
    ----------------------------------------------------
    2)
    in file etc/init.d/vboxinit check 2 fragments,
    edit (# Required-Stop: $all)
    ,all system services will continue work some time after shutdown/reboot, until vboxinit script run)
    add delay 60 seconds ($su_command "sleep 60s")
    and change command from savestate to acpipowerbutton in script,


    --fragment1: -----------------------------------
    ### BEGIN INIT INFO
    # Provides: vboxinit
    # Required-Start: vboxdrv $local_fs
    # Required-Stop: $all
    # Default-Start: 2 3 4 5
    # Default-Stop: 0 1 6
    # Description: Controls VirtualBox sessions
    ### END INIT INFO
    ---fragment2:-------------------------------------
    stop()
    {
    # vms are saved, instead of stopped.
    MACHINES=$($su_command "VBoxManage list runningvms | awk '{ print \$NF }' | sed -e 's/[{}]//g'")
    for UUID in $MACHINES; do
    VMNAME=$($su_command "VBoxManage showvminfo $UUID | sed -n '0,/^Name:/s/^Name:[ \t]*//p'")
    echo "$0: stopping machine ${VMNAME} ..."
    $su_command "VBoxManage controlvm $UUID acpipowerbutton" >>/var/log/vb.log
    $su_command "sleep 60s"
    done
    }
    ----------------------------------------------------


    3)


    check "run premission" for etc/init.d/vboxinit
    4)
    run command from shell:
    sudo update-rc.d vboxinit defaults


    5) reboot system , start VM , check host reboot\shutdown,
    shutdown test for Windows Guest VM:
    put test.cmd in "computer" shutdown scenaries in gpedit.msc:
    ------------
    ping 127.0.0.1 -n 10
    ping 127.0.0.1 -n 3 > c:\log.txt
    ---------
    (for result need minimum 13 seconds)


    check c:\log.txt file and creation data of file.


    check "windows Reliability Monitor" 10-15 min after host reboot , non graceful windows shutdown-s show warnings in "Reliability Monitor graph".


  • Sorry, when you talk about 4 version or 2.14 you talk bout version of what OMV, Kernel or Virtualbox?


    sorry for the dumb question

  • i test 4 version, with original kernel , OMV 4.1.3 with all update 15.01.2019,


    delays for shutdown (60 seconds) /savestate (20 seconds) not work,


    full host shutdown time - 2-4 seconds, and in virtualbox config delay 20 seconds for default "savestate" mode ?


    if shutdown settings (in configs) after reboot\shutdown host , in system stability monitor, in VM-s logs - "incorrect windows shutdown".
    if savestate settings (default), windows7-64 VM-s no become to savestate. After host start, VM-s with "manual start settings" have "power-off" status (not "saved") and errors in windows system stability monitor.


    only in very fast host, with very fast VM, have chance to become guest to "savestate" in 1-2 seconds, and no errors in windows logs.


    if in VM-s settings "manual start", and for default ''savestate" settings:
    VM-s after host reboot status - "saved" - savestate work/delay work
    VM-s after host reboot status - "power-off" - savestate not work/delay not work
    VM-s after host rebootstatus - "aborted" - savestate not work/delay not work

  • Heya All,


    New user of OpenMediaVault here (specifically version 4), long time IT guy and I have been tackling this same issue. I believe i have found the solution so I want to post is below while fresh, but be advised implementation for you may require some modifications rather than a direct copy/paste of what i have done, which i will note at the end of each section.


    I am posting this here as when I have been researching and testing this issue for the past many days this is the top result that has come back consistently, so hopefully this gets the message out to those in need.


    To reiterate for clarity: The issue is that with a shutdown or restart of the OMV server virtual machines (VM) are not being shut down properly and end up in an aborted state and run the risk of potentially get corrupted/unusable.


    The determined cause of the issue: The system is terminating the virtualbox kernel on shutdown/reboot before all of the machines states can be saved, resulting in some or none of the VM's stopping correctly.


    To note from original post: The methods of saving the VM state using VBoxManage at system shutdown and reboot have already been implemented in the default install of the virtualbox extra plugin as of this writing. It is this implementation that needs a bit of tweaking.

    Remember, your services may not be exactly the same as mine, so you will need to add/remove/change them as your needs dictate.


    The Issue


    Note: This requires some knowledge of systemd and how it all works. There will be some explanation at the end but not much. So read up on that if needed.


    The file to locate and edit: /lib/systemd/system/phpvirtualbox-machines@.service


    How the file should look from default install:
    [Unit]
    Description=PhpVirtualBox - start and save machines on boot and shutdown for user %I


    [Service]
    Type=oneshot
    ExecStart=/usr/bin/phpvirtualbox-manage-vms --start-vms
    ExecStop=/usr/bin/phpvirtualbox-manage-vms --save-vms
    RemainAfterExit=true
    User=%i
    Group=vboxusers


    [Install]
    WantedBy=multi-user.target


    What will the above do: when executed, either start auto start marked VM's or save the state of the vm's on shutdown/reboot. The " %I and%i " will be replaces by vbox as verified by the logs, so they work fine.


    The issue: It has no directions regarding what order it should be run in with everything else the system is doing during shutdown.


    The Solution


    How to fix: In this file, add in systemd command statements like "Wanted=" and "After=" among others to ensure that a) the process executes at the right time on both start and shutdown events and b)that the system allows it to complete without viciously chopping it off at the knees in the middle of execution.


    Example of my fixed file:
    [Unit]
    Description=PhpVirtualBox - Start and Save machines on Boot and Shutdown for user %I
    Wants=zfs-mount.service smbd.service nut-monitor.service
    Requires=virtualbox-web.service virtualbox.service
    After=zfs-mount.service network.target auditd.service zfs.target smbd.service virtualbox-web.service nut-monitor.service virtualbox.service
    RequiresMountsFor=/RAIDZ2/VirtualMachines/



    [Service]
    Type=oneshot
    ExecStart=/usr/bin/phpvirtualbox-manage-vms --start-vms
    ExecStop=/usr/bin/phpvirtualbox-manage-vms --save-vms
    RemainAfterExit=true
    User=vbox
    Group=vboxusers
    KillMode=none


    [Install]
    WantedBy=multi-user.target


    What I did:
    In UNIT section
    Added the "Wants=" section to indicate the services that really should be started before this service, but don't have to be. (nut service is there since it starts late on boot, and helps ensure UPS functionality)
    Added the "Requires=" section for the services that MUST be started before this one. (nut should probably be here too instead of wants, your choice)
    Added the "After=" section to instruct this service to only start after those have started.
    Added "RequiresMountsFor=" added this for OCD factor, seemed to help ensure the mount stays up until the operation completes. Easily broken by the system's shutdown procedure and probably not necessary.


    In SERVICE section
    Added "KillMode=none" to instruct the system that until this service completes it's tasks, it will not be killed (Think Gandalf vs Balrog if you need a LOTR reference for it)


    In regards to the "KillMode=none", that does not mean it is invincible. if the service the task relies on or the mount the task is using is removed in mid-process, the task immediately fails and is killed anyway cause it is "done".


    IMPORTANT


    You should probably also edit the /lib/systemd/system/virtualbox-web.service and add similar commands to the Unit section. The commands I added are listed below:
    [Unit]
    Description=VirtualBox Web Service
    Before=phpvirtualbox-machines@vbox.service
    After=virtualbox.service


    The "Before=" command will ensure the web interface is up before the machines start up from their saved state. The "After=" command ensures that the virtualbox kernel has been successfully loaded before the web interface starts. The "After=" could probably be replaced with a "Required=", but seems to work either way.


    And that's it! After applying these changes I have no problem doing multiple restarts of the server and having the running virtual machines that are set to manual appear in the web interface as saved and the ones that start automatically do so without any shutdown errors.


    TL;DR You're lazy. Go back and read it cause it takes some thought and logic to apply this if you need to get this fixed.


    That's all from me. I know it is a ramble but then again if this was an easy fix it would not have still been a problem.


    -LAN

    I do IT. I don't do YOUR IT.

    4 Mal editiert, zuletzt von LANPartyCEO () aus folgendem Grund: clarity

  • Heya All,


    New user of OpenMediaVault here (specifically version 4), long time IT guy and I have been tackling this same issue. I believe i have found the solution so I want to post is below while fresh, but be advised implementation for you may require some modifications rather than a direct copy/paste of what i have done, which i will note at the end of each section.


    I am posting this here as when I have been researching and testing this issue for the past many days this is the top result that has come back consistently, so hopefully this gets the message out to those in need.


    To reiterate for clarity: The issue is that with a shutdown or restart of the OMV server virtual machines (VM) are not being shut down properly and end up in an aborted state and run the risk of potentially get corrupted/unusable.


    The determined cause of the issue: The system is terminating the virtualbox kernel on shutdown/reboot before all of the machines states can be saved, resulting in some or none of the VM's stopping correctly.


    To note from original post: The methods of saving the VM state using VBoxManage at system shutdown and reboot have already been implemented in the default install of the virtualbox extra plugin as of this writing. It is this implementation that needs a bit of tweaking.


    The Issue


    Note: This requires some knowledge of systemd and how it all works. There will be some explanation at the end but not much. So read up on that if needed.


    The file to locate and edit: /lib/systemd/system/phpvirtualbox-machines@.service


    How the file should look from default install:
    [Unit]Description=PhpVirtualBox - start and save machines on boot and shutdown for user %I

    [Service]Type=oneshotExecStart=/usr/bin/phpvirtualbox-manage-vms --start-vmsExecStop=/usr/bin/phpvirtualbox-manage-vms --save-vmsRemainAfterExit=trueUser=%iGroup=vboxusers

    [Install]WantedBy=multi-user.target


    What will the above do: when executed, either start auto start marked VM's or save the state of the vm's on shutdown/reboot. The " %I and%i " will be replaces by vbox as verified by the logs, so they work fine.


    The issue: It has no directions regarding what order it should be run in with everything else the system is doing during shutdown.


    The Solution


    How to fix: In this file, add in systemd command statements like "Wanted=" and "After=" among others to ensure that a) the process executes at the right time on both start and shutdown events and b)that the system allows it to complete without viciously chopping it off at the knees in the middle of execution.


    Example of my fixed file:
    [Unit]Description=PhpVirtualBox - Start and Save machines on Boot and Shutdown for user %IWants=zfs-mount.service smbd.service nut-monitor.serviceRequires=virtualbox-web.service virtualbox.serviceAfter=zfs-mount.service network.target auditd.service zfs.target smbd.service virtualbox-web.service nut-monitor.service virtualbox.serviceRequiresMountsFor=/RAIDZ2/VirtualMachines/

    [Service]Type=oneshotExecStart=/usr/bin/phpvirtualbox-manage-vms --start-vmsExecStop=/usr/bin/phpvirtualbox-manage-vms --save-vmsRemainAfterExit=trueUser=vboxGroup=vboxusersKillMode=none

    [Install]WantedBy=multi-user.target


    What I did:
    In UNIT section
    Added the "Wants=" section to indicate the services that really should be started before this service, but don't have to be. (nut service is there since it starts late on boot, and helps ensure UPS functionality)
    Added the "Requires=" section for the services that MUST be started before this one. (nut should probably be here too instead of wants, your choice)
    Added the "After=" section to instruct this service to only start after those have started.
    Added "RequiresMountsFor=" added this for OCD factor, seemed to help ensure the mount stays up until the operation completes. Easily broken by the system's shutdown procedure and probably not necessary.


    In SERVICE section
    Added "KillMode=none" to instruct the system that until this service completes it's tasks, it will not be killed (Think Gandalf vs Balrog if you need a LOTR reference for it)


    In regards to the "KillMode=none", that does not mean it is invincible. if the service the task relies on or the mount the task is using is removed in mid-process, the task immediately fails and is killed anyway cause it is "done".


    IMPORTANT

    You should probably also edit the /lib/systemd/system/virtualbox-web.service and add similar commands to the Unit section. The commands I added are listed below:
    [Unit]Description=VirtualBox Web ServiceBefore=phpvirtualbox-machines@vbox.serviceAfter=virtualbox.service


    The "Before=" command will ensure the web interface is up before the machines start up from their saved state. The "After=" command ensures that the virtualbox kernel has been successfully loaded before the web interface starts. The "After=" could probably be replaced with a "Required=", but seems to work either way.


    And that's it! After applying these changes I have no problem doing multiple restarts of the server and having the running virtual machines that are set to manual appear in the web interface as saved and the ones that start automatically do so without any shutdown errors.


    TL;DR You're lazy. Go back and read it cause it takes some thought and logic to apply this if you need to get this fixed.


    That's all from me. I know it is a ramble but then again if this was an easy fix it would have still been a problem.


    -LAN

  • Heya All,




    New user of OpenMediaVault here (specifically version 4), long time IT guy and I have been tackling this same issue. I believe i have found the solution so I want to post is below while fresh, but be advised implementation for you may require some modifications rather than a direct copy/paste of what i have done, which i will note at the end of each section.




    I am posting this here as when I have been researching and testing this issue for the past many days this is the top result that has come back consistently, so hopefully this gets the message out to those in need.




    To reiterate for clarity: The issue is that with a shutdown or restart of the OMV server virtual machines (VM) are not being shut down properly and end up in an aborted state and run the risk of potentially get corrupted/unusable.




    The determined cause of the issue: The system is terminating the virtualbox kernel on shutdown/reboot before all of the machines states can be saved, resulting in some or none of the VM's stopping correctly.




    To note from original post: The methods of saving the VM state using VBoxManage at system shutdown and reboot have already been implemented in the default install of the virtualbox extra plugin as of this writing. It is this implementation that needs a bit of tweaking.




    The Issue




    Note: This requires some knowledge of systemd and how it all works. There will be some explanation at the end but not much. So read up on that if needed.




    The file to locate and edit: /lib/systemd/system/phpvirtualbox-machines@.service




    How the file should look from default install:


    [Unit]

    Description=PhpVirtualBox - start and save machines on boot and shutdown for user %I

    [Service]

    Type=oneshot

    ExecStart=/usr/bin/phpvirtualbox-manage-vms --start-vms

    ExecStop=/usr/bin/phpvirtualbox-manage-vms --save-vms

    RemainAfterExit=true

    User=%i

    Group=vboxusers

    [Install]

    WantedBy=multi-user.target




    What will the above do: when executed, either start auto start marked VM's or save the state of the vm's on shutdown/reboot. The " %I and%i " will be replaces by vbox as verified by the logs, so they work fine.




    The issue: It has no directions regarding what order it should be run in with everything else the system is doing during shutdown.




    The Solution




    How to fix: In this file, add in systemd command statements like "Wanted=" and "After=" among others to ensure that a) the process executes at the right time on both start and shutdown events and b)that the system allows it to complete without viciously chopping it off at the knees in the middle of execution.




    Example of my fixed file:


    [Unit]

    Description=PhpVirtualBox - Start and Save machines on Boot and Shutdown for user %I

    Wants=zfs-mount.service smbd.service nut-monitor.service

    Requires=virtualbox-web.service virtualbox.service

    After=zfs-mount.service network.target auditd.service zfs.target smbd.service virtualbox-web.service nut-monitor.service virtualbox.service

    RequiresMountsFor=/RAIDZ2/VirtualMachines/

    [Service]

    Type=oneshot

    ExecStart=/usr/bin/phpvirtualbox-manage-vms --start-vms

    ExecStop=/usr/bin/phpvirtualbox-manage-vms --save-vms

    RemainAfterExit=true

    User=vbox

    Group=vboxusers

    KillMode=none

    [Install]

    WantedBy=multi-user.target



    What I did:


    In UNIT section


    Added the "Wants=" section to indicate the services that really should be started before this service, but don't have to be. (nut service is there since it starts late on boot, and helps ensure UPS functionality)


    Added the "Requires=" section for the services that MUST be started before this one. (nut should probably be here too instead of wants, your choice)


    Added the "After=" section to instruct this service to only start after those have started.


    Added "RequiresMountsFor=" added this for OCD factor, seemed to help ensure the mount stays up until the operation completes. Easily broken by the system's shutdown procedure and probably not necessary.




    In SERVICE section


    Added "KillMode=none" to instruct the system that until this service completes it's tasks, it will not be killed (Think Gandalf vs Balrog if you need a LOTR reference for it)




    In regards to the "KillMode=none", that does not mean it is invincible. if the service the task relies on or the mount the task is using is removed in mid-process, the task immediately fails and is killed anyway cause it is "done".



    IMPORTANT



    You should probably also edit the /lib/systemd/system/virtualbox-web.service and add similar commands to the Unit section. The commands I added are listed below:


    [Unit]

    Description=VirtualBox Web Service

    Before=phpvirtualbox-machines@vbox.service

    After=virtualbox.service




    The "Before=" command will ensure the web interface is up before the machines start up from their saved state. The "After=" command ensures that the virtualbox kernel has been successfully loaded before the web interface starts. The "After=" could probably be replaced with a "Required=", but seems to work either way.




    And that's it! After applying these changes I have no problem doing multiple restarts of the server and having the running virtual machines that are set to manual appear in the web interface as saved and the ones that start automatically do so without any shutdown errors.




    TL;DR You're lazy. Go back and read it cause it takes some thought and logic to apply this if you need to get this fixed.




    That's all from me. I know it is a ramble but then again if this was an easy fix it would have still been a problem.




    -LAN

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!