Moderators

@Tony-Fiorentino said in FOG Can't Access Windows 10 Hard Drive:

@george1421

No, it’s older.

If it was 2012 or newer then you could use this wiki to dynamically support both bios and uefi systems: https://wiki.fogproject.org/wiki/index.php/BIOS_and_UEFI_Co-Existence#Using_Windows_Server_2012_.28R1_and_later.29_DHCP_Policy

That way you would not be locked into booting one specific hardware style.

Another option would be to install dnsmasq on your fog server to supply only the dynamic pxe boot information for network booting. The reset of the dhcp options (like client IP address) would continue to come from your existing dhcp server.

@Tony-Fiorentino Let me ask one more question. What device is your dhcp server? Is it a windows 2012 or later dhcp server?

@krejci You are going to have a difficult time finding a server that meets your requirements, especially with a 31cm depth. Maybe a 37cm depth, but 31 will be really difficult unless you have a custom system. One issue is that 31cm is close to the ATX style motherboard in size. Also to get >10TiB drives you need 3.5" drives since 2.5" drives are not at the 10TiB capacity yet.

I did find this chassis with a 40cm depth, but it is a build your own server. Its not an already complete server, just the chassis: https://www.newegg.com/p/N82E16811219052

In theory you should be able to get FOG running on a synology nas since the nas OS (DSM) is based on linux. I have not tried to do this, but DSM has most of the components needed. You may need to add additional RAM to the rackstation to support both DSM and FOG. Again, I can’t say for 100% sure it will work, only it should work with some hard work. I can say I have turned a synology nas into a FOG Storage Node (not the main server) before, and it works. I have a tutorial here: https://forums.fogproject.org/topic/9430/synology-nas-as-fog-storage-node

@Nabeel Did you configure your dhcp server to supply dhcp options 66 and 67? For dhcp option 66 that needs to be the IP address of your fog server. For dhcp option 67 that should be undionly.kpxe for bios based computers and ipxe.efi for UEFI based systems.

If you need to support both systems in your environment then once you prove that the above options work you can review this article: https://wiki.fogproject.org/wiki/index.php/BIOS_and_UEFI_Co-Existence#Using_Windows_Server_2012_.28R1_and_later.29_DHCP_Policy

How short of depth?

Really from a fog server standpoint you don’t need much horse power if you are installing it on bare metal. I quad core processor with 8GB of ram and fast sata drives in raid-1 is probably enough. The goal for the fog server is to move the image from disk to the network adapter the fastest it can. All the heavy lifting of imaging is done by the target computer not the fog server. Now outside of imaging, the fog server also manages clients where the fog service is installed. Depending on the number of fog clients in your environment I may need to bump up the server specs because the fog server will be doing more than just imaging.

FWIW I can run FOG on a raspberry pi 2. For single unicast imaging it works just fine. If I was hitting it with 20 fog clients it would have some issues while imaging.

@buercky I just ordered some 7400s, they should be here by 15-Jul. I plan on testing them with the WD15 usb-c docks. From what I understand there is a few bios settings you need to make to allow these 7400s to pxe boot.

I guess there are a few unanswered questions here.

1. What is the target computer hardware, both manufacture and model?
2. It sounds like the target computer is in uefi mode. If this is a dell and uefi mode is turned off, change the disk controller from raid-on mode to ahci mode. That will allow FOS to see the hard drives behind the raid controller.
3. If the target computer is in uefi mode, what pxe boot file are you sending to it? ipxe.efi I hope, this is set by dhcp option 67.

If everything works fine (image capture and deploy) except the exit to hard disk then its a different issue.

@Olduser What the image sysprep’d? Did you include the 9020 drivers into your golden image? But the likelyhood if you sysprep’d the image then the native win10 drivers will probably work on the 9020. Other issues, is the 7760 in uefi or bios mode? The same goes for the 9020? You can only capture and deploy uefi based images to uefi base target computers. You can’t mix bios hardware with uefi captured images.

I understand this information will not help you with your capture performance but it does give is a baseline to contrast and compare against.

Hardware:
Both virtualization servers are Dell R540 servers with 2x 14 core processors running on a Dell raid-10 8 disk array. The link between the primary site and the hot site is 1GbE. The hypervisor is vSphere 6.5 at both sites. The Hyper-V server is running as a VM at the hot site on 2016 Datacenter server. It has 4vCPU and 16GB of ram allocated with 2 virtual hard drives. One for the OS and one for the disks for hyper-v. For the hyper-v host I installed hyper-v along side the existing windows 2016 data center. I did not install hyper-v on “bare metal” so I don’t know if that would have any performance impact or not (sorry not a hyper-v admin).

Disk image /compression setup as windows 10 zstd level 6. I picked zstd because its a bit more cpu intensive than gzip.

Test #1
FOG Server: Main site running as a vSphere client.
FOG target: Hot site running a hyper-v client (inside a vSphere client).

Test #2
FOG Server: Main site running as vSphere client.
FOG Target: Main site running as vSphere client (on same server as fog server)

Test #3
FOG Server: Hot site running as hyper-v client (inside a vSphere client)
FOG target: Hot site running a hyper-v client (inside a vSphere client).

Test #4
FOG Server: Hot site running as hyper-v client (inside a vSphere client)
FOG Target: Main site running as vSphere client.

Conclusion:
It appears that the vm client has a bigger impact on the fog capture performance than the fog server. Which is understandable because the target computers does all of the heavy lifting during image capture and deployment, the fog server does very little other than take the image stream from the network and write it to the local hard drive on the fog server and also manager the overall imaging process. So adding 12 vCPUs to your fog server will not make imaging go faster. For the hyper-v target I had to use the legacy network adapter which allowed for pxe booting. The native network adapter would not pxe boot. I’m suspecting some of the slowness was in the legacy network adapter as @sudburr posted already. Never the less I still can explain the 32MB/m transfer rates you are seeing. I’m almost half tempted to install virtual box here and see what kind of performance I get out that slow poke type-2 hypervisor.

I have to ask, what value is this information to the FOG community?

Don’t get me wrong, the information laid out here is very helpful if you want to stand up a WDS server, but most people come to these forums for FOG Project related help.