SnapRAID- HDD failure simulation running on Virtual Box v6.1<Cannot Be Done only on Real Hardware>

    • OMV 5.x (beta)
    • Resolved

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

    • SnapRAID- HDD failure simulation running on Virtual Box v6.1<Cannot Be Done only on Real Hardware>

      Hi,

      I am running OMV 5 in Virtual Box v6.1 for testing out SnapRAID.

      So far I have tested out UNDELETE function is working, except that you have to bear in mind,
      reading from the Snapraid Manual from: snapraid.it/manual that permissions on
      the files cannot be recovered to the original state.

      Luckily there is a way to solve this problem, by reading @wolf8auer pdf manual:
      forum.openmediavault.org/index…reconnect-shared-folders/

      However, I stuck in trying out hard disk failure.........what happens if you experiencing a hard disk crashed.

      Or it is about to crash, but you have got a good spare drive to replace it.......

      I am testing a scenario where by a hard disk (virtual) has just died in a Virtual environment using Virtual Box v6.1.
      The purpose of this test, is to experience what I need to do if my data disk failed to boot.

      Say, virtual hard disk No.3 suddenly crashed, so to simulate this crash event, I detached VBdata3.vdi (virtual hard disk No.3)
      within VBox program.

      I created another virtual hard disk No.9 called: VBdata9.vdi, to replace the failed disk No.3.

      But when I boot up the system in VBox, OMV5 could not load. See diagram No.3.

      Thank you.

      The post was edited 3 times, last by wepee ().

    • I managed to get it to boot:
      1) type in my root password, at the last line: Give root password to maintenance.
      2) type in the command: mount -a, to mount all my HDDs
      2) type in the command: vi/etc/fstab
      3) Press "insert" key and begin to edit
      Within fstab file, I commented out using # to hard disk No.3 to unmount it
      4) type in :wq and press enter to save and exit vi editor.
      5) reboot the system.

      Now, I am stuck, Web GUI does not load.
    • wepee wrote:

      I managed to get it to boot:
      1) type in my root password, at the last line: Give root password to maintenance.
      2) type in the command: mount -a, to mount all my HDDs
      2) type in the command: vi/etc/fstab
      3) Press "insert" key and begin to edit
      Within fstab file, I commented out using # to hard disk No.3 to unmount it
      4) type in :wq and press enter to save and exit vi editor.
      5) reboot the system.

      Now, I am stuck, Web GUI does not load.
      I am trying to reverse the above action......
      I boot up in Recovery mode at GNU GRUB, but now when I try to edit fstab file,
      the OS is complaining that the file is a READ ONLY, I cannot edit the file, why?
    • I've experienced some of these issues in VB when dropping hard disks out of the overall line up, in RAID testing. Along with networking problems (running a sub-interface on a sub-interface) there are some interesting quirks when working with virtual hardware.

      In your case, if you can't get back into the GUI with the disk added back in, you might have to rebuild.
      The next time around, clone the VM before deleting or removing disk. (It saves a lot of time.) I'd do update-grub in any case to eliminate boot order problems which happen, even with virtual hardware.

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

    • crashtest wrote:

      I've experienced some of these issues in VB when dropping hard disks out of the overall line up, in RAID testing. Along with networking problems (running a sub-interface on a sub-interface) there are some interesting quirks when working with virtual hardware.
      You are talking about quirks..........would the outcome behave differently(than using a virtual hardware) if it happen using real hardware?
    • wepee wrote:

      You are talking about quirks..........would the outcome behave differently(than using a virtual hardware) if it happen using real hardware?
      Unfortunately, yes. I have found that if something works in a VM, it will work when using real hardware. The other way around, however, is not always true. Something that works on hardware, may not work in a VM.

      VM's are good for testing but the various packages have limitations. Virtual Box is OK for basic testing, but it falls short of a full simulation of hardware. (As you may or may not have noticed, virtual hard drives don't support SMART and other drive features and VB has networking limitations.)

      Sorry, I got the command bass ackwards. It's update-grub.
      (To prevent confusion, I'll need to retroactively edit previous posts.)
    • crashtest wrote:

      wepee wrote:

      You are talking about quirks..........would the outcome behave differently(than using a virtual hardware) if it happen using real hardware?
      Unfortunately, yes. I have found that if something works in a VM, it will work when using real hardware. The other way around, however, is not always true. Something that works on hardware, may not work in a VM.
      VM's are good for testing but the various packages have limitations. Virtual Box is OK for basic testing, but it falls short of a full simulation of hardware. (As you may or may not have noticed, virtual hard drives don't support SMART and other drive features and VB has networking limitations.)

      Sorry, I got the command bass ackwards. It's update-grub.
      (To prevent confusion, I'll need to retroactively edit previous posts.)
      Thanks for your quick response.

      Although, the command works this time: update-grub when I type reboot command, to reboot whole VB and run again,
      OMV still cannot load.

      OMV still complains about in emergency mode.

      See the picture attached below:
    • I am wondering......

      If I leave the virtual hard disk intact.

      Rebuild another new VB using OMV image file on clean new fresh virtual disk (.vdi)

      Next, slowing migrate all virtual hard disks to the new server.
      Except virtual hard disk no.3
      Replace a virtual hard disk no.9 -> wipe and format in EXT4

      Will this method work?
    • I really don't know. I've never tried anything like that.

      And I really don't understand "why" OMV will boot up in Virtual Box, with a disk missing, and not log into the GUI. (Assumes that the GUI will login with the disk in place.) Is the VM fully updated? It takes awhile to do it and it kind of seems pointless in a VM, but in this case the install should be undated to eliminate more variables.
      ____________________________________________________________

      As an idea - it won't hurt anything:
      You might simply move the disk (the .vdi file) to the folder of another VM, attach it in the 2nd VM, format it (maybe delete some contents, etc.), then move it back.

      The post was edited 2 times, last by crashtest: edit ().

    • @crashtest, you are right, I cannot rely fully Virtual Box to perform full simulation of hard disk failure.

      It behaves differently. Maybe I have to configure something to make it behave more like a real hardware, I suppose? :)

      I tested on my real OMV hardware, and guess what? It complained that it has detected some errors at the beginning in POST.

      after loading GRUB.

      But eventually on my real OMV hardware, I was able to boot as per normal load up OMV.

      It was able to load the OMV web interface (log in using a web browser). See the Picture below.

      CASE closed.

      Thank you!! Forum users who willing to read my thread and help me out.

      Conclusion: Guys don't try this at home (Virtual Box does not simulate Hard disk failure, as far as I know, unless
      someone may enlighten me otherwise) =O

      The post was edited 2 times, last by wepee ().

    • jollyrogr wrote:

      Something else to try - select the box to say that the drive is hot-pluggable?
      I tried this method again, set all my virtual drives to be hot-pluggable.
      All virtual disks fully connected and it was running as per original set up.

      booted up OMV in VB and once it has fully loaded and the console is prompting for ROOT and keying for PASSWORD.

      I went to setting in VB, detached virtual disk no.3, then I went and attached a new virtual disk no. 9.

      But eventually, OMV complained: ERROR message within WEB GUI and the connection was lost, sadly I was back to square one again.
      This method did not solve my problem.
    • The lesson here is, if it will work in a VM, it will work on real hardware (95% of the time). This is how I test new methods and approaches. It's a useful vetting tool. On the other hand, if it doesn't work in the VM that doesn't mean it won't work on real hardware.

      I have an old box I use for testing. Also, I've set up OMV on a USB stick and used a Windows Client for some tests (being careful not to tamper with the Win boot drive). This gets around the networking limitations for Docker tests. With a real machine, booting from a USB thumbdrive and using a handful of USB thumbdrives for data (you might need a USB hub), it might be possible to run your drive replacement test.

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