Sooooo as stupid as this sounds but I have a solution / workaround.
Reduce the number of CPU’s on the VM to 1
Enable migrate to a physical computer with a different processor version
Changing either of these setting causes the speed to bottom out at 21mb/m leaving the setting at this results in 230mb/m capture speed.
So the image finished from the physical laptop at 2.1gb/m which would suggest that the issue is on the windows 10 VM side.
@george1421 Hey thanks, So today I accessed a known good Fog server running 1.5.4 (fog1.5.4 from now on) on hyper-v with the same specs above (I used the settings as a guide for setting up the new ones, but it was a fresh install each time)
fog1.5.4 historically would capture at 300mb/m and would images at 1.2gb/m (limited by the network connection), I’m currently uploading the image at 21mb/m (this is the same if I attempt to capture the last known good image, whilst writing this I got the rcu_sched self-detected stall error). I’ve updated its network connection to the synthetic connection and it will deploy images at 7-8gb/m now.
I’m about to upload a previously imaged computer in to fog1.5.4 to see what it does.
When uploading a windows 7 image from hyper V to fog 1.5.4 (its running currently) I’m getting 220mb/m but that’s fluctuating currently (between 210 and 230 mb/m due to the hang on the current block as described before).
The hosts are all Windows server 2012R2 Datacentre.
2x16 core 2.1ghz processors (AMD Opteron 6272)
64gb Ram
3x 300gb 15k sas drives in Raid 5 for the OS
3x 1tb 10k sas drives in raid 5 for the storage of the VM’s
4 1gb network links teamed together shared with the OS
The Dev server I’m working with:
Windows server 2012R2 Datacentre
2x 6 core 2.4ghz Processors (AMD Opteron 2431)
32gb Ram
2x 250gb SSD’s in Raid 0
2x 1gb network links teamed together shared with the OS.
Below are the specs for the individual VM’s
@george1421 So I spoke too soon…
The image is still running but looks like its hung, see attached (I’ve blanked out the identifying info)
So over the weekend I’ve been playing around, I cleared some space on our hyper V Dev server which has 2 SSD’s in Raid 0 and moved the windows 10 VM across to it.
It has been capturing steady at 35mb/m for 10 hours, the stuttering on the block count is much better still happening but not for very long each time.
The virtual host has 2x 16 core processors (32 cores total) for both the server hosting the VM as well as fog server.
The disk setup is 2 raid5 arrays, the system is on 3x15k 300gb SAS drive and the storage (where the VHD is) is on 3x10k 1tb SAS drives.
Good to know about the CPU cap.
Hey sorry for the delay in getting back to you yesterday.
So I installed the same version of windows 10 to a laptop this morning and captured it at 1.2gb/m but it did still do the pausing on the blocks (just not as often or for as long) (about 10 mins for a 12gb fresh install of windows).
My Colleague lowered the CPU count on the windows 10 VM from 12 to 4 and re ran the job on his physical FOG server and it captured in 2 hours at 250mb/m, I did the same on the virtual host which didn’t make any change.
I’ve also just tested unteaming 1 network connection from each of the virtual hosts and setting up a dedicated switch for imaging. That also didn’t make any difference.
@sudburr Thanks for the reply, I realise that i didn’t add this but I did move the fog server to a different virtual host and tried to capture the windows 10 virtual and it had the same issue.
Also one of my colleagues (about 20 minutes ago) copied the windows 10 VM and tried to capture it to his physical fog box, I don’t have the specs for that server but it did exactly the same as the virtual Fog servers
Also we have been using fog for years on a virtual server (with limited speeds 300mb/min, which is totally acceptable for our setup and how often we capture images, its much faster when deploying) we have only started having issues with Windows 10 Edu Pro
Thanks, when I captured a physical windows 7 computer the speeds were much better 1.2gb/min, I’ll run a windows 10 install tomorrow morning and capture it but I would expect it to be better.
I have access to several Fog servers, previously another server (fog 1.5.4) captured a windows 10 VM at 300mb/min which is slow but it does finish in about 8 hours. I moved the VM I’m trying to capture across and started the capture with the same results (1mb/min capture rate). So off the back of this I started again with my image (same Windows 10 version, Windows 10 Pro Education 1903) but had the same result on both fog servers.
Afternoon all, I have a new virtual Fog server running on the Dev-Branch (it was on 1.5.6) on Debian 9 but when capturing a Windows 10 image from a Hyper-v Server it starts at 3GB/min but gradually drops to 1.28MB/min over the course of a few hours.
The image I’m Capturing has been running 18 hours and only taken 3.74% of a 37gb image.
If we capture a freshly installed windows 10 image it does capture but it slows to 70mb/min by the end of the image.
I’ve tried dropping the Kernel back to 4.15.2 (and all versions in between) based on a couple of other posts with no success.
What is strange is that the capture seams to hang after a sever thousand blocks and will do a batch then pause again.
Fog Server specs :
12 CPU
8gb Ram
Legacy network adaptor (but tried the synthetic adaptor as well)
Client pc:
12 CPU’s
8gb Ram
Legacy Network Adaptor
The virtual host doesn’t seam to be over stretched on performance.
Any suggestions will be appreciated.