HBA - PCIe pass-through HP380g9 w/ P840 card for Xpenology "works" but pegs hosts processor.

vetvetter

New Member
Apr 23, 2024
5
0
1
Hello everyone,

Over the last bit I have been working on setting up my Proxmox 8.1.4 cluster. I will be running 2 nodes with an extra eventual witness disk likely on a raspberry pi. Been working through the PCIe pass-through for NVME's as well as in this case HBA to Xpenology.

I have been able to work through all of the issues to in fact get this working. NVME's pass-though works great on both current nodes without issue. Boxes work great and speed seems to be around what I would expect.

The problem comes in when I try to passthrough my P840 card in HBA mode. I have the card blocked ID as well as the HPSA drive via config files in /etc/modprobe.d/.

I also ran # update-initramfs -u -k all and rebooted the node. At that point Proxmox no longer saw the drives anymore which is the desired result. I spun up a new Xpenology VM with correct perams plus P840 HBA pass-through and upon boot was going REEEEEEALLLY slow. Then it would just hang on boot. Host was noticibly slugish and CPU + Mem on the VM seemed pretty pegged.

I got everything shut down tried a few things and found some articles about turning off memory balloning for the VM as well as turning off rombar=0 via uncheck box inside of the PCIe passthrough via VM settings gui. All of the settings in a fresh created VM just to be on the safe side.
At this point the VM would at least boot up and I could go throug the Arc Loader Xpenology setup. Problem is it did seem sluggish again but I was able to see my drives passed through OK inside of DSM. But the box was REEEEALLLY slow again.
Turning off the VM doesn't seem to work gracefully or not gracefully. I could not get out of the box flogging the CPU until I rebooted the node. Then it was fine until I tried the HBA passthough again.

I think at this point I might just pass the drives through themselves rather then the whole HBA. That does seem to work fine. I just wanted to get the best performance possible thus trying the HBA pass-through. In this case it seemed to me quite the opposite!

Wanted to see if anyone has seen anything like this before. I am going to post my # TOP results if it helps. This was with the pass-through VM off after it had been on. Clearly something was flogging the CPU still:

top - 22:49:19 up 2:06, 1 user, load average: 1.07, 2.15, 2.25
Tasks: 885 total, 1 running, 884 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.9 us, 1.2 sy, 0.0 ni, 97.9 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
MiB Mem : 257781.5 total, 252149.7 free, 5959.6 used, 1246.1 buff/cache
MiB Swap: 0.0 total, 0.0 free, 0.0 used. 251821.8 avail Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1923 root 20 0 171748 102688 5376 S 45.3 0.0 17:45.56 pvestatd
25927 root 20 0 11744 4928 2688 R 16.4 0.0 0:25.27 top
1892 root rt 0 557328 163984 52432 S 14.3 0.1 13:56.49 corosync
25868 www-data 20 0 255428 144404 7168 S 3.0 0.1 0:03.47 pveproxy worker
7290 root 20 0 0 0 0 I 2.7 0.0 0:05.73 kworker/22:2-events
17 root 20 0 0 0 0 I 1.6 0.0 1:12.53 rcu_preempt
1814 root 20 0 631516 58448 52588 S 0.8 0.0 1:49.80 pmxcfs

 
Also these are pretty beefy nodes. Dual e5-2660v4 / 256gb ram in each. Booting from USB attached NVME drives. Seperate NVME drives for pass-through and some large spinners.
 
I'm having exactly the same issues with same kit bar using E5-2650v4 with 128gb ram also booting from nvme although not passing through any others. It hoses the main proc and all fans hit 100% - sounds like a hanger at heathrow.
Any clues please.
 
i have the same (or similar issue). passing trough the P840 with ROM-BAR enabled just gives me an endless Configuring controller... message. Disabling ROM-BAR seems to help, but after a while iLO throws a critical error on the controller and fans spin up to 100%.
my goal was to use ZFS on the device, what makes it basically a no-go for disk passtrough...
as the computer is quite old already I am surprised this issue has not popped up earlier. maybe something in the recent PVE releases causing this behaviour?

EDIT: i am also thinking about removing the cache module from the card, if that will help with the passtrough issue...
 
Last edited:
i have the same (or similar issue). passing trough the P840 with ROM-BAR enabled just gives me an endless Configuring controller... message. Disabling ROM-BAR seems to help, but after a while iLO throws a critical error on the controller and fans spin up to 100%.
my goal was to use ZFS on the device, what makes it basically a no-go for disk passtrough...
as the computer is quite old already I am surprised this issue has not popped up earlier. maybe something in the recent PVE releases causing this behaviour?

EDIT: i am also thinking about removing the cache module from the card, if that will help with the passtrough issue...
Was never able to pass through the entire HBA but I was easily able to pass through all the drives including the NVMe not shown here to the VM
HTH

