nim:/# ifconfig en0 largesend

nim:/# ifconfig -a

en0: flags=1e080863,4c0<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST,GROUPRT,64BIT,CHECKSUM_OFFLOAD(ACTIVE),LARGESEND,CHAIN>

        inet 180.24.56.123 netmask 0xffffff00 broadcast 180.24.56.255

        inet 181.24.56.188 netmask 0xffffff00 broadcast 181.24.56.255

         tcp_sendspace 262144 tcp_recvspace 262144 rfc1323 1

lo0: flags=e08084b,c0<UP,BROADCAST,LOOPBACK,RUNNING,SIMPLEX,MULTICAST,GROUPRT,64BIT,LARGESEND,CHAIN>

        inet 127.0.0.1 netmask 0xff000000 broadcast 127.255.255.255

        inet6 ::1%1/0

         tcp_sendspace 131072 tcp_recvspace 131072 rfc1323 1

nim:/#

tablespace.net ... 대략 짱~ 이라는... ^^

- http://www.tablespace.net/quicksheet/powervm-quickstart.html

PowerVM QuickStart

Version 1.2.1
Date: 3/11/12

Virtualization Components

PowerVM Acronyms & Definitions

CPU Allocations

• Shared (virtual) processor partitions (Micro-Partitions) can utilize additional resources from the shared processor pool when available. Dedicated processor partitions can only use the "desired" amount of CPU, and only above that amount if another CPU is (dynamically) added to the LPAR. • An uncapped partition can only consume up to the number of virtual processors that it has. (Ie: A LPAR with 5 virtual CPUs, that is backed by a minimum of .5 physical CPUs can only consume up to 5 whole / physical CPUs.) A capped partition can only consume up to its entitled CPU value. Allocations are in increments of 1/100th of a CPU, the minimal allocation is 1/10th of a CPU for each virtual CPU. • All Micro-Partitions are guaranteed to have at least the entitled CPU value. Uncapped partitions can consume beyond that value, capped cannot. Both capped and uncapped relinquish unused CPU to a shared pool. Dedicated CPU partitions are guaranteed their capacity, cannot consume beyond their capacity, and on Power 6 systems, can relinquish CPU capacity to a shared pool. • All uncapped micro-partitions using the shared processor pool compete for the remaining resources in the pool. When there is no contention for unused resources, a micro-partition can consume up to the number of virtual processors it has or the amount of CPU resources available to the pool. • The physical CPU entitlement is set with the "processing units" values during the LPAR setup in the HMC. The values are defined as: › Minimum: The minimum physical CPU resource required for this partition to start. › Desired: The desired physical CPU resource for this CPU. In most situations this will be the CPU entitlement. The CPU entitlement can be higher if resources were DLPARed in or less if the LPAR started closer to the minimum value. › Maximum: This is the maximum amount of physical CPU resources that can be DLPARed into the partition. This value does not have a direct bearing on capped or uncapped CPU utilization. • The virtual CPU entitlement is set in the LPAR configuration much like the physical CPU allocation. Virtual CPUs are allocated in whole integer values. The difference with virtual CPUs (from physical entitlements) is that they are not a potentially constrained resource and the desired number is always received upon startup. The minimum and maximum numbers are effectively limits on DLPAR operations.

• Processor folding is an AIX CPU affinity method that insures that an AIX partition only uses as few CPUs as required. This is achieved by insuring that the LPAR uses a minimal set of physical CPUs and idles those it does not need. The benefit is that the system will see a reduced impact of configuring additional virtual CPUs. Processor folding was introduced in AIX 5.3 TL 3. • When multiple uncapped micro-partitions compete for remaining CPU resources then the uncapped weight is used to calculate the CPU available to each partition. The uncapped weight is a value from 0 to 255. The uncapped weight of all partitions requesting additional resources is added together and then used to divide the available resources. The total amount of CPU received by a competing micro-partition is determined by the ratio of the partitions weight to the total of the requesting partitions. (The weight is nota nice value like in Unix.) The default priority for this value is 128. A partition with a priority of 0 is effectively a capped partition. Figure 0: Virtualized and dedicated CPUs in a four CPU system with a single SPP. • Dedicated CPU partitions do not have a setting for virtual processors. LPAR 3 in Figure 0 has a single dedicated CPU. • LPAR 1 and LPAR2 in Figure 0 are Micro-Partitions with a total of five virtual CPUs backed by three physical CPUs. On a Power 6 system, LPAR 3 can be configured to relinquish unused CPU cycles to the shared pool where they will be available to LPAR 1 and 2 (provided they are uncapped).

Shared Processor Pools

PowerVM Types

VIOS (Virtual I/O Server)

VIO Redundancy

VIOS Management Examples

VIOS Networking Examples

VIOS Unix Subsystem

User Management

Virtual Disk Setup

Disk Redundancy in VIOS

• LVM mirroring can be used to provide disk redundancy in a VIOS configuration. One disk should be provided through each VIOS in a redundant VIOS config to eliminate a VIOS as a single point of failure. • LVM mirroring is a client configuration that mirrors data to two different disks presented by two different VIOS. • Disk path redundancy (assuming an external storage device is providing disk redundancy) can be provided by a dual VIOS configuration with MPIO at the client layer. • Newer NPIV (N Port ID Virtualization) capable cards can be used to provide direct connectivity of the client to a virtualized FC adapter. Storage specific multipathing drivers such as PowerPath or HDLM can be used in the client LPAR. NPIV adapters are virtualized using VIOS, and should be used in a dual-VIOS configuration. • MPIO is automatically enabled in AIX if the same disk is presented to a VIOC by two different VIOS. • LVM mirroring (for client LUNs) is not recommended within VIOS (ie: mirroring your storage pool in the VIOS). This configuration would provide no additional protections over LVM mirroring in the VIOC. • Storage specific multipathing drivers can be used in the VIOS connections to the storage. In this case these drivers should not then be used on the client. In figure 1, a storage vendor supplied multipathing driver (such as PowerPath) would be used on VIOS 1 and VIOS 2, and native AIX MPIO would be used in the client. This configuration gives access to all four paths to the disk and eliminates both VIOS and any path as a singe point of failure.

Figure 1: A standard disk multipathing scenario.

Virtual Optical Media

Storage Pools

SEA Setup - Overview

• The command used to set up a SEA (Shared Ethernet Adapter) is mkvdev. • IP addresses cannot be configured on either the virtual or the physical adapter used in the mkvdev command. IP addresses are configured either on the SEA itself (created by the mkvdev -sea command) or another physical or virtual adapter that is not part of a SEA "bridge". (An example of the latter is seen in Figure 2.) • Best practices suggest that IP addresses for the VIOS should not be created on the SEA but should be put on another virtual adapter in the VIOS attached to the same VLAN. This makes the IP configuration independent of any changes to the SEA. Figure 2, has an example of an IP address configured on a virtual adapter interface en1 and not any part of the SEA "path". (This is not the case when using SEA failover). • The virtual device used in the SEA configuration should have "Access External Networks" (AKA: "Trunk adapter") checked in its configuration (in the profile on the HMC). This is the only interface on the VLAN that should have this checked. Virtual interfaces with this property set will receive all packets that have addresses outside the virtual environment. In figure 2, the interface with "Access External Networks" checked should be ent2. • If multiple virtual interfaces are used on a single VLAN as trunk adapters then each must have a different trunk priority. This is typically done with multiple VIOS servers - with one virtual adapter from the same VLAN on each VIO server. This is required when setting up SEA Failover in the next section.

Figure 2: Configuration of IP address on virtual adapter. • The examples here are of SEAs handling only one VLAN. A SEA may handle more than one VLAN. The -default and -defaultid options to mkvdev -sea make more sense in this (multiple VLAN) context.

Network Redundancy in VIOS

