Why is it these people can never spell?

+1 for avoiding 3rd party install scripts, the official install doc is like, 10 commands? I think it takes maybe 10 minutes or less the last time I did it on a fresh debian system, and you know it's always the correct instructions (which is NOT the case with 3rd party scripts, as you'll see in this forum when even the slightest architectural change is made to the XO sources). You also get to learn at least a little bit about the architecture of what you're installing and running instead of pressing go on a script you grabbed from some guy's github and hoping the XO web interface appears. I thought the whole point of "homelab" (for which sources are intended and primarily used) was learning and developing skills in the first place?

No disrespect intended to the people that create and maintain said scripts, it just seems to me like it bypasses the point of sources a little bit

I can start adding to this this weekend probably - would a "guide to installing pfsense" be useful? I know there's many guides out there already, but more than half of them have useless (or worse than useless) steps telling people to turn off things that don't need to be turned off

that looks good, and the fact that the VM is properly using the new SSH keys means the config data (and config drive) is properly being formatted and passed to the VM, and the VM is picking it up and using it - which rules out XOA as the source of the issue. It looks like CentOS is choosing to ignore the hostname config, I'm not an experienced centOS user so I have no idea.

paste exactly what you're entering into the two cloud-init config boxes in XO

How much RAM does the system have? my first guess is the host doesn't have enough free RAM to start the VM, the dom0 management VM will take some up, plus whatever VM you're trying to start

I'm not sure, I have not used cloud-init in centos. I'd imagine it's similar, you need to find the cloud-init config file in your centos template install, and edit it to prefer the nocloud datasource

In terraform for vsphere they are not using cloud-init, they're using "guest customization" which apparently just uses vmware guest tools: https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.vm_admin.doc/GUID-E63B6FAA-8D35-428D-B40C-744769845906.html#GUID-E63B6FAA-8D35-428D-B40C-744769845906

XCP-NG / xen guest tools do not have the option of configuring the network like this that I know of, only reporting

it's hard to understand exactly what you're asking, but that only works with the nocloud datasource because that's the design of cloud-init (out of our control). nocloud is the only data source (versus openstack) that cloud-init will allow network config: https://cloudinit.readthedocs.io/en/latest/topics/datasources/nocloud.html

It should present an openstack config drive type, and a nocloud config drive type, your cloud-init settings should be set to use nocloud first, and it will have both your settings from the network box, as well as from the user-data box. This is the config template I use:

  version: 1
  config:
    - type: physical
      name: eth0
      subnets:
        - type: static
          address: 192.168.1.40/24
          gateway: 192.168.1.1

Note that cloud-init will not overwrite and replace any existing network settings in the vm (like in /etc/network/interfaces), it only appends whatever settings you add to the existing settings by placing a file in /etc/network/interfaces.d/ - I would see if you have anything here. I would also check /var/log/cloud-init.log to see if it's seeing and choosing the nocloud data source, and if not, why not. There is a currently a bug with the way OS recognizes the FAT volume label of the nocloud drive, this could be happening as well.

Why is it these people can never spell?

pretty much everyone here is running PfSense fully virtualized, no passthrough. I'm able to saturate gigabit links with full firewalling etc. What's nice about not having it pegged down to one host with a pci passthrough is you can hot-migrate it between servers with no dropped traffic. Or maybe you wanted passthrough for the ALTQ-reliant traffic shaping features?

I was never succesfully able to get PCI passthrough to work, but for me it was related to a bug in Dell's IOMMU implementation. In the BIOS make sure anything mentioning IOMMU, vt-d, and SR-IOV is enabled. However your CPUs not officially supporting SR-IOV points to your CPU/BIOS not having a proper IOMMU management/implementation either