Volume Migration Using SVC 2.1 July2005

SVC VOLUME MIGRATION
The information, tools and documentation (Materials) are being provided to IBM customers to
assist them with customer installations. Such Materials are provided by IBM on an as-is basis.
IBM makes no representations or warranties regarding these Materials and does not provide any
guarantee or assurance that the use of such Materials will result in a successful customer installation.
MATERIAL UPDATED ON JULY 2005, IT REFLECTS CHANGES/FIXES ON THE

SAN VOLUME CONTROLLER CODE 2.1 and the ICAT CONSOLE 2.1.
ADDITIONAL TEST SCENARIOS WILL BE ADDED AS NECESSARY TO CLARIFY NEW
AVAILABLE FUNCTIONS.
Copyright IBM 2004

DISK VOLUME MIGRATION USING THE SAN VOLUME CONTROLLER
WHITE PAPER
The purpose of this paper is to provide detailed, step-by-step instructions on the migration of SAN attached
disk volumes to a virtualized environment using the IBM SAN Volume Controller (SVC, SIS or SVC for
Cisco MDS).
The current IBM publications (SVC Redbook SG24-6423 and the SVC Configuration Guide SC26-7543)
provide some detail on migration, but this critical function has to be clearly understood and documented to
enable a successful implementation of IBM Virtualization using the SVC family of products.
This paper is intended for people who are familiar with the SVC, but need a practical example to guide them
through the steps of how to migrate from an existing SAN environment to a SVC virtualized environment.
FIGURE 1 shows the lab environment, in which a LUN is assigned to a Windows 2000 Server from an ESS
Model 800 storage system. The LUN is seen by Windows as a basic disk by default and can be converted to a
dynamic disk if desired. In this whitepaper dynamic disks will be used. The disk is formatted and the volume
is labeled as H:\WIN2KAPPL.
.
Copyright IBM 2004

Here is the way LUN H:\WIN2KAPPL looks to the Win2K Server before we start the virtualization
migration:
Notice that the WIN2KAPPL (H: disk) comes from the 2105-800 (ESS_800) machine.
Copyright IBM 2004

These are the contents of the H:\WIN2KAPPL disk provided by the ESS_800:
Capacity: 1.86GB, 121 MB being used.
Copyright IBM 2004

To perform a SAN attached disk migration to a virtualized environment; the following 5 steps need to take
place before we start using the IBM SAN Volume Controller:
1) Using the SAN fabric zoning tool (any of the supported switches tools), create an SVC_STORAGE Zone
that includes the ESS_800, the FAStT900 and the SVC Fibre Channel adapters (all 4 in each node).
2) Create an additional SVC_HOST Zone that includes the Win2K Server (SAN340_1) used in our
environment to represent the HOST, and the SVC Adapters (2 FC adapters, one from each SVC node
should be sufficient).
3) Activate the zone changes so they are ready when needed.
4) Shutdown the Win2K Server (SAN340_1), so the operating system is not aware of the LUN changes
that take place during the disk migration to SVC.
5) Using the ESS Specialist, un-assign the WIN2KAPPL LUN from the Win2K Server FC adapter, and
assign it to all the SVC FC adapters in each node, as shown in FIGURE 2.
Copyright IBM 2004

Having the environment ready by performing the previous 5 steps we can start the virtualization process using
the SVC master console (in this paper we assume familiarity with the SVC and its user interface).
NOTE: IF YOU NEED INFORMATION ON HOW TO VIRTUALIZE A LUN ON A
UNIX ENVIRONMENT, PLEASE REFERENCE THE APPENDIX ITEM 3 ON THIS
PAPER.
6) The first task is to find the newly attached LUN from the ESS_800. So under My Work we click on
WORK WITH MANAGED DISKS and click on MANAGED DISKS and the following panel is
displayed:
:
Notice that there are 3 pages of Managed Disks. We look for the new LUN and dont find it, so we continue
with step 7.
Copyright IBM 2004

7) We execute the DISCOVER MDISKS function and click GO. After the SVC discovers the newly
assigned disk (in our case MDISK5) it will appear with Status=ONLINE and
Mode= UNMANAGED.
NOTE: Sometimes the newly assigned disk is recognized dynamically, so there is no need for the
DISCOVER function, so make sure you look for the unmanaged disk that you acquired.
In our example, MDISK5 is the same LUN that was previously allocated to the SAN340_1 Win2K
Server, so all the files and data are still intact.
8) A good practice we recommend is to rename the disks so they make more sense to your installation, in our
example, MDISK5 will be renamed using the function RENAME AN MDISK. The new name is
WIN2K_IMAGE.
Copyright IBM 2004