• The two primary methods of providing network redundancy for a VIOC in a dual VIOS configuration are NIB (Network Interface Backup) and SEA Failover. (These provide protection from the loss of a VIOS or VIOS connectivity to a physical LAN.) • NIB creates a link aggregation in the client of a single virtual NIC with a backup NIC. (Each virtual NIC is on a separate VLAN and connected to a different VIOS.) This configuration is done in each client OS. (See Figure 3 for an example of the VIOC that uses NIB to provide redundant connections to the LAN.) • SEA Failover is a VIOS configuration option that provides two physical network connections, one from each VIOS. No client configuration is required as only one virtual interface is presented to the client. • Most Power 6 based systems offer IVE (Integrated Virtual Ethernet) hardware that provides virtual NICs to clients. These do not provide redundancy and must be used in pairs or with another NIC / backup path on each client (or VIOS) to provide that capability. (Note: This is in the context of client NIB configurations. When IVE is used directly to the client different configuration rules apply. See the IVE Redpaper for the particulars of configuring IVE for aggregation and interface failover.) • NIB and SEA Failover are not mutually exclusive and can be used together or with link aggregation (EtherChannel / 802.3ad) to a physical device in the VIOS. Figure 3 shows a link aggregation device (ent3) in VIOS 1 as the physical trunk adapter for the SEA (ent4) in what is seen by the client as a NIB configuration. • Link aggregation (EtherChannel / 802.3ad) of more than one virtual adapter is not supported or necessary from the client as all I/O moves at memory speed in the virtual environment. The more appropriate method is to direct different kinds of I/O or networks to particular VIOS servers where they do not compete for CPU time.

Figure 3: NIC failover implemented at the VIO Client layer along with additional aggregation/failover at the VIOS layer. • The primary benefit of NIB (on the client) is that the administrator can choose the path of network traffic. In the case of figure 3, the administrator would configure the client to use ent0 as the primary interface and ent1 as the backup. Then more resources (in the form of aggregate links) can be used on VIOS1 to handle the traffic with traffic only flowing through VIOS2 in the event of a failure of VIOS1. The problem with this configuration is that it requires additional configuration on the client and is not conducive as SEA Failover to simplistic NIM installs. • NIB configurations also allow the administrator to balance clients so that all traffic does not go to a single VIOS. In this case hardware resources would be configured more evenly than they are in figure 3 with both VIOS servers having similar physical connections as appropriate for a more "active / active" configuration.

SEA Setup - Example

SEA Management

SEA Failover

• Unlike a regular SEA adapter, a SEA failover configuration has a few settings that are different from stated best practices. • A SEA failover configuration is a situation when IP addresses should be configured on the SEA adapter. • A control channel must be configured between the two VIOS using two virtual ethernet adapters that use that VLAN strictly for this purpose. The local virtual adapter created for this purpose should be specified in the ctl_chan attribute in each of the SEA setups. • Both virtual adapters (on the VLAN with clients) should be configured to "Access External network", but one should have a higher priority (lower number) for the "Trunk priority" option. A SEA failover configuration is the only time that you should have two virtual adapters on the same VLAN that are configured in this manner.   Figure 3: SEA Failover implemented in the VIOS layer.

The following command needs to be run on each of the VIOS to create a simple SEA failover. (It is assumed that interfaces match on each VIOS.) mkvdev -sea ent0 -vadapter ent1 -default ent1          -defaultid 1 -attr ha_mode=auto          ctl_chan=ent3 netaddr=10.143.180.1 ›››   Explanation of the parameters:    -sea ent0 -- This is the physical interface    -vadapter ent1 -- This is the virtual interface    -default ent1 -- Default virtual interface to send untagged packets    -defaultid 1 -- This is the PVID for the SEA interface    -attr ha_mode=auto -- Turn on auto failover mode    (-attr) ctl_chan=ent3 -- Define the control channel interface    (-attr) netaddr=10.143.180.1 -- Address to ping for connect test   • auto is the default ha_mode, standby forces a failover situation   Change the device to standby mode (and back) to force failover chdev -dev ent4 -attr ha_mode=standby  chdev -dev ent4 -attr ha_mode=auto See what the priority is on the trunk adapter  netstat -cdlistats | grep "Priority"

Disk

Devices

Low Level Redundancy Configuration

Best Practices / Additional Notes

VIOS commands are documented by categories on this InfoCenter page.

The lsmap command

The mkvdev command

Performance Monitoring

Backup

VIOS Security

1. 대상서버의 vios와 Target 서버의 vios의 virtual adapter 설정에서 ...
      > vscsi client의 target이 모두 'Any Partition' && 'Any Partition Slot'
      > required 속성이 'No' 일 것

2. VIO 구성시 mpio 의 속성이 no_reserve !!!
    >  lsdev -Cc disk | grep MPIO | awk '{print "chdev -l " $1 " -a reserve_policy=no_reserve "}'| sh –x 
    >   lsdev -Cc disk | grep MPIO | awk '{print "chdev -l " $1 " -a algorithm=round_robin "}' | sh -x 


3. 각각의 vios와 HMC 가 SSH 통신이 가능해야 함
       && LPM의 대상 파티션에서 /.ssh/known_hosts 파일이 존재해야 함
             (ssh hscroot@hmc.ipaddr 로 해당 파일을 생성해 줄 것)

 


-  http://www.ibm.com/developerworks/aix/library/au-LPM_troubleshooting/index.html 

Basic understanding and troubleshooting of LPM

Introduction

Live Partition Mobility (LPM) was introduced on Power6. It helps to avoid downtime during VIOS and firmware updates when migrating to other frames. LPM also reduces the amount of work that is required while creating a new LPAR and set-up, which is required for the application.

A majority of customers perform LPM activities on a daily basis, and many may not know the exact procedure or what is taking place. This article shows steps to overcome or fix LPM issues.

Back to top

LPM key points

Things to remember about LPM are that it migrates running partitions from one physical server to another while maintaining complete transactional integrity and transfers the entire environment: processor state, memory, virtual devices, and connected users. Partitions may also migrate while powered off (inactive migration), and the operating system and application must reside on shared storage.

Back to top

LPM prerequisites

You must have a minimum of two machines, a source and a destination, on POWER6 or higher with the Advanced Power Virtualization Feature enabled. The operating system and application must reside on a shared external storage (Storage Area Network). In addition to these hardware requirements, you must have:

• One hardware management console (optional) or IVM.
• Target system must have sufficient resources, like CPU and memory.
• LPAR should not have physical adapters.

Your virtual I/O servers (VIOS) must have a Shared Ethernet Adapter (SEA) configured to bridge to the same Ethernet network which the mobile partition uses. It must be capable of providing virtual access to all the disk resources which the mobile partition uses (NPIV or vSCSI). If you are using vSCSI, then the virtual target devices must be physical disks (not logical volumes).

You must be at AIX version 5.3J or later, VIOS version 1.4 or later, HMC V7R310 or later and the firmware at efw3.1 or later.

Back to top

What happens at the time of LPM

The following describes the general LPM depiction in Figure 2:

1. Partition profile (presently active) copied from source to target FSP.
2. Storage is configured on the Target.
3. Mover service partitions (MSP) is activated.
4. Partition migration started.
   1. Majority of memory pages moved.
   2. All threads piped down.
5. Activation resumed on target.
   1. Final memory pages moved.
   2. Cleanup storage and network traffic.
6. Storage resources are deconfigured from the source.
7. Partition profile removed from source FSP (Flexible Service Processor).

Back to top

How to do LPM

Before doing LPM, we need to verify the availability of resources on both the source and destination side. If validation fails with some error, then we have to fix it to proceed further. Sometimes validation may end up with warning messages which can be ignored.

LPM using HMC GUI

Figure 3 shows you how to validate the LPAR with the HMC GUI.

From the System management -> Servers -> Trim screen, select the LPAR name: Operations -> Mobility -> Validate

The validate screen, shown in Figure 4, shows that upt0052 LPAR is validated for migration from trsim to dash, and if needed, we have to specify the destination HMC.

Figure 5 show that the LPM has ended with a warning message, ignore the message and select Close to continue with the migration.

Figure 6, the Partition Migration Validation screen, shows that the information is selected to set up a migration of the partition to a different managed system. Select Migrate to verify the information.

