Deployment stuck at x percentage
-
@george1421 The 10 pcs getting all the same image, but through the normal deployment. It would be still better to use multicast deploying in that case?
Edit: I tried the multicast for one group now, they starting the Partclone part but don’t start the deplayoment. As I seen the FOG server and the client pcs has to be in the same VLAN for multicast? That’s not our case, they have different ones.
-
@sega said in Deployment stuck at x percentage:
As I seen the FOG server and the client pcs has to be in the same VLAN for multicast? That’s not our case, they have different ones.
Generally the fog server and target computers should be on the same vlan for multicasting to work. It can work if you have a igmp-proxy server setup on your router between the vlans. Multicast traffic don’t normally pass a normal router.
But now in your network you’ve introduced another choke point in your router must be able to handle the load of these 10 systems being imaged simultaneously. As I said you can flood a 1GbE link with between 2-3 simultaneous unicast images. Also on your fog server, is the image stored on what media ssd or hdd? If hdd, how many spindles are being used? That will have an impact on performance too if its hdd.
-
@george1421
We have the following structure:- FOG Server on office VLAN
- 3 rooms with separate VLANs each (because they have different rights in the network, but all can access the FOG server)
- FOG server is running on the VM but on ssd, if I’m correct
- All are linked with aruba managed switches
Somewhere I read that it’s possible to have it with different VLANs if the udp stream is forwarded.
The weird thing is: we didn’t had the problems in the past… so yea something in the network could be the problem. -
This post is deleted! -
The current status: FOG and client pc in different VLANs. We have managed switches where the streams should be forwarded (we don’t managed them ourselves). We started a multicast session for 6 pcs. They are all going into the Partclone windows, but don’t start the deployment process.
In the active task tab I have once (under “Active Tasks”) 6 task (for each pc one) and under “Active Multicast Tasks” I have one for the whole group. State is in “In-Progess” and status is “0”.
edit: I somehow can’t post the logs because they are marked as spam
-
@sega if you want more “speedy” unicast I would suggest setting your storage nodes queue limit to 2 or three.
I know this sounds low and all but it’d be better to have 10 systems imaged in 30 - 45 minutes than to have 10 systems imaged in 2-3 hours.
Unless you can get multicast to work, I think this is your best approach. Another method, though unrealistic, would be to setup multiple storage nodes in the same group (each with only 2 or 3 per vlan) and possible the location plugin to designate the vlan systems to their respective vlan ip groups.
Ultimately keeping things as they currently are is not going to magically work the next time you try again.
-
@sega if you can post logs to paste bin and send the link in the forums that may work as well.
-
That’s a good idea to reduce the limit. But our priority will be to get multicast to work. I’m pretty sure somewhere in our network structure is the error why it’s not working yet.
Since we have to do that multiply times in a week, reducing the time would be great.And here are the logs: https://pastebin.com/JQadkbZ0
-
@sega Multicasting should work correctly if the fog server and target computers are on the same subnet. You said that may not be the case. For multicasting to work your router has to support forwarding multicast packets or your router or some device that has access to all of the vlans need to be running an igmp-proxy. This is akin to what a dhcp-helper/relay is to dhcp. You should see exactly what you are seeing if the network doesn’t support multicasting. The FOS Engine is started using unicast messaging, the partcone part is where the multicast stream really starts moving data.
-
Yea, it’s not possible having the FOG and the target pcs on the same subnet. Our switches have the option active igmp. And I see a warning on the switches that they get a v3 query but the device is just configured for igmp v2. But that I have to look with our service provider.
-
We just saw our switches can’t process v3… Is it possible to change a setting that FOG uses the v2 of igmp?
-
@sega https://www.udpcast.linux.lu/hints.html
I think this may tell you more?
We don’t control what “version” your switches can/cannot allow?
-
I mean is there a setting in FOG where I can change it or does FOG just uses the version that is available?
-
@sega I think that’s where I’m confused.
ALl FOG does is start a software that sends packets. How those packets traverse your network is independent of that (from what I can tell).
Layer 2/Layer 3.
I think you’d want to look into something IGMP Snooping or something for V2 functionality?
-
@Tom-Elliott
Alright, that was the point where I was confused too. Now I understood. -
@sega I don’t know enough to answer your question intelligently.
I can tell you that for multicast imaging FOG uses the linux commands udpsend and udpreceive.
I don’t see any command line switches to pick which igmp mode is being used.
https://users.soe.ucsc.edu/~kent/test/udpcast.htmlI can say its rare that there is ever a question on the revision of igmp being used.
