Multicasting
-
@george1421 The multicast logs showed that the job was complete, so the machines sit there waiting for it to start - they are on the same screen as when they are waiting for all machines to be ready prior to a job starting.
“Multicast is a great bandwidth saver but it also relies on the networking infrastructure to be setup well. Also if you use multicasting ensure you have igmp snooping enabled for the VLAN where you need to multicast on.”
This is an entirely segregated network using unmanaged switches. The PC we use for controlling FOG has 2 NIC’s to access the corporate network and FOG.
Just got another pallet load of machines to do, so I’ll let you know how I get on with these.
-
Just so you have the entire picture.
Hosts are HP440 Probook G7 machines. I go into BIOS to start with and make the following changes:
- Boot sequence to IPv4 nic
- Disable fast boot
- Disable Secure boot
- Set WOL to network boot
- Allow host to quick register
- Reboot and power off to await for WOL with multicast session
- Open FOG, go to groups and select group of hosts just added
- click Multicast icon and click Task now with WOL selected and schedule immediately.
- Machines all fire up simultaneously and being the multicast session.
- After deployment completes, they reboot and boot from network again. This takes us back to the deploy image screen as if they are all waiting for the other hosts to join the session before starting.
I have another 8 of these machines to do, so I will try a couple with various settings to see if I can stop the occurrence, or if it does it regardless.
I’ll let you know how I get on.
-
@Goll420 said in Multicasting:
Machines all fire up simultaneously and being the multicast session.
After deployment completes, they reboot and boot from network again. This takes us back to the deploy image screen as if they are all waiting for the other hosts to join the session before starting.
Right in here is when the FOG server needs to be told, “hey we are all done”, so the task on the fog server clears and when the targets reboot they just boot into the OS. That task not closing out on the fog server is why the clients are getting stuck.
-
@george1421 I’ve set the remaining 8 going now, but I omitted the WOL part and started them manually. See if it makes any difference.
I never said before that this was a RAW image as the drive was encrypted with Bit Locker. I noticed an error on the end of the deployment on the hosts and then the reboot.
The tasks still show spinning and the hosts have all gone back to the deployment screen amd sitting there waiting for it to begin.
Logs show that the Multicast has finished, but I believe it’s this error that is stopping it progressing any further.
-
The next bunch of machines I have to do are not using Bit Locker, so I will see how I get on with those.
-
@george1421 @Goll420 I have worked on the multicast tasking/finishing code just before the release of FOG 1.5.9 because there were issues when you schedule a test not via the group but by creating a named multicast session. I thought I had this all tested and working correctly but I might be wrong. I will need to get a test setup ready and see if I can replicate the issue as described.
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
-
I’ve just done another 24 machines using Multicast which worked beautifully with the deployment, done in under 4 mins! These did not rejoin the session after completion, however then I hit another small issue as rEFInd would not proceed any further than initializing.
If I removed the network cable and rebooted, they went into Windows perfectly.
I also tried with SANBOOT but then the FOG client would countdown from 10 and just loop to itself (go back to 10).
Not sure if this is related. These machines were HP 430 G7’s so will be on the same BIOS as the 440’s.
-
@Goll420 said in Multicasting:
I also tried with SANBOOT but then the FOG client would countdown from 10 and just loop to itself (go back to 10).
I might be getting my threads mixed up, but if these are uefi systems SANBOOT exit mode should not work because its a BIOS exit mode. You need to use rEFInd as an exit mode for uefi systems. Under the global settings, they should be defaulted to bios exit: SANBOOT and uefi exit: REFIND
Its great that you have the multicast working. When it works it works really well, when it doesn’t then its the infrastructure that needs to be tweaked. Mutlicast is very dependant on your network stack than unicast (single deployment) imaging. I know some universities that can reimage their entire computer lab between classes. They can jump between ubuntu and windows for 30 computers in just a few minutes.
-
@george1421 Sorry George, I was just reading the other thread in regards to refind not working too so I can see how they could be muddled up.
Yes this is the default setting, however refind just doesn’t go past Initializing.
I did some Dynabooks last week (dreadful machines) and refind worked just fine and dandy with those, but that was using unicast. Not sure if that’s related or not but wanted to give the full picture.
-
Updating the binary has worked fine, they are now booting into Windows when the client menu times out.
So back to the initial problem, it’s seems to be a problem when using RAW images or drives with Bit Locker enabled.
-
@Goll420 said in Multicasting:
Updating the binary has worked fine,
Updating the binaries to what version? 0.11.0?
Bitlocker:
Well bitlocker, I was wondering why/how you expected a bitlocker protected volume from one computer to be useful on a second computer. Its kind of the point of full disk encryption.
-
@george1421 said in Multicasting:
Updating the binaries to what version? 0.11.0?
Bitlocker:
Well bitlocker, I was wondering why/how you expected a bitlocker protected volume from one computer to be useful on a second computer. Its kind of the point of full disk encryption.
Yes to 0.11.0
I totally agree, and I did suggest to the guy who prepared the image to remove it; he said he had done but FOG still found the disk to be encrypted.
Anyhoo, thanks for your help with all of this. The software and support from you guys is marvellous.
-
-
@george1421 said in Multicasting:
@Goll420 bitlocker ref: https://forums.fogproject.org/topic/10824/image-upload-deploy-taking-a-long-time/15
Very interesting, thank you. I imagine this was the problem for these machines.
-
@Goll420 said in Multicasting:
I’ve set the remaining 8 going now, but I omitted the WOL part and started them manually. See if it makes any difference.
I never said before that this was a RAW image as the drive was encrypted with Bit Locker. I noticed an error on the end of the deployment on the hosts and then the reboot.
The tasks still show spinning and the hosts have all gone back to the deployment screen amd sitting there waiting for it to begin.
Logs show that the Multicast has finished, but I believe it’s this error that is stopping it progressing any further.Sorry for the long delay. Time is sparse at the moment and digging into such things usually takes a bit. I just tested multicasting several times and they all worked perfectly fine finishing the task. I am fairly sure that what you describe is caused by some kind of “checkout” issue where hosts are don’t properly report back to the FOG server when finishing the multicast session. So it would be helpful to know what error message you see at the end. If you see this happening again you might want to take a look at the Apache and PHP logs (see my signature) on the FOG server to see if errors are reported there as well.
Image type being RAW shouldn’t play a role. As far as I can test and know the code this does not seem to be a general issue in the multicast code I reckon.
