Moderators

If you are seeing bzImage being transferred you can remove iPXE out of the problem. The default you should have for uefi is ipxe.efi.

Now you should focus on the FOS Linux engine (bzImage). What version is the FOS Linux kernel? I know I have a Dell 7400 2 in 1 with a Dell usb c dongle (as well as a WD15/WD19 docks) that boot into FOS Linux and pick up a dhcp address.

I find it strange that it finds the network adapter, and sees the link come up but can’t communicate over that link. Lets start with what version of kernel are you using? The next part is to schedule a new capture/deploy task but tick the debug check box before you schedule the task. Then pxe boot the target computer that will but the target computer in debug mode so we can key in some additional commands.

@george1421 To be honest, I never expected the partclone update to really change anything in that regard. I just figured there was a possibility that it could improve somewhat.

I’ve been confusing this thread with another one I think. I assumed he was already on those inits.

It’s worth a shot!

Can be downloaded from: https://dev.fogproject.org/blue/organizations/jenkins/fos/detail/master/95/artifacts

@Peter365 The only comment I can make is watch the permissions on the /images directory now. If you run into upload issues issue this command (note is a bit loose with the security, but its not too big of a risk) chmod -R 777 /images

@rocksteve69 This may be too much to ask, but if you swapped the WD drive for the Samsung drive in the same model laptop, does the problem move with the drive? That would then point directly to the Samsung drive.

@Quazz do you think the updated version of partclone would solve this issue ?

@rocksteve69 Can I ask which model it is specifically?

@f-an Did you install FOG using the git method or the tarball method? Because if you use the git method you can switch to the working branch and install fog 1.5.7.2 which addresses some issues since 1.5.7 GA was released. I’m not saying that solves anything also @Quazz was working on updated inits (FOS Linux virtual hard drive) with the updated version of partclone. That updated version I seem to remember fixed a slow nvme issue. Let me see if I can find the link he posted.

Edit: Read the entire thread so you can see how to install the inits without breaking your fog deployment: https://forums.fogproject.org/topic/13620/very-slow-cloning-speed-on-specific-model/12 Upgrading to 1.5.7.2 is not required to test these inits.

@f-an said in Deploying images from virtual FOG-server to VM's on the same host takes forever:

The FOG server is right now running with 48GB RAM and 8 vCPU

Just for reference 4GB ram and 2 vCPU is all that is required, a bit more if you have many fog client checking in.

With 1.5.7 your FOS Linux kernel and inits are pretty new so that probably isn’t the issue. So if you introduce a physical machine to capture or deploy to what are your transfer rates? The physical machine doesn’t need to boot for this test, only to deploy the image to get the speed.

As for your VM is it a type 1 or type 2 (not the right words) hyper-v vm? Is the vm in uefi or bios mode? If we find out its the VM (based on the results of the physical machine deploy) we can run some tests to see if its the target machine disk or network that’s causing the issue.

Also just for reference what OS is the hyper-v host running on?

@paat So just to be clear, you have a Dell branded usbc cable?

I have a dell branded usb c ethernet adapter on a 7400 and I can pxe boot into the fog compatibility menu (I don’t want to image my workstation at the moment) and ping devices. So I know the network adapter works. Also when we image we typically use the WD15 dock (the WD19 docks are flaky some times with pxe booting). That way we charge the laptop as well as image at the same time.

This is the dell usbc dongle we are using: https://www.dell.com/en-us/shop/dell-adapter-usb-c-to-ethernet-pxe-boot/apd/470-abnd/pc-accessories

Also what version of FOG are you using as well as what FOS Linux kernel version do you have?

What version of FOG are you using? I remember a while ago the FOS Linux engine would stall out during the partclone process then take off again.

As for the speed, I’ve heard about hyper-v being slow before, but not by first hand experience.

In can say in our environment we use vSphere and capture from a vsphere vm to a vshpere FOG server is about 6GB/m and deployment is in the area of 13GB/min. I can push out a 25GB (fat) golden image in about 2 minutes. I’m only saying this to show what is possible.

So what would be interesting to know in your setup is the hyper-v FOG server slow or is it the target computer (vm)? I can say during a fog image deployment cycle the target computer does almost all of the work in imaging, the FOG server only manages the process. In my home lab I have a fog server running on a raspberry PI3 and I get 4.5 to 5.0GB/min transfer rates so the point is the fog server isn’t a major factor in imaging speed its the target computer.

@rocksteve69 Try nvme_core.default_ps_max_latency_us=0

For the purposes of FOS, we don’t require a threshold where the drive assumes a lower power state, so we may as well try and eliminate lower power states altogether.

There may also be firmware updates for the SSDs in question