When the migration completes, as shown in Figure 7, select Close

HMC using commandline option

To validate the LPM in local HMC, enter the following:

migrlpar -o v -m [source cec] -t [target cec] -p [lpar to migrate] 

To validate the LPM in the Remote HMC, type:

migrlpar -o v -m [source cec] -t [target cec] -p [lpar to migrate] \
> --ip [target hmc] -u [remote user]

Note, you may prefer to use the hscroot command as the remote user.

Use the following migration command for LPM in the local HMC:

migrlpar -o m -m [source cec] -t [target cec] -p [lpar to migrate] 

The following migration command for LPM is used with the remote HMC:

migrlpar -o m -m [source cec] -t [target cec] -p [lpar to migrate] \
> --ip [target hmc] -u [remote user]

In case of MPIO (Multipath IO) failure of a LPAR due to configuration issues between source and destination, type the following to proceed (if applicable):

migrlpar -o m -m wilma -t visa -p upt07 --redundantpgvios 0 -n upt07_n
oams_npiv -u hscroot --vlanbridge 2 --mpio 2 -w 60 -d 5 -v -i
"source_msp+name=wilmav2,dest_msp_name=visav2" --ip destiny4
		          

Back to top

Troubleshooting

This section covers various errors messages you might encounter and ways to correct them.

• If LPM needs to be done across two different HMCs, in case of migration, the appropriate authorization between HMCs needs to be set. If proper authorization is not set, the following mkauthkey error displays:

  hscroot@destiny4:~> migrlpar -o v -m trim -p UPT0052 --ip hmc-arizona -u hscroot -t arizona HSCL3653 The Secure Shell (SSH) communication configuration between the source and target Hardware Management Consoles has not been set up properly for user hscroot. Please run the mkauthkeys command to set up the SSH communication authentication keys.

  
  

  To overcome this error, type the following:

  hscroot@destiny4:~> mkauthkeys -g --ip hmc-arizona -u hscroot Enter the password for user hscroot on the remote host hmc-arizona

  
  
• If migrating an POWER7 Advanced Memory Expansion (AME) partition, to any of the POWER6 machines, the following error displays:

  hscroot@destiny4:~> migrlpar -o v -m trim -p UPT0052 --ip hmc-liken -u hscroot -t wilma HSCLA318 The migration command issued to the destination HMC failed with the following error: HSCLA335 The Hardware Management Console for the destination managed system does not support one or more capabilities required to perform this operation. The unsupported capability codes are as follows: AME_capability hscroot@destiny4:~>

  
  

  To correct this error either migrate to POWER7 or remove the AME and then migrate.

• If you are doing a migration of an Active Memory Sharing (AMS) partition with improper AMS setup or no free paging device on the destination side, the following error displays:

  hscroot@hmc-liken:~> migrlpar -o v -m wilma -t visa --ip destiny4 -u hscroot -p upt0060 --mpio 2 Errors: HSCLA304 A suitable shared memory pool for the mobile partition was not found on the destination managed system. In order to support the mobile partitions, the destination managed system must have a shared memory pool that can accommodate the partition's entitled and maximum memory values, as well ad its redundant paging requirements. If the destination managed system has a shared memory pool, inability to support the mobile shared memory partition can be due to lack of sufficient memory in the pool, or lack of a paging space device in the pool that meets the mobile partition's redundancy and size requirements. Details: HSCLA297 The DLPAR Resource Manager (DRM) capability bits )x) for mover service partition (MSP) visav2 indicate that partition mobility functions are not supported on the partition. HSCLA2FF An internal Hardware Management Console error has occurred. If this error persists, contact your service representative.

  
  

  To correct this error do either, or both, of the following:

  • Since this problem is related to redundant AMS setup, the destination AMS pool should have redundant capability for an AMS pool defined as Shared Memory Pool with two Paging VIOS partitions for high availability HMC only. Users can select primary and alternate paging VIOS for each Shared Memory Partition. For any details related to AMS, please refer to "Configuring Active Memory Sharing from a customer's experience" (developerWorks, Aug 2009) for more information.
  • A sufficient space for paging device should be present in the target AMS pool.
• If we try to migrate a LPAR from Power7 to Power6 CPU, we get the following error:

  hscroot@destiny4:~> migrlpar -o v -m dash -t arizona --ip hmc-arizona -u hscroot -p upt0053 Errors: HSCLA224 The partition cannot be migrated because it has been designated to use a processor compatibility level that is not supported by the destination managed system. Use the HMC to configure a level that is compatible with the destination managed system.

  
  

  The solution for the above error could be one of the following:

  • Migrate to POWER7.
  • Change the processor mode to appropriate mode (as in the destination managed system).

    The steps to change processor mode in HMC GUI are:

    • Select the LPAR and deactivate it.
    • Go to Configuration -> Manage Profiles.
    • Select the profile that needs to be activated.
    • Go to Processors, change the Processor compatibility mode: to the required setting and boot it using the same profile.
  • LPAR should have the same shared vSCSI disks on source and destination MSPs:

    hscroot@destiny4:~> migrlpar -o v -m dash -t arizona --ip hmc-arizona -u hscroot -p upt0058 Errors: The migrating partition's virtual SCSI adapter cannot be hosted by the existing virtual I/O server (VIOS) partitions on the destination managed system. To migrate the partition, set up the necessary VIOS hosts on the destination managed system, then try the operation again. Details: HSCLA356 The RMC command issued to partition arizona failed. This means that destination VIOS partition arizona2 cannot host the virtual adapter 6 on the migrating partition. HSCLA29A The RMC command issued to partition failed. The partition command is: migmgr -f find_devices -t vscsi -C 0x3 -d 1 The RMC return code is: 0 The OS command return code is: 85 The OS standard out is: Running method '/usr/lib.methods/mig_vscsi 85 The OS standard err is: The search was performed for the following device descriptions: <v-scsi-host> <generalInfo> <version>2.0 </version> <maxTransfer>262144</maxTransfer> <minVIOSpatch>0</minVIOSpatch> <minVIOScompatability>1</minVIOScompatability> <effectiveVIOScompatability>1</effectiveVIOScompatability> <generalInfo> <ras> <partitionID>2</partitionID> </ras> <virtDev> <vLUN> <LUA>0x81000000000000000</LUA> <LUNState>0</LUNState> <clientReserve>no</clientReserve> <AIX> <type>vdasd</type> <connWhere>1</connWhere> </AIX> </vLUN> <blockStirage> <reserveType>NI_RESERVE</reserveType> <AIX> <udid>261120017380003D30194072810XIV03IBMfcp</udid> <type>UDID</type> </AIX> </blockStirage> </virtDev> </v-scsi-host>

    
    

    And, the solution is as follows:

    • Make sure destination MSP has access to same vSCSI disks as source MSP.
    • Also make sure disks are not reserved.

  In cases where the mapping is correct, and you are still getting the same error, it may be due to having different types of FC adapters between source and destination MSP. For mapping methods, refer to last Note section of "Troubleshooting".

• In the destination CEC, if the LPAR has insufficient CPUs, then we get the following error:

  hscpe@destiny4:~> migrlpar -o v -m dash -t wilma -p upt0053 --ip defiant2 -u hscroothmc-arizona -u hscroot Errors: The partition cannot be migrated because the processing resources it requires exceeds the available processing resources in the destination managed system's shared processor pool. If possible, free up processing resources from that shared processor pool and try the operation again.

  
  

  And the solution is:

  • We need to reduce the CPU in LPAR by DLPAR or change the profile.
  • We can increase the number of processors at destination machine by reducing the number of processor units using DLPAR operation on a few of its clients (if applicable).
