VMware 6.7 VM not able to capture image using UEFI

[quinniedid]

@george1421 @Sebastian-Roth I just wanted to see about tackling this issue again. Using the SATA controller for the VM hard disk is costing us a lot of time as it takes roughly 2 hours to capture an image. Where as the SCSI controller takes less then 20 minutes.

This is in reference to an issue I posted about 10 months ago: https://forums.fogproject.org/topic/11179/vmware-6-5-vm-not-able-to-capture-image-using-efi-uefi

FOG Version: 1.5.4
bzImage: 4.18.3

This is what I am seeing:

[quinniedid]

@george1421 @Sebastian-Roth I just discovered the solution to this issue.

Back a while ago we had HP Z400 workstations that required us to put a global kernel argument of “ahci = off” as they would fail to deploy an image without it. The reason we made this global as it did not have an impact on any other devices and I would not have to specify it specifically on every workstation. The oddness of this all, when the VM was running in BIOS this was not an issue with capturing the image with the SCSI controller. When the VM was UEFI it would fail and would require us using the SATA controller which slowed capturing to be almost a 2 hour process. Removing this kernel argument now allows us to capture an image at full speed again using teh SCSI controller and it fixed a hang issue that occurred in the beginning that was also previously reported with the “can’t find IRQ”.

All in all this is now fixed removing that kernel argument. I am just shocked that it would be affected differently between BIOS and UEFI specifically on a VM.

Thanks for all your help.

[george1421]

While this might sound counter intuitive, what happens if you roll the FOS kernel back to 4.15.2? Do you get similar results? I don’t have vmware 6.7 in my environment yet so I can’t compare results easily. But is your 6.7 release been updated since the GA release? It looks like a fully patched build base # should be 10176752.

6.7 GA build base is 8169922.

[quinniedid]

@george1421 I tried that kernel and it is doing the same thing. We are on Build 9433931. They have an update U1 out but our hardware vendor does not support it yet.

[Sebastian Roth]

@quinniedid In the picture we see a note about using kernel parameter pci=biosirq. Have you tried this yet? You can set kernel parameters for particular hosts in the host settings in the web UI.

[quinniedid]

@Sebastian-Roth I have tried specifying that setting for the host in the kernel arguments and still continues to show the same message.

[quinniedid]

@george1421 @Sebastian-Roth I just discovered the solution to this issue.

Back a while ago we had HP Z400 workstations that required us to put a global kernel argument of “ahci = off” as they would fail to deploy an image without it. The reason we made this global as it did not have an impact on any other devices and I would not have to specify it specifically on every workstation. The oddness of this all, when the VM was running in BIOS this was not an issue with capturing the image with the SCSI controller. When the VM was UEFI it would fail and would require us using the SATA controller which slowed capturing to be almost a 2 hour process. Removing this kernel argument now allows us to capture an image at full speed again using teh SCSI controller and it fixed a hang issue that occurred in the beginning that was also previously reported with the “can’t find IRQ”.

All in all this is now fixed removing that kernel argument. I am just shocked that it would be affected differently between BIOS and UEFI specifically on a VM.

Thanks for all your help.