Testing the agent out on Arch Linux (mainly due to the spotty 'support' in the AUR/generally) and it is working fine - better than what I had before (which did not report VM info properly). I've set it up as a systemd service to replace the previous one I had, also working as expected. This would be fun to contribute towards.

@bleader just checked the Excel assessment file I got from the security team. They used Crowdstrike (sensor is not installed on xcp-ng hosts). The funny thing is, the asset that it reports as vulnerable is the VM that is running XOA (official image provided by XCP-NG). It is deployed recently, so everything is up-to-date, but even then I don't understand how it reports the XOA VM as the one containing the vulnerabilities.

@benapetr This is driven by hacky logic from 16 years ago: on revert, unserialize the previous state, and update the VM record with its saved values. As we do not want to modify that each time we add a field in the datamodel, use some low-level database functions to iterate over the fields of a record. Not very nice as it makes some assumptions on the database layer, but seems to work allright and I don't think that database layer will change a lot in the future. I think it might be a good idea to add a revert rpc call to the storage interface that xapi can call to, with a backup to use the current logic if necessary; xapi should be able to clean up the database afterwards. I'll ask other maintainers about this or possible alternatives, but since SMAPIv1 is considered deprecated, I doubt it will happen. I have to say that SMAPIv3 was finally fixed upstream on June by Xenserver (migrations were finally done!) and XCP-ng should get the update that fixes it in the coming weeks. Given this, I would encourage you to take all the learnings you've acquired while doing the driver and porting it to SMAPIv3. SMAPIv1 just simply has too many problems, some of them are architectural, so in general xenserver and xcp-ng maintainers would like to see it finally go away. for now I am still targetting XCP-ng 8.2 as that's what I use in production, and I haven't seen many SMAPIv3 drivers there. 8.2 is out of support for xenserver, and for xcp-ng yesterday was the last day it was supported, you really should update

@abudef Got it, the agent was not changed since the last version so the build number was not bumped. I'll keep that in mind for the next release.

Hi, There is an issue and/or a PR (I don't remember where though) to have a specific extra file to manage user config without overwriting it. Until then, it will be overwritten after updates. @Team-XAPI-Network could provide the link to the issue (or PR?) and check to make it merged when possible

Hello everyone, I absolutely understand the point regarding datacenters. I am using xcp-ng for years in smaller - non datacenter - environments and its great. Therefore I added the nut packages (8.2 and 8.3) and it works like a charm. It's installation is well explained in: https://xcp-ng.org/forum/topic/4300/performing-automated-shutdown-during-a-power-failure-using-a-usb-ups-with-nut-xcp-ng-8-2/13?_=1742229073030 However, I agree with @Kajetan321 that it would be great if the nut package could be included in the standard "updated" packages repo since its added quite some benefits (imho) for "smaller" IT environments. However, I do not know how much effort it takes to maintain that.

Yes, you can install Windows Server 2022 Essentials as a VM on XCP-ng, but the issue is likely due to using a DELL ROK DVD. ROK media checks for DELL hardware during setup and won’t work properly in a virtual environment like XCP-ng. Instead, download the standard Microsoft ISO for Server 2022 Essentials and install that. If your DELL key doesn’t work or you need a new one, you can get a genuine key from Noxkeys.com for around $20 worked perfectly for me. Activation was smooth after that.

@bogikornel As discussed in the thread, pygrub doesn't work. (It might be fixable, because copying kernel and initrd to dom-0 and directly setting PV-kernel, PV-ramdisk and PV-args works, which is basically what pygrub is supposed to do. But I stopped investigating as pvhgrub is a much better option which acually works.) You have 3 options copy kernel and initrd do dom-0 and configure xe vm-param-set uuid=... domain-type=pvh xe vm-param-set uuid=... PV-kernel=/dom-0/path/to/kernel xe vm-param-set uuid=... PV-ramdisk=/dom-0/path/to/initrd xe vm-param-set uuid=... PV-args="root=... ro console=hvc0 ..." xe vm-param-clear uuid=... param-name=PV-bootloader Not a very practical option, just PoC. use pvh-ovmf, but this requires UEFI-enabled VM (ie. GPT disk layout with EFI partition and some EFI bootloader or kernel directly in EFI with proper config (or as UKI) use pvhgrub. You need a recent grub2 to build the image for i386-xen_pvh target. Or just get the blob - this one is from Alpine package curl https://dl-cdn.alpinelinux.org/alpine/edge/main/x86_64/grub-xenhost-2.12-r8.apk | tar -xzf - --strip-components=3 usr/lib/grub-xen/grub-i386-xen_pvh.bin Save it to dom-0 (e.g. to /var/lib/xcp/guest/grub-i386-xen_pvh.bin) and configure the VM xe vm-param-set uuid=... domain-type=pvh xe vm-param-set uuid=... PV-kernel=/var/lib/xcp/guest/grub-i386-xen_pvh.bin xe vm-param-clear uuid=... param-name=PV-ramdisk xe vm-param-clear uuid=... param-name=PV-args xe vm-param-clear uuid=... param-name=PV-bootloader If the VM has valid grub2 config, it should work. Of course, you need a linux kernel with CONFIG_XEN_PVH enabled.

@ronan-a Thanks! I've installed the plugin, and configured it. Now to wait until the next power outage. (or until I get time this weekend to test it and annoy my family)

Upon further testing, it seems that initiating a rescan of the 0 byte SR fixes the size issue. However, I should not be having to do this but at least it appears to be more easily dealt with than I previously assessed.

@TeddyAstie I ran iperf3 tests between two VMs on Xeon E5-2680v2 and average results were within 2% of each other with the patch being slower. Peak speed was 14.5 vs. 13.7 Gbits/sec.

@gduperrey Got it, thank you for your assistance, this is super helpful.

@olivierlambert Fabulous! This is great news!

@LonnieTC Don't try to install XCP-ng as if it's any other Linux OS. It's an appliance, you need to download the XCP-ng ISO directly, install this to your hardware and then setup your management interface (Xen Orchestra). Xen Orchestra is installable to Ubuntu.

@guiand888 Thank you for the feedback. Just a note: before running XenClean, please turn off the "Manage Citrix PV drivers via Windows Update" option; otherwise, Windows will try to reinstall Citrix drivers as soon as it's rebooted. For the storage perf, Xen PV does fluctuate a lot at I/O performance (both network and storage), so the real performance would be better seen with long benchmark runs (depending on your I/O backend).

xe is a XAPI client, like XO is a XAPI client too. The issue with this, is if you have 1 pool it's OK. If you have many pools, it's a lot better to use XO API.

FYI and for what it's worth - In my experience as of Jan 2025, the process aligns with RHEL and appears to have no issues. From a fresh install of Alma 9.5: sudo dnf install epel-release sudo dnf install xe-guest-utilities-latest sudo systemctl enable --now xe-inux-distribution graphs and other Xen Orchestra behaviours work as expected.

turned out that this is not necessary. An easier option is to simply add the bootparameter aacraid.numacb=1000 before booting into xcp-ng. As of my current understanding this makes sure that the xen-specific larger management fib size of 16 is taken into account (the driver default is 8). Only tested on Version 8.2.1

@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