Cloning and deploying multiple Linux machines with RAID1 OS drive setup

[samuelxhu]

I would like to use FOG to clone one Linux server (Centos 7) and deploy the image to tens of other servers with the same hardware. With single disk OS (operating system) drive, it works perfect. Thanks a lot for all you doing such a great project.

However, I want all my servers to use a RAID1 OS drive setup (almost all motherboard support SATA RAID1 for booting), to improve UP time in case one disk fails. For the moment, I can use FOG to clone an image from RAID1 boot disks and to restore the image to itself, BUT not able to deploy the image to other machines with the same hardware setup.

Is it possible to support this feature to FOG project?

[George1422]

The short answer is yes, and no, but mostly yes. I have a someone (gosh) old tutorial on the FOG forum that talks about doing this with the intel built in RAID controller here: https://forums.fogproject.org/topic/7882/capture-deploy-to-target-computers-using-intel-rapid-storage-onboard-raid

In short the intel raid controller presents both the native disks and the raid disks to the OS. What you need to do is interact with only the virtual raid disk during imaging. This holds true for the fake raid as well as traditional HBA raid controllers (but the HBAs typically hide the physical disks from the OS). So when you capture or deploy to the systems that have this intel raid sestup you need to image through /dev/md127 (or what ever its mounted as) instead of /dev/sda . FOG will surely image /dev/sda without problem, but it will break your mirror.

[samuelxhu]

Hi, George,

Thanks a lot. I will try the method, and hope to get it through.

best regards,

Samuel

On Fri, Jun 19, 2020 at 10:41 PM George1422 notifications@github.com wrote:

The short answer is yes, and no, but mostly yes. I have a someone (gosh) old tutorial on the FOG forum that talks about doing this with the intel built in RAID controller here: https://forums.fogproject.org/topic/7882/capture-deploy-to-target-computers-using-intel-rapid-storage-onboard-raid

In short the intel raid controller presents both the native disks and the raid disks to the OS. What you need to do is interact with only the virtual raid disk during imaging. This holds true for the fake raid as well as traditional HBA raid controllers (but the HBAs typically hide the physical disks from the OS). So when you capture or deploy to the systems that have this intel raid sestup you need to image through /dev/md127 (or what ever its mounted as) instead of /dev/sda . FOG will surely image /dev/sda without problem, but it will break your mirror.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/FOGProject/fogproject/issues/392#issuecomment-646852966, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACYMCALFXDSFMTUJNFBEVITRXPEPZANCNFSM4OC3Z5FQ .

[samuelxhu]

Dear George,

I followed your guidelines, and was able to use FOG to capture RAID OS from one machine, and restore it back, but unfortunately, when deploying to other machines, the process finished seemingly OK, but the machines do not boot, see attached file for details.

What could be the problem? or i missed something?

thanks a lot for your help,

samuel

On Fri, Jun 19, 2020 at 10:41 PM George1422 notifications@github.com wrote:

The short answer is yes, and no, but mostly yes. I have a someone (gosh) old tutorial on the FOG forum that talks about doing this with the intel built in RAID controller here: https://forums.fogproject.org/topic/7882/capture-deploy-to-target-computers-using-intel-rapid-storage-onboard-raid

In short the intel raid controller presents both the native disks and the raid disks to the OS. What you need to do is interact with only the virtual raid disk during imaging. This holds true for the fake raid as well as traditional HBA raid controllers (but the HBAs typically hide the physical disks from the OS). So when you capture or deploy to the systems that have this intel raid sestup you need to image through /dev/md127 (or what ever its mounted as) instead of /dev/sda . FOG will surely image /dev/sda without problem, but it will break your mirror.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/FOGProject/fogproject/issues/392#issuecomment-646852966, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACYMCALFXDSFMTUJNFBEVITRXPEPZANCNFSM4OC3Z5FQ .

[George1422]