• If the destination CEC does not have sufficient memory, then:

  hscpe@destiny4:~> migrlpar -o v -m extra5 -t dash -p upt0027 Errors: There is not enough memory: Obtained: 2816, Required: 4608. Check that there is enough memory available to activate the partition. If not, create a new profile or modify the existing profile with the available resources, then activate the partition. If the partition must be activated with these resources, deactivate any running partition or partitions using the resource, then activate this partition.

  
  

  And, the solution is either:

  • We need to reduce the amount of memory in LPAR by using DLPAR operation or by changing the profile; or,
  • We can increase the memory at the destination machine by reducing the memory of any other LPARs using DLPAR operation.

  If the RMC (Resource Monitoring and Control) connection is not established among the source, target VIOS's and LPAR, then we may get following error:

  hscpe@destiny4:~> migrlpar -o v -m dash -t trim -p upt0053 Errors: The operation to check partition upt0053 for migration readiness has failed. The partition command is: drmgr -m -c pmig -p check -d 1 The partition standard error is: HSCLA257 The migrating partition has returned a failure response to the HMC's request to perform a check for migration readiness. The migrating partition in not ready for migration at this time. Try the operation again later. Details: HSCLA29A The RMC command issued to partition upt0053 failed. \ The partition commend is: drmgr -m -c pmig -p check -d 1 The RMC return code is: 1141 The OS command return code is: 0 The OS standard out is: Network interruption occurs while RMC is waiting for the execution of the command on the partition to finish. Either the partition has crashed, the operation has caused CPU starvation, or IBM.DRM has crashed in the middle of the operation. The operation could have completed successfully. (40007) (null) The OS standard err is:

  
  

  To fix this problem, refer to "Dynamic LPAR tips and checklists for RMC authentication and authorization" (developerWorks, Feb 2005) for more information.

  • If the partition you are trying to migrate is having MPIO with dual VIOS setup, and the target having dual VIOS but not set up properly for MPIO, then we may get error listed below:

    hscroote@hmc-liken:~> migrlpar -o v -m wilma -t visa --ip destiny4 -u hscroot -p upt0060 Errors: HSCLA340 The HMC may not be able to replicate the source multipath I/O configuration for the migrating partition's virtual I/O adapters on the destination. This means one or both of the following: (1) Client adapters that are assigned to different source VIOS hosts may be assigned to a single VIOS host on the destination; (2) Client adapters that are assigned to a single source VIOS host may be assigned to different VIOS hosts on the destination. You can review the complete list of HMC-chosen mappings by issuing the command to list the virtual I/O mappings for the migrating partition. HSCLA304 A suitable shared memory pool for the mobile partition was not found on the destination managed system. In order to support the mobile partition, the destination managed system must have a shared memory pool that can accommodate the partition's entitled and maximum memory values, as well as its redundant paging requirements. If the destination managed system has a shared memory pool, inability to support the mobile shared memory partition can be due to lack of sufficient memory in the pool, or lack of a paging space device in the pool that meets the mobile partition's redundancy and size requirements. Details: HSCLA297 The DLPAR Resource Manager (DRM) capability bits 0x0 for mover service partition (MSP) visav2 indicate that partition mobility functions are not supported on the partition. HSCLA2FF An internal Hardware Management Console error has occurred. If this error persists, contact your service representative. Warning: HSCLA246 The HMC cannot communicate migration commands to the partition visav2. Either the network connection is not available or the partition does not have a level of software that is capable of supporting partition migration. Verify the correct network and migration setup of the partition, and try the operation again.

    
    

    The solution is:

    • Check the correctness of dual VIOS, availability of adapters, mappings in SAN and switch.

    If above solution is not feasible to implement then:

    • Use --mpio 2 with the migrlpar command. By using this, we may lose dual VIOS setup for MPIO disks. Generally this is not a recommended solution by PowerVM.
  • If the Source VIOS is having non-recommended NPIV, we will get the following error:

    hscroote@hmc-liken:~> migrlpar -o v -m wilma -t visa --ip destiny4 -u hscroot -p upt0060 Errors: HSCLA340 The HMC may not be able to replicate the source multipath I/O configuration for the migrating partition's virtual I/O adapters on the destination. This means one or both of the following: (1) Client adapters that are assigned to different source VIOS hosts may be assigned to a single VIOS host on the destination; (2) Client adapters that are assigned to a single source VIOS host may be assigned to different VIOS hosts on the destination. You can review the complete list of HMC-chosen mappings by issuing the command to list the virtual I/O mappings for the migrating partition. HSCLA304 A suitable shared memory pool for the mobile partition was not found on the destination managed system. In order to support the mobile partition, the destination managed system must have a shared memory pool that can accommodate the partition's entitled and maximum memory values, as well as its redundant paging requirements. If the destination managed system has a shared memory pool, inability to support the mobile shared memory partition can be due to lack of sufficient memory in the pool, or lack of a paging space device in the pool that meets the mobile partition's redundancy and size requirements. Details: HSCLA297 The DLPAR Resource Manager (DRM) capability bits 0x0 for mover service partition (MSP) visav2 indicate that partition mobility functions are not supported on the partition. HSCLA2FF An internal Hardware Management Console error has occurred. If this error persists, contact your service representative. Warning: HSCLA246 The HMC cannot communicate migration commands to the partition visav2. Either the network connection is not available or the partition does not have a level of software that is capable of supporting partition migration. Verify the correct network and migration setup of the partition, and try the operation again.

    
    

    When we verify in VIOS:

    lsmap -all -npiv

    
    

    Name Physloc ClntID ClntName ClntOS ----------- --------------------------------- ------- ------------ ------ vfchost3 U9117.MMB.100302P-V1-C14 5 upt0052 AIX Status:LOGGED_IN FC name:fcs0 FC loc code:U78C0.001.DBJ0563-P2-C1-T1 Ports logged in:35 Flags:a<LOGGED_IN,STRIP_MERGE> VFC client name:fcs1 VFC client DRC:U8233.E8B.100244P-V5-C4-T1

    
    

    Name Physloc ClntID ClntName ClntOS ----------- --------------------------------- ------- ------------ ------ vfchost3 U9117.MMB.100302P-V1-C13 Status:LOGGED_IN FC name:fcs0 FC loc code:U78C0.001.DBJ0563-P2-C1-T1 Ports logged in:0 Flags:4<NOT_LOGGED> VFC client name: VFC client DRC

    
    

    Here the problem is vfchost3 and vfchost8 both mapped to same host (upt0058) and both mapped to same physical FC(fcs0). This is not the recommended setup. To fix this use either of these methods:

    • We need to map one of the vfchost to another FC (fcs1) on the server which is connected to the switch.
    • We can remove one of the vfchost through DLPAR.
  • This error basically represents the incompatibility between the source and target FC adapters. The incompatibility can be due to a number of reasons in terms of characteristics of FC adapter (For many different kinds of FC incompatibility problems or mapping problems, we may get "return code of 69".)

    hscroot@guandu5:~> migrlpar -o v -m flrx -t dash --ip destiny4 -u hscroot -p upt0064 HSCLA319 The migrating partition's virtual fibre channel client adapter 4 cannot be hosted by the existing Virtual I/O Server (VIOS) partitions on the destination managed system. To migrate the partition, set up the necessary VIOS host on the destination managed system, then try the operation again. HSCLA319 The migrating partition's virtual fibre channel client adapter 3 cannot be hosted by the existing Virtual I/O Server (VIOS) partitions on the destination managed system. To migrate the partition, set up the necessary VIOS host on the destination managed system, then try the operation again. Details: HSCLA356 The RMC command issued to partition dashv1 failed. This means that destination VIOS partition dashv1 cannot host the virtual adapter 4 on the migrating partition. HSCLA29A The RMC command issued to partition dashv1 failed. The partition command is: migmgr -f find_devices -t vscsi -C 0x3 -d 1 The RMC return code is: 0 The OS command return code is: 69 The OS standard out is: Running method '/usr/lib/methods/mig_vscsi' 69 The OS standard err is: The search was performed for the following device description: <vfc-server> <generalInfo> <version>2.0 </version> <maxTransfer>1048576</maxTransfer> <minVIOSpatch>0</minVIOSpatch> <minVIOScompatability>1</minVIOScompatability> <effectiveVIOScompatability>-1</effectiveVIOScompatability> <numPaths>1</numPaths> <numPhysAdapPaths>1</numPhysAdapPaths> <numWWPN>34</numWWPN> <adpInterF>2</adpInterF> <adpCap>5</adpCap> <linkSpeed>400</linkSpeed> <numIniat>6</numIniat> <activeWWPN>0xc0507601a6730036</activeWWPN> <inActiveWWPN>0xc0507601a6730037</inActiveWWPN> <nodeName>0xc0507601a6730036</nodeName> <streamID>0x0</streamID> <generalInfo> <ras> <partitionID>1</partitionID> </ras> <wwpn_list> <wwpn>0x201600a0b84771ca</wwpn> <wwpn>0x201700a0b84771ca</wwpn> <wwpn>0x202400a0b824588d</wwpn> <wwpn>0x203400a0b824588d</wwpn> <wwpn>0x202500a0b824588d</wwpn> <wwpn>0x203500a0b824588d</wwpn> <wwpn>0x5005076303048053</wwpn> <wwpn>0x5005076303098053</wwpn> <wwpn>0x5005076303198053</wwpn> <wwpn>0x500507630319c053</wwpn> <wwpn>0x500507630600872d</wwpn> <wwpn>0x50050763060b872d</wwpn> <wwpn>0x500507630610872d</wwpn> <wwpn>0x5005076306ib872d</wwpn> <wwpn>0x500a098587e934b3</wwpn> <wwpn>0x500a098887e934b3</wwpn> <wwpn>0x20460080e517b812</wwpn> <wwpn>0x20470080e517b812</wwpn> <wwpn>0x201400a0b8476a74</wwpn> <wwpn>0x202400a0b8476a74</wwpn> <wwpn>0x201500a0b8476a74</wwpn> <wwpn>0x202500a0b8476a74</wwpn> <wwpn>0x5005076304108e9f</wwpn> <wwpn>0x500507630410ce9f</wwpn> <wwpn>0x50050763043b8e9f</wwpn> <wwpn>0x50050763043bce9f</wwpn> <wwpn>0x201e00a0b8119c78</wwpn> <wwpn>0x201f00a0b8119c78</wwpn> <wwpn>0x5001738003d30151</wwpn> <wwpn>0x5001738003d30181</wwpn> <wwpn>0x5005076801102be5</wwpn> <wwpn>0x5005076801102dab</wwpn> <wwpn>0x5005076801402be5</wwpn> <wwpn>0x5005076801402dab</wwpn> </wwpn_list> <vfc-server>

    
    

    The solution can be any one of the following (or it may fail due to other mismatching characteristic of target FC adapters):

    • Make sure the characteristic of FC adapter is the same between source and target.
    • Make sure the source and target adapters reach the same set of targets (check the zoning).
    • Make sure that the FC adapter is connected properly.

    Sometimes the configuration log at the time of validation or migration is required to debug the errors. To get the log, run the following command from source MSP:

    alog -t cfg -o > cfglog

    
    

    NPIV mapping steps for LPM:

    1. Zone both NPIV WWN (World Wide Name) and SAN WWN together.
    2. Mask LUN's and NPIV client WWN together.
    3. Make sure the target source and target VIOS have a path to the SAN subsystem.

    vSCSI mapping steps for LPM:

    1. Zone both source and target VIOS WWN and SAN WWN together.
    2. Make sure LUN is masked with source and target VIOS together from SAN subsystem.
    
    