9) In this step we will create an IMAGE MODE vDisk.
On the same Managed Disks panel, we select the WIN2K_IMAGE disk, and execute the CREATE A
VDISK IN IMAGE MODE function. This will trigger an SVC wizard that needs to be followed carefully.
NOTE: ALL MANAGED DISKS HAVE TO BE ASSOCIATED WITH A MANAGED DISK GROUP,
BUT WE SUGGEST THAT YOU CREATE AN MDG WITHOUT ANY DISKS AND NAME IT
MY_IMAGES_GROUP OR ANY OTHER NAME THAT MAKES SENSE IN YOUR
ENVIRONMENT.
See Appendix item 5 (COMMENTS ON MDG FOR IMAGE MODE VDISKS)
for a step-by-step process to create this Managed Disk Group.
MOST PEOPLE ALREADY HAVE MANAGED DISK GROUPS DEFINED, IN
THAT CASE, PROCEED WITH THE FOLLOWING INSTRUCTIONS.
Copyright IBM 2004

The first panel labeled CHOOSE AN I/O GROUP AND MANAGED DISK GROUP merits a
discussion to clarify the values on the different fields.
The flag Let the system choose a preferred node and I/O group should be checked (that is the default).
In our case, the defaults were used, which are the correct choice in most cases.
The field SELECT THE MANAGED DISK GROUP will allow us to associate the vDisk we are
creating with a specific managed disk group. In our lab we already had several Managed Disk Groups,
so we selected from them the ESS800_GROUP,and clicked Next.
NOTE: When creating an IMAGE MODE vDisk, we dont use storage from the selected MDG, but just
pick the extent size associated with that pool (Managed Disk Group). The extent size will be important
when our IMAGE disk is migrated to a totally virtualized vDisk.
SEE APPENDIX ITEM 4 (COMMENTS ON EXTENT SIZE REQUIERMENTS ON VDISK MIGRATION).
Copyright IBM 2004
Notice that the type of virtual disk is Image, and that the number of vDisks is already selected with a
value of 1. We click NEXT to continue.
Copyright IBM 2004
10
We chose the name WIN2K_DISK for the Virtual Disk. We click NEXT.
Copyright IBM 2004
11
The panel above shows that the Image-Mode vDisk will be created from the WIN2K_IMAGE Mdisk,
which was originally attached from the ESS_800 to the Win2K Server. We click NEXT.
The panel above is a summary of the process to create our Image disk.
We click finish to create the WIN2K_DISK.
Copyright IBM 2004
12
The vDisk was successfully created, as shown in the above panel.

10) On the SVC Console, we will select Work with Virtual Disks, and select Hosts, to create the Host that will
represent the Win2K Server; we chose the same name that Windows has for that machine (SAN340_1).
The following panel shows that SAN340_1 is already created, and has one port WWPN available. This
was possible by the SVC_HOST Zone we created in step 2.
Copyright IBM 2004
13

11) The next step will be to map the image vDisk to the WIN2K Server called SAN340_1.
We select the SVC console function WORK WITH VIRTUAL DISKS, and select VIRTUAL DISKS.
Find the image vDisk, in our example called WIN2K_DISK, select it and execute the function MAP
vDisk TO A HOST, as shown below.
Copyright IBM 2004
14

The SVC Console shows the following display with a list of possible hosts which can be owners of this
vDisk.
We select SAN340_1
At this time, we should start the SAN340_1 host (remember it was shutdown to allow the storage
change, from ESS_800 to SVC).
NOTE: Once the SAN340_1 is up and running, it will have the Virtual Disk WIN2K_DISK attached
and any additional SVC migration, disk expansion, etc. will NOT require the Win2K Server to be down.
Copyright IBM 2004
15

The following chart summarizes all the steps that we took to create an Image Disk and attach it to the
Win2K Server.
Copyright IBM 2004
16

