@mietek I can assure you there's no malicious intent to mislead you, why we would do that to our users is beyond me. Olivier is simply one of the most busy people I've worked with, and he still takes the time to come here and answer free users when he can. He might not have the time to scour the internet and github for the relevant patches and news for niche threads like this. We were not made aware of the cloud-init fix until just a few days ago when a patch was submitted. Cloud-init has been notoriously hard to support and document because the upstream project is constantly doing things like this, and as you noticed it can affect how it works on one OS version versus another very differently. If it were up to me we would drop built-in support for it because of this mess (and a lot of large projects have dropped it entirely and moved to Ignition, like CoreOS) but a lot of users still find it very useful so we continue to support it as best we can, baring with the mess going on upstream.

I'm not sure if you're aware, but Olivier is the founder and CEO of Vates, who is behind both XCP-ng and XOA. I welcome you to go to the ESXI forum and try and get the CEO of VMware to personally answer your questions, as a free user to top it off.

Why is it these people can never spell?

@alexanderk Heh yes, and a few other Brocade/Quanta/Dell guides

+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

@maxcerny Indeed, the Ubuntu cloud-init template should be up by the end of this week (cloud-init has so many fun bugs to work around for these applications)

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

@s-pam If you don't mind about power usage, high performance (that you've already selected) is the way to go. It will avoid entering C states as often and leave the CPU clocked high among other things so there is no latency for workloads waiting on the CPU existing C states etc.

Leave x2APIC enabled, it helps to distribute interrupts between multiple cores/CPUs. There's no downside to having it enabled unless the hypervisor doesn't support it (and you would know immediately by having errors).

Regarding your last setting, also referred to as CCX as NUMA, this changes how the CPU cores are presented to the hypervisor (either as one NUMDA domain, or multiple, one for each set of cores that share cache). From the benchmarks I can find, leaving this on gains maybe 3 to 4 percent improvement https://blogs.vmware.com/performance/2020/05/app-perf-vmware-vsphere-amd-epyc-rome.html

@Gheppy I'm not sure if xo-cli supports job interactions, @olivierlambert may have to inquire with the xo-cli dev @julien-f . For your niche use case, you could solve it in the meantime by running your XO instance from your house (or wherever this CR destination and DB test server are). Then, you can set the CR job to replicate to two remotes, your main CR destination, and then your test pool you've been manually copying to. Since these are now both local to XOA, it won't use up extra internet bandwidth, XOA will still only be pulling one stream from the production server out on the internet, then once it's inside your network on XO, it duplicates and writes to both local CR destinations

