How to migrate HP-UX workloads between physical and virtual servers easily

9
Figure 6, shows 2 SAN fabric connections: ATC_RACK and ATC_RACK0. The first one uses port 1 of the VC module in
Bay6 and the second, port 1 of the VC located in Bay5.
Figure 6. SAN fabric connections defined in VC modules
To perform a P2V move of a physical logical server with ATC_RACK and ATC_RACK0 SAN fabrics connections,
the LSM needs to find an NPIV capable device on the possible target hosts for both SAN fabrics. All eligible target
hosts of the portability group have in their hardware database (Figure 7), records mapping SAN fabrics to physical
NPIV capable devices (/dev/fcd0 and /dev/fcd1 in Figure 7).
Figure 7. Mapping of NPIV capable devices with SAN fabrics in an HP Integrity VM host
The mapping of NPIV capable devices and SAN fabric names is used as well for V2P moves. In the case of Figure 7, when
the move of a virtual logical server having NPIV connections on /dev/fcd0 and /dev/fcd1 is triggered, the LSM
will provide the ATC_RACK and ATC_RACK0 SAN fabric names to the Virtual Connect modules (via VCEM) for creating
the server profile of the target physical server.
Note: Servers located in environments with no Virtual Connect modules (i.e., rackmount servers) are not eligible for hosting physical logical servers
because the concept of server profile is missing. However, the activation of virtual logical servers with NPIV connectivity in HP Integrity VM hosts present in
such environments is possible because the hosts can communicate SAN fabric connections to LSM via the vmVirtProvider. Hence, P2V migrations
toward such HP Integrity VM hosts are supported.
Network connections
A similar mapping mechanism between physical and virtual networks (networks used by virtual machines) must exist to
enable fluid, cross-technology migrations.
Physical networks are defined in Virtual Connect modules by a record containing a name and various dynamic or static
parameters like the state of the connections, as shown in Figure 8.