To verify the Virtualization operation was a success, we select the Windows function COMPUTER
MANAGEMENT, and click DISK MANAGEMT, to display the status of the SAN340_1 disks.
In our example, notice the original H: disk is back, but now instead of being provided by the ESS_800, it
comes from 2145 (SVC machine number).
NOTE: In some cases with Windows, the disk (in our case Disk 3), will appear offline. If that is the case,
right click on area labeled Disk 3, and select REACTIVATE DISK. This will bring the disk online will all
the appropriate attributes.
Copyright IBM 2004
17

Notice the WIN2KAPPL contents provided by the SVC Image disk; match perfectly the original contents
when the disk was directly attached to the ESS_800: Capacity of 1.86 GB, 121 MB being used.
Copyright IBM 2004
18

The last step to complete the Virtualization process will be to make the IMAGE disk part of a virtualized
pool. In our example the image disk associated with ESS_800 Storage, will be transferred to FastT900
based storage.
If our original disk had been on an EMC Symmetrix, these same steps would apply, so we could migrate
from EMC to ESS, FastT, Hitachi, etc.
The following chart summarizes the process to migrate from one type of storage to another:
Copyright IBM 2004
19

13) The migration of SVC Virtual disks from one pool (Managed Disk Group) to another is a very simple
command done in the Virtual Disks panel, as you can see below. The most important issue is that this
migration of the storage will be done under the covers by the SVC, so the owning host (in our case
SAN340_1) will NEVER loose connectivity with the LUN while it is being migrated.
We find our vDisk called WIN2K_DISK, select it and issue the MIGRATE VDISK function, as seen
above, notice the type is IMAGE, and the Mdisk Group Name that is associated with is ESS800_GROUP.
Copyright IBM 2004
20

The following panel is displayed, showing a list of available target Managed Disk Group, where the Image
disk will migrate to, in our case FastT900_MIGRAT.
Another selection required, is the priority of this migration (number of threads) 1 being low and 4 being
high. This priority will be highly dependent on the workload taking place at the moment of migration.
In our case 4 Threads, the highest priority, is the chosen value.
Copyright IBM 2004
21

Notice on the screen capture below that the WIN2K_DISK, now has a type of STRIPED, and that it
belongs to the Mdisk Group Name FastT900_MIGRAT.
This migration means that all the data that was in one LUN was moved to a group of multiple LUNs that
are part of the FastT900_MIGRAT, and the data is striped across all those LUNs, which in most cases
will increase performance.
Copyright IBM 2004
22

This screen shows that the data in the Windows Server, which now is being provided by the SVC using
multiple FastT900 based disks, looks EXACTLY the same as before the migration.
Capacity: 1.86 GB, 121 MB being used.
Copyright IBM 2004
23

APPENDIX:
1) COMMENTS ON THE DOCUMENT:
As mentioned on the introduction, this paper is a detailed step-by-step instruction on how to migrate SAN
attached storage to a Virtualized environment. People with little experience on the SVC should be able to
follow the logical sequence of events to make the migration possible. For those more experienced users,
this document could be a reference guide to verify their own process. If you have any comments or
suggestions, please send a note to gfuentes@us.ibm.com.
2) COMMENTS ON THE TEST SCOPE:

The examples used to illustrate the migration apply specifically to a Windows 2000 host, but they can be
used for all other operating systems supported by the SVC.
We should point out that the outage of the Windows host in our example took only a matter of minutes,
so the impact of having to shutdown some server types should not be a big concern.
Another area that is important to point out, is that we used the SVC ICAT console to perform the
migration, but all the functions used, are also available on the Command Line Interface, so many of these
tasks could be scripted to automate the Virtualization.
3) COMMENTS ON VIRTUALIZING A LUN ON A UNIX ENVIRONMENT:

To virtualize a SAN attached volume, originally attached to an AIX machine, the following steps should
take place:
1) UNMOUNT THE FILE SYSTEM (release the Disks from AIX)
2) VARY OFF VOLUME GROUP
(release the SCSI reserve on the LUNs)
3) EXPORT VOLUME GROUP
(remove Volume Group and File System from the OS)
4) Assign original LUN to SVC
(Using ESS Specialist, SM8 or other tool)
5) Discover the new Managed Disk under SVC
6) Create an Image Mode vDisk on SVC
7) Map the vDisk to the AIX host on the SVC.
8) RUN CFGMGR
(discover new environment)
9) IMPORT VOLUME GROUP
(recover the Group and File System definitions)
10) MOUNT THE FILE SYSTEM
11) DONE!!!!
(At this point the original file system is available for access)
NOTE: We are not documenting the tasks needed to handle multipaths, which in most cases will require
the installation of SDD to replace the multipathing software used to connect directly to the
SAN storage.
There are several AIX tasks, which are not documented in this section, because they are considered
part of the normal housekeeping of the system.
.
Copyright IBM 2004
24

