Introduction

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.

Back to top

Planning

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.

Back to top

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.

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:

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:

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:

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:

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:

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.

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.

Back to top

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:

telnet 172.17.210.2 
login:  USERID
password: ******** 

			

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

system> kvm -b 12

system> mt -b 12

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

system> power -off -T blade[12]

system> console -T blade[12]

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.

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

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, 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"

     
     
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 172.17.217.2 -m 255.255.255.224 -g 172.17.217.1 -n 172.17.210.254 -d iic.msk.ibm.com

   
   
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).

  name=AIX6_1, lpar_env=aixlinux, min_mem=512, desired_mem=4096, max_mem=8192

  
  

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.

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

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.
virtual_eth_adapers=<slot_number>/<is_ieee>/<port_vlan_id>/<additional_vlan_ids>/<is_trunk>/<is_required> virtual_scsi_adapters=<slot_num>/<adapter_type>/<remote_lpar_id>/<remote_lpar_name>/<remote_slot_num>/<is_required>

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

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

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

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

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!

Back to top

Conclusion

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.

Back to top

Download

Information about download methods

Resources

• "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)
  
  

About the authors

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 n.yaskevich@ru.ibm.com.

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 ignat.ivanov@ru.ibm.com

Rate this article

Comments

Back to top

Table of contents

• Introduction
• Planning
• Configure the BladeCenter switch
• Configure POWER7 processor-based blade server
• Conclusion
• Download
• Resources
• About the authors
• Comments

Dig deeper into AIX and UNIX on developerWorks

IBM SmartCloud trial. No charge.

Unleash the power of hybrid cloud computing today!

---

Public and private solutions in one trial.

Special offers