Last Updated: 24 September 2025


Details on how to avoid issues using LGR in an SSI environment


Users of z/VM Single System Image (SSI) with Live Guest Relocation (LGR) may encounter the following during LGR:

  • Message HCP1940E userid is not relocatable for the following reason(s):
    HCP1944I userid: Architecture incompatibility
  • Or output from the QUERY VMRELOCATE userid command which includes:
    HCP1818I Excluded members: system_names when a z17 member is dynamically added to a relocation domain with mixed levels of z17 and non-z17 support. In this case, z17 support refers to APAR VM66823 for z/VM 7.3 and VM66824 for z/VM 7.4 and non-z17 support refers to any version of z/VM without either VM66823 or VM66824 applied. Dynamically added refers to either addition to a relocation domain via CEC-swap or redefinition of an existing relocation domain to include the new member.


To avoid this issue:

  • For z/VM 7.3 apply VM66823 to all members of the relocation domain to which you wish to add a z17.
  • For z/VM 7.4 apply VM66824 to all members of the relocation domain to which you wish to add a z17.
  • There are several workarounds available should you not be able to apply the corrective service:
    1. Once a member is excluded, you can shutdown-reIPL one of the members in the existing relocation domain that does not have the z17 support applied.
    2. You can define a new relocation domain including the z17 and use SET VMRELOCATE to change the VM's (or virtual machine's) relocation domain to the new domain.
    3. You can use the FORCE ARCHITECTURE operands on the VMRELOCATE command. Typically, this would not clear the excluded member, but in this case, that member will be cleared from the list and the vm is able to relocate freely around the domain.


Rollback Impacts with Secure Boot (Guest Secure IPL):
The Secure Boot facility is automatically supported for guests under z/VM once all members of an SSI support it (z16 or newer). If any member is later rolled back to a z15 or older for any reason, relocation attempts to that member will fail with "Architecture incompatibility" errors, because the IBM z15 and older do not support Secure Boot. The FORCE ARCHITECTURE DOMAIN option cannot override this restriction due to security considerations.

Plan to avoid disruption:

  • Before introducing an SSI member that supports Secure Boot, place rollback-critical guests in a legacy relocation domain that does not require Secure Boot.
  • If fallback to z15 is an option, maintain separate Secure Boot and Legacy relocation domains until the entire SSI supports Secure Boot.
  • If you encounter this condition, either:
    • Reassign affected guests to a legacy domain and recycle them (log them off/on), or
    • Log them off of the Secure Boot enabled system, and onto the system without Secure Boot capability