FOG slow to image when on VM

  • We have shutdown our physical server and created a brand new FOG server on a VM. The time it takes to deploy an image is almost half of what it was on the physical server. We are using latest version of ESXi.

    I did some file transfers from centos on the old physical server over to the centos running FOG on the new VM and it was crazy fast. Why is the image deployment so slow on the VM and is there a setting I can adjust to get it going like it was?

  • @Sebastian-Roth Thank you very much. We had an outage last week so I didn’t have time to follow up. I just upgraded to latest dev-branch and things are working now. Advanced menu is working as it was before. Thanks everyone involved!

  • Developer

    @TaTa I just pushed a fix, follow the discussion here:

  • Developer

    @TaTa Thanks for the update. Would you mind opening a new topic for this as it has not much to do with the initial posting. I feel it’s good to keep things separated so people will find answers quickly as well.

    At first I though you might be running into an issue we already found in 1.5.5 and fixed some weeks ago: (definitely worth reading the whole topic as it also has some information on how this works)

    But as you are using dev-branch I suppose you already have that fix. When did you last update to the latest dev-branch version?

    Can you please post your advanced menu code here? Possibly it’s just an issue within the menu code?!

  • @Sebastian-Roth Whenever I selected Advanced Menu and signed in, the machine will either beep or display a black screen (sounded like missing RAM beeping sound). I installed dev-branch on a test server with fresh installed ubuntu 18.04 with same issues.

  • Developer

    @TaTa Can you please post more information on the “Advanced menu issue” you see with current dev-branch. I’d like to fix this before we push out the next release.

  • @kafluke We gave up on the VM route. Went back to physical server and it’s working as expected. I am going to put in a bug report though about the log viewer. I rely on that and it’s not working in latest dev-branch build.

  • @kafluke It happens to me too. Also on the latest dev-branch, Advance Menu has stopped working.

  • Okay so I just built it up on a different physical server and it’s fast again. Something to note though… when I use the dev-branch I have no logs and behaves a bit funny (snapins not installing and not able to join the target to the domain). If I use the working branch everything works fine.

  • I’ll throw my two-cents in here. Has anything changed network wise? I know I ran into an issue when one of the hubs we had went down and we replaced it with a 10/100 we had lying around. As soon as we put in a gigabit hub it was blazing again. Just an idea.

  • Moderator

    @kafluke So unless I’m missing something you have 16 vCPUs allocated to the FOG vm with 12 cores in the host system? Yeah, I’d drop that back to 2 vCPUs with 8GB of ram to start with. Over provisioning the VM is counter productive.

    4 x CPU Sockets
    4 x CPU Cores
    8 GB RAM

    And really the FOG server doesn’t do much for imaging. It just moves the image from disk to the network adapter. There is no calculations done on the fog server, the target computer does all of the real work. Much more than 2 cores is a bit of a waste unless you have a lot of client computers checking into the fog server, then I’d probably go to 4 vCPUs.

  • @george1421 No that’s the VM not the host. Here’s the specs on the host:

    12 CPU’s Xeon X5675
    96GB RAM
    10 Terabyte SAS RAID10

  • Moderator

    @kafluke said in FOG slow to image when on VM:

    I can copy an image from the old physical server over to the VM at the OS level (centos) using SSH with no bottleneck whatsoever (Full 1Gbs)

    How about in the other direction new fog server to old fog server? That is actually the direction the image will be traveling during deployment.

    Also the other thought is that the old fog server to new fog server is probably happening on the same network switch, whereas going to a target computer would probably be switch to switch communication.

  • Moderator

    @kafluke said in FOG slow to image when on VM:

    4 x CPU Sockets
    4 x CPU Cores
    8 GB RAM

    Just to be clear this is the physical vm host machine info right? 8GB of ram is super low.

    Also how is the esxi box connected to your network?

  • @george1421 That’s what I first thought. The thing is, I can copy an image from the old physical server over to the VM at the OS level (centos) using SSH with no bottleneck whatsoever (Full 1Gbs). Here are the specs of the VM:

    4 x CPU Sockets
    4 x CPU Cores
    8 GB RAM
    30 drive RAID10 SAS drives

    There are only two other VM’s running on the host and they are very small file servers with limited resources.

  • Moderator

    @kafluke I’m pretty sure its not FOG that is the bottle neck here, but more your virtualization infrastructure you have in place. Remember a virtualization environment is shared, where a physical server is typically dedicated to the service.

    Tell use about the virtualization host.
    How many cores (not hyperthreads, but real cores)
    How much memory
    How is the disk subsystem designed (raid level + number of disks)
    How does the host interface with the network infrastructure? (1GbE, 1GbEx2, 10GbE, ?)
    How many other VMs run on this vm host?
    How many vCPUs do you have dedicated to the FOG server?
    How much ram do you have dedicated to the FOG server?

    I can tell you that FOG running as a VM with 2 vCPU 3GB of ram on a 28 core server ,with a Raid 10 array, and (2) 10GbE interfaces to the network. I can push a unicast image out to current tech desktop at 13.4 GB/min (according to Partclone)

  • @Sebastian-Roth I unchecked MULTICASTGLOBALENABLED and it’s still super slow.

  • Well whatever the default is set to. I couldn’t see any settings in the fog settings to change it to unicast but we’re testing on just a single image. We don’t do multiple machine images at the same time.

  • Developer

    @kafluke Multicast deployment?

Log in to reply