Learn how to resolve PCI device disruption issues, configure network settings, enable IOMMU, and passthrough SATA controllers for optimal performance in Proxmox VE. Includes troubleshooting tips and best practices for hard drive passthrough and system stability.

PCI Device Disruption Issue  

This issue is caused by changes in motherboard settings or the addition of new PCI devices, requiring a re-passthrough of hardware. It is also related to the motherboard itself. For example, when I used the Supermicro X11SRA-F to replace a PCIe device, there was minimal change, but with the Supermicro X10DRL-i, the change occurs, though not always.

Solution: Avoid setting virtual machines to auto-start; manually adjust after each hardware change.

Reconfigure Network

You can manually edit the file “/etc/network/interfaces” to configure the network.

Alternatively, you can perform graphical operations: bridge ports, separating them with spaces, and bind multiple network interfaces together.

Afterward, don’t forget to click “Apply Configuration.”

A quick complaint: PVE limits adding no more than 5 PCI devices to a virtual machine. PVE does have some stability and minor issues, but it can be made relatively stable for long-term use with slight compromises.

Additionally, it seems that passthrough of more than 6 SATA controllers will also cause errors.

Resolve PVE Network Card Confusion

First, identify network card names one-to-one:  

lspci | grep -i ethernet

Example output:

The addresses at the beginning are PCI bus addresses in hexadecimal. Based on related rules, the corresponding network card names are:

Onboard network cards: “eno1”, “eno2”

The 2.5G network cards, based on hexadecimal, are:  

“f” corresponds to 15, “10” corresponds to 16, “11” corresponds to 17, “12” corresponds to 18, so the names are “enp15s0”, “enp16s0”, “enp17s0”, “enp18s0”.

Enable IOMMU

This step is almost mandatory.

Enable kernel IOMMU support:    

vim /etc/default/grub

Change:  

GRUB_CMDLINE_LINUX_DEFAULT=”quiet”  

to  

GRUB_CMDLINE_LINUX_DEFAULT=”quiet intel_iommu=on iommu=pt pcie_acs_override=downstream video=efifb:off”

Then run:  

update-grub

reboot

Hard Drive Passthrough and Sleep

It is possible to passthrough a hard drive via the “qm” method, but it is not recommended.

The best method is still passthrough of the SATA controller because:  

1. It allows sleep mode, hard disk health checks, and fully utilizes the advantages of a NAS system.

2. When the virtual machine is powered off, the hard drive is completely powered off, not in sleep mode. This saves power and extends the lifespan of mechanical hard drives.

My Supermicro motherboard has two SATA controllers, one with 4 ports and the other with 6. The 4-port controller is used for running the PVE host system, so I passthrough the other 6-port SATA controller to TrueNAS, typically using mechanical SATA or SAS disks for cold backup, which are rarely powered on and only temporarily started during scheduled backups.

For regular data, I use PCI-to-M.2 SSD to switch between “all SSD NAS” and “mechanical NAS.”

Note: If your host machine uses a SATA SSD, never passthrough the SATA controller directly (because some users might rashly attempt this).

Simple “qm” Passthrough Method

Check the storage device’s ID and remember it:  

ls /dev/disk/by-id

Then map the hard drive:  

Note: Here, replace “107” with the actual VM ID, and “sata1” can be replaced with an unused ID (PVE supports “sata0-5”).

qm set 107 -sata1 /dev/disk/by-id/ata-TOSHIBA_MG06ACA10TE_6970A01YFKQE

If the following message is returned, the mapping was successful:  

update VM 107: -sata1 /dev/disk/by-id/ata-WDC_XXXX_XXXX_XXXX

Check on the web interface under VM 100 to confirm success, then proceed with further operations.