Multicasting
-
Hello folks
I got multicast working it would seem, it certainly reduces the bandwidth used comparatively to unicast when doing a large chunk of machines.
However, after the image has deployed, the machines are booting up again and going back to the multicast screen and waiting for the image. In tasks, the hosts all show with the task queued icon spinning round but no progress bar.
If I shut a host down and boot to the local disk, the image has deployed fine but it doesn’t seem to update in FOG?
Also, the host information doesn’t update in FOG, showing the date the image was deployed.
I start the task by quick registering the hosts and adding them to a group. Once the hosts are powered off i start the task clicking the multicast icon next to the group and waking them all from LAN. This fires them up perfectly fine and they begin but after the finish, they reboot and go back into multicast mode where they are waiting for the cast to begin; which of course it doesn’t as it’s finished.
Ubuntu 20.04 VM with FOG 1.5.9
-
Will you check to see if the task is still running on the FOG server. This is done by clicking on the Tasks icon.
-
@george1421 Yes it does, it sits with the wheel spinning but no progress. The screen on the host looks like it’s waiting for other hosts to join the session before it can start.
-
@Goll420 Sorry I did not explain correctly. On the FOG Server in the WebUI there is a Tasks menu item. When you select that is there a task still running? If it is you can terminate it here so the computers will boot correctly. Then we need to identify why that task isn’t closing. Did all of the computers that should have been installed complete?
-
@george1421 Hi George
Yes you explained it correctly, and yes the task appears to be still running when this occurs. I cancel the task and then reboot the machines and find the image has been deployed fine.
I don’t have any machines on the bench at the moment, but when I do I will take some screenshots.
-
@Goll420 said in Multicasting:
Yes you explained it correctly, and yes the task appears to be still running when this occurs.
Ok if this is the case and ALL target computers have completed the deployment then we will have to get the developers to look at the code that releases the task when the last system completes the deployment. This might because one of the systems didn’t wol correctly or it hung during image deployment. Because this signal is not telling the FOG server that everyone is done.
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.
-
@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.
