• Recent
  • Unsolved
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Register
  • Login
  • Recent
  • Unsolved
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Register
  • Login

Capture/Deploy to target computers using Intel Rapid Storage (onboard) RAID

Scheduled Pinned Locked Moved
Tutorials
3
6
5.5k
Loading More Posts
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • G
    george1421 Moderator
    last edited by george1421 Jun 22, 2016, 6:57 PM Jun 23, 2016, 12:00 AM

    Part 1 (The Back story)

    FOG has the built in capabilities to talk to almost all direct attached storage media. One caveat to that is storage media that is behind some type of storage (RAID) controllers. Since FOG (more precisely FOS) is targeted for workstation capture/deployment the FOS engine has limited support for every flavor of RAID storage controllers. We have to remember that the FOS engine is a customized high performance linux operating system developed by the FOG Developers specifically for imaging. The FOS engine does not support the multitude of hardware that a commercial linux operating system might. But within the desktop/workstation realm FOS does support the Intel Rapid Storage (onboard) RAID controllers. These RAID controllers are typically found on the mid range desktop targeted at the workstation class market. I’ve been known to reference this class of computers with a snobbish reference of “fake RAIDs”. In reality a more accurate description would be hardware enhanced software raid. These Intel onboard raids are typically referenced by their ICHXX chipset design that offer several different RAID designs. http://www.intel.com/content/www/us/en/support/boards-and-kits/000005807.html

    FOG typically references local storage through its built in storage drivers. These drivers will typically connect to local storage through the /dev/sdX interface. As I stated before the FOS engine does support the Intel Rapid Store RAID as long as you do a little setup that tells the FOS engine to enable its build in raid functions. Once the RAID functionality has been enabled in the host configuration page you will be able to capture and deploy images to the storage located behind these “fake” RAID controllers. What is confusing is that without enabling the RAID functions in FOG, the FOS engine will see the disks as /dev/sdX and let you write to them, no problem. But, this kind of breaks your RAID setup, so I would advise against writing directly to the sata disks.

    Ref: Thread that started the discussion about FOG and onboard raid: https://forums.fogproject.org/topic/7851/intel-raid0-image-capture

    Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG!

    1 Reply Last reply Reply Quote 2
    • G
      george1421 Moderator
      last edited by george1421 Jun 22, 2016, 6:56 PM Jun 23, 2016, 12:00 AM

      Part 3 (When simple is not so simple)

      This process is much more involved since we need to locate the RAID driver interface (blind approach).

      1. The first thing we need to do is register this new target computer
      2. Using the FOG web gui navigate to this target computer’s host configuration page
      3. In the Host Kernel Arguments, enter mdraid=true
      4. Save the settings
      5. Schedule a debug deploy (you can choose capture or deploy it doesn’t matter, what we need is console access on the FOS engine).
      6. PXE boot the target computer into the debug console (you may have to press enter a few times to get past the wall of text)
      7. Once you are at the FOS command prompt key in the following: cat /proc/mdstat You should see a similar display as this
      # cat /proc/mdstat
      
      personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] [multipath] [faulty]
      md126 : active raid0 sda[1] sdb[0]
            156307456 blocks super external:/md127/0 128k chunks
      
      md127 : inactive sdb[1](S) sda[0](S)
            4856 blocks super external:imsm
      
      unused devices: <none>
      

      I’m not going to decode this output for you other than to say that the line that starts with md126 is the array we are search for. If your RAID controller has multiple arrays created, you should see them here. You will need to identify which array will be your target array. You can see that our target array is made up of members sda and sdb in a raid0 configuration. Remember mdf126 is the driver name we need.
      8. The next step is to query the raid driver/array for its status. The cat command above told the structure of the array, not the condition of the array. To check the condition of the array we’ll use the mdadm -D /dev/md126 command. Note that the array is referenced by its device driver name (/dev/md126). After you key in that command you should see an output similar to this

      # mdadm -D /dev/md126
      
      /dev/md126:
            Container : /dev/md/imsm0, member 0
           Raid Level : raid0
           Array Size : 156307456 (149.07 GiB 160.06 GB)
         Raid Devices : 2
        Total Devices : 2
      
                State : clean
       Active Devices : 2
      Working Devices : 2
       Failed Devices : 0
        Spare Devices : 0
      
           Chunk Size : 128K
      
      
                 UUID : d0202e14:9f7ca368:a44d0646:e4480443
          Number   Major   Minor   RaidDevice State
      

      The key values to note here is the array size, state and working devices. If everything looks good then continue onto the next step.
      9. So through this process we identified that the host primary disk (in this case) is /dev/md126.
      10. Back in the FOG web gui update the host information for this target computer, set Host Primary Disk: to the value we identified in step 9 (in this case /dev/md126)
      11. Save the settings
      12. Delete the pending debug task for this target system
      13. Schedule a real capture/deploy job (no debug mode this time)
      14. Key in reboot on the target computer in debug mode.
      15. PXE boot the target system and monitor its progress
      16. Done.

      Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG!

      1 Reply Last reply Reply Quote 3
      • G
        george1421 Moderator
        last edited by george1421 Jun 22, 2016, 6:56 PM Jun 23, 2016, 12:00 AM

        Part 2 (The simple setup)

        The setup is quite simple. In the Host configuration (for each system that uses the Intel onboard RAID controllers) you need to set two ( 2 ) values.

        The first settings we need to make is to turn on the RAID drivers in the FOS engine. We do that by passing a kernel parameter to the FOS engine when its sent from the FOG server to the target system. To do this add the following to the kernel arguments: mdraid=true.

        The second setting we need to make is to tell the FOS engine how to communicate with the RAID drivers/array. This is done by telling FOG that the primary disk is /dev/md126, not the default disk of /dev/sdX.

        So to recap, you just have to make these changes to each host configuration that has the intel RAID controllers enabled.

        Host Kernel Arguments: mdraid=true
        Host Primary Disk: /dev/md126
        

        NOTE: We've only tested this configuration on devices that have the intel onboard RAID controllers. These controllers and the linux RAID drivers set the first hard dive to device /dev/md126. The FOS engine may support more / different vendors RAID controllers that may use a different driver mount point (i.e. not /dev/md126). If you have a non-Intel onboard RAID controller follow Part 3 to see if you can get it to work with FOS.

        Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG!

        1 Reply Last reply Reply Quote 1
        • W
          Wayne Workman
          last edited by Jun 23, 2016, 1:11 AM

          #wiki worthy

          Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG!
          Daily Clean Installation Results:
          https://fogtesting.fogproject.us/
          FOG Reporting:
          https://fog-external-reporting-results.fogproject.us/

          1 Reply Last reply Reply Quote 1
          • G
            george1421 Moderator
            last edited by george1421 Jun 23, 2016, 6:28 PM Jun 24, 2016, 12:25 AM

            While this is a bit off-point of the article. I can say the FOS engine was able to capture and deploy to an LSI 9240-8i raid card (installed in the OptiPlex 780). This card presented itself as /dev/sda. mdadmin did not/could not see it.

            The RocketRraid 640L also worked with the FOS engine right out of the box. The Dell Perc 4DC card I had (which is also a LSI model variant) was not recognized by the FOS kernel. As they say, 2 out of 3 ain’t bad.

            I have read reports that the mdraid driver supports windows based software raid arrays (to what degree I’m not sure). I think next week if I have some time, it would be interesting to know. I can foresee a capture working like it normal, but a deploy should fail (since there won’t be an existing software raid pre-existing to put the image back to). You can establish a software raid with mdadmin (windows software raid, I’m not sure. But definitely a linux software raid is possible), but I think that would be a bit beyond the scope or intent of the FOG Project.

            Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG!

            1 Reply Last reply Reply Quote 0
            • S
              Sebastian Roth Moderator
              last edited by Jun 24, 2016, 10:40 AM

              Great work @george1421!

              Web GUI issue? Please check apache error (debian/ubuntu: /var/log/apache2/error.log, centos/fedora/rhel: /var/log/httpd/error_log) and php-fpm log (/var/log/php*-fpm.log)

              Please support FOG if you like it: https://wiki.fogproject.org/wiki/index.php/Support_FOG

              1 Reply Last reply Reply Quote 1
              • G george1421 referenced this topic on Jul 23, 2024, 10:34 PM
              • G george1421 referenced this topic on Aug 25, 2024, 9:37 PM
              • 1 / 1
              1 / 1
              • First post
                1/6
                Last post

              164

              Online

              12.0k

              Users

              17.3k

              Topics

              155.2k

              Posts
              Copyright © 2012-2024 FOG Project