Back to top

LPM enhancement in POWER7

As per the prerequisites for LPM section for doing LPM, the LPAR should not have any physical adapters, but if it is a POWER7, it can have Host Ethernet Adapter (Integrated Virtualized Ethernet) attached to it. However, for a POWER7 LPAR which you want to migrate to other POWER7 can have HEA attached to it, but we must create etherchannel on a newly created virtual adapter and HEA in aggregation mode. When we migrate at the target we see only virtual adapter configured with IP and etherchannel; HEA will not be migrated. Also, make sure the VLANs used in virtual adapters to create etherchannel are added to both source and target VIOS.

Before LPM:

# lsdev -Cc adapter
ent0  Available       Logical Host Ethernet Port (lp-hea)
ent1  Available       Logical Host Ethernet Port (lp-hea)
ent2  Available       Logical Host Ethernet Port (lp-hea)
ent3  Available       Logical Host Ethernet Port (lp-hea)
ent4  Available       Virtual I/O Ethernet Port (l-lan)
ent7  Available       Virtual I/O Ethernet Port (l-lan)
ent6  Available       Virtual I/O Ethernet Port (l-lan)
ent7  Available       Virtual I/O Ethernet Port (l-lan)
ent8  Available       EtherChannel / 802.3ad Link Aggregation
ent9  Available       EtherChannel / 802.3ad Link Aggregation
ent10 Available       EtherChannel / 802.3ad Link Aggregation
ent11 Available       EtherChannel / 802.3ad Link Aggregation
fcs0  Available C3-T1 Virtual Fibre Channel Adapter
fcs1  Available C3-T1 Virtual Fibre Channel Adapter
lhea0 Available       Logical Host Ethernet Adapter (l-hea)
lhea1 Available       Logical Host Ethernet Adapter (l-hea)    
vsa0  Available       LPAR Virtual Serial Adapter
[root@upt0017] /

In this case doing LPM is also a bit different compared to the earlier method; this has to be done from the LPAR using smitty (also called client side LPM), not from HMC. But, LPAR must install with SSH fileset to do LPM through smitty.

openssh.base.client
openssh.base.server
openssh.license
openssh.man.en_US
openssl.base
openssl.license
openssl.man.en_US

Use smitty to migrate an Power7 LPAR with HEA. Smit --> Applications will be the first step to do LPM from smitty.

# smit

System Management
Move cursor to desired item and press Enter
  
  Software Installation and Maintenance
  Software License Management
  Mange Edition
  Devices
  System Storage Management  *Physical & Logical Storage)
  Security & User
  Communication Applications and Services
  Workload Partition Administration
  Print Spooling
  Advanced Accounting
  Problem Determination
  Performance & Resource Scheduling
  System Environments
  Processes & Subsystems
  Applications
  Installation Assistant
  Electronic Service Agent
  Cluster Systems Management
  Using SMIT (information only)
  
 

After selecting "Applications", then select "Live Partition Mobility with Host Ethernet Adapter (HEA)" to proceed.

Move cursor to desired item and press Enter

Live Partition Mobility with Host Ethernet Adapter (HEA)
    

Next enter the required fields such as source and destination HMC and HMC users, source and destination managed system names, LPAR name.

                   Live Partition Mobility with Host Ethernet Adapter (HEA)    
 
Type or select values in the entry fields.
Press Enter AFTER making all desired changes

                                                     [Entry Fields]
* Source HMC Hostname or IP address                [destinty2]
* Source HMC Username             [hscroot]
* Migration between two HMCs                         no
        Remote HMC hostname or IP address          [ ]
        Remote HMC Username                        [ ]
*Source System                                     [link]
* Destination System                               [king]
* Migrating Partition Name                         [upt0017]
* Migration validation only                          yes

Once the successful migration the smitty command output says OK.

Command Status
                                           
Command: OK            stdout: yes           Stderr: no
Before command completion, additional instruction may appear below.

Setting up SSH credentials wit destinty2
If prompted for a password, please enter password for user hscroot on HMC destinty2
Verifying EtherChannel configuration ...
Modifying EtherChannel configuration for mobility ...
Starting partition mobility process. This process is complete.
DO NOT halt or kill the migration process. Unexpected results may occur if the migration
process is halted or killed.
Partition mobility process is complete. The partition has migrated.

After successful LPM, all HEA's will be in defined state, but still the etherchannel between HEA and Virtual adapter exists and IP is still configured on Etherchannel.

      
[root@upt0017] /
# lsdev -Cc adapter

