If it's only the XAPI that was damaged, you can restore metadata from your XO/Pool metadata backup. Alternatively, if you forgot to make metadata backup, you can introduce SR to find back all your previous disks (but you will lose the medata data with it).

Great news! Thanks for the feedback

I have good experience with WiBu Key dongles and a "Matrix USB-Key" (also license dongle) but couldn't get an Aladdin HASP working. I can pass it through (it's visible and attached) but the VM doesn't show it in device manger (Windows 10 1909). I gave up for now and will probably use a network USB thingie from SEH - already have 2 of their devices running in different environments and they work flawlessly.

@stormi Thanks, looking forward.

So you have to dig in the SMlog to check what's going on

@ScarfAntennae At a glance, there are those links : Nvidia : https://docs.nvidia.com/grid/gpus-supported-by-vgpu.html https://www.nvidia.com/pt-br/data-center/graphics-cards-for-virtualization/ https://docs.nvidia.com/grid/13.0/product-support-matrix/index.html AMD : Introducing the AMD FirePro(TM) S7100X, the Industry's First and Only Hardware-Virtualized GPU for Blade Servers https://www.semiaccurate.com/2018/08/26/amd-v-series-virtualization-gpus-launch-with-the-v340/ https://techreport.com/news/29666/firepro-s7100-graphics-cards-bring-hardware-gpu-virtualization-to-life https://web.archive.org/web/20160507042500/http://www.tomsitpro.com/articles/amd-firepro-s1750-firepro-s7150x2-hardware-virtualization,1-3129.html https://www.amd.com/pt/graphics/workstation-virtual-graphics https://www.amd.com/system/files/documents/gpu-consistency-security-whitepaper.pdf https://www.techtarget.com/searchvirtualdesktop/opinion/Comparing-AMD-vs-Nvidia-for-virtual-desktop-GPU-cards https://www.reddit.com/r/VFIO/comments/nqf749/gpu_splitting_on_consumer_amd_gpus_vgpu_mxgpu/ https://github.com/DualCoder/vgpu_unlock - here there is a hack to make consumer GPUs able to provide vGPU So, coming from all those links, we would have to do : Add entries to the docs or do a separate wiki regarding this subject Design a "test bed" with some guidance so people can test their setups and GPUs Design some methods (and which tools could be used) to perform benchmarks and find possible bottlenecks regarding driver, synchronization, pass-through issues etc. We also would have to dig into specs of each vendor's GPU families and series, to find anything that could drag us to a more "precise" judgment on which ones does provide support for vGPU. @olivierlambert Could we create a GPU dedicated section on docs, and perhaps provide some GPU HCL - Hardware Compatibility List - regarding vGPU and who knows what else stuff is relevant ? Am I missing something here ?

@kagbasi-ngc tries this a while ago, but my default group are in OU having , or () in their name (i know it's very bad but it's been there before my arrival) tried with a security group in a simple OU this time it worked using fully DN.

The documentation is now in a much better shape than when I started this thread, has been available for months at https://xcp-ng.org/docs/. You can still contribute to it. Each page footer has a "help us improve this page" link that allows to create a pull request with your changes. Many thanks to everyone who contributed to the documentation and to those who will.

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

@ilidza no unfortunately not I opend a github issue. Here the link - Maybe you can ad something. https://github.com/vatesfr/xen-orchestra/issues/6097 @olivierlambert i have tried it on XOA - the same Issue. wuchererbe created this issue in vatesfr/xen-orchestra closed unknown filesystem type LVM2_member #6097

@flakpyro Thanks, that will probably save me an hour this summer if I decide to upgrade my production system. By then it might all be fixed.

Trying something new... Remove all servers from XO and log out. Host 1 is powered off. On host 2. xe task-list uuid ( RO) : 727ecb6b-6f2e-15eb-601b-110b2478996b name-label ( RO): Async.host.power_on name-description ( RO): status ( RO): pending progress ( RO): 0.000 xe task-cancel uuid=727ecb6b-6f2e-15eb-601b-110b2478996b Task is still there. From XCP-NG Center. Shutdown all VMs and host2 (All powered off). Powered up both servers. Wait 15 minutes to make sure no tasks are pending (xe task-list). Logging output to file via putty of; tail -f /var/log/audit.log Added host2 (master) to XO Settings/Servers. The Async.host.power_on task hasn't come back.

@olivierlambert deploying fresh copy worked and registered under different email. Thank you for assistance

@olivierlambert Awesome! Can't wait.

We have already a branch started with CBT (we had first to store the backup metadata outside the snapshot itself because we'll remove it with CBT). This work is now done and now Florent is directly working on CBT

@MathieuRA Thanks for doing the fix, I have tested this and I confirm it is working. I am able to migrate VMGuest to a different host by ticking the check box in the vmlist. [image: 1709761883728-29d4f92f-f074-488d-b2b3-27b74c2e0ae4-image.png] [image: 1709761905422-0b61a637-4dac-41a4-9aba-ba7c6db85c8b-image.png]

That's really weird

just a personal opinion I'm leaving here, no follow-up needed. If I want to run containers I use OKD. I've always seen all the comments about keeping the dom0 controller to a minimum, docker alone adds a 2GB overhead to it, no more problems in adding stuff to it.

Thanks for the feedback @mathiashedberg !