• [6.10.3] Array Start does not trigger VM Autostart


    hawihoney
    • Closed Minor

    There's a difference between Autostart on Docker Container page and Autostart on VM page.

     

    Consider a stopped array: Some Docker Containers are marked with Autostart and some VMs are marked with Autostart.

     

    Now start the array: The Docker Containers marked with Autostart will start. The VMs marked with Autostart will NOT start.

     




    User Feedback

    Recommended Comments

    Quote

    The VMs marked with Autostart will NOT start.

    This is done on purpose, sometimes users pass-through the wrong device to a VM and it can crash Unraid, or for example lose a controller, this way you can disable array auto-start, start the array and correct the VM settings.

    Link to comment
    1 hour ago, JorgeB said:

    This is done on purpose

     

    What does Autostart on VM page do then? Perhaps I don't understand your answer:

     

    1,) Autostart on VM page does not Autostart VMs. Why is this option available?

     

    2.) Autostart on VM page does not Autostart VMs on Array Start, but does work .... (when?)

     

    Whatever it is: "Autostart" on two different pages (Docker, VM) has two different meanings then. IMHO this is a bad GUI descision.

     

    *** EDIT *** I'm talking about these two settings:

    Clipboard01.jpg.3abd3a481bd3aecd8c9c44a3c35b8d58.jpg

     

    Clipboard02.jpg.f0ae0734c1ea15347ee242624c33a674.jpg

     

    How to reproduce:

    - On Settings > Disk Settings > Enable auto start --> Off

    - On Docker > [Container of your choice] > Autostart --> On]

    - On VM > [VM of your choice] > Autostart --> On

    - Stop a running Array (no reboot, no shutdown, simply stop array)

    - Start array

    --> Docker Containers with Autostart=On will start

    --> VMs with Autostart=On will NOT start

     

    Edited by hawihoney
    Link to comment
    4 hours ago, hawihoney said:

    1,) Autostart on VM page does not Autostart VMs. Why is this option available?

    In my experience this works if the array is auto started on boot.

    Link to comment
    4 hours ago, hawihoney said:

    What does Autostart on VM page do then?

    It will autostart the VMs at first array start if array autostart is enabled.

    Link to comment
    1 hour ago, itimpi said:

    In my experience this works if the array is auto started on boot.

     

    58 minutes ago, JorgeB said:

    It will autostart the VMs at first array start if array autostart is enabled.

     

    So "Autostart VM" will only work if "Autostart Array" is enabled during a boot process.

     

    But "Autostart VM" will not work if "Autostart Array" is disabled, the machine is already booted and the Array is started afterwards.

     

    So the "Autostart" options on the "VM tab" are bound to the "Autostart Array" AND the VM - with the "Autostart Array" being the main factor. This differs from the "Autostart" option on the "Docker tab" that does not care about "Autostart Array" at all.

     

    Got it, very confusing, but got it.

     

    IMHO, this should be mentioned on the "VM page". Some hours were gone without running VMs when I finally found out that my VMs with Autostart were not started. After that I scanned thru all logs this morning because I thought the VMs had errors during start.

     

    If an option suggests an Autostart it should not be bound to a different option behind the scene.

     

    Consider what I did: I stopped the array (no shutdown, no reboot, simply stop) to replace a disk. After that I started the array again and my VMs did not start. Guess nobody would expect that in this situation.

     

    • Like 1
    Link to comment
    1 hour ago, hawihoney said:

    But "Autostart VM" will not work if "Autostart Array" is disabled, the machine is already booted and the Array is started afterwards.

    No - just checked and if this is the first start of the array after booting then the VM IS auto started.

    Link to comment
    1 hour ago, itimpi said:

    No

     

    So Unraid works different in your environment than in mine.

     

    Trust me, I'm working long enough with Unraid to know what I do and what settings are in place since years (I guess).

     

    The machine was running since monday (upgrade from 6.10.2 to 6.10.3). "Autostart Array" was off as always. Today I had to replace a disk in the array. I manually stopped all running VMs, manually stopped all running Docker Containers, stopped the array, replaced the disk, started the array to rebuild the replacement disk and the VMs, marked with "Autostart", did not start. That's all.

     

    In the meantime I've set "Autostart Array" to on, so that my VMs honor the "Autostart VM" setting in the future.

     

    I'm not satisfied but I will close that bug. Seems that it is intendent behaviour.

     

    Link to comment
    13 minutes ago, hawihoney said:

    Today I had to replace a disk in the array. I manually stopped all running VMs, manually stopped all running Docker Containers, stopped the array, replaced the disk, started the array to rebuild the replacement disk and the VMs, marked with "Autostart", did not start

    Note I said FIRST start of the array after booting.     You did not mention rebooting in the above sequence.

    Link to comment

    And you think that this logic avarage users like me will understand? There's an option "Autostart VM" that only works if another option "Autostart Array" is set. But only if it is a first start of the array after boot, not on a second or later start of the array.

     

    Please take a step back and look at this from a distance. I already gave up and closed because I don't see that anybody understands that this option "Autostart VM" will be source of confusion in the future. It will NOT autostart VMs always and it works different than other autostart options (e.g. Autostart Docker Container).

     

    I'm not here to change the logic, I was here to make it more transparent.

     

    Let's stop here. I already closed.

     

    Link to comment
    3 minutes ago, hawihoney said:

    And you think that this logic avarage users like me will understand? There's an option "Autostart VM" that only works if another option "Autostart Array" is set. But only if it is a first start of the array after boot, not on a second or later start of the array.

    I tested with Autostart of the array set to No, and the VM still autostarted when I manually started the array.   It appears that it only works once until you next reboot.

    Link to comment
    Quote

    I tested with Autostart of the array set to No, and the VM still autostarted when I manually started the array.   It appears that it only works once until you next reboot.

     

    That's what I described and said:

     

    Autostart Array=off, boot, start Array manually --> Autostart VM works.

     

    Now stop Array, start Array, Autostart VM does not work --> that was my problem and the reason for this bug report.

     

    Simply confusing, not documented on VM page and I still don't see a reason for that.

     

    Autostart means Autostart. Don't change that. Just my two cents.

     

    Link to comment
    9 hours ago, itimpi said:

    I tested with Autostart of the array set to No, and the VM still autostarted when I manually started the array.   It appears that it only works once until you next reboot.

     

    To be honest and if this is true don't see the point of VM autostart not always working, IIRC and like mentioned above this was initially done on purpose so any user could fix a VM that was crashing Unraid, if VM autostart was on and it always autostarts after the array start it would make fixing it very difficult, since AFAIK there's no easy was to disable VM autostart by editing some config file, so the array autostarts, VMs autostart, Unraid crashes, user reboots, array autostarts, VMs autostart and Unraid crashes, and so on, the solution was disabling array autostart, and that can be done by editing a config file, the VMs would not start automatically allowing the user to edit the VM, if they still autostart at first array start it's not possible to do that, so if this is the current behavior might as well always auto-start the VMs.

    Link to comment

    Got that. So my VMs only autostart after an Unraid upgrade. That's what I know now.

     

    My servers only boot for Unraid updates - they run 365/24. Alle Disk Additions or Replacements can be done with a stopped array without shutdown or reboot. With the "Autostart Array=no" (this is IMHO more important) the manual array start after Disk Replacements will trigger VM autostart only once and then never again until next boot.

     

    That's what I learned and that's what I have to live with ...

     

    Edited by hawihoney
    Link to comment


    Join the conversation

    You can post now and register later. If you have an account, sign in now to post with your account.
    Note: Your post will require moderator approval before it will be visible.

    Guest
    Add a comment...

    ×   Pasted as rich text.   Restore formatting

      Only 75 emoji are allowed.

    ×   Your link has been automatically embedded.   Display as a link instead

    ×   Your previous content has been restored.   Clear editor

    ×   You cannot paste images directly. Upload or insert images from URL.


  • Status Definitions

     

    Open = Under consideration.

     

    Solved = The issue has been resolved.

     

    Solved version = The issue has been resolved in the indicated release version.

     

    Closed = Feedback or opinion better posted on our forum for discussion. Also for reports we cannot reproduce or need more information. In this case just add a comment and we will review it again.

     

    Retest = Please retest in latest release.


    Priority Definitions

     

    Minor = Something not working correctly.

     

    Urgent = Server crash, data loss, or other showstopper.

     

    Annoyance = Doesn't affect functionality but should be fixed.

     

    Other = Announcement or other non-issue.