@john-c said in USB Passthrough Override Script - to ensure usb-policy.conf consistency:

This is no longer needed if you have Xen Orchestra version 5.93 or later, alternatively if using in home lab and from source then any commit dated after 29th March 2024 (or current head on GitHub Main - Master). The reason being that Xen Orchestra from version 5.93 has official support for USB Passthrough and later from version 5.95 you can do PCI Passthrough.

This is unfortunately still needed, as otherwise the XO simply does not show the PUSB in the host, so it cannot be assigned as a VUSB for the VM.

@zeropointer thanks for the idea, this seems to be the most pragmatic solution.

Everything told here is already in our (huge) backlog 🙂

CCing @bleader too.

@sapcode said in openssl 1.1.1 update or manual build in XCP 8.2.1 possible ?:

Would it be safe to run yum remove openssl as the first step or would this break the XCP installation:

The second option. And actually it's not openssl you're looking for, it's openssl-libs, and removing it will not even work, as it attempts to remove yum and systemd which depend on it and are protected.

Note that we do offer openssl 1.1.1 through the xs-openssl-libs package, and that is what XAPI uses for communication instead of the system one. However you'd have to patch and rebuild curl or wget so that they use it, and this definitely voids your warranty.

You are going on a journey that is far more difficult than you initially expected, I fear. So I'd start questioning the initial needs again.

Why do you need to contact websites such as ssl-tools.net from dom0? Can't you do it from a VM?

@olivierlambert said in Redhad CoreOS and Guest Tools installation:

Have you tried with the new Rust guest tools?

Sorry for the delay in replying, I have not. I'll see if I can find them and install them.

@mhomoky Thanks, worked perfectly fine.

deb [trusted=yes] https://gitlab.com/api/v4/projects/xen-project\%252Fxen-guest-agent/packages/generic/deb-amd64/ release/

No issues in Cloud-config

Also for hostname, I just used {name}without any %

The only thing missing is being able to reapply cloud-init configs or easy reconfigure from the Ui. But that's for another topic.

@olivierlambert Thanks 🙂

@probain As @olivierlambert said, Redis is used to story very little data, and we are already thinking about migrating away from it. We would like to use a simpler solution that would not require users to manage it like an SQLite database.

For the time being, we will likely keep Redis as long as it's available in open source distributions like Debian but we are keeping an eye on it 🙂

@cg Those HDD's will take their fair time to rebuild.
Always stressful looking how far along it is while crossing your fingers that another drive wont pop during the process.

@julien-f
I can confirm that the fix worked! Snapshots are back and working.

I am impressed at how quick you managed to fix it too.
Thanks!

@wolfmon You have this documentation https://xenbits.xen.org/docs/unstable/man/xl.1.html
But be careful, most operations of xl are not officially supported in XCP-ng.

@CJ yum update from 8.3 beta to 8.3 will be possible, but I still recommend using the ISO. In a perfect world, yum update would give you exactly the same result, but in reality there are always corner cases where files or packages are left behind (we have no sane way to tell yum/rpm to remove an installed RPM, unless making another RPM obsolete it and thus make it impossible to reinstall later if someone needs it for a good reason).

@mohammadm i think for nfs you should handle that from the kubernetes side. i.e. use an nfs-provisioner or the built-in nfs storageclass

@thepro101

i would install the guest-tools right from the start after base install of the os.

create min 3 nodes, install them as you like with guest-tools and then install the first rke2-node. read the docs how to config metallb on rke2. you have to do a small config tweak in the nginx ingress controller config

then add the other nodes.

to manage rke2 i would use openlens.

you can use democtratic-csi but be aware that you completely trust truenas and this opensource-project for your data. i dont think that i would go this route when i am not expirienced with k8s.

i would use the nfs-provisioner and when everything works fine and you have a solid csi-enabled backup you can add democratic-csi in the mix.

for us, backup and restore was the biggest problem. in theory everything seebs easy with k10 or velero but if you completely shoot your cluster you will have a very hard time.

to be honest, after 6 month and some installations we gave up on k8s and migrated our customers and our internal IT to a setup where we use openSuse MicroOS VMs for every docker-compose project. We now have approximately the same amount of VMs which we had as namespace but with the benefit of complete control over resources with very little overhead. And we have the benefit of an optimal backup and restore.

K8S bite me quite a bit too often 😉

@Nux rebuilding the dom0 kernel is quite tricky, and I am not sure it is going to help your usecase, if you really want, you may want to look on xcp-ng-rpms and the related linux rpm
Regarding nested Hyper-V in Xen, gen2 support was considered in the past, but it never got fully implemented, see https://lore.kernel.org/xen-devel/20191130115737.15752-1-liuwe@microsoft.com/
and https://lore.kernel.org/xen-devel/20190923100931.29670-1-liuwe@microsoft.com/ for related discussion on the Xen mailing list.
So as it is now, Xen in Hyper-V gen2 vm is not supported.
Only gen1 is supported on a best-effort basis.

Gen1 use realistic-behaving emulated devices, thus there is no Hyper-V specific driver that may improve performance.

@jasonnix depends on what PV driver you want to implement.
But such place would be the Xen MiniOS repo (tiny PV kernel project that serves as a base for Unikraft among others) : http://xenbits.xen.org/gitweb/?p=mini-os.git;a=tree

Also give a look at https://wiki.xenproject.org/wiki/Unikernels