4) COMMENTS ON EXTENT SIZE REQUIREMENTS ON vDisk MIGRATION:
The extent size is very important in our examples migration from ESS to FastT, because having the
SAME EXTENT size, is a requirement to migrate from one pool (Managed Disk Group) to another.
Because of this requirement, we recommend that you try to set a common extent size for all the Managed
disk groups.
The SVC Redbook states that a value of 32 MB (128 TB) or 64 MB (256 TB) can be the best trade-off
between performance and capacity.
5) COMMENTS ON MDG FOR IMAGE MODE VDISKs:

If you are creating an IMAGE MODE vDisk for the first time, the following instructions should provide a
guide to make your life easier.
Note: the Mdisk Candidates in this panel, pointed by the blue arrows. We DO NOT add any of them
to our group, as that would make a pool, and destroy the data in those disks. We just want an empty
Group. We click Next> to continue
Copyright IBM 2004
25
We select an Extent Size of 64MB and click next
We click finish to create the Managed Disk Group, notice there are ZERO managed disks in this
group.
Copyright IBM 2004
26

This section of the migration document will address new image mode migration capabilities
available in SVC 2.1.
We will start with a Windows 2000 Server that has a 15 gig LUN allocated from a DS4300,
The environment is illustrated in figure 1:
Copyright IBM 2004
27

Here is a display of the Windows Z: disk, called SVC21_MIGR, and its properties
Notice on the Disk2 Properties that the 15 gig LUN came from DS4300 (1722-600).
Copyright IBM 2004
28

Our objective is to use the SVC 2.1, to help us migrate the Windows disk from DS4300 storage to
FastT200, as this disk is of low importance and should be moved to less expensive storage.
The first step is to allocate the existing disk to the SVC. In order to do that, we shutdown the
Win2K system, and using the SM8 management tool, we assign the LUN we want to migrate to the
SVC.
NOTE: After the LUN is unassigned from the Win2K host, we can reactivate this host at any time.
We show this process in Figure 2:
Copyright IBM 2004
29

We are now working with the SVC Console, and when we issue a command on the Managed Disks
panel to Discover Mdisks, we find the 15 gig LUN that was part of Windows, available for
Virtualization. We keep our practice of renaming the Mdisks to a meaningful name, so we
rename the Mdisk from mdisk16 to SVC21_MIG_MDISK, for easier identification.
The first step we take to virtualize the LUN is to create an Image Mode disk, to preserve all the data
that was available in the Windows Z: disk called SVC21_MIGR.
Copyright IBM 2004
30
To set the attributes of the new virtual image mode vDisk, we select to keep the same name as the
Original Windows disk, because it is the first Image Mode vDisk that we handle, we accept the
default of Create an Empty Managed Disk Group (remember the only attribute we take from the
MDG is the extent size). The panel below also shows that the Mdisk SVC21_MIG_MDISK is the
base for our Image Mode vDisk
Copyright IBM 2004
31

We give the name MIGRATION_GROUP to the newly created Managed Disk Group
We select 64MB as the extent size, as we decided this is a good value for our environment, we
decided to have ALL Managed Disk Groups with this extent value, so we can move and migrate
among all of them.
We keep all the defaults and select as highlighted below the MIGRATION_GROUP MDG.
Copyright IBM 2004
32
Here is the result of our SVC21_MIGR Image Mode vDisk creation
Now we only need to map the Image Mode vDisk to SAN340_1 as shown on Figure 3
Copyright IBM 2004
33
Mapping the Image Mode vDisk to the Windows 2000 host is accomplished with the following
command:
Copyright IBM 2004
34

On the Windows host SAN340_1, we go to the Disk Management function and issue a rescan to
recover the SVC21_MIGR disk, as shown below, we recover a disk but it shows offline.
We click right button to get the following properties, so we can Reactivate Disk to allow
access to Windows. You see in the panel below, that the Windows disk kept all the attributes,
like Drive letter (Z:), name (SVC21_MIGR) and the 15 GIG size.
Copyright IBM 2004
35

