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.
|Resource||IP address||VLAN ID|
|BladeCenter chassis||172.17.210.2 / 24||150|
|VIOS||172.17.217.2 / 27||123|
|AIX 1||172.17.218.34 / 29||456|
|AIX 2||172.17.222.158 / 28||789|
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:
- IP packet arrives to the interface, no VLAN information is in the packet.
- The input interface, by default, has PVID 1.
- IP packet gets its VLAN ID 1 from the interface.
- Forwarding engine checks IP packet VLAN ID and chooses output interfaces with corresponding PVID.
- 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.
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.
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.
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.
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.
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.
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
|BladeCenter switch internal interface corresponded to the appropriate BladeCenter slot.|
|Trunk native VLAN declaration (for untagged traffic).|
|This 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.|
|This declares that the link is the trunk and is capable of carrying traffic from different VLANs simultaneously.|
For Nortel BladeCenter switches, the configuration is not so easy. Let us go through it step by step in general:
- Make the switch port understand the tagging. Change its option tag to Enable.
- Set a default VLAN ID. For the "garbage" VLAN, specify where all untagged packets will be sent.
- In the L2 configuration mode, add the port to all the VLANs that should be available on this port.
Commands for these steps:
- Going to the switch configuration menu
[Main Menu] info - Information Menu stats - Statistics Menu cfg - Configuration Menu oper - Operations Command Menu ...... >> Main# cfg
- 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
- Choosing the necessary port:
Enter port (INT1-14, MGT1-2, EXT1-4): int12
- 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
- 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
- As a result:
>> Port INT12# cur Current Port INT12 configuration: enabled, PVID 99, VLAN tagged name INT12 Fast forwarding mode: disabled
- 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.
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
In case SOL is activated, you can reach the blade server the following way:
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
To switch off the blade, use:
system> power -off -T blade
To open the console of the blade (in case it is started already), use:
system> console -T blade
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.
While the blade server is loading, change its boot list settings in the SMS menu
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
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.
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.
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 172.17.217.2 -m 255.255.255.224 -g 172.17.217.1 -n 172.17.210.254 -d iic.msk.ibm.com -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.
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
- Remove all networking devices from VIOS.
- 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, is_trunk=1,trunk_priority=1"
- 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"
- 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).
- Create SEA.
After adapter creation, change to the administrator mode and make
# cfgmgr. After it is finished, look
# lsdev | grep enand
# lscfg | grep ento 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.
- 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
# cfgmgrto refresh the device list and you see that ent8 has appeared. Then create the TCP/IP configuration for this device - by
# smitty tcpipor using a familiar command:
# mktcpip -h vios1 -i en8 -a 172.17.217.2 -m 255.255.255.224 -g 172.17.217.1 -n 172.17.210.254 -d iic.msk.ibm.com
- 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.
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
name=AIX6_1,lpar_env=aixlinux,min_mem=512,desired_mem=2048, max_mem=4096,mem_mode=ded,min_proc_units=0.10, desired_proc_units=0.40,max_proc_units=4.00,min_procs=1, desired_procs=4,max_procs=4,proc_mode=shared, sharing_mode=uncap,uncap_weight=128,max_virtual_slots=10, virtual_scsi_adapters=2/client/1///1, virtual_eth_adapters=4/0/456//0/0,boot_mode=norm,auto_start=0
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.
- Check current mapping.
$ lsmap -allNormally, 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 rootvgcommand, 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 cdfor 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:
- 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.
- Next, attach this image to the LPAR:
$ mkvdev -fbo -vadapter vhost0
This creates a virtual device for the virtual adapter vhost0 and checks the items in the library.
- Load the image into the virtual device.
$ loadopt -f -vtd vtopt0 -disk aix6.iso
Here aix6.iso is the image name displayed in the
- Create a 10 GB library:
- If you mount the CD, then check with
Now, the new LPAR is ready.
Now start the target LPAR.
$ chsysstate -r lpar -o on --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"'
# cfgmgrin 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 article||aix6_lpar_profile.txt||1KB||HTTP|
"POWER5 Virtualization: How to work with VLANs using the IBM Virtual I/O Server"
(developerWorks, Nov 2008) is an article describing the benefits of working with VLANs using IBM VIOS.
"Complex networking using Linux on POWER7 processor-based blades"
(developerWorks, Aug 2008) is an article describing the benefits of working with VLANs using IBM VIOS.
"IBM PowerVM Virtualization Introduction and Configuration"
(IBM Redbooks®, Sep 2011)
"IBM PowerVM Virtualization Managing and Monitoring"
(IBM Redbooks, Sep 2011)
Nikita 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 firstname.lastname@example.org.
Ignat 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 email@example.com