Deployment starts fast but then it slows
I experience a problem when I want to deploy an image to a single Windows 7 PC.
I have created the image from another Windows 7 machine and it took like 1 hr and 20 min. The creation of the image was very straight forward and the speed was fixed between 1.4 GB and 1.5 GB per minute.
However, when I deploy an image, the speed starts with 1.4 GB per minute but then it slows dramatically to 300 MB or even 100 MB per minute.
I have checked the switch and both ports are full duplex with 1000 Mb.
I have also checked the bandwidth transmit of the server and it doesn’t seem to upload anything. I have checked the network history from the Ubuntu System Monitor and the upload traffic fluctuates between 0 bytes/sec until 5.5 Kb/sec.
Any help would be appreciated.
Hi Tom, thanks for your quick reply!
The PCs come actually with the 100 MB partition.
I will have a look at the documentation carefully and I will image not the entire disk but just the Windows 7 partition and see how it goes.
I will post my results after I’m done with the task.
I’m under the understanding of your setup. You basically received the systems with OS Pre-loaded on them. You’re trying to create the image based on what was originally sent to you.
Most times, I’d recommend performing a complete fresh install. This will set the partition 1 to the setup FOG prefers, (100MB first Partition).
This isn’t really necessary, but it just makes sure things work properly for your setup.
The main partition, which is that comes by default by these new HP PCs is the 457 GB but used is only 32 GB. The recovery partition is around 10 GB for recovery. The other PCs are still in their boxes and the idea would be to deploy Windows 7 with the necessary software. I could also change the partition and make it smaller but I don’t know if FOG edits partitions “on the fly”.
What I’m doing now is to read a documentation about “Implementing the FOG Cloning Solution with Universal Windows 7 Images”. I don’t know if this will work but at least I will give it a chance.
What is the size of the Hard drive?
As it’s being partitioned, chances are this drive is a 250GB drive?
The size you’re seeing on the server (29GB) means the compressed image is taking 29GB worth of space.
Factor in that Gzip compression/Pigz compression, usually compresses down to about 40-50% of the actual image data, this leads me to think your image size, when deployed to a machine, is actually around 60GB. Does this sound about right? This information is displayed on the Client during an upload/download task.
thanks you for your reply!
actually, the initial client has two partitions: the C: drive which has a size of 32 GB and a recovery partition which has a size of 8 GB. What I don’t understand is that the image that has been created of the C: drive is 192 GB! so I don’t know why it’s so big. I have used “Multiple Partition Image - All disks”. Maybe, as you said, this could be one of the reasons why it takes so slow.
I have also experienced that after completing the imaging process, the operating system (Windows 7) seems to work fine but the name of the machine has not been changed (I don’t know if I have to left the client always booting from network). I usually have to change the name, restart the machine and automatically runs CHKDSK to fix some problems.
The other observation that I have noticed is that when the deployment starts, at the beginning it says for some seconds that the HP Compaq 6300 is not supported.
Regarding your question about the kernel, is the server kernel? in that case, I’m using UBUNTU 13.10 Kernel 3.11.0-14
So in summary I think we need to figure out why the size of the image is so big (this is what is shown in the image process).
I have to add as well that the size of the /image/image_name/ folder is 29 GB. So I don’t know where the 192 GB come from.
Sorry for this long message
How big is the image you’re trying to deploy?
I’ve heard of slowdowns, usually with images over 50GB which seems, to me at least, an issue with NFS v3, rather than a problem you’ve performed.
It also could be the kernel you’re using. I had issue with kernels where upload would work, hang for about 10 secs, then work for about a minute, hang, and so on until complete. I didn’t have issues with deploy, but I know it was directly related to the kernel and have since corrected it in my latest kernel. Maybe see if this will help you?
I hope this helps, and maybe we can troubleshoot further.