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

@jivanpal I think trying to get OpenVswitch (our underlying network layer) managing and using a wifi dongle for core hypervisor networking would be a nightmare, and you'd probably need to install some extra packages to handle the authentication / WPA management etc - then of course there's zero guarantee OVS wouldn't overwrite or revert any of this custom stuff for said interface (OVS was not designed to work with wifi)

Not to mention you'd have to have a relatively hackable AP, one that will allow the dongle to source a lot of different MAC addresses, which is pretty rare. From OVS's own docu:

@Andi79 https://www.youtube.com/watch?v=tDacjrSCeq4

@zxcp Something is very broken - with customers and most users we typically see around ~90% of bare metal perfs (in things like passmark and real use). This is with modern virtualization using PVHVM - which is what most of the templates should default to if your hardware supports it. What hardware is this exactly? is it running the latest bios/firmware and you've ensured it has VT-D / IOMMU / etc enabled? In simple cases of poor virtualization overhead we may expect to see something like ~30% worse performance compared to bare metal, so maybe an 8 minute ubuntu install instead of 5. Three hours means something is very broken somewhere - could be storage related as well as installs are usually very write heavy. If you attach a dmesg from XCP-ng it should make it clear what your hardware supports virt wise

@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

@zxcp PowerEdge 1950 and R900 are far too old for virtualization with xen. This era of Xeons (more than 12 years old) are missing a ton of extensions that help with virtualization, with no IOMMU subsystem to be used by xen etc as you noticed in dmesg (I'm honestly surprised our installer even worked on these). The bare minimum I would consider for virtualization would be 11th gen dell stuff (R610, R710, etc)

@MilitaryNerd Have you restarted the host since removing this bond? It's reporting that bond0 is still attached to an OVS bridge, so it may need a reboot. You can also ensure the bond is really gone by running xe bond-list, it should return nothing. You could also still have the bond PIF existing or other networks using the old bond, check that you don't have any PIFs with device ( RO): bond0 listed when running xe pif-list

@Andi79 https://www.youtube.com/watch?v=tDacjrSCeq4

@zxcp PowerEdge 1950 and R900 are far too old for virtualization with xen. This era of Xeons (more than 12 years old) are missing a ton of extensions that help with virtualization, with no IOMMU subsystem to be used by xen etc as you noticed in dmesg (I'm honestly surprised our installer even worked on these). The bare minimum I would consider for virtualization would be 11th gen dell stuff (R610, R710, etc)

@zxcp Something is very broken - with customers and most users we typically see around ~90% of bare metal perfs (in things like passmark and real use). This is with modern virtualization using PVHVM - which is what most of the templates should default to if your hardware supports it. What hardware is this exactly? is it running the latest bios/firmware and you've ensured it has VT-D / IOMMU / etc enabled? In simple cases of poor virtualization overhead we may expect to see something like ~30% worse performance compared to bare metal, so maybe an 8 minute ubuntu install instead of 5. Three hours means something is very broken somewhere - could be storage related as well as installs are usually very write heavy. If you attach a dmesg from XCP-ng it should make it clear what your hardware supports virt wise

@jivanpal I think trying to get OpenVswitch (our underlying network layer) managing and using a wifi dongle for core hypervisor networking would be a nightmare, and you'd probably need to install some extra packages to handle the authentication / WPA management etc - then of course there's zero guarantee OVS wouldn't overwrite or revert any of this custom stuff for said interface (OVS was not designed to work with wifi)

Not to mention you'd have to have a relatively hackable AP, one that will allow the dongle to source a lot of different MAC addresses, which is pretty rare. From OVS's own docu:

@Andi79 the guest RX messages are normal, some OSs like debian etc put unused interfaces in some type of "sleep" mode if I remember correctly and this causes these harmless messages

@Andi79 it's impossible to say without more testing, it could be a firmware issue on these boards causing IO stalls or similar, the only way to be sure now is to run some perf tests inside dom0 to confirm it's not VM related, once you get that confirmation, install (or live boot) plain CentOS on one of the machine and test there as well. Are both the SSD and the HDD underneath an mdadm software raid? I suppose it could be a software raid configuration issue as well, but it's hard to say without further testing

@olivierlambert definitely doesn't ring any bells but definitely smells like a storage issue, I would test disk performance directly in dom0 on the RAID SR using something like FIO, although we don't provide this in our repos so that would be difficult to get in dom0. perhaps a simple dd speed test under the SR mount directly, you should be able to find it by running df -h. Just be sure you don't overwrite any VM disk files

@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