You will see that in the Disk Properties, it shows that the disk came from 2145, which
identifies the SVC machine number.
Copyright IBM 2004
36

You can verify that the contents of the SVC21_MIGR disk are exactly the same as they were
when the disk was provided by the DS4300.
Copyright IBM 2004
37

IMAGE MODE TO IMAGE MODE MIGRATION, AND
REMOVAL OF FastT200 DISK FROM THE SVC CONTROL
Up to this point, creating an Image Mode vDisk has been the same as previous releases of
SVC. In this section we will use the SVC2.1 function to migrate an Image Mode vDisk in
Image Mode format, in that manner allowing the File to be moved to different storage (in our
example we will move it to FasT200), and also very important, if we so desire, we can take
that migrated Image Mode LUN, and give it DIRECTLY to the host, removing any
dependency to have the data under SVC. This function allows a very efficient way to provide
storage migration, with a minimal impact to the supported hosts.
Our environment is describer in Figure 4
Copyright IBM 2004
38

Using the SM8 management tool for FastT, we allocated a 15 gig LUN, from FastT200
storage to the SVC. This new LUN will be used as our target in the migration from DS4300
based storage to FastT200.
We issue a Discover MDisks to rescan the Fibre Channel network and we find a new
Managed Disk, that we immediately renamed SVC21_MIG_F200
We will start using the new SVC 2.1 function called Migrate to an Image Mode vDisk, so
we select our SVC21_MIGR vDisk as the source. During the migration, the Win2K host will
be able to access information without any impact of the major changes happening under the
SVC control. We will move the data from DS4300 to FastT200 totally transparent to the
Win2K Host.
Copyright IBM 2004
39

The target of the Image Mode vDisk migration is selected below, as we mentioned before,
this is the LUN that was allocated to the SVC from the FastT200, and the one we named
SVC21_MIG-F200.
We will associate the SVC_MIG_F200 to the MIGRATION_GROUP MDG, so it also gets

the attribute of 64MEG Segment Size, like the Source LUN so it can be migrated.
Copyright IBM 2004
40

Here is the summary of our Image to Image Migration: We will take the extents and data
associated with SVC21_MIGR (on the DS4300 MDSIK called SVC21_MIG_MDISK) and
move it to a FastT200 based MDISK called SVC_MIG_F200.
Copyright IBM 2004
41

While migrating from one kind of storage to another, we issued reads and writes to the
Windows disk, while it was migrating on the SVC, and verified that all the new data was
reflected in the new storage.
We started an unzip to create a new file called BIG_ZIP_CONCURRENT
Copyright IBM 2004
42

The following panel indicates that the IMAGE to IMAGE migration was successful
This panel shows that the Image Mode vDisk is now running on storage provided by the
SVC21_MIG_F200 Managed Disk, and the supporting storage come from the FastT200
Controller.
Copyright IBM 2004
43

REMOVAL OF FastT200 DISK FROM THE SVC CONTROL
If we need to provide the FastT200 disk, directly to the Windows host, we would need to
perform the following additional steps:
1) Shutdown the SAN340_1 host. We are going to change the storage source for the
SVC21_MIGR disk, so we need to do that with the operating system down.
2) Unmap the SVC21_MIGR vDisk from the SAN340_1 Host, using the SVC Console.
Copyright IBM 2004
44

3) Delete the SVC21_MIGR vDisk (as seen below) to insure the SVC writes the cache to
the disk, before we unattach the MDISK (LUN) from the SVC, using SM8.
4) Unmap the SVC21_MIG_F200 Mdisk from the SVC using the FastT Management
tool (SM8), and map it to SAN340_1.
5) Power on the SAN340_1 Host, access disk management to see the status of the disk.
The SVC21_MIGR disk might be offline, like show below, in that case, we reactivate the
Windows dynamic disk.
Copyright IBM 2004
45

Once the disk is active, we can see that all the attributes, and the files that were created are
available to Win2K, but now the disk comes directly from the FastT200, with all SVC
dependencies removed.
Copyright IBM 2004
46

MIGRATION FROM AN SVC STRIPPED vDisk TO AN IMAGE
MODE vDisk.
Using the SVC Console, we start by creating a 1GB vDisk from the DS4300 MDG, and map
it to the SAN340_1 Host.
In the SAN340_1 disk, we format the disk (Y :) and give it the name SVC21_STRIP, we add
Data so we use 679 Meg.
Copyright IBM 2004
47

