IBM POWER7 processor-based IBM BladeCenter server configuration using command line interface (CLI)

CLI for IBM BladeCenter and IBM POWER7 processor-based BladeCenter server configuration

This article describes the IBM® POWER7® processor-based IBM BladeCenter® blade server installation starting from BladeCenter Ethernet Switch setup through logical partitioning (LPAR) configuration and to IBM AIX® setup. Everything written in this article could be made from the command line, so these recommendations can be helpful for system administrators and system engineers working with hosts through a tiny channel or firewall that is blocking all ports except the Telnet or Secure Shell (SSH) port.

Nikita Andreevich Yaskevich (, Lab Services Technical Consultant, IBM

Nikita Yaskevich PhotoNikita Yaskevich works as Lab Services Technical Consultant in IBM Russia/CIS. He specializes in IBM Power Architecture, IBM AIX, IBM PowerVM, IBM Systems Director and Oracle Database Administration. He also has more than three years experience of working as Power Systems and System z Field Technical Specialist as well as IT Specialist in IBM Innovation Center Moscow. You can reach him at

Ignat Vladimirovich Ivanov (, MVS Delivery and Deployment Engineer within MTS division, IBM

Ignat Ivanov PhotoIgnat has six years of experience in dealing with LAN and WAN computer networks of different sizes. He is a Cisco (CCIP and CCNP), Juniper and Brocade LAN certified engineer. Currently, he is working as a team leader at the IBM Russia MVS Network department. You can reach him at

10 July 2012

Also available in Chinese


Current business needs, more and more often, make companies optimize their spendings on IT. Virtualization is one of the most effective ways to reach this goal. It is a common situation when many virtual servers, stored on the same hardware equipment, operate in different networks and tended for different workloads. This is why IT architects and system administrators face the problem of how to configure virtual environment promptly. This task requires configuration of processors, memory, storage, networking, I/O devices and so on. It becomes more complicated when you need to store several virtual servers on the same blade but in different virtual networks (with different virtual local area network [VLAN] numbers).

There are a lot of articles giving recommendations on BladeCenter blade server configurations. I recommend that you read the articles mentioned in the Resources section about IBM Power Systems™ networking aspects, as from my point of view, they give a clear understanding of how it works.

The goal of this article is to consolidate recommendations for the BladeCenter setup and to provide a fast path for standard installation. In many cases, such as system setup using null-modem cable, firewall restrictions or automation needs, the most appropriate option to configure the server is to use the command line interface (CLI). This is the most instant and exact configuration approach, but it takes time to study the commands syntax. This perspective often makes engineers to use an Integrated Virtualisation Manager (IVM) web-interface instead of IVM CLI, but web interface do not allow to make complicated tuning and this is why they have an illusion that POWER7 processor-based blades have less functionality than standalone machines. This is not true! In this article, I can show how to make the most typical configuration of the network on POWER7 processor-based blades using only the CLI. The IBM Innovation Center Moscow activities sometimes require configuring POWER7 processor-based blades and standalone machines several times a week, and therefore my colleagues and I use these recommendations as well as give them to our clients and Business Partners in order to explain Power technologies.

While setting up network services, the BladeCenter configuration and blade server configuration should be both taken into account. To enable a virtual local area network (VLAN)-aware network on a blade server, we need to configure the BladeCenter switch, and to make the VLAN-aware networking on a particular system, we need to change the settings in the Virtual I/O Server (VIOS) LPAR and on the operating system's LPAR. If you just have a POWER7 processor-based blade without any software installed, you should make some basic configuration for it to set up the operating systems. In order to give a working end-to-end example of network setup, for this example, we considered a Nortel BC switch and a POWER6 processor-based blade server JS22.


The first step in every activity is planning. Each installation might change during its exploitation, but before making the initial installation, one should plan it — how the server is organized, where is it placed, what networks should be accessible by this server. We assume, that planning is already done and the system administrator already knows the virtual networks to be accessed by each system as well as their tag numbers. Among these VLAN numbers there must be one ID that will be a "garbage" VLAN. All packets with tags that differ from those that are in the list of allowed numbers, will be sent to this VLAN. This VLAN ID must differ from any other "working" VLAN IDs. Further, you will use these values in network adapter settings.

Let us assume that our VIOS should be accessed in VLAN 123, two of our partitions should be accessed in VLAN 456 and 789 correspondingly and a garbage VLAN will be VLAN 99. The BladeCenter AMM VLAN is 150. The blade is in slot 12 in BladeCenter.

Resources allocation in the network.
ResourceIP addressVLAN ID
BladeCenter chassis172.17.210.2 / 24150
VIOS172.17.217.2 / 27123
AIX 1172.17.218.34 / 29456
AIX 2172.17.222.158 / 28789

Configure the BladeCenter switch

We will discuss Cisco and Nortel BladeCenter Switches configuration for the support of IBM POWER7 processor-based blade server work. But we will start with a little tagging-VLAN-trunk theory, hoping this will help you to understand how to configure BladeCenter switches from other vendors, not only Cisco and Nortel. If you know what VLAN, trunk, and tagging means, just skip to the configuration part.

By default, all switch interfaces belong to VLAN 1 and are in access mode. This means that each switch interface is marked with a port VLAN ID (PVID) equal to 1 and when an IP packet arrives (without any VLAN information) at the switch it is tagged with VLAN ID 1 from that interface. Later, a switch-forwarding engine checks the VLAN ID of the packet and chooses the appropriate interfaces to send the packet out. Let us try to follow this process step by step:

  1. IP packet arrives to the interface, no VLAN information is in the packet.
  2. The input interface, by default, has PVID 1.
  3. IP packet gets its VLAN ID 1 from the interface.
  4. Forwarding engine checks IP packet VLAN ID and chooses output interfaces with corresponding PVID.
  5. IP packet leaves the switch again without any VLAN tagging, because the outgoing port in access mode will strip the VLAN tag from the IP packet.
Figure 1. IP packet switching in general.
Figure 1. IP packet switching in general.

So let us imagine the VLAN ID and tagging as some kind of internal switch mechanism to understand through which interface it should forward the IP packet. VLAN tagging allows hosts in one VLAN to connect only to hosts in the same VLAN. It is good from the security point of view and helps to control traffic in the network.

To illustrate this, let us assume one of the input interfaces belongs not to the default VLAN 1, but to VLAN 2 for example and there is no output interfaces in this VLAN. The following will happen:

Figure 2. IP packet discards with VLAN ID mismatch.
Figure 2. IP packet discards with VLAN id mismatch.

As you have probably guessed, the IP packet will be dropped, because the forwarding engine will not be able to match the IP packet VLAN ID with the output interface PVID. But, if there is the interface with the VLAN 2 tag, we will see the following:

Figure 3. IP packet forwarding with appropriate VLAN ID.
Figure 3. IP packet forwarding with appropriate VLAN ID.

The IP packet with VLAN 2 tagging will be forwarded to the output interface 3 because it has the same PVID. So hosts in VLAN 2 (connected to the interfaces with these PVIDs) will be able to communicate only to each others and will not be able to communicate with hosts in the VLAN 1 or any other.
As you know by now, the IP packet loses VLAN identification when exiting the output interface, so, for example, when the packet will arrive at the second switch it will be tagged again with the input interface PVID, so the following situation might happen:

Figure 4. VLAN hopping with improper interfaces configuration between two switches.
Figure 4. VLAN hopping with improper interfaces configuration between two switches.
Figure 4b. VLAN hopping with improper interfaces configuration between two switches.

As you can see, the host from VLAN 2, connected to the switch 1, tries to send a packet to other hosts in VLAN 2, connected to switch 2. When this packet exits switch 1, it loses its VLAN tagging and then arrives untagged at switch 2. Incoming port 3 on the second switch has PVID 3, so the IP packet was tagged with VLAN ID 3. The switch 2 forwarding engine sends this packet to the outbound port 2, because it has the same PVID. As a result, the IP packet will be discarded by the receiving host in VLAN 3, because it was initially designated to VLAN 2 but was improperly forwarded to that VLAN.
To resolve this issue and let hosts from VLAN 2 correctly work with each other through several switches, we need to find a way to keep IP packet VLAN tagging on the link between the switches. The link that can do that is called the trunk. So we can observe the following:

Figure 5. No VLAN hopping with trunk configuration - IP packet from VLAN2 on the first switch goes to the appropriate VLAN on the second switch.
Figure 5. No VLAN hopping with trunk configuration - IP packet from VLAN2 on the first switch goes to the appropriate VLAN on the second switch.
Figure 5. No VLAN hopping with trunk configuration - IP packet from VLAN2 on the first switch goes to the appropriate VLAN on the second switch.

Outbound trunk interfaces, unlike access interfaces do not the strip the VLAN ID from the outgoing IP packets, so the trunk line can carry IP packets from multiple VLANs and keep their VLAN tagging:

Figure 6. Trunk interfaces can carry IP packets from multiple VLANs.
Figure 6. Trunk interfaces can carry IP packets from multiple VLANs.

The trunk interface has one special option that is relevant to our topic — native VLAN. Native VLAN is the VLAN where all untagged IP packets go. Usually, we expect only tagged traffic on the trunk port, traffic that has VLAN information inside the IP packet, but sometimes a trunk port can receive untagged traffic. By default, all untagged traffic goes to VLAN 1, but you can easily change it. Just remember that native VLAN is the VLAN for untagged traffic on the trunk port.
According to our task, we have the following VLANs: VLAN 123 for VIOS, VLANs 456 and 789 for LPAR, VLAN 150 for BladeCenter AMM, and VLAN 99 as the garbage VLAN where all untagged useless traffic goes. So, we need a link between the server in bay 12 and the BladeCenter switch that can transfer packets from different VLANs — the trunk link.

Table 2. Example of an IBM BladeCenter Cisco switch configuration
Blade-SW1# show running-configuration interface gi0/12
Building configuration...
interface GigabitEthernet0/12BladeCenter switch internal interface corresponded to the appropriate BladeCenter slot.
switchport trunk native vlan 99Trunk native VLAN declaration (for untagged traffic).
switchport trunk allowed vlan 123, 456, 789, 150This command allows us to select VLANs and the traffic that will go through the trunk link. All other traffic from other VLANs (if any) will be discarded.
switchport mode trunkThis declares that the link is the trunk and is capable of carrying traffic from different VLANs simultaneously.
switchport nonegotiate
spanning-tree portfast

For Nortel BladeCenter switches, the configuration is not so easy. Let us go through it step by step in general:

  1. Make the switch port understand the tagging. Change its option tag to Enable.
  2. Set a default VLAN ID. For the "garbage" VLAN, specify where all untagged packets will be sent.
  3. In the L2 configuration mode, add the port to all the VLANs that should be available on this port.

Commands for these steps:

  1. Going to the switch configuration menu
    [Main Menu]
         info     - Information Menu
         stats    - Statistics Menu
         cfg      - Configuration Menu
         oper     - Operations Command Menu
    >> Main# cfg
  2. Going to the port menu to configure the necessary port:
    [Configuration Menu]
         sys      - System-wide Parameter Menu
         port     - Port Menu
         pmirr    - Port Mirroring Menu
         l2       - Layer 2 Menu
         l3       - Layer 3 Menu
         slb      - Server Load Balancing (Layer 4-7) Menu
    >> Configuration# port
  3. Choosing the necessary port:
    Enter port (INT1-14, MGT1-2, EXT1-4):   int12
  4. Activating the tagoption for that port. It makes this port aware of the IP packet VLAN tagging and it starts to work as a trunk port:
    [Port INT12 Menu]
         gig      - Gig Phy Menu
         pvid     - Set default port VLAN id
         alias    - Set port alias
         name     - Set port name
         rmon     - Enable/Disable RMON for port
         tag      - Enable/disable VLAN tagging for port
         tagpvid  - Enable/disable tagging on pvid
    >> Port INT4# tag
    Current VLAN tag support: enabled
    Enter new VLAN tag support [d/e]: e
  5. Assigning the special VLAN where all untagged traffic will go for that trunk port:
    >> Port INT4# pvid 
    Current port VLAN ID: 
    Enter new port VLAN ID [1-4095]: 99
  6. As a result:
    >> Port INT12# cur
    Current Port INT12 configuration: enabled, PVID 99, VLAN tagged
        name INT12
        Fast forwarding mode: disabled
  7. Now, we need to go to the L2 configuration level and add this port to each VLAN that should be available through this trunk:
    [Configuration Menu]
         sys      - System-wide Parameter Menu
         port     - Port Menu
         pmirr    - Port Mirroring Menu
         l2       - Layer 2 Menu
         l3       - Layer 3 Menu
         slb      - Server Load Balancing (Layer 4-7) Menu
         setup    - Step by step configuration set up
    >> Configuration# l2
    [Layer 2 Menu]
         stg      - Spanning Tree Menu
         trunk    - Trunk Group Menu
         thash    - IP Trunk Hash Menu
         lacp     - Link Aggregation Control Protocol Menu
         failovr  - Failover Menu
         vlan     - VLAN Menu
         rmon     - RMON Menu
         upfast   - Enable/disable Uplink Fast
    >> Layer 2# vlan
    Enter VLAN number: (1-4095) 150
    [VLAN 150 Menu]
         name     - Set VLAN name
         stg      - Assign VLAN to a Spanning Tree Group
         add      - Add port to VLAN
         rem      - Remove port from VLAN
         def      - Define VLAN as list of ports
    >> VLAN 150# add
    Current VLAN 150:  EXT1
    Enter port (INT1-14, EXT1-4):  INT12
    Current ports for VLAN:  EXT1
    Pending new ports for VLAN 150:  INT12 EXT1
    >> VLAN 150# apply
    >> VLAN 150# save

    So we have made port INT 12 tagging aware and added it to VLAN 150. The same should be done for VLANs 123, 456, and 789. At the end, you should see the following:

    >> Main# cfg
    [Configuration Menu]
         sys      - System-wide Parameter Menu
         port     - Port Menu
         pmirr    - Port Mirroring Menu
         l2       - Layer 2 Menu
         l3       - Layer 3 Menu
         slb      - Server Load Balancing (Layer 4-7) Menu
    >> Configuration# l2
    [Layer 2 Menu]
         upfast   - Enable/disable Uplink Fast
         update   - UplinkFast station update rate
         cur      - Display current layer 2 parameters
    >> Layer 2# cur
    Current VLAN 150: 
        name "management", jumbo disabled, ports INT12 EXT1, enabled
        spanning tree 1
    Current VLAN 123: 
        name "VIOS", jumbo disabled, ports INT12 EXT1, enabled
        spanning tree 1
    Current VLAN 456: 
        name "LPAR_1", jumbo disabled, ports INT12 EXT1, enabled
        spanning tree 1
    Current VLAN 789: 
        name "LPAR_2", jumbo disabled, ports INT12 EXT1, enabled
        spanning tree 1
    Current VLAN 99: 
        name "native", jumbo disabled, ports INT12 EXT1, enabled
        spanning tree 1

As a result from such Cisco and Nortel configuration, we will have a link from the blade server in slot 12 to the BladeCenter switch that carries tagged traffic for VLANs 150, 123, 456, and 789 and all untagged traffic goes to VLAN 99.

Configure POWER7 processor-based blade server

Access your blade

First, if you are using a remote blade server, ensure that Serial over LAN mode is activated in BladeCenter as well as on the blade server. Otherwise, if VIOS is unreachable over the network, you will need either physical access to the BladeCenter server, or remote video session in the BladeCenter web-interface.
In case SOL is activated, you can reach the blade server the following way:

login: USERID
password: ********

We are in. Let us give KVM ownership on the required blade server

system> kvm -b 12

And make it media tray owner, so it can boot from CD:

system> mt -b 12

Next, we switch on the blade server and open its console:

system> power -on -c -T blade[12]

To switch off the blade, use:

system> power -off -T blade[12]

To open the console of the blade (in case it is started already), use:

system> console -T blade[12]

Now, you can work with your blade as if you stand in front of the KVM of your BladeCenter server.
Let us move to the next step.

Install VIOS

While the blade server is loading, change its boot list settings in the SMS menu - press
1 - SMS Menu during load, then
5 - Select Boot Options, then
2 - Configure Boot device Order, then
1 - Select 1-st Boot Device, then
8 - List All Devices, then
select CD-DVD ( or USB CD-DVD - depends on what you use), then
2 - Set Boot Sequence, then
X - Exit and 1 - Yes to agree.

Now, you will boot from the VIOS installation disk, change the required parameters, and install VIOS to the disk. Set password, accept licenses, and finally you will have a VIOS command line that we will use for further steps.
When you have a working VIOS, check the current firmware code by using the command # lsmcode. It is better to upgrade the firmware first, before you might encounter errors. Also check the VIOS fix level by using the command # oslevel -s. You can find all firmware and OS fixpacks at the IBM FixCentral website.

Setup VIOS networking

Okay, we have installed VIOS, but it still has no access by network — we still work with it from the BladeCenter console. These are the steps to gain "independent" access. Let us focus on two simple examples.

Example 1. You have two Ethernet physical ports. Then, you can configure one of them to connect to VIOS by network, and another port, you will share among the other LPARs. This will allow you to have a physical connection to VIOS, separate from another LPAR, so in case of any problems on the shared port, you will be able to connect to the VIOS using another port. In this case, you select the port to be used by VIOS, for example, en4, and configure TCP/IP for this port. Next, you have to configure a shared Ethernet adapter (SEA) that will pass Ethernet traffic from an external network to the LPARs and back.

Example 2. You have only one port that VIOS will share with other LPARs. In this case, you have to configure a SEA on this only physical port. This also relates to configuration based on link aggregation (several ports are aggregated into one virtual port), as finally you enable SEA on a single virtual port.

Figure 7. Typical configuration of virtual network inside the POWER7 processor-based blade server.
Figure 7. Typical configuration of virtual network inside the POWER7 processor-based blade server.

To configure TCP/IP for a separate port, use the text menu # smitty tcpip or issue the next command:

# mktcpip -h vios1 -i en4 -a -m 
-g -n -d -s

where -h stands for hostname, -i - for interface, -m - for mask, -g - for gateway, -n - for nameserver, -d - for domain, -s - for start TCP/IP daemon now.

And here is how to create a single-port based network configuration.

  1. Remove all virtual Ethernet adapters, if any.
    • Remove all networking devices from VIOS.
      # rmdev -Rdl <ent..., en..., et..., inet...>
    • Remove all virtual Ethernet adapters from VIOS, except adapters for 1,2,3 and 4 VLANs (ent0 - ent3). They could not be removed and reconfigured.
      • First, explore your system. This shows the system name and other details. Let it be Server-7998-61X-SN100AD3A

        $ lssyscfg -r sys

        This shows the current LPAR profiles settings (static).

        $ lssyscfg -m Server-7998-61X-SN100AD3A -r prof

        On a single server, you can use $ lssyscfg -r prof

        This shows the current LPAR settings (dynamic). Assume that the VIOS LPAR name is 10-4797E_vios.

        $ lssyscfg -m Server-7998-61X-SN100AD3A -r lpar

        On a single server you can use $ lssyscfg -r lpar

      • Second, remove all the virtual Ethernet adapters that you found in the command output for the VIOS profile settings, except the adapters for 1,2,3 and 4 VLAN IDs. For instance, let us remove the virtual Ethernet adapter in virtual slot 12 in VIOS LPAR. This will remove the adapter without VIOS reboot:
        $ chhwres -p 10-4797E_vios -r virtualio --rsubtype eth -o r -s 12
  2. Create virtual adapters.
    • Create a virtual Ethernet adapter for VIOS that will be used by the SEA for virtual network connection to LPARs. The next command creates a new virtual Ethernet adapter on the fourteenth virtual slot on the VIOS LPAR. This adapter is VLAN-aware, that allows 123,456 and 789 VLANs and sends the rest of the traffic with other tags or untagged to VLAN 99 (let us call it garbage VLAN).
      $ chhwres -p 10-4797E_vios -o a -r virtualio --rsubtype eth -s 14
      -a "ieee_virtual_eth=1,port_vlan_id=99,addl_vlan_ids=123,456,789,
    • If your virtual servers on the POWER7® processor-based blade should be in the same VLAN, then no need to configure the virtual Ethernet adapter to be VLAN-aware. Then, use this command:
      $ chhwres -p 10-4797E_vios -o a -r virtualio --rsubtype eth -s 14
      -a "ieee_virtual_eth=0,port_vlan_id=99,is_trunk=1,trunk_priority=1"
  3. Create SEA.

    After adapter creation, change to the administrator mode and make # cfgmgr. After it is finished, look # lsdev | grep en and # lscfg | grep en to ensure that you have an active virtual Ethernet adapter. For instance, it is ent6. ent5 is a physical adapter. So, the SEA will use the physical port ent5 to connect to the external network, and the virtual Ethernet adapter ent6 to connect to the hypervisor. All untagged packets and packets with tags that are not from the allowed list will drop to VLAN 99.

    Issue the command:

    $ mkvdev -sea ent5 -vadapter ent6 -default ent6 -defaultid 99
    ent7 has appeared - SEA is ready.
  4. Make VIOS connect to SEA.

    VIOS has only one physical port, and it is used by SEA, so we cannot configure TCP/IP for access to VIOS. Thus we have to connect VIOS to the virtual network as it were a normal AIX LPAR. Here, we have to create another virtual Ethernet adapter that will get traffic from the VLAN, where VIOS should be stored, and set up TCP/IP.

    $ chhwres -p 10-4797E_vios -o a -r virtualio --rsubtype eth -s 15 
    -a "ieee_virtual_eth=0,port_vlan_id=123,is_trunk=0"

    A new virtual Ethernet adapter in slot 15 is created, and it accepts packets only for VIOS VLAN 123. In case of a single-VLAN configuration, port_vlan_id should be equal to the default VLAN on SEA. Now, issue # cfgmgr to refresh the device list and you see that ent8 has appeared. Then create the TCP/IP configuration for this device - by # smitty tcpip or using a familiar command:

    # mktcpip -h vios1 -i en8 -a -m 
    -g -n -d
  5. That is it! Your VIOS is available from the network.

    No need to use the BladeCenter console any more.
    You can also connect VIOS to different VLANs in the system by these commands:

    $ mkvdev -vlan ent7 -tagid 456

    After ent9 appears, set the IP address from VLAN 456.

    $ mkvdev -vlan ent7 -tagid 789

    After ent10 appears, set the IP address from VLAN 789.

Create and modify an AIX LPAR

Now it is time to create LPARs. If you have not created any LPAR yet, do it now. It could be done either by using the IVM web-interface or the IVM command line. But, as we agreed to use only the IVM command line, let us go forward this way. Here is an example of the procedure of LPAR creation using the CLI that is based on the LPAR profile template.

  • First, delete any automatically generated LPARs. Use $ rmsyscfg -r lpar -n RHEL52, where RHEL52 is the LPAR name.
  • Create a file for the LPAR profile (for example, name it "aix6_lpar_profile") and add the next records (they should be written in one string, one by one. Here it is a column only for convenient reading).

These strings create an LPAR named AIX6_1, for Linux® or AIX, with a minimum memory of 512 MB, desired memory of 4096 MB, and maximum memory of 8192 MB. These are mandatory strings, but we will add more optional parameters to make the desired profile description. So, add the subsequent records also.


These parameters create an LPAR with four virtual processors based on 0.4 physical processors in uncapped mode, a virtual SCSI adapter to connect storage to LPAR, and a virtual Ethernet adapter to connect the LPAR to the virtual network.
Finally, the configuration should look in the aix6_lpar_profile file this way


Note that the <slot number> parameter in the next parameters should not be duplicated in any two virtual adapters — each adapter has a unique slot number.

In the VIOS LPAR, the first 10 virtual slots are normally occupied by a system for internal needs, so the system administrator cannot modify them. While configuring the VIOS LPAR, you should start tracking the free slots after number 11. In all other LPARs, virtual slots numbering starts from 1, as usual.

<slot_number>, <port_vlan_id> and <additional_vlan_ids> parameters contain numbers. <is_ieee>,<is_trunk> and <is_required> are boolean parameters, 0 or 1.
The slot number for the first virtual SCSI device must be 2, otherwise the system will create it. The slot number for the virtual Ethernet device must be more or be equal to 4.
To use this profile to create an LPAR, issue the command

$ mksyscfg -r lpar -f aix6__lpar_profile

- this will create the LPAR.

Create the mapping

  • Check current mapping. $ lsmap -all Normally, if you have one LPAR in the system, there should be one virtual host (vhost0) without any connected devices. As we need to install AIX into this LPAR, we should connect to this vhost0 logical volume as the backing device for primary disk for operational system. To create the jfs2 logical volume from the rootvg volume group with 80 physical partitions (check PP size with # lsvg rootvg command, by default it is 256 MB), issue the command
    # mklv -t jfs2 -y aix61_rootvg_lv rootvg 80
  • Next, map this logical volume to the virtual host related to the target LPAR, for example, vhost0
    $ mkvdev -vdev aix61_rootvg_lv -vadapter vhost0 -dev aix61_lv_rvg
  • Check it again with $ lsmap -all
  • You also need to map the device with AIX installation disk.
    • If you mount the CD, then check with # lsdev | grep cd for the available CDs in VIOS (for example cd0), and map the device with the disk as follows
      $ mkvdev -vdev cd0 -vadapter vhost0 -dev aix6_cd_inst
    • There is another option — if you have a .iso file with an AIX installation disk image, than you can create the VIOS image library when needed. Next steps:
      1. Create a 10 GB library:
        $ mkrep -sp rootvg -size 10G

        This will create a 10 GB library in the /var/vio/VMLibrary directory. Copy there necessary aix6.iso image by FTP or SCP.
      2. Next, attach this image to the LPAR:
        $ mkvdev -fbo -vadapter vhost0
        $ lsrep

        This creates a virtual device for the virtual adapter vhost0 and checks the items in the library.
      3. Load the image into the virtual device.
        $ loadopt -f -vtd vtopt0 -disk aix6.iso

        Here aix6.iso is the image name displayed in the $ lsrep output.

Now, the new LPAR is ready.

Install AIX

Now start the target LPAR.

$ chsysstate -r lpar -o on --id 2
$ mkvt -id 2

ID 1 belongs to VIOS, and therefore, the first user LPAR has ID 2. Now, you are in the LPAR console mode. Correct the boot order in the SMS menu, install AIX like you have installed VIOS (installation menu is the same), then set the root password, accept licenses, and configure TCP/IP. If you created the only virtual Ethernet adapter for this LPAR (than in AIX) you will see the only Ethernet device - en0. Configure TCP/IP for it and check the connection. This should work.

If you have to leave the LPAR console, type the command # ~. and this will drop you back to the VIOS console. To end the LPAR terminal session - type

$ rmvt -id 2

If you need to shut down LPAR either shut it down normally from the operating system inside the LPAR, or type in VIOS

$ chsysstate -r lpar -o shutdown --immed -id 2

If you need to add virtual adapters to the LPAR for any reason, type in VIOS

$ chsyscfg -r prof -i 'lpar_id=2,"virtual_eth_adapters=5/0/789//0/0"'

Then make # cfgmgr in AIX and configure TCP/IP for the Ethernet device that appears as usual.

Do the same for the rest of the LPARs that you need. If you have done all correct (OK), enjoy using multiple AIX in multiple VLANs on the same machine!


According to the last trends in the Power Systems platform development, SEA is still the key mechanism for networking services configuration in a majority of Power server models. IVM, along with the Hardware Management Console (HMC) and SDMC, are the common mechanisms for POWER7 processor-based blade and Power standalone server configuration. HMC commands look similar to IVM commands and most of them are nearly the same. Thus, these recommendations allow you to maintain the whole range of Power Systems servers.


Sample AIX6 profile file for this articleaix6_lpar_profile.txt1KB



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into AIX and Unix on developerWorks

Zone=AIX and UNIX
ArticleTitle=IBM POWER7 processor-based IBM BladeCenter server configuration using command line interface (CLI)