+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

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

@akurzawa

It's done quite a bit and totally depends on your workload type, but for general use on my hosts I typically get up to 2:1 oversub and never see any issues or performance hit. If all of your VMs are crunching hard 24/7 obviously your rules will be very different

+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

we prefer to build with debian, which should not come prepackaged with a node release. Then, you can use the simple nodesource repo to install node 8: (follow the node v8.x section): https://github.com/nodesource/distributions/blob/master/README.md#installation-instructions

@Biggen said in HUB Templates:

Nothing has "moved to being paid", all the things you list started as paid only features in XOA - Cloud-init did have a bug where it would be able to be used in lesser license levels, but this was accidental - you can check our commit history on the documentation for it, we intended it to be a premium only feature. What I mean to say is if a feature is going to be paid we make that clear from the get go, we do not release a feature/product for free and then change that later. It's for this reason you do not need to worry about the netdata plugin changing to paid only. It's also worth noting we publish the source code for all the aforementioned paid features - I know there's at least a couple people out there using our XOSAN glusterfs driver in their own (free) projects

I do understand the frustration with some things only being in paid products, but we have to find a balance of being able to pay the bills so our developers can keep xcp-ng going and release stuff like new plugins

if it will take RPMs, you can probably use this method https://github.com/xcp-ng/xcp/wiki/Guest-Tools#install-the-linux-guest-tools-on-an-unsupported-distro