Virtual I/O (VIO) is the virtualization feature software implemented from IBM POWER5™ processor-based servers onwards. This software facilitates the sharing of physical I/O resources between client LPARs within the server. VIOS has all the physical I/O resources and it allocates the physical devices, such as disks and network adapters to the client partitions. For the client partitions, the devices are virtual devices. We can create LPARs without requiring additional physical I/O resources in the system. Client LPARs can share Small Computer System Interface (SCSI) devices, Fibre Channel (FC) adapters, and Ethernet adapters and expand the amount of memory available to LPARs using paging space devices.
To leverage IBM Power Systems virtualization using VIOS, customers can either freshly set up the environment on the VIO client LPAR or migrate their current physical LPAR with internal disks to SAN-attached virtual disks backed virtual LPAR as VIO client. Migrating the LPARs with internal physical disks to LPARs with virtual disks on VIOS can be challenging. This article provides the step-by-step procedure for migrating LPARs with internal disks to VIO client LPAR. This overview of the migration process prepares the user for what needs to be done and what is to be expected, so that the migration can be as quick and easy as possible.
This article demonstrates the physical to virtual migration procedures used to migrate the IBM AIX® systems. It is assumed that the reader is already familiar with AIX, VIOS, SAN, and the Hardware Management Console (HMC) and also assumed that the reader already has the HMC and VIOS in their environment. If not, it is recommended to review the documentation in the “Resources” section first.
Migrating a physical LPAR to a virtual LPAR
Migrate the root volume group (rootvg) that is on the internal disk of the server to the external disk or SAN disk which is temporarily attached to the server through FC. The rootvg exists on the internal disk of any server. Internal disk implies any disk which is on the central processor complex (CPC) server or in the I/O drawer attached to the server.
The process of migration is summarized in the following steps:
- Prepare for the migration.
- Clone the rootvg from the internal disk to
the external disk by using the
- Export the altinst_rootvg from the source LPAR.
- Set up the VIO client LPAR (target LPAR).
- Use the exported disk in step 3 as the boot device for target LPAR.
Each of these steps are elaborated in the rest of this article.
Preparing for the migration
If rootvg is mirrored on multiple disks on the source LPAR, we have to unmirror rootvg
before carrying out the migration under discussion. This section can be skipped if rootvg is not mirrored.
To unmirror the rootvg, use the
For example, run the following command to unmirror the root volume group on hdisk11.
unmirrorvg rootvg hdisk11
If multiple copies are available on different disks, unmirror the rootvg from all the mirrored disks.
reducevg command to reduce the disk out of the root volume group.
reducevg rootvg hdisk11
to reinitialize the boot record of the remaining disk and modify the boot list in order to remove the
unmirrored disk from the list. If the source LPAR has rootvg in hdisk1, run the following commands:
bosboot -a -d /dev/hdisk1 bootlist -m normal hdisk1
Assign additional hdisks from the external storage
On the source physical LPAR, we have disk hdisk1 and rootvg on hdisk1. We can check the physical volumes:
hdisk1 00000f6ac39aea95 rootvg active
Create a logical unit number (LUN) on the storage and assign it to the source physical system and issue the
chdev command to change
the characteristics of the new device. Make sure that you run the
cfgmgr command on the source physical
LPAR to configure the new hdisk in the LPAR.
chdev -l hdisk0 -a pv=yes
Check the status of the physical disks on the source system. The output is similar to the following example:
#lspv hdisk1 00000f6ac39aea95 rootvg active hdisk0 00000f6a47b2e4d5 none
In this example, hdisk1 is an internal disk and hdisk0 is an external SAN disk.
alt_disk_copy from hdisk1 (internal disk) to hdisk0 (external disk)
alt_disk_copy command copies the current rootvg to an
alternate disk. In short, it is used to clone the currently running disk to an alternate disk.
alt_disk_copy –d hdisk0 -B -O #(hdisk0 is the target disk)
Where -B specifies to not run the boot list after the
mksysb or clone.
-O performs a device reset on the target altinst_rootvg. This causes the alternate disk install to not retain any user-defined device configuration. This flag is useful if the target disk or disks become the rootvg of a different system (such as in the case of logical partitioning or system disk swap).
We can now view the altinst_rootvg on the source LPAR as:
hdisk0 00c5f37067790da3 altinst_rootvg
hdisk1 00c5f370dda17847 rootvg active
Export the altinst_rootvg from the source LPAR
Export the altinst_rootvg on hdisk0 by using the
This command exports the definition of a volume group from a set of physical volumes.
exportvg command removes the definitions of altinst_rootvg definition from the source LPAR and allows hdisk0 to be
used as the boot device in other partitions.
VIO client LPAR setup
The VIOS has the physical resources, such as disks and Ethernet adapters. These physical resources are being used by the client LPARs as virtual devices, that is, the physical resources are being allocated by the servers to the clients. The allocation of the disks from VIOS to the client partitions will be discussed.
Create the new profile for the target LPAR in the HMC. As part of VIOS and client setup, we will discuss on editing the new target LPAR profile in the HMC to add the virtual Ethernet and virtual SCSI (VSCSI) setup.
Virtual Ethernet setup
On the VIOS, the Shared Ethernet Adapter enables the client partitions to communicate with other systems outside the CPC without requiring physical Ethernet adapters in the partitions. The enabling and setup of a virtual Ethernet adapter in an AIX client partition does not require any special hardware or software. After a specific virtual Ethernet is enabled for a partition, a network device is created within the partition.
In order to create the virtual Ethernet on the client side, in the HMC GUI, select the newly created LPAR profile and in the Tasks (bottom side) section of the window:
Click Configuration-> Manage Profiles->Actions-> Edit->Virtual Adapters-> Create Ethernet Adapter.
Figure 1. Creating the virtual Ethernet adapter
In order to use the disks from the VIOS, create a virtual SCSI adapter at the VIOS and client LPAR. At the VIOS side, create a VSCSI server adapter and at the client side, create a VSCSI client adapter.
Create these adapters using the HMC GUI. For creating the client SCSI adapter, in the HMC GUI, select the newly created LPAR profile, and in the Tasks (bottom side) section of the window:
Click Configurations->Manage profiles->Actions->Edit->Virtual Adapters->Create SCSI Adapter.
Figure 2. Creating the client SCSI adapter
For creating the server SCSI adapter, in the HMC GUI, select the VIOS LPAR profile and in the Tasks (bottom side) section of the window:
Click Configurations->Manage profiles->Actions->Edit->Virtual Adapters->Create SCSI Adapter.
Figure 3. Creating the server SCSI adapter
The slot number of the SCSI adapters must be mapped correctly on the VIOS and VIO client.
Assign the LUN that was created in the previous section "Assign additional hdisk from external Storage" to the VIOS and issue the
chdev command to change the characteristics of the new device. Make sure that you issue the
cfgmgr command in the root shell of the VIOS to configure the hdisk in the VIOS.
Map the assigned hdisk to the corresponding virtual SCSI server adapter using the
mkvdev command in the padmin shell. The command to map the hdisk to the virtual SCSI server adapter is:
$mkvdev –vdev assigned_hdiskname -vadapter virtual_SCSI_server_adapter -dev virtual_target_device_name
mkvdev –vdev hdisk4 -vadapter vhost0 -dev target_lpar_rootvg
Here hdisk4 is the same disk where we cloned the physical source LPAR.
On VIOS, the corresponding virtual SCSI host adapters and the physical devices, that is, the hdisks are mapped. You can check this mapping using the
lsmap –all command in the padmin shell.
SVSA Physloc Client Partition ID
--------------- ----------------------------- -------------------
vhost0 U9119.FHA.025F370-V1-C30 0x00000005
Backing device hdisk4
The first column of the
lsmap –all output shows the server VSCSI adapter name as vhostname
In the Physloc (second column) check the last digit, which is C30. Here, 30 is the server SCSI adapter ID.
Use the exported disk as the boot device for the target LPAR
This completes the physical to virtual migration. The target LPAR now has the rootvg on the hdisk that is cloned from the source physical LPAR. The hdisk is backed by the VIOS.
Activate the migrated virtual LPAR in the HMC. For activating a new virtual LPAR in the HMC GUI, select the newly created LPAR profile in the Tasks section of the window:
Click Operations -> Activate.
Set the new host name and the new IP address after activating the migrated virtual LPAR. There might be a need to migrate the data volume group present in the source physical LPAR to the virtual LPAR, which is similar to the root volume group migration.
- Learn about the HMC
- Refer to the AIX 7.1 information center
- Learn more on Virtual I/O Server
- IBM Products Information Centers Index
- Stay current with developerWorks technical events and webcasts focused on a variety of IBM products and IT industry topics.
- Attend a free developerWorks Live! briefing to get up-to-speed quickly on IBM products and tools as well as IT industry trends.
- Follow developerWorks on Twitter.
- Watch developerWorks on-demand demos ranging from product installation and setup demos for beginners to advanced functionality for experienced developers.
Get products and technologies
- Evaluate IBM products in the way that suits you best: Download a product trial, try a product online, use a product in a cloud environment, or spend a few hours in the SOA Sandbox learning how to implement service-oriented architecture (SOA) efficiently.
- Participate in the discussion forum.
- Get involved in the My developerWorks community. Connect with other developerWorks users while exploring the developer-driven blogs, forums, groups, and wikis.