ent0   Defined             Logical Host Ethernet Port  (lp-hea)
ent1   Defined             Logical Host Ethernet Port  (lp-hea)
ent2   Defined             Logical Host Ethernet Port  (lp-hea)
ent3   Defined             Logical Host Ethernet Port  (lp-hea)
ent4   Available           Virtual I/O Ethernet Adapter  (l-lan)
ent5   Available           Virtual I/O Ethernet Adapter  (l-lan)
ent6   Available           Virtual I/O Ethernet Adapter  (l-lan)
ent7   Available           Virtual I/O Ethernet Adapter  (l-lan)
ent8   Available           EtherChannel  /  IEEE 802.3ad Link Aggregation
ent9   Available           EtherChannel  /  IEEE 802.3ad Link Aggregation
ent10  Available           EtherChannel  /  IEEE 802.3ad Link Aggregation
ent11  Available           EtherChannel  /  IEEE 802.3ad Link Aggregation
fcs0   Available  C3-T1    Virtual Fibre Channel Client Adapter
fcs1   Available  C4-T1    Virtual Fibre Channel Client Adapter
lhea0  Defined             Logical Host Ethernet Adapter  (l-hea)
lhea1  Defined             Logical Host Ethernet Adapter  (l-hea)
vsa0   Available           LPAR Virtual Serial Adapter
[root@upt0017] /
# netstat -i
Name  Mtu    Network      Address            Ipkts   Ierrs        Opkts  Oerrs  Coll
en8   1500   link#2      0.21.5E.72.AE.40    9302210    0       819878     0       0
en8   1500   10.33       upt0017.upt.aust    9302210    0       819978     0       0
en9   1500   link#3      0.21.5e.72.ae.52      19667    0          314     2       0
en9   1500   192.168.17  upt0017e0.upt.au      19667    0          314     2       0
en10  1500   link#4      0.21.5e.72.ae.61      76881    0         1496     0       0
en10  1500   192.168.18  upt0017g0.upt.au      76881    0         1496     0       0
en11  1500   link#5      0.21.5e.72.ae.73       1665    0         2200     2       0
en11  1500   192.168.19  upt0017d0.upt.au       1665    0         2200     2       0
lo0   16896  link#1                          1660060    0       160060     0       0
lo0   16896  loopback    localhost ''        1660060    0       160060     0       0
lo0   16896  ::1%1                           1660060    0       160060     0       0
[root@upt0017] /
# 

Other enhancements for POWER7

Additional enhancements are:

• User defined Virtual Target Device names are preserved across LPM (vSCSI).
• Support for shared persistent (SCSI-3) reserves on LUNs of a migrating partition (vSCSI).
• Support for migration of a client across non-symmetric VIOS configurations. The migrations involve a loss of redundancy. It requires an HMC level V7r3.5.0 and the GUI "override errors" option or command line --force flag. It also allows for moving a client partition to a CEC whose VIOS configuration does not provide the same level of redundancy found on the source.
• The CLI interface to configure IPSEC tunneling for the data connection between MSPs.
• Support to allow the user to select the MSP IP addresses to use during a migration.

Back to top

Limitations

• LPM cannot be performed on a stand-alone LPAR; it should be a VIOS client.
• It must have virtual adapters for both network and storage.
• It requires PowerVM Enterprise Edition.
• The VIOS cannot be migrated.
• When migrating between systems, only the active profile is updated for the partition and VIOS.
• A partition that is in a crashed or failed state is not capable of being migrated.
• A server that is running on battery power is not allowed to be the destination of a migration. A server that is running on battery power may be the source of a migrating partition.
• For a migration to be performed, the destination server must have resources (for example, processors and memory) available that are equivalent to the current configuration of the migrating partition. If a reduction or increase of resources is required then a DLPAR operation needs to be performed separate from migration.
• This is not a replacement for PowerHA solution or a Disaster Recovery Solution.
• The partition data is not encrypted when transferred between MSPs.

Back to top

Conclusion

This article gives administrators, testers, and developers information so that they can configure and troubleshoot LPM. A step-by-step command line and GUI configuration procedure is explained for LPM activity. This article also explains prerequisites and limitations while performing LPM activity.

Resources

Learn

• IBM PowerVM Live Partition Mobility 
  
  
• Virtual I/O Server and support for Power Systems (including Advanced PowerVM feature) 
  
  
• Capacity on Demand 
  
  
• IBM PowerVM 
  
  
• IBM System p and AIX Information Center 
  
  

Discuss

• Follow developerWorks on Twitter.
  
  
• Get involved in the My developerWorks community. 
  
  
• Participate in the AIX and UNIX® forums:
  • AIX Forum
  • AIX Forum for developers
  • Cluster Systems Management
  • Performance Tools Forum
  • Virtualization Forum
  • More AIX and UNIX Forums
  
  

About the authors

Raghavendra Prasannakumar works as a systems software engineer on the IBM AIX UPT release team in Bangalore, India and has worked there for 3 years. He has worked on AIX testing on Power series and on AIX virtualization features like VIOS, VIOSNextGen, AMS, NPIV, LPM, and AIX-TCP features testing. He has also worked on customer configuration setup using AIX and Power series. You can reach him atkpraghavendra@in.ibm.com.

Shashidhar Soppin works as a system software test specialist on the IBM AIX UPT release team in Bangalore, India. Shashidhar has over nine years of experience working on development tasks in RTOS, Windows and UNIX platforms and has been involved in AIX testing for 5 years. He works on testing various software vendors' applications and databases for pSeries servers running AIX. He specializes in Veritas 5.0 VxVM and VxFS configuration and installation, ITM 6.x installation and configuration and Workload Development tasks on AIX. He is an IBM Certified Advanced Technical Expert (CATE)-IBM System p5 2006. He holds patents and has been previously published. You can reach him at shsoppin@in.ibm.com.

Shivendra Ashish works as software engineer on the IBM AIX UPT release team in Bangalore, India. He has worked on AIX, PowerHA, PowerVM components on pSeries for the last 2 years at IBM India Software Labs. He also worked on various customer configurations and engagements using PowerHA, PowerVM, and AIX on pSeries. You can reach him at shiv.ashish@in.ibm.co

Live Partition Mobility (LPM) Nutshell

Neil Koropoff, 06/11/2012

Access pdf version of the Live Partition Mobility (LPM) Nutshell

The information below is from multiple sources including:

• Live Partition Mobility Redbook (SG24-7460)
• IBM Power/System p Notifications

This document is not intended to replace the LPM Redbook or other IBM documentation. It is only to summarize the requirements and point out fixes that have been released.Changes are in bold.

Major requirements for active Live Partition Mobility are:

Software Version Requirements:

Base LPM:

Hardware Management Console (HMC) minimum requirements

• Version 7 Release 3.2.0 or later with required fixes MH01062 for both active and inactive partition migration. If you do not have this level, upgrade the HMC to the correct level.
• Model 7310-CR2 or later, or the 7310-C03
• Version 7 Release 710 when managing at least one Power7 server.

Systems Director Management Console requirements

• Systems Director Management Console requirements would be the base SDMC and the minimum requirements for the machine types involved when attached to an SDMC.

Integrated Virtualization Manager (IVM) minimum requirements

• IVM is provided by the Virtual I/O Server at release level 1.5.1.1 or higher.

PowerVM minimum requirements:

• Both source and destination systems must have the PowerVM Enterprise Edition license code installed.
• Both source and destination systems must be at firmware level 01Ex320 or later, where x is an S for BladeCenter®, an L for Entry servers (such as the Power 520, Power 550, and Power 560), an M for Midrange servers (such as the Power 570) or an H for Enterprise servers (such as the Power 595).
  Although there is a minimum required firmware level, each system may have a different level of firmware. The level of source system firmware must be compatible with the destination firmware. The latest firmware migration matrix can be found here:

http://publib.boulder.ibm.com/infocenter/powersys/v3r1m5/index.jsp?topic=/p7hc3/p7hc3firmwaresupportmatrix.htm

