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

[george1421]

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

[george1421]

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.

[george1421]

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.

[Wayne Workman]

#wiki worthy

[george1421]

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.

[Sebastian Roth]

Great work @george1421!