We initiate a migration from the striped SVC21_STRP_TEST vDisk to an Image Mode
vDisk, so we can later assign that disk directly to the SAN340_1.
Our Target disk for the image will be 1 GIG LUN, called IMAGE_STR_TGT, this Mdisk
comes from the DS4300.
Copyright IBM 2004
48

We need to assign the Mdisk to a Managed Disk Group (MDG) so we can get the attributes
like extent size, so we picked the one labeled another migration Mdisk Group.
We assign 4 threads to speed up the migration, verify all our parameters, and execute the
migration.
Copyright IBM 2004
49

The following steps are required if we want to provide the disk directly from the DS4300, to
the Windows host. These are the same steps as we saw in our previous example:
1) Shutdown the SAN340_1 host
2) Delete the Host mapping on the SVC
3) Delete the vDisk, to insure that the cache is written to the disk, before we
unattach from the SVC, using SM8.
4) Unassign image LUN from SVC, and assign directly to the Win2K host, using SM8.
5) Power-on the SAN340_1 host.
Here is the status of the LUN in Windows, showing that now it comes from the DS4300
(1722-600):
Copyright IBM 2004
50

We verify that the contents of the LUN from FasT600 are exactly the same as they were
under the SVC vDisk, and they are.
We need some additional housekeeping on the SVC Console:

6) Issue a Discover Mdisks command on the SVC Mdisks panel, so the fibre channel
network is rescanned
7) Issue a Refresh on the SVC Mdisks panel, so the console reflects the
IMAGE_STR_TGT Managed Disk (LUN) is not allocated anymore to the SVC, as it is
now directly assigned by the FastT management tool, to the SAN340_1 Host.
Copyright IBM 2004
51
Copyright IBM 2004
52

Volume Migration Using SVC 2.1 July2005

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Volume Migration Using SVC 2.1 July2005

Diunggah oleh

Hak Cipta:

Format Tersedia

SVC VOLUME MIGRATION

MATERIAL UPDATED ON JULY 2005, IT REFLECTS CHANGES/FIXES ON THE

Copyright IBM 2004

SVC VOLUME MIGRATION

Copyright IBM 2004

SVC VOLUME MIGRATION

Copyright IBM 2004

SVC VOLUME MIGRATION

Copyright IBM 2004

SVC VOLUME MIGRATION

Copyright IBM 2004

SVC VOLUME MIGRATION

Copyright IBM 2004

SVC VOLUME MIGRATION

Copyright IBM 2004

SVC VOLUME MIGRATION

Copyright IBM 2004

SVC VOLUME MIGRATION

Copyright IBM 2004

SVC VOLUME MIGRATION

Copyright IBM 2004

SVC VOLUME MIGRATION

Copyright IBM 2004

SVC VOLUME MIGRATION

Copyright IBM 2004

SVC VOLUME MIGRATION

The vDisk was successfully created, as shown in the above panel.

Copyright IBM 2004

SVC VOLUME MIGRATION

Copyright IBM 2004

SVC VOLUME MIGRATION

Copyright IBM 2004

SVC VOLUME MIGRATION

Copyright IBM 2004

SVC VOLUME MIGRATION

Copyright IBM 2004

SVC VOLUME MIGRATION

Copyright IBM 2004

SVC VOLUME MIGRATION

Copyright IBM 2004

SVC VOLUME MIGRATION

Copyright IBM 2004

SVC VOLUME MIGRATION

Copyright IBM 2004

SVC VOLUME MIGRATION

Copyright IBM 2004

SVC VOLUME MIGRATION

Copyright IBM 2004

SVC VOLUME MIGRATION

2) COMMENTS ON THE TEST SCOPE:

3) COMMENTS ON VIRTUALIZING A LUN ON A UNIX ENVIRONMENT:

SVC VOLUME MIGRATION

5) COMMENTS ON MDG FOR IMAGE MODE VDISKs:

Copyright IBM 2004

SVC VOLUME MIGRATION

We select an Extent Size of 64MB and click next

Copyright IBM 2004

SVC VOLUME MIGRATION

Copyright IBM 2004

SVC VOLUME MIGRATION

Copyright IBM 2004

SVC VOLUME MIGRATION

Copyright IBM 2004