You'll still need SAN lifs on both nodes to support HA and NDO. The SVM is a cluster-wide construct aggregating resources from all the nodes in the cluster. You can place your NAS and SAN volumes and your NAS lifs on the desired nodes to acheive that intent, but you can also non-disruptively move LUNs, Volumes, NAS Lfs, and even data serving aggregates between controllers as needs evolve over time, so try not to think too rigidly about how you are laying things out now.
If this post resolved your issue, help others by selecting ACCEPT AS SOLUTION or adding a KUDO.
yeah I sorta glossed over that with the "home ports" mention. I'm not clear if the OP is familar with the 7-mode approach which doesn't have an SVM abstraction layer (well, vfiler0 but still) . My sense is yes as this is a fairly classic 7 mode design pattern with an "entry level" class FAS. It's easy enough to mimic this in modern ONTAP and is certainly not a wrong initial deployment approach either. I was trying to stay relatively high level and ignoring multipathing and assign at least one second FC lif on the other controller as well as allowing for LIF failover for the SMB SVM data lif.
For the original poster, core to understanding current data ontap and how it enables non-disruptive operations is understanding cluster-scope, node-scope, and svm-scope. layer 3 interfaces are logical constructs that ride on physical ports or possibly even virtual porrts (ifgrps, vlans, vlans on top of ifgrps). This is a big change from 7-mode. understanding lif roles (Data, cluster, node, intercluster) and how they fit into node-scoped, svm-scoped, and cluster mgmt-scope is important to grasp.
so you can bulid and deploy in the way you might have on 7-mode with one controller running FC and one running CIFS. But you have enormous flexibility going forward in where data needs to live and how you present it because of the cluster capabilities and the additional layers of abstraction inherent to the platform.