make sure you define /dev/md126 (or what ever the source device is called) for the target disk on the destination computer. Otherwise FOG will default the image to /dev/sda (which is a valid physical disk) but what will happen is you will break the mirror because both sda and sdb won't be in sync, but if you write to the raid adapter md126 (or what ever its name) FOG will write to the array and the data on both disks will be sync'd

Its an extra step you need to do because the intel array presents both the raid disk and the individual disks to the target OS. This is unlike a traditional HBA raid controller where it only presents the logical raid disk to the target OS.

[George1422]

Before you reimage the disk using the method previously, go into the raid configuration and confirm the array is broken. The array manager software will tell you this. If so delete the disk array and recreate it to get everything back in sync and then redeploy to the virtual array adapter this time and not the physical disks.

[samuelxhu]

Dear Geoge,

Thanks a lot for your help, and i feel almost get there but still got stuck at the last step.

I was able to set a machine A with mirrored OS on /dev/md126, then use FOG to capture the image; on another machine B, i first created a mirrored disk /dev/md126, and was able to use FOG to clone the image onto machine B. From the command line, it shows that the clone process finished successfully. However, when booting machine B, it fails by saying not find the boot disk...

I then did another test as follows: I use FOG to restore the captured image back to machine A, and the machine can boot successfully.

It looks to me that, the captured image may have a UUID which corresponds to machine A, and thus when the image was restored to A, it works, but when cloned to machine B, it fails because of the unmatched UUID. I may be wrong but this is my guess...

What do you think? OR any new ideas i could try?

best regards,

samuel

On Sat, Jun 27, 2020 at 4:44 PM George1422 notifications@github.com wrote:

Before you reimage the disk using the method previously, go into the raid configuration and confirm the array is broken. The array manager software will tell you this. If so delete the disk array and recreate it to get everything back in sync and then redeploy to the virtual array adapter this time and not the physical disks.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/FOGProject/fogproject/issues/392#issuecomment-650569783, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACYMCAMNSPYWVK6S7MA5ILDRYYAVBANCNFSM4OC3Z5FQ .

[George1422]

I don't have an answer for you on the UUID part. One thought would be to move away from uuid mapping of the partitions and go back to static or label mapping of the partitions. This will need to be done on the source system before you capture it. Make sure the source image boots correctly when changing the mapping source. Also when you capture, do it to a new image in fog so that you can use the existing image as a backup in case something happens to the mother/golden/reference computer while switching over mapping sources.

[samuelxhu]

Dear Geoge,

With your suggestion on switching grub uuid to md0, we can now clone an image from RAID and massively deploy the image to multiple machines at the same time. Thanks a lot for your help.

Yet another question, I have a OS drive 240GB, but only used about 80GB, and work with Centos 7, is it possible to use FOG to create an image, and deploy it to a smaller disk drive, say 120GB?

best regards,

samuel

On Fri, Jul 3, 2020 at 4:24 PM George1422 notifications@github.com wrote:

I don't have an answer for you on the UUID part. One thought would be to move away from uuid mapping of the partitions and go back to static or label mapping of the partitions. This will need to be done on the source system before you capture it. Make sure the source image boots correctly when changing the mapping source. Also when you capture, do it to a new image in fog so that you can use the existing image as a backup in case something happens to the mother/golden/reference computer while switching over mapping sources.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/FOGProject/fogproject/issues/392#issuecomment-653572417, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACYMCAMVYHTBVRKFOLTKJ33RZXS25ANCNFSM4OC3Z5FQ .

[George1422]

The answer is it depends. If your Centos 7 uses LVM (typically yes by default) then the answer is NO. If Centos 7 disk uses standard partitions then the answer is YES. At the moment FOG can't step into an LVM volume to resize the logical volumes. It is on the roadmap for FOG, but it is not available today. So just as with the UUID changes, if you change the linux disk partitions to standard partitions then FOG can resize the disks to a smaller target disk size.