My current findings regarding this:
https://github.com/xcp-ng-rpms/microsemi-aacraid/issues/2

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

Tried to Boot the Installer for XCP-ng 8.3 beta 2 ISO (07-Feb-2024 19:21) on my Testmachine today:

Gigabyte B550 AORUS PRO AC
AMD Ryzen 7 3700X 8-Core Processor
Adaptec 6405E (Hardware-RAID PCIe 2.0-Card)

But the (discontinued by Adaptec but flawlessly working) RAID 6405E creates the following Errors (as in 8.2) on Boot:

aacraid 0000:03:00.0: AAC0: aac_eh_abort: Host adapter abort request.
aacraid 0000:03:00.0: AAC0: aac_eh_abort: Timed out Command

In case anyone wants to fix this, this is my other forum posts regarding this:
https://xcp-ng.org/forum/post/47040 (RAID 6405E)

Adaptec RAID 8405E (also discontinued by Adaptec but newer) is on my productive System and I cannot test 8.3 at the moment there, but as I am aware of it should be better supported with 8.3. In case I manage to test it there, I will update you in this thread.
https://xcp-ng.org/forum/post/47048 (RAID 8405E)

https://github.com/xcp-ng/xcp/issues/472

@Andrew Thanks! How to close this issue?

@Andrew
Yess!
After specifying "async" on the NFS-Server I get 70 Mbytes/Second
Is there any downside for using "async" in this context?
Thank you!

Hi XCP Community,

I use self-build Xen-Orchestra latest version; commit: 1961d; running as a VM
xcp-ng 8.2.1 on an

B450 AORUS ELITE Mainboard
AMD Ryzen 5 3600XT 6-Core Processor

XCP-NG ist installed on a single SSD with 256GB.

Additonally there is an Adaptec-PCI-Raidcard connected with a Raid1 of 2x4TB HDDs.

Local-Storage on the XCP-NG host ist EXT4! Dom0 Ram is 1,6 GB.

I am connected to a RaspberryPi4 USB-HDD with NFS for Backups.

For Test Purposes, every VM including Dom0 is on the single SSD only (you can Ignore the Raid1).

Following things run as fast as expected:

• Normal "Backup" of a random VM from Xen-Orchestra to the RaspberryPi4 - no matter if hosted on the SSD or on the Raid1.
• Test-File-Transfer via Command Line into mounted NFS share on Dom0, Xen-Orchestra-VM or random VM.
• iperf benchmark for network connection is fine between Dom0<->XO-VM; Dom0<->RapsberryPi4; XO-VM<->RaspberryPi4; RandomVM<->Dom0 and RandomVM<->XO-VM

Networkspeed I get is 1 Gbit/s, HDD-Speed is far over 60MB/s.

But I don't get this numbers when using "Continuous Replication".
I only get 4-6 Mbyte/s speed when I want to Backup the "RandomVM" to the NFS-Share on the Raspberry. (No matter if the VM is "ON" or "OFF")

I see via htop that there seems to be two processes involved "tapdisk" and "vhd-tool serve" when doing a "Continuous Replication". In the "Disk Write" Column of htop I only get approximatly 5.27 to 6.60 M/s for these two processes. Tapdisk is always a few Kbytes faster than the "vhd-tool serve".

In the Logfiles I cannot find anything which would help me further.

Any Ideas to find the bottleneck?

Things tried:
Used "http://" for connecting the server with XO. -> No change.

Thanks!

Hi everyone!

This is work in progress! May not work for everybody.

See story below!

1. Install Buildtools:

yum install make gcc kernel-devel

2. Download latest driver for your Card - maybe works also for other Adaptec Cards:
   https://storage.microsemi.com/en-us/support/raid/
   --> Linux Driver Source

3. Unpack the Sourcefolder

4. For the compilation to work for XCP-NG you have to specifiy the C-Preprocessor-Definition: "AAC_CITRIX"! (add "#define AAC_CITRIX" to the beginning of the aacraid.h-File.)

sed -i '1s/^/#define AAC_CITRIX\n/' ~/aacraid-1.2.1-60001/aacraid.h

5. Compile

make

6. Copy resulting Kernel-Module into the Place where it is called.

cp aacraid.ko /lib/modules/4.19.0+1/updates/

depmod -a
modprobe -v aacraid
dracut -f /boot/initrd-4.19.0+1.img 4.19.0+1

8. To check initramfs:

lsinitrd /boot/initrd-4.19.0+1.img | grep aacraid

Reboot and be Happy - hopefully

---

Story:

I replaced my Adaptec ASR-6405E PCI-Raid-Controller-Card with the ASR-8405E.

Getting the Adaptec ASR-6405E to run was quite a challange for me, see this forum-post how to do it.

With the Kernel and the ALT-Kernel I got no connection to the controller -> If I remember correctly; Maybe I failed to Update Initramfs from my old raid-card-driver which caused this - I am not sure because I am still learning how linux works.

I got the following following Error during boot (and dmesg | head) - not sure anymore what driver was loaded:

AAC0: fib_map_alloc:pci_alloc_consistent failed

After a lot of involvment with the Source-Code of the Driver of Adaptech my insight was that there are two Driver Branches of the so called "aacraid" driver.
One is maintained from Linux Kernel Team (https://www.kernel.org/) and the other from the manufacturer Adaptec (https://storage.microsemi.com/en-us/support/raid/).

XCP-NG 8.2 uses at the moment of this writing the Driver Version from the Linux Branch:

microsemi-aacraid: (built-in) 1.2.1[50877]-custom
Source1: https://github.com/xcp-ng/xcp/wiki/Drivers
https://github.com/torvalds/linux/commit/1cdb74b80f93343d7b44b5d99b28d9b0c46375ba <--???

I don't know how PCI works and I am not a Driver-Developer but the following code-area here is the source of the fib_map_alloc error. It seems that Xenserver has other restrictions on some pci-parameters than the normal Linux kernel - therfore it's necessary to give the Compiler the Preprocessor-Definition "AAC_CITRIX" so that some allocated Memory gets properly managed by the driver to work with XCP-NG.

Filename: comminit.c (Driver Version 56008 from Adaptec-Website)

...
if (aac_is_src(dev)) {
#if(defined(AAC_CITRIX)) /*<------ /*
  if (host -> can_queue > 248)
    host -> can_queue = 248;
#elif(defined(CONFIG_XEN) && LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 19))
  if (host -> can_queue > 128)
    host -> can_queue = 128;
#else
  if (host -> can_queue > (status[3] >> 16) - AAC_NUM_MGT_FIB)
    host -> can_queue = (status[3] >> 16) - AAC_NUM_MGT_FIB;
#endif
} else if (host -> can_queue > (status[3] & 0xFFFF) - AAC_NUM_MGT_FIB)
  host -> can_queue = (status[3] & 0xFFFF) - AAC_NUM_MGT_FIB;
dev -> max_num_aif = status[4] & 0xFFFF;
}
else
  aac_info(dev,
    "Driver Init: GET_COMM_PREFERRED_SETTINGS 0x%lx failed\n",
    (unsigned long) status[0]);
...

Now the Adapter is working on the latest Adaptec-Driver :-).

Thank You all being a part of this wounderful project!