Note:  When a partition mobility operation is performed from a Power6 system running at xx340_122 (or earlier) firmware level to a Power7 system running at a firmware level xx720_yyy, a BA000100 error log is generated on the target system, indicating that the partition is running with the partition firmware of the source system.  The partition will continue to run normally on the target system, however future firmware updates cannot be concurrently activated on that partition.  IBM recommends that the partition be rebooted in a maintenance window so the firmware updates can be applied to the partition on the target system.

If the partition has been booted on a server running firmware level xx340_132 (or later), it is not subject to the generation of an error log after a mobility operation.

Source and destination Virtual I/O Server minimum requirements

• At least one Virtual I/O Server at release level 1.5.1.1or higher has to be installed both on the source and destination systems.
• Virtual I/O Server at release level 2.12.11 with Fix Pack 22.1 and Service Pack 1, or later for Power7 servers.

Client LPARs using Shared Storage Pool virtual devices are now supported for Live LPAR Mobility (LPM) with the PowerVM V2.2 refresh that shipped on 12/16/2011.

Operating system minimum requirements
The operating system running in the mobile partition has to be AIX or Linux. A Virtual I/O Server logical partition or a logical partition running the IBM i operating system cannot be migrated. The operating system must be at one of the following levels:

Note: The operating system level of the lpar on the source hardware must already meet the minimum operating system requirements of the destination hardware prior to a migration.

• AIX 5L™ Version 5.3 Technology Level 7 or later (the required level is 5300-07-01) or AIX Version 5.3 Technology Level 09 and Service Pack 7 or later for Power7 servers.
• AIX Version 6.1 or later (the required level is 6100-00-01) or AIX Version 6.1 Technology Level 02 and Service Pack 8 or later.
• Red Hat Enterprise Linux Version 5 (RHEL5) Update 1 or later (with the required kernel security update)
• SUSE Linux Enterprise Server 10 (SLES 10) Service Pack 1 or later (with the required kernel security update)

Active Memory Sharing (AMS) software minimum requirements:

Note: AMS is not a requirement to perform LPM and is listed because both are features of PowerVM Enterprise Edition but AMS has more restrictive software requirements in case you plan to use both.

• PowerVM Enterprise activation
• Firmware level 01Ex340_075
• HMC version 7.3.4 service pack 2 (V7R3.4.0M2) for HMC managed systems
• Virtual I/O Server Version 2.1.0.1-FP21 for both HMC and IVM managed systems
• AIX 6.1 TL 3
• Novell SuSE SLES 11
  See above requirements for Power7 servers.

Virtual Fibre Channel (NPIV) software minimum requirements:

• HMC Version 7 Release 3.4, or later
• Virtual I/O Server Version 2.1 with Fix Pack 20.1, or later (V2.1.3 required for NPIV on FCoCEE)
• AIX 5.3 TL9, or later
• AIX 6.1 TL2 SP2, or later

Configuration Requirements:

Base LPM:

Source and destination system requirements for HMC managed systems:

The source and destination system must be an IBM Power Systems POWER6 technology- based model such as:

• 8203-E4A (IBM Power System 520 Express)
• 8231-E2B, E1C (IBM Power System 710 Express)
• 8202-E4B, E4C (IBM Power System 720 Express)
• 8231-E2B, E2C (IBM Power System 730 Express)
• 8205-E6B, E6C (IBM Power System 740 Express)
• 8204-E8A (IBM Power System 550 Express)
• 8234-EMA (IBM Power System 560 Express)
• 9117-MMA (IBM Power System 570)
• 9119-FHA (IBM Power System 595)
• 9125-F2A (IBM Power System 575)
• 8233-E8B (IBM Power System 750 Express)
• 9117-MMB, MMC (IBM Power System 770)
• 9179-MHB, MHC (IBM Power System 780)
• 9119-FHB (IBM Power System 795)

Source and destination system requirements for IVM managed systems:

• 8203-E4A (IBM Power System 520 Express)
• 8204-E8A (IBM Power System 550 Express)
• 8234-EMA (IBM Power System 560 Express)
• BladeCenter JS12
• BladeCenter JS22
• BladeCenter JS23
• BladeCenter JS43
• BladeCenter PS700
• BladeCenter PS701
• BladeCenter PS702
• BladeCenter PS703
• BladeCenter PS704
• 8233-E8B (IBM Power System 750 Express)
• 8231-E2B, E1C (IBM Power System 710 Express)
• 8202-E4B, E4C (IBM Power System 720 Express)
• 8231-E2B, E2C (IBM Power System 730 Express)
• 8205-E6B, E6C (IBM Power System 740 Express)

Source and destination system requirements for Flexible Systems Manager (FSM) managed systems:

• 7895-22X (IBM Flex System p260 Compute Node)
• 7895-42X (IBM Flex System p460 Compute Node)
  

A system is capable of being either the source or destination of a migration if it contains the necessary processor hardware to support it.

Source and destination Virtual I/O Server minimum requirements

• A new partition attribute, called the mover service partition, has been defined that enables you to indicate whether a mover-capable Virtual I/O Server partition should be considered during the selection process of the MSP for a migration. By default, all Virtual I/O Server partitions have this new partition attribute set to FALSE.
• In addition to having the mover partition attribute set to TRUE, the source and destination mover service partitions communicate with each other over the network. On both the source and destination servers, the Virtual Asynchronous Services Interface (VASI) device provides communication between the mover service partition and the POWER Hypervisor.

Storage requirements

For a list of supported disks and optical devices, see the Virtual I/O Server
data sheet for VIOS:

http://www14.software.ibm.com/webapp/set2/sas/f/vios/documentation/datasheet.html

Make sure the reserve_lock on SAN disk is set to no_reserve.

Network requirements

The migrating partition uses the virtual LAN (VLAN) for network access. The VLAN must be bridged (if there is more than one, then it also has to be bridged) to a physical network using a shared Ethernet adapter in the Virtual I/O Server partition. Your LAN must be configured so that migrating partitions can continue to communicate with other necessary clients and servers after a migration is completed.

Note:  VIOS V2.1.3 adds support of 10 Gb FCoE Adapters (5708, 8275) on the Linux and IBM AIX operating systems by adding N_Port ID Virtualization (NPIV).+
 

Requirements for remote migration

The Remote Live Partition Mobility feature is available starting with HMC Version 7 Release 3.4.
This feature allows a user to migrate a client partition to a destination server that is managed by a different HMC. The function relies on Secure Shell (SSH) to communicate with the remote HMC.

The following list indicates the requirements for remote HMC migrations:

• A local HMC managing the source server
• A remote HMC managing the destination server
• Version 7 Release 3.4 or later HMC version
• Network access to a remote HMC
• SSH key authentication to the remote HMC

The source and destination servers, mover service partitions, and Virtual I/O Servers are required to be configured exactly as though they were going to be performing migrations managed by a single HMC.

To initiate the remote migration operation, you may use only the HMC that contains the mobile partition.

Active Memory Sharing configuration

An IBM Power System server based on the POWER6 or POWER7 processor

Virtual Fibre Channel (NPIV) configuration

Virtual Fibre Channel is a virtualization feature. Virtual Fibre Channel uses N_Port ID Virtualization (NPIV), and enables PowerVM logical partitions to access SAN resources using virtual Fibre Channel adapters mapped to a physical NPIV-capable adapter.

The mobile partition must meet the requirements described above. In addition, the following components must be configured in the environment:

• An NPIV-capable SAN switch
• An NPIV-capable physical Fibre Channel adapter on the source and destination Virtual I/O Servers
• Each virtual Fibre Channel adapter on the Virtual I/O Server mapped to an NPIV-capable physical Fibre Channel adapter
• Each virtual Fibre Channel adapter on the mobile partition mapped to a virtual Fibre Channel adapter in the Virtual I/O Server
• At least one LUN mapped to the mobile partition's virtual Fibre Channel adapter
• Mobile partitions may have virtual SCSI and virtual Fibre Channel LUNs. Migration of LUNs between virtual SCSI and virtual Fibre Channel is not supported at the time of publication.

Fixes that effect LPM:

