While this will not help your performance issue, please update to the latest trunk build. There has been major improvements in the platform in the last month.
With that said, if your current setup was running on vmware, adding extra vCPUs would actually kill performance on a busy vm host than help. It has to do with have time slices available where all of the 7 cpus are in a ready state. More complicated to explain than I’m going to post here.
I would say for your setup the vm client should only need 2 vCPUs and about 2GB of RAM memory for the FOS (Fog Operating System) engine (the software that uploads and downloads disk images). What your actual virtual machine needs when you create the client install is up to you.
Now for performance issues. I can imagine a few areas where you could have performance issues.
- You could have a slow vm host disk subsystem.
- You could have a network bottleneck between the vm host server and the FOG server
- You could have a slow fog server disk or network link.
First of all fog server performance. The performance of the FOG server is really minimal in the typical image capture and deployment process. In this setup the FOG server only really moves data from the network interface to the FOG disk and from the FOG disk back to the target computer.
The real work is being done by the target computer for both capture and deploying images. In one installation I have the FOG server running on a dual core celeron Intel NUC. For small deployments it runs great, but thats another story.
To help debug your issue we may need to do a few tests.
Configure your vm target computer with 2 vCPU and 4GB of ram. This is only to help build a consistent backup environment.
If you feel up to it recapture your reference image using the above settings to establish a baseline. What I’m interested in is the GB per minute number. Let the capture run for 5 minutes to make sure you have a solid transfer rate. Note the transfer rate. You don’t need to let it run the full 100 minutes unless you note that the transfer gets slower and slower the longer it runs after the 5 minute mark.
For your image you want to capture, drop the compression on the image to 0. Then recapture the image from the target computer. Note the speed difference.
Now lets try to capture a physical computer (preferred core 2 duo 4GB of ram) at the initial compression ratio. Again we want to note the transfer rate after ~5 minutes of running.
Capture that physical computer again at 0 compression ratio. Again we want to note the transfer rate after ~5 minutes of running.
Report back the numbers and maybe we can focus on a specific area.