Update pfSense/OPNsense BIOS + Add Optimize Boot

[cyrilchristin]

• Added preferred boot mode UEFI for pfSense versions > 2.4
• Fixed "logic" of different VM-UUID in step 3
• Added optional step 4. Optimize VM Boot Process (removing parallel/serial ports)

The above changes follow investigations of a slow boot process of a pfSense 2.6.0 VM on XCP-ng 8.2.1 (2022/10/12).

XCP-ng is installed on "slow" hardware which probably made the issues more noticeable PC Engines APU6 AMD quad core 1Ghz + 4GB DRAM

Our timing tests between boot mode BIOS and UEFI are as follows:	Step	BIOS	UEFI
Installation	~8 minutes	~5 minutes
Boot Screen	1 min 30 secs	10 secs
XEN Starting	2 mins 50 secs	20 secs
DEVD Starting	4 mins 10 secs	1 min
Boot Complete	4 mins 50 secs	1 min 40 secs

The problem seems to be related with how the pfSense VM prefers communicating with the virtual disk using the emulated IDE controller instead of the SCSI controller during the boot process, if the VM is using the boot mode BIOS.

The blog post "pfSense firewall boot process optimization under Xen hypervisor" describes this issue with "vanilla" Xen, which seems to provide "direct" control on the emulated controller using the disk name (hd[x] vs sd[x]). Having not found such an option in XCP-ng, it seems we can achieve the same results when using boot mode UEFI instead of BIOS.

Removing the parallel port optimizes the boot process by 30 seconds and removing the serial port removes the risk of pfSense selecting it as the main "console" during boot (and missing boot output).

Signed-off-by: Cyril Christin 55538276+cyrilchristin@users.noreply.github.com

Before submitting the pull request, you must agree with the following statements by checking both boxes with a 'x'.

• [x] "I accept that my contribution is placed under the CC BY-SA 2.0 license [1]."
• [x] "My contribution complies with the Developer Certificate of Origin [2]."

[1] https://creativecommons.org/licenses/by-sa/2.0/ [2] https://xcp-ng.org/docs/contributing.html#developer-certificate-of-origin-dco

[stormi]

This looks good to me, although I don't know the technical details myself, so I can only trust that your guide is pertinent. There is indeed unfortunately no other way to change the emulated controller than by switching from BIOS to UEFI. It's all linked together in the way XAPI handles it at the moment.

@Fohdeesha: any comments before we merge this?

[Fohdeesha]

The commit looks and reads good to me, as one of the devs said in the XCP-ng channel, sadly the emulated disk type (virtualized vs virtual nvme) is tied to BIOS vs NVMe boot so this is the best we can do for now.

[cyrilchristin]

Thanks for confirming that I hadn't missed the option to control the emulated disk type (thought there might be).

I should add that all the configurations were done with XenCenter as I have (still) not found the time to play with Xen Orchestra. Therefore, I'm not sure when creating a VM other install media with XO if the default boot mode is also BIOS (is it linked to the template?).

Also my investigations/tests were only done on the slow hardware (APU6) and could have some unique "situation". However, I did various performance tests between a BIOS and UEFI pfSense 2.6.0 VM and could not find any differences post boot (DEVD Starting). Therefore, I don't see any negative effects in recommending to prefer UEFI boot mode for pfSense versions > 2.4.

[stormi]

All templates but the Windows templates currently set the boot mode to BIOS, as far as I remember. In Xen Orchestra, you can change it in the advanced settings of the VM - both at VM creation and afterwareds - and it's rather easily discoverable, so I don't think we need to add it to the doc.

[stormi]

Thanks for your contribution. We may wait a bit before merging it, but we'll do it in due time.

[cyrilchristin]

Happy to give back to the XCP-ng community!

Thank you XCP-ng team for making this all possible ❤️

[stormi]

This PR was integrated manually to the new documentation as commit 2e4508e751da7d1636177dd6150a1f248d15d9dc.

Closing.

Thanks for your contribution!