Trying to passthrough sata/sas controller

[ruffpl]

From couple days I am trying to passthrough sata drives to my Xpeology VM.I need to connect 8 drives (6 for the btrfs pool + 2 extra), so I have to pass the limit somehow. I tried with "qm set" command- works with sata but with scsi it mounts only first drive and only when megaraid is selected. I had enabled IOMMU for Intel in Proxmox grub config file so I could passthrough whole (integrated on mobo) LSI Logic Megaraid 3108 controller where all needed drives are connected. It looks like that:

root@PROXMOX:~# dmesg | grep -e DMAR -e IOMMU
[ 0.010263] ACPI: DMAR 0x00000000799D68C0 0000BC (v01 ALASKA A M I 00000001 INTL 20091013)
[ 0.070731] DMAR: IOMMU enabled
[ 0.163696] DMAR: Host address width 46
[ 0.163697] DMAR: DRHD base: 0x000000fbffc000 flags: 0x1
[ 0.163701] DMAR: dmar0: reg_base_addr fbffc000 ver 1:0 cap d2078c106f0466 ecap f020de
[ 0.163702] DMAR: RMRR base: 0x0000007bc18000 end: 0x0000007bc27fff
[ 0.163703] DMAR: ATSR flags: 0x0
[ 0.163704] DMAR: RHSA base: 0x000000fbffc000 proximity domain: 0x0
[ 0.163706] DMAR-IR: IOAPIC id 1 under DRHD base 0xfbffc000 IOMMU 0
[ 0.163707] DMAR-IR: IOAPIC id 2 under DRHD base 0xfbffc000 IOMMU 0
[ 0.163708] DMAR-IR: HPET id 0 under DRHD base 0xfbffc000
[ 0.163709] DMAR-IR: Queued invalidation will be enabled to support x2apic and Intr-remapping.
[ 0.164051] DMAR-IR: Enabled IRQ remapping in x2apic mode
[ 1.153102] DMAR: dmar0: Using Queued invalidation
[ 1.162793] DMAR: Intel(R) Virtualization Technology for Directed I/O


After that I can add the sata/sas controller ( 0000:01:00.0, IOMMU group 26, Lsi Logic/Symbios Logic Megaraid SAS-3 3108 invader, not mediated device) to VM, but after I start it there is no way to login to VM by ip number.

 

[Stefan_R]

Any logs from the start attempt? I.e. the task log from the "VM start" (or the console output when using "qm start <vmid>" on the CLI), dmesg, journalctl -e

Does the VNC console of the VM show something?

 

[ruffpl]

VNC starts normal with info "....open http://find.synology.com to continue". After VM start, zfs pool and other disks connected to LSI controller disappear from proxmox/disk menu. Syslogs looks like this:

Mar 24 17:30:00 PROXMOX pvedaemon[14131]: start VM 201: UPIDROXMOX:00003733:0000C01A:5E7A3588:qmstart:201:root@pam:
Mar 24 17:30:00 PROXMOX pvedaemon[1991]: <root@pam> starting task UPIDROXMOX:00003733:0000C01A:5E7A3588:qmstart:201:root@pam:
Mar 24 17:30:00 PROXMOX systemd[1]: Starting Proxmox VE replication runner...
Mar 24 17:30:01 PROXMOX systemd[1]: pvesr.service: Succeeded.
Mar 24 17:30:01 PROXMOX systemd[1]: Started Proxmox VE replication runner.
Mar 24 17:30:01 PROXMOX systemd[1]: Started 201.scope.
Mar 24 17:30:01 PROXMOX systemd-udevd[14140]: Using default interface naming scheme 'v240'.
Mar 24 17:30:01 PROXMOX systemd-udevd[14140]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
Mar 24 17:30:01 PROXMOX systemd-udevd[14140]: Could not generate persistent MAC address for tap201i0: No such file or directory
Mar 24 17:30:01 PROXMOX pvedaemon[1989]: zfs error: cannot open 'STORAGECENTER': pool I/O is currently suspended
Mar 24 17:30:02 PROXMOX kernel: device tap201i0 entered promiscuous mode
Mar 24 17:30:02 PROXMOX systemd-udevd[14140]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
Mar 24 17:30:02 PROXMOX systemd-udevd[14140]: Could not generate persistent MAC address for fwbr201i0: No such file or directory
Mar 24 17:30:02 PROXMOX systemd-udevd[14147]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
Mar 24 17:30:02 PROXMOX systemd-udevd[14147]: Using default interface naming scheme 'v240'.
Mar 24 17:30:02 PROXMOX systemd-udevd[14147]: Could not generate persistent MAC address for fwpr201p0: No such file or directory
Mar 24 17:30:02 PROXMOX systemd-udevd[14139]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
Mar 24 17:30:02 PROXMOX systemd-udevd[14139]: Using default interface naming scheme 'v240'.
Mar 24 17:30:02 PROXMOX systemd-udevd[14139]: Could not generate persistent MAC address for fwln201i0: No such file or directory
Mar 24 17:30:02 PROXMOX kernel: fwbr201i0: port 1(fwln201i0) entered blocking state
Mar 24 17:30:02 PROXMOX kernel: fwbr201i0: port 1(fwln201i0) entered disabled state
Mar 24 17:30:02 PROXMOX kernel: device fwln201i0 entered promiscuous mode
Mar 24 17:30:02 PROXMOX kernel: fwbr201i0: port 1(fwln201i0) entered blocking state
Mar 24 17:30:02 PROXMOX kernel: fwbr201i0: port 1(fwln201i0) entered forwarding state
Mar 24 17:30:02 PROXMOX kernel: vmbr0: port 2(fwpr201p0) entered blocking state
Mar 24 17:30:02 PROXMOX kernel: vmbr0: port 2(fwpr201p0) entered disabled state
Mar 24 17:30:02 PROXMOX kernel: device fwpr201p0 entered promiscuous mode
Mar 24 17:30:02 PROXMOX kernel: vmbr0: port 2(fwpr201p0) entered blocking state
Mar 24 17:30:02 PROXMOX kernel: vmbr0: port 2(fwpr201p0) entered forwarding state
Mar 24 17:30:02 PROXMOX kernel: fwbr201i0: port 2(tap201i0) entered blocking state
Mar 24 17:30:02 PROXMOX kernel: fwbr201i0: port 2(tap201i0) entered disabled state
Mar 24 17:30:02 PROXMOX kernel: fwbr201i0: port 2(tap201i0) entered blocking state
Mar 24 17:30:02 PROXMOX kernel: fwbr201i0: port 2(tap201i0) entered forwarding state
Mar 24 17:30:04 PROXMOX pvedaemon[1989]: zfs error: cannot open 'STORAGECENTER': pool I/O is currently suspended
Mar 24 17:30:04 PROXMOX kernel: vfio-pci 0000:01:00.0: vfio_ecap_init: hiding ecap 0x19@0x1e0
Mar 24 17:30:05 PROXMOX pvedaemon[1991]: <root@pam> end task UPIDROXMOX:00003733:0000C01A:5E7A3588:qmstart:201:root@pam: OK


There is some "Could not generate persistent MAC address " that can be the problem

 

[Stefan_R]

After VM start, zfs pool and other disks connected to LSI controller disappear from proxmox/disk menu.

Yes, that's expected.

What does the network config on the guest show, when you access it via VNC? Not familiar with Synology devices, but there's probably a way to log in via the terminal and issue an "ip address"/"ifconfig" command or similar.

The "MAC address" issue is harmless, as discussed here.