ISFC logical link configuration

Specific attention was paid to the configuration of the ISFC logical link connecting the two z/VM members.

In general, the z/VM recommendations given in z/VM CP Planning and Administration, chapter Planning the ISFC Network in an SSI Cluster and those given in the IBM® z/VM Performance Report (see Live Guest Relocation and ISFC Improvements) were followed. However, if necessary for the investigation of corner cases of the ISFC logical link configurations, some of the guidelines were not applied.

An ISFC logical link connecting two z/VM members is configured by selecting up to sixteen FCTC connections. These FCTC connections must have been previously configured in the IOCDS (IOCDS configuration for FICON CTCs), such that each FCTC connection in turn connects the two LPARs hosting the z/VM members.

For example, if the FCTC device with device number D000 is configured in IOCDS for LPAR1 and if in the z/VM member running LPAR1 that FCTC device D000 is activated for the ISFC logical link connecting to LPAR2, then a corresponding FCTC device - preferably with the same device number D000 - (the other "end" of the FCTC connection) must in turn be configured for LPAR2 in the IOCDS, and in the z/VM member running in LPAR2 must be activated for the ISFC logical link connecting to LPAR1.

Each side of an ISFC logical link is configured separately by ACTIVATE ISLINK statements in the z/VM system configuration file, by executing ACTIVATE ISLINK privileged CP commands, or both. Either way, ACTIVATE ISLINK requires the FCTC device number(s) as parameter(s). The use of CP commands provides for the ability to dynamically modify the actual configuration of ISFC logical links after IPL.

Once one or more respectively prepared FCTC connections are configured for an ISFC logical link on both of its sides, the z/VM members connected through the ISFC logical link can use the link for communication and data transfer; this includes the case of transporting the data resulting from virtual machines being relocated from one z/VM member to the other.

In the test environment, the z/VM system configuration file contained an initial configuration for the ISFC logical link between the two z/VM members that became effective at IPL time. Then, during the preparation phase of each test case, the ISFC logical link was dynamically reconfigured, thereby establishing the test specific ISFC logical link configuration requirements.

A FCTC connection can potentially be used for communication in both directions.

However, if both sides try to send through a particular FCTC connection at the same time, a so called write collision occurs. While this is a recoverable situation, recovery consumes considerable processing and I/O resources and hence should be avoided.

In order to avoid write collisions, z/VM implements a specific usage convention for the FCTC connections configured for an ISFC logical link. By means of that usage convention, z/VM internally designates FCTC connections for unidirectional use.

The usage convention depends on the FCTC device numbers and the system names of the connected z/VM members; for details, see ISFC Improvements.

In summary, if two z/VM members are connected through an ISFC logical link, then

• The z/VM member with the lexicographically lesser system name¹ uses the FCTC devices starting from the lowest device number, up to higher device numbers
• The z/VM member with the lexicographically greater system name uses the FCTC devices starting from the highest device number, and down to lower device numbers
• If the ISFC logical link is composed of two up to eight FCTC devices, then each side uses at most one FCTC device less than configured, leaving the unused FCTC device for exclusive use of the adjacent side
• If the ISFC logical link is composed of nine up to sixteen FCTC devices, then each side uses at most two FCTC devices less than configured, leaving the unused FCTC devices for exclusive use of the adjacent side

For example, if the z/VM members in LPARs LPAR1 and LPAR2 were connected through an ISFC logical link with the FCTC connections with device numbers D000 through D00F, then LPAR1 (the system with the lexicographically lesser name) would perform its write operations on FCTC devices D000 up to D00D, leaving D00E and D00F exclusively for write operations of LPAR2. On the other hand, LPAR2 would perform its write operations on D00F down to D002, leaving FCTC devices D000 and D001 exclusively for write operations of LPAR1. This is illustrated in Figure 1.

With live guest relocation, asymmetric load on an ISFC logical link is typical, such that at a particular point in time only one side is sending a large amount of data, while the adjacent side at that time typically only sends small amounts of control information back to the sender.

As long as more than one FCTC connection is configured for an ISFC logical link, the two latter of the above rules ensure that there always remains at least one (or two) FCTC device(s) designated for the recipient for sending back control information, thereby – for the typical asymmetric load conditions – minimizing the risk that write collisions occur.

However, these two rules also imply that not all connections of an ISFC logical link are used for transferring relocation data; this is particularly significant

• If the ISFC logical link is composed of only few FCTC connections, and / or
• If the unidirectional FCTC devices are the only ones configured from a particular FICON channel.