Firmware Release Ex340_095:
On systems running system firmware Ex340_075 and Active Memory Sharing, a problem was fixed that might have caused a partition to lose I/O entitlement after the partition was moved from one system to another using PowerVM Mobility.

 Firmware Release Ex350_063
A problem was fixed which caused software licensing issues after a live partition mobility operation in which a partition was moved to an 8203-E4A or 8204-E8A system.

Firmware Release Ex350_103
HIPER: IBM testing has uncovered a potential undetected data corruption issue when a mobility operation is performed on an AMS (Active Memory Sharing) partition.  The data corruption can occur in rare instances due to a problem in IBM firmware.  This issue was discovered during internal IBM testing, and has not been reported on any customer system. IBM recommends that systems running on EL340_075 or later move to EL350_103 to pick up the fix for this potential problem.  (Firmware levels older than EL340_075 are not exposed to the problem.)

Firmware Release AM710_083
A problem was fixed that caused SRC BA210000 to be erroneously logged on the target system when a partition was moved (using Live Partition Mobility) from a Power7 system to a Power6 system.
A problem was fixed that caused SRC BA280000 to be erroneously logged on the target system when a partition was moved (using Live Partition Mobility) from a Power7 system to a Power6 system.

Firmware Release AM720_082
A problem was fixed that caused the system ID to change, which caused software licensing problems, when a live partition mobility operation was done where the target system was an 8203-E4A or an 8204-E8A.
A problem was fixed that caused SRC BA210000 to be erroneously logged on the target system when a partition was moved (using Live Partition Mobility) from a Power7 system to a Power6 system.
A problem was fixed that caused SRC BA280000 to be erroneously logged on the target system when a partition was moved (using Live Partition Mobility) from a Power7 system to a Power6 system.
A problem was fixed that caused a partition to hang following a partition migration operation (using Live Partition Mobility) from a system running Ax720 system firmware to a system running Ex340, or older, system firmware. 

Firmware Release Ax720_090

HIPER: IBM testing has uncovered a potential undetected data corruption issue when a mobility operation is performed on an AMS (Active Memory Sharing) partition. The data corruption can occur in rare instances due to a problem in IBM firmware. This issue was discovered during internal IBM testing, and has not been reported on any customer system.

 
VIOS V2.1.0
Fixed problem with disk reservation changes for partition mobility
Fixed problem where Mobility fails between VIOS levels due to version mismatch

VIOS V2.1.2.10FP22
Fixed problems with NPIV LP Mobility
Fixed problem with disk reservation changes for partition mobility
Fixed problem where Mobility fails between VIOS levels due to version mismatch

VIOS V2.1.2.10FP22.1
Fixed a problem with NPIV Client; reconnect failure

VIOS V2.1.2.10FP22.1 NPIV Interim Fix
Fixed a problem with the NPIV vfc adapters

VIOS V2.1.3.10FP23 IZ77189 Interim Fix
Corrects a problem where an operation to change the preferred path of a LUN can cause an I/O operation to become stuck, which in turn causes the operation to hang.

VIOS V2.2.0.10 FP-24
Fixed problems with Live partition mobility Fix Pack 24 (VIOS V2.2.0.10 FP-24)
Documented limitation with shared storage pools

VIOS V2.2.0.12 FP-24 SP 02, V2.2.0.13 FP-24 SP03
Fixed a potential VIOS crash issue while running AMS or during live partition mobility
Fixed an issue with wrong client DRC name after mobility operation

Change history:
10/20/2009 - added SoD for converged network adapters.
04/15/2010 - added NPIV support for converged network adapters.
09/13/2010 - added new Power7 models
01/25/2011 - added OS source to destination requirement, updated fix information
03/28/2011 - added BA000100 error log entry on certain firmware levels and firmware fixes.

cat /opt/ibm/director/version.srv

#!/usr/bin/ksh
if [ $# -ne 1 ]; then
 echo " Usage: env_chk.sh <log_file> "
 echo "    ex. env_chk.sh env_variables.log "
 exit 1
fi

base_param=${1}
if [ -f ${base_param} ]
   then
        continue
   else
        env >> ${base_param}
        ulimit -a >> ${base_param}
        schedo -aF >> ${base_param}
        vmo -aF >> ${base_param}
        no -aF >> ${base_param}
fi

current_param="${1}_`date +\"%Y%m%d%H%M%S\"`"
env >> ${current_param}
ulimit -a >> ${current_param}
schedo -aF >> ${current_param}
vmo -aF >> ${current_param}
no -aF >> ${current_param}

compare_result=`diff ${base_param} ${current_param} | wc -l`
#echo ${compare_result}
if [[ ${compare_result} -ne 0 ]]
   then
        echo 'parameters are changed... backing up the current variables...'
        echo '#ftp.sh ....           '
        echo 'updating base param....'
        cp ${current_param} ${base_param}
        # exit
   else
        echo 'parameters are not changed... moving to next check'
        # exit
 fi

#echo "removing current param"
rm ${current_param}

#!/usr/bin/ksh
if [ $# -ne 5 ]; then
    echo " Usage: ftp.sh <ftp server ip> <ftp user> <ftp password> <target director> <source file> "
    echo "    ex. ftp.sh 10.10.20.101 root passwd /home/ftp_back /etc/hosts "
    exit 1
fi

source_full_path=${5}
source_file=`echo ${source_full_path} | awk -F"/" '{print$NF}'`
source_path=`echo ${source_full_path} | awk -F'/[^/]*$' '{print $1}'`

new_file_name="${source_file}_`date +\"%Y%m%d%H%M%S\"`"

ftp -n ${1}  <<! >> ftp.log

        user ${2} ${3}
        lcd ${source_path}
        cd ${4}
        as

        put ${source_file} ${new_file_name}
        bye
!

   # cat path.sh
   ---------------------------------------------------------------------
#!/usr/bin/ksh
source_full_path="/home/event_action/ftp.log"

      source_file=`echo ${source_full_path} | awk -F"/" '{print$NF}'`
      source_path=`echo ${source_full_path} | awk -F'/[^/]*$' '{print $1}'`

echo "source_full_path: " ${source_full_path}
echo "source_file: " ${source_file}
echo "source_path: " ${source_path}
    ---------------------------------------------------------------------

+. awk 로 field 추출시 조건문 사용 
    ex. 5번째 field의 값이 IPv4 이거나 IPv6인 경우, 특정 컬럼 또는 전체 컬럼을 출력
      # lsof | awk '$5=="IPv4"||$5=="IPv6"{print}'
        >> awk로 field의 조건만 검사한 후 전체 데이터를 그대로 출력하려면 'print'만 지정
      # lsof | awk '$5=="IPv4"||$5=="IPv6"{$1,$2,$3,$5,$7}'
      # lsof | awk '$5!="IPv4"&&$5!="IPv6"{print}'


+. awk로 받은 값을 shell을 통해서 명령을 실행하는 경우
    (device 리스트 조회 후 파라미터 변경시에 주로 사용)
      # lsdev –Cc disk | grep –v hdisk0 | awk '{print "chdev -l" $1 "-a fc_err_recov=fast_fail" }' | sh -x




------------------------------
awk '{print substr($0, index($0,$9))}'
awk -v N=9 '{sep=""; for (i=N; i<=NF; i++) {printf("%s%s",sep,$i); sep=OFS}; printf("\n")}' 
awk -v N=9 '{for(i=1;i<N;i++){$i=""}}1'
awk '{ s = ""; for (i = 9; i <= NF; i++) s = s $i " "; print s }'

a1:/home# diff 1.txt 2.txt
1a2
>
4d4
< aaa

a1dir2:/home# sdiff 1.txt 2.txt
111                                                                111
                                                                >
222                                                                222

aaa                                                             <

a1:/home#

+. aix에 등록된 ssh-key 삭제

   > /.ssh/known_hosts 에서 해당 IP 정보 삭제

+. HMC에 등록된 ssh-key 삭제 (~/.ssh/authorized_keys2 파일을 수정하는 명령)

   >  mkauthkeys --remove '$user@$hostname'

     ex. mkauthkeys --remove 'root@10.10.10.121'