[SOLVED] LIO target LUNs not restored on boot - not a TYPE_DISK block device

G

GeraldH

Member
Proxmox Subscriber
Dec 30, 2020
18
1
23
Hello,
I've activated the LIO iSCSI target on some promxox hosts for sharing local NVMe's over iSCSI (beside using those NVMe's for replicated storage)
But now my LIO target LUNs are not restored on boot anymore:

Code: 
systemd[1]: Starting rtslib-fb-targetctl.service - Restore LIO kernel target configuration...
target[2623]: Could not create StorageObject vg0pv0: Device /dev/zvol/tank/iscsi/vg0_pv0 is not a TYPE_DISK block device, skipped
target[2623]: Could not find matching StorageObject for LUN 0, skipped
target[2623]: Could not find matching TPG LUN 0 for MappedLUN 0, skipped
  • when I restart the rtslib-fb-targetctl.service later / interactively the LIO iSCSI LUNs become avaiable
  • all connected iSCSI initiators also fail and I've to re-login manually to the failed-restore-on-boot LIO target
I'm running:
pve-manager/8.4.1/2a5fa54a8503f96d (running kernel: 6.8.12-11-pve) zfs 2.2.7-pve2

I've tried to delay the rtslib-fb-targetctl.service / reorder iscsi systemd units - no success - rtslib-fb-targetctl always fails to load the LUNs with zfs backing block devices on boot - what could I try next?
 
that sounds like the units are not ordered correctly - the iSCSI part probably needs to come after the ZFS pool import part (potentially with a slight delay, since creation of the device symlinks happens in an async fashion via udev and the kernel).
 
please post the journal for the full boot sequence (i.e., until multi-user.target is reached).
 
journalctl -b is attached.
  • checked once again - manually starting rtslib-fb-targetctl.service works
  • rtslib-fb-targetctl.service is loaded too early on ZFS systems
  • who can suggest some systemd magic to make rtslib-fb-targetctl.service load after ZFS zvols are ready?
 

Attachments

it seems like your zpools are not imported during boot at all.. you could try removing the zfs cache file to force the scan service, or enable the per-pool instances for importing..
 
thanks - yes the zpool cache is involved
  • rm -f /etc/zfs/zpool.cache - reboot - works
  • another reboot with existing /etc/zfs/zpool.cache - fails again
  • setting another cache file for this pool doesn't help - fails
  • so only removing the /etc/zfs/zpool.cache imports the zfs pool before the rtslib-fb-targetctl.service loads
 
it might be the easiest to enable the "zfs-import@<POOL>.service" servce (replace "<POOL>" with your pool name) to ensure it is always imported at boot time.
 
yes - this loads the pool always!

ln -s /lib/systemd/system/zfs-import@.service /etc/systemd/system/zfs-import.target.wants/zfs-import@poolname.service

I'll with check with newer zfs versions again - if the problem still exists. Some months ago - when I last rebooted, I had no problems with zfs backed LIO luns.

Regards,
Gerald
 
You must log in or register to reply here.
Top Bottom