@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

@psafont said in Stunnel - Future plans to use something else?: @nikade We've already fixed some issues to start using ocaml 5 regarding the C interfaces. Handling threading in ocaml 5 is still an open problem that the ecosystem has not yet solved (there are many libraries competing now). We still need to create a credible strategy to port xapi to the new model, and don't have any timelines yet Yea porting it is probably not a bad idea, but I guess that involves the biggest tasks as well All tho if you port it there might be opportunities to re-do a lot of things that you have been looking to fix for ages. Crossing my fingers that this is something that you get time to do in the near future, there is a real chance here to take a big part of the esxi market as a lot of ppl are migrating.

@olivierlambert I think so. ceph.ko anyway isn't a core module for XCP-ng, so I don't think there's a high risk in patching it, especially with patches coming from upstream kernel.org. Regarding the initial question, XCP-ng 8.3 will also have a newer kernel-alt. However, I don't recommend it for production, because it is a lot less tested in the context of XCP-ng.

@TheiLLeniumStudios I'm trying to do something similar with Talos, were you able to find a workflow that worked for you since this post?

Hi, It depends on your Windows version (eg > 2019 : go for XenServer drivers). Those PV drivers are pretty stable and works. Alternatively, you can use https://www.xenserver.com/downloads

Our latest update train should provide full vTPM support or close to that (even for migration/snapshot). It's 8.3 beta 2. See https://xcp-ng.org/forum/post/68789

Yes, we are considering OpenELA for many reasons. It's backed by big companies with a common goal, so it's probably less risky than other choices (but Alma is also an interesting choice anyway). As usual, it will be loosely based too: it's relatively impossible to "transform" a regular distro to XCP-ng, but it is very helpful to re-use many packages as possible for reducing the burden of maintaining them all

Well, it's not really possible to answer with a short answer. Globally, for the whole platform, we are talking about hard in a way that it takes time.

@ThierryC01 said in XCP-ng Windows PV Drivers 8.2.2: Why is there no video drivers for Windows, I have a Windows 10 Pro VM and the video lags a bit compared to my Linux Desktop VMs despite having 8GO RAM and 16MO (?16 max???) video memory. Because it's rudimentary GFX and has no acceleration at all. It's not made for what you might expect.

Hi, No, nothing urgent to update them. It's mostly minor changes

@reinvtv @jedimarcus Checking Netbox feature requests right now Would this feature still be important to you? I'm also wondering: at the moment, there's a button in the pool's advanced tab to manually run a synchronization for that pool. But with multiple instances, how would that work? Would it synchronize the pool with all the configured instances? What if you only ever wanted to sync pool A with instance A and pool B with instance B?

@Andrew said in RTL8153 Compile: @etomm For the code I compiled it mostly as-it (with one change to support the different XCP kernel header version). I also added three udev rule changes. One is included with the driver code. One change to stop XCP scripts changing USB ethernet names. And one that is to support static USB ethernet names and rename unknown USB ethernet devices to protect the system from conflicts. I now have it working correctly with multiple USB ethernet adapters and stabled names that don't interfere with regular ethernet adapters. It still requires manually adding the MAC addresses and ethernet device names because XCP/Xen does not support USB ethernet devices. @Andrew would you be willing to share the udev rule changes that you made? Also, are you using 8.2 or 8.3 beta? Thank you!

Hi! Link fixed, thanks for the report! This is indeed: https://github.com/xcp-ng/xcp-ng-xapi-storage/tree/add-zfs-vol-driver

No sure this will be compatible with the level of memory isolation provided in Xen (vs the more "open bar" model in KVM). Worth taking a look though, thanks for the link.

We'll be pleased to you review your future contributions

Hello, just a follow-up I figured out probable fix for performance issues (the locking issue seems to have disappeared on its own I suspect it happened only due to upgrade process as pool contained mix of 8.0 and 8.2 hosts) It was caused by very slow (several second) executions of basic LVM commands - pvs / lvs etc took many seconds. When started with debug options it seems it took excessive amount of time scanning iSCSI volumes in /dev/mapper as well as the individual LVs that were also presented in /dev/mapper as if they were PVs - it actually subsequently ignored them but still those were (in my case) hundreds of LVs and each had to be open to check metadata and size. After modifying /etc/lvm/master/lvm.conf by adding this: # /dev/sd.* is there to avoid scanning RAW disks that are used via UDEV for storage backend filter = [ "r|/dev/sd.*|", "r|/dev/mapper/.*|" ] Performance of LVM commands improved from ~5 seconds to less than 0.1 second and issue with slow startup / shutdown / snapshot of VMs (sometimes they took almost 10 minutes) was resolved. Of course this filter needs to be adjusted based on specific needs of the given situation. In my case both /dev/sd* as well as /dev/mapper devices are NEVER used by LVM backed SRs, so it was safe to ignore them for me. (all my LVM SRs are from /dev/rbd/)

@JacobS Hi ! You can find it here : https://xcp-ng.org/forum/topic/5361/xostor-hyperconvergence-preview (PS: I'm using XOSTOR with 3 nodes, and it's works well!)

Some time later I faced with problem that VMs (Linux and Windows) can't correctly start GPU (ADM MxGPU). In windows device manager there was error #43. I have solved this error without host reboot by reloading gim module. Hope this will help somebody else. rmmod gim gim_api modprobe gim gim_api