qm set 330 -scsi1 /dev/disk/by-id/ata-SAMSUNG_MZ7TE128HMGR-000H1_S1BDNSAG607779
qm set 330 -scsi2 /dev/disk/by-id/scsi-35000c500572bbebf
qm set 330 -scsi3 /dev/disk/by-id/scsi-35000c50058cf033b
qm set 330 -scsi4 /dev/disk/by-id/scsi-35000c500570e825f
qm set 330 -scsi5 /dev/disk/by-id/scsi-35000c500589f6947
qm set 330 -scsi7 /dev/disk/by-id/scsi-35000c500589f8307
qm set 330 -scsi6 /dev/disk/by-id/scsi-35000c500589f5f83
 
  • Like
Reactions: Penetr8tor
over at reddit some guy managed to get it work.... by throwing out the P840 and replacing it with a LSI 9300. so far that is the closest thing to a solution i've seen and I am planning to do it once I decide if i really need that HP machine in my homelab
 
over at reddit some guy managed to get it work.... by throwing out the P840 and replacing it with a LSI 9300. so far that is the closest thing to a solution i've seen and I am planning to do it once I decide if i really need that HP machine in my homelab
We always need the things we have in our home lab. We will throw money at it even it’s not cost effective just to make it work. Lol
 
Fine. Just understand that this is still a virtual drive, even though "write data to block 1234" will result in data written to block 1234. The VM has still no direct access to the hardware. Afaik.

Please verify: can you see SMART-data from inside the guest? (https://en.wikipedia.org/wiki/Self-Monitoring,_Analysis,_and_Reporting_Technology)
Tbh, I don't really worry about SMART-data - I'm running TrueNAS with 7 mirrored vdevs, cache-drive, log drive and an online spare.... what could go wrong besides the controller anyway :D
 
Tbh, I don't really worry about SMART-data - I'm running TrueNAS with 7 mirrored vdevs, cache-drive, log drive and an online spare.... what could go wrong besides the controller anyway :D

The seven drives from post #5, right? With 2*2 mirrors+cache+slog+spare? Yes, it may run forever. But personally I would not put any important data on it.

Good luck! :-)
 
The seven drives from post #5, right? With 2*2 mirrors+cache+slog+spare? Yes, it may run forever. But personally I would not put any important data on it.

Good luck! :-)
Yes, from post 5 - it was so long ago i forgot to respond sry.
The DL380 G9 I have only has 16 Bays - 14 of the drives [7vdevs] - rust, the cache is an SSD - the slog is dual 128GB NVMe - [zfs clears it every 5 secs so doesn't need to be larger] and the 16 bay is for the online spare.
I was as diligent as I could be to make this work well ans so far fingers crossed.
That being said - I would never underestimate someone's personal view. I am very interested to hear why you wouldn't think it safe for important data
BTW - this is not the backup it's the working storage for most of my VM's and containers that aren't running on the Ceph cluster
 
Last edited:
Actually I rely on the makers of TrueNAS - they should know, don't they? This old article is still valid: https://www.truenas.com/community/r...guide-to-not-completely-losing-your-data.212/

The main point is that virtual disk are not a good basis for TrueNAS. They insist on pass-through a controller.
Thanks very much for that - read thoroughly [plus the other links inset] - interesting that passing through the drives with the controller in HBA mode and therefore using RDM IS supported in Proxmox but NOT unsupported in VMware. I can't find any sources where people have had this go wrong and demonstrated why, albeit that they say it 'happens' with FreeNAS/TrueNAS; so, I am duly warned shall we say

ALL the drives are being SMART monitored in Proxmox even though they're being passed through I can get readings from Proxmox while they are running in the VM but not from the VM - makes sense to me.

I do find it Interesting that despite the entire drive being passed through that it is considered a 'virtual drive' when I can spark up the Baremetal with a USB and import the pool directly into FreeNAS/TrueNAS using the same drives and it still works?? - Then booting to USB on the baremetal sees the whole system including the HBA and can see the smart values since nothing is virtual - but it proves the portability/integrity of the ZFS pool. Also my pools are scrubbed 3 times week so there is error checking going on -

The fact that I use a separate dedicated and NOT integrated PCIe Controller in HBA mode which mode mitigates the concerns that ZFS expects to be able to strictly control write ordering and cache flushing towards the drives, since it can and does have direct control over the drives which is what ZFS needs and actually what the creators of ZFS say. Add to that - you need to look at the solution in context - 99.9% of the issues reported are VMware related which does not support RDM anyway. There also seems to be a lot of issues where NOT enough resources are allocated to the VM in general. I have 128GB RAM dedicated to the VM [most of which is L1ARC] and 2 sockets [with numa] and 8 cores each using host processor.

I am still therefore not convinced and that the issues you are warning against are not relevant to this specific setup.

I will come back and update should I discover that changes
 
Last edited:
  • Like
Reactions: UdoB
Thanks for the latest post.
ALL the drives are being SMART monitored in Proxmox even though they're being passed through
That is one sign that they are not really passed over to the VM but belong to the host. Only a virtual abstraction is handed over to the VM - with as many identical parameters (drive geometry etc.) as possible.

Obviously it works for you. That's fine. And you do monitor the situation actively. And you know that there may happen "something". As long as you have enough frequent backups you still can sleep well, I believe.

Best regards!
 
  • Like
Reactions: Penetr8tor