How it this supposed to work?
You do export the WWPN/WWNN of the associated host to the guest (nb:
will get interesting for non NPIV setups ...), but virtio scsi will
still do a LUN remapping.
IE the LUNs you see on the host will be different from the LUNs
presented to the guest.

This is taken care of in the host by presenting to the host all LUNs from
a host's NPIV vHBA.  (Libvirt probably would be the one taking care of this,
because QEMU may not have enough permissions).

Plus you don't _actually_ expose the FC host, but rather the WWPN of the
host presenting the LUN.
So how do you handle LUNs from different FC hosts on the guest?

I'm not sure I understand.

Neither I nor Fam know this stuff very well, but we are trying to do the same
as Hyper-V (and other proprietary hypervisors too).

Overall, I'm not overly happy with this approach.
You already added WWPN ids to the virtio transport, so why didn't you
update the LUN field, too, to avoid this ominous LUN remapping?

Is this your old idea of adding a separate target field to commands,
in order to support 64-bit LUNs?  That is separate, and most FC drivers
only default to 16-bit LUNs anyway.

And we really should make sure to have a single FC host in the guest
presenting all LUNs.

Yes, of course.

Paolo