@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?

+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

@olivierlambert I believe he means be able to rename / map a hosts physical interfaces to different namings. For instance on host 1, "network 0 / eth0" would be mapped to the physical eth0 interface, but on another host in the pool with a different NIC configuration, he could map the same pool "network 0 / eth0" to the server's physical eth1.

@S-Pam this certainly isn't currently supported, I believe it would take a lot of rewriting the network backend to make it possible.

Hey again:

1. With the latest debian and the latest cloud-init, no there should not be any extra steps now that the weird drive detection bug has been patched upstream. The important thing is that cloud-init inside your template VM is set to look for the nocloud datatype among others, and in the default config, it's already in the list of types of sources to look for so it shouldn't need changing

2. No at this time I am not aware of any plans to add ignition support as there hasn't been any demand (we prioritize features added by demand mostly). Personally, pretending I'm a non-employee, I would like to see Ignition support included as it would be quite handy, so it may be something we can approach down the road

If it wasn't already mentioned, the preferred data source now is NoCloud: https://cloudinit.readthedocs.io/en/latest/topics/datasources/nocloud.html

That's what XOA passes to VMs, a NoCloud config drive. Note that there was a serious upstream bug in cloud-init that was stopping OS's like debian from seeing this drive - as Olivier linked above it seems it was finally just now fixed.

Indeed this seems like yet another broadcom driver/firmware issue (not uncommon)

@olivierlambert I believe he means be able to rename / map a hosts physical interfaces to different namings. For instance on host 1, "network 0 / eth0" would be mapped to the physical eth0 interface, but on another host in the pool with a different NIC configuration, he could map the same pool "network 0 / eth0" to the server's physical eth1.

@S-Pam this certainly isn't currently supported, I believe it would take a lot of rewriting the network backend to make it possible.

I think when I last asked @julien-f about this he said it work work (just as you described), but the issue is xo-server will not reload certs without restarting the process. So the next time your let's encrypt instance updates those certs, xo-server will have no idea and you'll need to schedule a restart of that service after certs are updated

Hi, I have never attempted to install guest-utils on FreeNAS (FreeBSD based). Our documentation is for generic FreeBSD installs, however FreeNAS is highly customized and I believe they have most of the repositories disabled (which is why you get the repo not found error). It seems they don't have the required build tools to make either, but I could be wrong.

I'm not sure where you're seeing instructions to do "make install", we have a dedicated document section just for FreeNAS specifically that does not require running make. Try following it here: https://xcp-ng.org/docs/guests.html#freenas-truenas

I'm pretty sure the "new" button doesn't show up until XOA succesfully connects to at least one host, and in your screenshot for "servers", it's showing a red warning triangle next to both hosstds you've added, so I don't think it's connected.

Indeed XOA definitely needs to have it's own IP address, and your hosts all need unique IP addresses to. Then just go to settings > servers as you have and add the IPs of all your xen hosts just like you would in xcp-ng center/xencenter.

If you hover over the red triangle, it should tell you the error. Another step would be to login to the console (ssh) of the XOA VM, and try to ping those two host IPs to see if it's maybe a network issue (if the XOA appliance can't reach the hosts' IPs, then it's definitely not going to work)

judging from the network errors I see in your update panel screenshot, it seems the XOA appliance doesn't have it's networking totally set up properly. I'd follow this on the XOA VM to ensure it has a gateway, DNS etc set properly: https://xen-orchestra.com/docs/troubleshooting.html#network-issues

Hey again:

1. With the latest debian and the latest cloud-init, no there should not be any extra steps now that the weird drive detection bug has been patched upstream. The important thing is that cloud-init inside your template VM is set to look for the nocloud datatype among others, and in the default config, it's already in the list of types of sources to look for so it shouldn't need changing

2. No at this time I am not aware of any plans to add ignition support as there hasn't been any demand (we prioritize features added by demand mostly). Personally, pretending I'm a non-employee, I would like to see Ignition support included as it would be quite handy, so it may be something we can approach down the road

@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.

@p4-k4 Indeed I believe this is expected behavior. It expects strict YAML formatted code in the network config file that is passed to it, and comments are unrecognized.

That's very strange, it's finding the nocloud drive, mounting it, and pulling the config files off of it. Interestingly, it's finding a network-config file and trying to read it, then it looks like it decides it doesn't like the formatting, and decides to ignore the whole nocloud drive config source:

2020-08-24 12:36:22,816 - util.py[DEBUG]: Running command ['mount', '-o', 'ro', '-t', 'auto', '/dev/xvdb', '/run/cloud-init/tmp/tmpy_922uof'] with allowed return codes [0] (shell=False, capture=True)
2020-08-24 12:36:22,830 - util.py[DEBUG]: Reading from /run/cloud-init/tmp/tmpy_922uof//user-data (quiet=False)
2020-08-24 12:36:22,830 - util.py[DEBUG]: Read 109 bytes from /run/cloud-init/tmp/tmpy_922uof//user-data
2020-08-24 12:36:22,831 - util.py[DEBUG]: Reading from /run/cloud-init/tmp/tmpy_922uof//meta-data (quiet=False)
2020-08-24 12:36:22,831 - util.py[DEBUG]: Read 50 bytes from /run/cloud-init/tmp/tmpy_922uof//meta-data
2020-08-24 12:36:22,831 - util.py[DEBUG]: Reading from /run/cloud-init/tmp/tmpy_922uof//vendor-data (quiet=False)
2020-08-24 12:36:22,831 - util.py[DEBUG]: Reading from /run/cloud-init/tmp/tmpy_922uof//network-config (quiet=False)
2020-08-24 12:36:22,831 - util.py[DEBUG]: Read 104 bytes from /run/cloud-init/tmp/tmpy_922uof//network-config
2020-08-24 12:36:22,831 - util.py[DEBUG]: Running command ['umount', '/run/cloud-init/tmp/tmpy_922uof'] with allowed return codes [0] (shell=False, capture=True)
2020-08-24 12:36:22,838 - util.py[DEBUG]: Attempting to load yaml from string of length 50 with allowed root types (<class 'dict'>,)
2020-08-24 12:36:22,839 - util.py[DEBUG]: Attempting to load yaml from string of length 104 with allowed root types (<class 'dict'>,)
2020-08-24 12:36:22,839 - util.py[DEBUG]: loaded blob returned None, returning default.
2020-08-24 12:36:22,839 - handlers.py[DEBUG]: finish: init-local/search-NoCloud: FAIL: no local data found from DataSourceNoCloud
2020-08-24 12:36:22,839 - util.py[WARNING]: Getting data from <class 'cloudinit.sources.DataSourceNoCloud.DataSourceNoCloud'> failed
2020-08-24 12:36:22,844 - util.py[DEBUG]: Getting data from <class 'cloudinit.sources.DataSourceNoCloud.DataSourceNoCloud'> failed

You said you were commenting out lines in the network config box, I might take a guess that that gets written to the config drive, and cloud-init tries to read it. Since it wants strict yaml, it's probably failing on those # characters. Can you try leaving the network config box in XOA COMPLETELY empty? (not even a space)

That's...strange. Can you try to reproduce the errors/failure to load in the VM again and grab the logs from the deployed VM? They should be under /var/log/cloud-init.log and /var/log/cloud-init-output.log - it should give us quite a bit of details