Weird issue with time taken to image
-
Hello all!
Recently moved FOG to a different subnet and in the process, I also updated FOG. I am having an issue now where imaging is taking a lot longer, specifically the partclone process.
Example is before, our base image would take about a minute to image. Now the process it taking about 15 minutes (even longer once we add a 2nd device to be imaged).
I’ve gone through quite a bit of troubleshooting and I am stuck at where the issue could be. I considered that it may be from the update (1.5.3 to 1.5.4) but I don’t see any posts.
Just looking for some input.
Current Versions:
FOG: 1.5.4
Kernel: 4.16.16 -
4.16 kernel has a bug where erasing MBR/GPT tables takes several minutes (instead of seconds). Change kernel to 4.15 version to address that.
Partclone speed is determined by several factors: connection speed, target CPU, target storage system, target RAM, server storage system, server CPU, server RAM.
-
@quazz The 4.16 bug I just haven’t downgraded to 4.15 yet. I’ve downgraded and just re-updated while I work on the new issue.
As for PartClone, the weird part is nothing has changed except for the FOG version and the subnet. Everything else has stayed the same.
-
@jemerson93 What exactly do you mean by changed to a different subnet? That could mean a lot. Can you verify that transfer speed between clients and server is still as high as in the old subnet? Speed tests?
-
@sebastian-roth Sorry for the late response. We currently have our work network being 192.168.1 and our lab network being 192.168.200. I went through the steps to re-statically assign FOG to the 2nd scope (completely different separate LAN).
I ran a LAN Transfer test and both tests came back relatively close together. Below will be those images. First image is the first network is was on when a base image would image in about a minute. Second image is our lab network where it is currently taking 12-15 minutes to image. Bandwidth tests had download a little lower on the 2nd network and upload extremely lower but I do not think that has a correlation when imaging.
-
Anyone have any further input? If I am correct partclone uses multicast. I don’t know if there is a way to check that. Pretty stumped on this.
-
@jemerson93 Partclone is the imaging medium, it doesn’t use multicast or unicast to perform its task. Partclone would work with a local file just as well as it does when we transfer the files over the network. How that information is transferred determines the "mode’ received (Multicast, Unicast).
-
@Tom-Elliott Gotcha.
Here is more of what I have found. I deployed a new FOG server (different IP and updated the DHCP Server) just to test that it wasn’t the server itself. Same issue with how long partclone is taking.
Something else I’ve noticed is that if I image a VM on the same host as FOG, it images fast again (most likely due to not being done over the network).
Currently we use Proxmox for hosting all of our VM’s and FOG.
So still the issue still seems that once the process hits partclone to image, it slows down. Network speeds seem fine and the firewall doesn’t seem to be blocking anything. I’ve checked the DHCP Server and nothing seems off. Kind of at a loss still.
I should also add that the image manager being used is Partclone Gzip
-
@jemerson93 Have you already tried using kernel version 4.15.2 as opposed to 4.16.6 and 4.17.0?
