> I like the functionality. To restate what I said when you first > proposed it, though, each pool is currently based on one iSCSI session, > so to preserve that paradigm, you should only allow zero or one > initiator IQNs per pool. If the pool contains an initiator IQN, it > will > be used when creating the session. If it does not contain an initiator > IQN, the system default initiator IQN will be used. If you require > multiple initiator IQNs, you create multiple pools, one per initiator > IQN each with the same target. I think that approach will result in a > very small patch. Do you have a specific use case for which that > approach would not work? > > Dave > Yes. Let us say I want to consider the LUNs behind a Target IQN as pool A.(Target centric terminology) If each initiator iqn creates separate pools than there will be duplicity of the same set of LUNs. And this is a side effect not necessarily a deliberate one. In this case the user knows that Pool A and Pool B are the same set of LUNs and it is a deliberate result. Possible usecase - Live Migration scenarios ... Increasing the initiator IQNs can be more effective in Load balancing, fault tolerance scenarios and the choice of the pools can be easily identified using Target IQNs. Also, with the above design if there is a need to create separate pools out of the same set of LUNs behind a Target IQN then that can be done explicitly by creating a fresh XML conf for each initiator IQN. -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list