@Torodiesel Are you using the ubuntu or debian hub template? the default user included with the debian template is debian, not ubuntu :)However if you're yusing the ubuntu template, it should indeed be ubuntu. I would start from scratch and copy/paste only my example config above without networking, replacing only the key line with your public key. If that still doesn't work, you can be sure the issue is somewhere on your side (probably the keypair is corrupted, or your ssh client isn't sending the correct privkey)

@ITJamie Alma Linux 8.5 template is finished and should be added to the hub in the next day or two. I should have Rocky Linux done shortly after that. Note that in CentOS/RHEL related distros, the hostname: {name}% parameter that's filled in under the cloud-init config is not enough to change the hostname for the machine, CentOS (and related) expects a fully qualified domain name. To get the newly spawned VM have the hostname you'd like, supply fqdn parameter as well:

use VM name as hostname:

#cloud-config
hostname: {name}%
fqdn: {name}%.localdomain.local

use custom hostname:

#cloud-config
hostname: testvm
fqdn: testvm.localdomain.local

@pdonias yep I can confirm that works as expected, cloud-init uses the base VM name specified in the top of the create VM page, not the numbered VM names that result after creation. Nevermind!

@olivierlambert thinking further it should probably just be completely removed from the example/default, when creating multiple VMs from our "create "VM" page, numbering of all the VM names directly is already achieved, so having another number variable on top of those numbered VM names inside the cloud init config will just end up with the multiple VMs having hostnames like "test00", "test11", "test22", etc

@bradk that's working as expected, the number of the VM is the % in the hostname variable. If you want the hostname to be set to the name of the VM, without numbering, just use hostname: {name}

I also just noticed you were using the v3 testing version of clonezilla, not stable. I just tested that as well just in case and as expected it works out of the box - Clonezilla at its core is just trimmed down ubuntu or debian, and the xen PV device drivers are built directly into the kernel for both of these, so it's incredibly unlikely they would ever not be present. Screenshot from clonezilla live testing (same ISO you stated in your original post):

@fred974 I think you definitely have your templates or something else mixed up, Clonezilla works great out of the box running as a VM under XCP-ng, using any Ubuntu or Debian VM template. In fact, you should be able to use any linux template when creating a VM. To double check, I just downloaded both clonezilla stable live ISO (debian based) and clonezilla live stable alternative (the ubuntu build), and both boot fine and have working network adapters out of the box, using either debian VM templates or ubuntu VM templates (doesn't matter).

In fact, the issue Olivier is remembering is that clonezilla does not work out of the box when booted under a Windows 10 template, because windows 10 templates present platform:device_id=0002 to the guest OS, and QEMU combined with some linux OS's get confused by this (understandably, the ID is for windows), and it breaks the display. So a customer that was trying to boot clonezilla under windows 10 templated VMs had garbled display output until he used xe to change platform:device_id=0002 to platform:device_id=0001 which is what linux templates use.

The fact that you're reporting your clonezilla actually works fine under windows templates, but not linux templates, tells me some wires are crossed somewhere - it could be the ISO you're using, the templates you're using or choosing from, or your XCP-ng install. Is your XCP-ng fully up to date? if so, have you rebooted it since applying updates? We also had some strange issues with customers applying updates recently but then not rebooting as advised, this left QEMU in a weird state until it was finally rebooted that I suppose could cause this issue. For reference, here is how I'm creating clonezilla templates that work right out of the box (note the template, ISO name, and boot mode: bios):

@vmpr Great work and example!

@Gheppy I'm not sure if xo-cli supports job interactions, @olivierlambert may have to inquire with the xo-cli dev @julien-f . For your niche use case, you could solve it in the meantime by running your XO instance from your house (or wherever this CR destination and DB test server are). Then, you can set the CR job to replicate to two remotes, your main CR destination, and then your test pool you've been manually copying to. Since these are now both local to XOA, it won't use up extra internet bandwidth, XOA will still only be pulling one stream from the production server out on the internet, then once it's inside your network on XO, it duplicates and writes to both local CR destinations

@Torodiesel Are you using the ubuntu or debian hub template? the default user included with the debian template is debian, not ubuntu :)However if you're yusing the ubuntu template, it should indeed be ubuntu. I would start from scratch and copy/paste only my example config above without networking, replacing only the key line with your public key. If that still doesn't work, you can be sure the issue is somewhere on your side (probably the keypair is corrupted, or your ssh client isn't sending the correct privkey)

@Torodiesel the networking config should go in the network config box when deploying the template, not in the same box as the cloud-config data. Also, I see a few things wrong, including your network config having non-existent fields (you have to define a nameserver type field, then list addresses under it). Here is a known-working config. Note that you don't need to create an xcp-ng user, the templates come configured with a sudo user with the name of the OS, so for our debian template, the default sudo user is debian, just provide a key like below and you can log in as him::

#cloud-config
hostname: {name}%
fqdn: {name}%.localdomain.local
ssh_authorized_keys:
  - ssh-rsa XXXXXXXX
packages:
  - tmux

  version: 1
  config:
    - type: physical
      name: eth0
      subnets:
        - type: static
          address: 192.168.1.169/24
          gateway: 192.168.1.1
    - type: nameserver
      address:
        - 8.8.8.8
        - 1.1.1.1
      search:
        - home.lan

And yes, filling a field with a value of {name}% will pass along the name of the VM, whatever you have named it

@vmpr Hi, this is one of cloud-inits many "features" - on debian and debian-like distros, it does not overwrite /etc/network/interfaces - it appends the existing config with a file placed under /etc/network/interfaces.d/ as you noticed - this is cloud-inits design choice. So when Debian's default /etc/network/interfaces file has dhcp configured on eth0, it's going to pull a DHCP address. There's two ways around this. One, you can remove the interface config inside of /etc/network/interfaces - I thought about this briefly when creating the hub templates - then debian would not have its own DHCP address added to your static config. The problem though is users who do not provide their own network config during spin up (which is about 90% of our users) will have a VM spin up with no network config or address at all, which obviously isn't an option.

The second option is using cloud-inits ability to run commands after spin-up, and use it to run sed or similar to remove the dhcp config out of the /etc/network/interfaces file, then restart the networking service. If you google around you'll find some suggestions about this and the syntax to use (I'm not an expert here). https://cloudinit.readthedocs.io/en/latest/topics/modules.html#runcmd

As for it taking a reboot for the static IP to be applied, I never experienced that so I can't say what's going on there. As for the default password, there is no passwords for any users on the templates by default for security reasons. You must use a key, or use the runcmd cloud-init param above to run something like echo 'root:mypass' | chpasswd after the first boot to set a password