Upload
hiehie272
View
216
Download
0
Embed Size (px)
Citation preview
7/26/2019 Volume Migration Using Svc 2.1 July2005
1/52
SVC VOLUME MIGRATION
Copyright IBM 2004 1
The information, tools and documentation (Materials) are being provided to IBM customers toassist 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 anyguarantee 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.
7/26/2019 Volume Migration Using Svc 2.1 July2005
2/52
SVC VOLUME MIGRATION
Copyright IBM 2004 2
DISK VOLUME M IGRATION USING THE SAN VOLUME CONTROLLER
WHI TE 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 forCisco 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 themthrough 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 ESSModel 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..
7/26/2019 Volume Migration Using Svc 2.1 July2005
3/52
SVC VOLUME MIGRATION
Copyright IBM 2004 3
Here is the way LUN H:\WIN2KAPPLlooks to the Win2K Server before we start the virtualization
migration:
Notice that the WIN2KAPPL(H: disk) comes from the 2105-800(ESS_800) machine.
7/26/2019 Volume Migration Using Svc 2.1 July2005
4/52
SVC VOLUME MIGRATION
Copyright IBM 2004 4
These are the contents of the H:\WIN2KAPPLdisk provided by the ESS_800:
Capacity: 1.86GB, 121 MB being used.
7/26/2019 Volume Migration Using Svc 2.1 July2005
5/52
SVC VOLUME MIGRATION
Copyright IBM 2004 5
To perform a SAN attached disk migration to a virtualized environment; the following 5 steps need to take
place beforewe start using the IBM SAN Volume Controller:
1) Using the SAN fabric zoning tool (any of the supported switches tools), create an SVC_STORAGEZonethat includes the ESS_800, the FAStT900 and the SVC Fibre Channel adapters (all 4 in each node).
2) Create an additional SVC_HOST Zonethat includes the Win2K Server (SAN340_1)used in ourenvironment to represent the HOST, and the SVC Adapters (2 FC adapters, one from each SVC nodeshould 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 changesthat take place during the disk migration to SVC.
5) Using the ESS Specialist, un-assign the WIN2KAPPLLUN from the Win2K Server FC adapter, andassign it to all the SVC FC adapters in each node, as shown in FIGURE 2.
7/26/2019 Volume Migration Using Svc 2.1 July2005
6/52
SVC VOLUME MIGRATION
Copyright IBM 2004 6
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 onWORK 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.
7/26/2019 Volume Migration Using Svc 2.1 July2005
7/52
SVC VOLUME MIGRATION
Copyright IBM 2004 7
7) We execute the DISCOVER MDISKSfunction and click GO. After the SVC discovers the newlyassigned disk (in our case MDISK5) it will appear with Status=ONLINE andMode= 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, MDISK5is the same LUN that was previously allocated to the SAN340_1Win2K
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 ourexample, MDISK5 will be renamed using the function RENAME AN MDISK. The new name is
WIN2K_IMAGE.
7/26/2019 Volume Migration Using Svc 2.1 July2005
8/52
SVC VOLUME MIGRATION
Copyright IBM 2004 8
9) In this step we will create an IMAGE MODE vDisk.
On the same Managed Disks panel, we select the WIN2K_IMAGEdisk, 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 DI SKS HAVE TO BE ASSOCIATED WI TH A MANAGED DI SK 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 I N YOUR
ENVIRONMENT.
See Appendix item 5 (COMMENTS ON MDG FOR IM AGE MODE VD ISKS)
for a step-by-step process to create this Managed Disk Group.
MOST PEOPLE ALREADY HAVE MANAGED DI SK GROUPS DEF INED, IN
THAT CASE, PROCEED WITH THE FOLLOWING I NSTRUCTIONS.
7/26/2019 Volume Migration Using Svc 2.1 July2005
9/52
SVC VOLUME MIGRATION
Copyright IBM 2004 9
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 arecreating 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 justpick 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).
7/26/2019 Volume Migration Using Svc 2.1 July2005
10/52
SVC VOLUME MIGRATION
Copyright IBM 2004 10
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.
7/26/2019 Volume Migration Using Svc 2.1 July2005
11/52
SVC VOLUME MIGRATION
Copyright IBM 2004 11
We chose the name WIN2K_DISKfor the Virtual Disk. We click NEXT.
7/26/2019 Volume Migration Using Svc 2.1 July2005
12/52
SVC VOLUME MIGRATION
Copyright IBM 2004 12
The panel above shows that the Image-Mode vDisk will be created from the WIN2K_IMAGEMdisk,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.
7/26/2019 Volume Migration Using Svc 2.1 July2005
13/52
SVC VOLUME MIGRATION
Copyright IBM 2004 13
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 willrepresent the Win2K Server; we chose the same name that Windows has for that machine (SAN340_1).
The following panel shows that SAN340_1is already created, and has one port WWPN available. This
was possible by the SVC_HOST Zonewe created in step 2.
7/26/2019 Volume Migration Using Svc 2.1 July2005
14/52
SVC VOLUME MIGRATION
Copyright IBM 2004 14
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.
7/26/2019 Volume Migration Using Svc 2.1 July2005
15/52
SVC VOLUME MIGRATION
Copyright IBM 2004 15
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_1host(remember it was shutdown to allow the storage
change, from ESS_800 to SVC).
NOTE: Once the SAN340_1 is up and runni ng, it wil l have the Vir tual D isk WIN2K_DI SK attached
and any addit ional SVC migrati on, disk expansion, etc. will NOT require the Win2K Server to be down.
7/26/2019 Volume Migration Using Svc 2.1 July2005
16/52
SVC VOLUME MIGRATION
Copyright IBM 2004 16
The following chart summarizes all the steps that we took to create an Image Disk and attach it to the
Win2K Server.
7/26/2019 Volume Migration Using Svc 2.1 July2005
17/52
SVC VOLUME MIGRATION
Copyright IBM 2004 17
To verify the Virtualization operation was a success, we select the Windows function COMPUTERMANAGEMENT, and click DISK MANAGEMT, to display the status of the SAN340_1disks.
In our example, notice the original H: disk is back, but now instead of being provided by the ESS_800, itcomes 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.
7/26/2019 Volume Migration Using Svc 2.1 July2005
18/52
SVC VOLUME MIGRATION
Copyright IBM 2004 18
Notice the WIN2KAPPLcontents 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.
7/26/2019 Volume Migration Using Svc 2.1 July2005
19/52
SVC VOLUME MIGRATION
Copyright IBM 2004 19
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_800Storage, will be transferred to FastT900based 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:
7/26/2019 Volume Migration Using Svc 2.1 July2005
20/52
SVC VOLUME MIGRATION
Copyright IBM 2004 20
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 thismigration 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 seenabove, notice the type is IMAGE, and the Mdisk Group Name that is associated with is ESS800_GROUP.
7/26/2019 Volume Migration Using Svc 2.1 July2005
21/52
SVC VOLUME MIGRATION
Copyright IBM 2004 21
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.
7/26/2019 Volume Migration Using Svc 2.1 July2005
22/52
SVC VOLUME MIGRATION
Copyright IBM 2004 22
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.
7/26/2019 Volume Migration Using Svc 2.1 July2005
23/52
SVC VOLUME MIGRATION
Copyright IBM 2004 23
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.
7/26/2019 Volume Migration Using Svc 2.1 July2005
24/52
SVC VOLUME MIGRATION
Copyright IBM 2004 24
APPENDIX:
1) COMMENTS ON THE DOCUMENT:As mentioned on the introduction, this paper is a detailed step-by-step instruction on how to migrate SANattached storage to a Virtualized environment. People with little experience on the SVC should be able tofollow 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 [email protected].
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 themigration, 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 SVC7) 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 SYSTEM11) 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.
.
7/26/2019 Volume Migration Using Svc 2.1 July2005
25/52
SVC VOLUME MIGRATION
Copyright IBM 2004 25
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 Manageddisk 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 aguide to make your life easier.
Note: the Mdisk Candidates in thi s panel, poin ted by theblue arrows. We DO NOT add any of them
to our group, as that woul d make a pool, and destroy the data in those disks. We just want an empty
Group. We click Next> to continue
7/26/2019 Volume Migration Using Svc 2.1 July2005
26/52
SVC VOLUME MIGRATION
Copyright IBM 2004 26
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 thisgroup.
7/26/2019 Volume Migration Using Svc 2.1 July2005
27/52
SVC VOLUME MIGRATION
Copyright IBM 2004 27
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:
7/26/2019 Volume Migration Using Svc 2.1 July2005
28/52
SVC VOLUME MIGRATION
Copyright IBM 2004 28
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).
7/26/2019 Volume Migration Using Svc 2.1 July2005
29/52
SVC VOLUME MIGRATION
Copyright IBM 2004 29
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:
7/26/2019 Volume Migration Using Svc 2.1 July2005
30/52
SVC VOLUME MIGRATION
Copyright IBM 2004 30
We are now working with the SVC Console, and when we issue a command on the Managed Diskspanel 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.
7/26/2019 Volume Migration Using Svc 2.1 July2005
31/52
SVC VOLUME MIGRATION
Copyright IBM 2004 31
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 thedefault 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 thebase for our Image Mode vDisk
7/26/2019 Volume Migration Using Svc 2.1 July2005
32/52
SVC VOLUME MIGRATION
Copyright IBM 2004 32
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 migrateamong all of them.
We keep all the defaults and select as highlighted below the MIGRATION_GROUP MDG.
7/26/2019 Volume Migration Using Svc 2.1 July2005
33/52
SVC VOLUME MIGRATION
Copyright IBM 2004 33
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
7/26/2019 Volume Migration Using Svc 2.1 July2005
34/52
SVC VOLUME MIGRATION
Copyright IBM 2004 34
Mapping the Image Mode vDisk to the Windows 2000 host is accomplished with the following
command:
7/26/2019 Volume Migration Using Svc 2.1 July2005
35/52
SVC VOLUME MIGRATION
Copyright IBM 2004 35
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.
7/26/2019 Volume Migration Using Svc 2.1 July2005
36/52
SVC VOLUME MIGRATION
Copyright IBM 2004 36
You will see that in the Disk Properties, it shows that the disk came from 2145, which
identifies the SVC machine number.
7/26/2019 Volume Migration Using Svc 2.1 July2005
37/52
SVC VOLUME MIGRATION
Copyright IBM 2004 37
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.
7/26/2019 Volume Migration Using Svc 2.1 July2005
38/52
SVC VOLUME MIGRATION
Copyright IBM 2004 38
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 ofSVC. 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 ourexample we will move it to FasT200), and also very important, if we so desire, we can takethat 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
7/26/2019 Volume Migration Using Svc 2.1 July2005
39/52
SVC VOLUME MIGRATION
Copyright IBM 2004 39
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 DS4300based 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 theSVC control. We will move the data from DS4300 to FastT200 totally transparent to the
Win2K Host.
7/26/2019 Volume Migration Using Svc 2.1 July2005
40/52
SVC VOLUME MIGRATION
Copyright IBM 2004 40
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.
7/26/2019 Volume Migration Using Svc 2.1 July2005
41/52
SVC VOLUME MIGRATION
Copyright IBM 2004 41
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.
7/26/2019 Volume Migration Using Svc 2.1 July2005
42/52
SVC VOLUME MIGRATION
Copyright IBM 2004 42
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 wasreflected in the new storage.
We started an unzip to create a new file called BIG_ZIP_CONCURRENT
7/26/2019 Volume Migration Using Svc 2.1 July2005
43/52
SVC VOLUME MIGRATION
Copyright IBM 2004 43
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 FastT200Controller.
7/26/2019 Volume Migration Using Svc 2.1 July2005
44/52
SVC VOLUME MIGRATION
Copyright IBM 2004 44
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 theSVC21_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.
7/26/2019 Volume Migration Using Svc 2.1 July2005
45/52
SVC VOLUME MIGRATION
Copyright IBM 2004 45
3) Delete the SVC21_MIGR vDisk(as seen below) to insure the SVC writes the cache tothe 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.
7/26/2019 Volume Migration Using Svc 2.1 July2005
46/52
SVC VOLUME MIGRATION
Copyright IBM 2004 46
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.
7/26/2019 Volume Migration Using Svc 2.1 July2005
47/52
SVC VOLUME MIGRATION
Copyright IBM 2004 47
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 mapit 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.
7/26/2019 Volume Migration Using Svc 2.1 July2005
48/52
SVC VOLUME MIGRATION
Copyright IBM 2004 48
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 Mdiskcomes from the DS4300.
7/26/2019 Volume Migration Using Svc 2.1 July2005
49/52
SVC VOLUME MIGRATION
Copyright IBM 2004 49
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.
7/26/2019 Volume Migration Using Svc 2.1 July2005
50/52
SVC VOLUME MIGRATION
Copyright IBM 2004 50
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 weunattach 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):
7/26/2019 Volume Migration Using Svc 2.1 July2005
51/52
SVC VOLUME MIGRATION
Copyright IBM 2004 51
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 Mdiskscommand on the SVC Mdisks panel, so the fibre channelnetwork is rescanned
7) Issue a Refreshon the SVC Mdisks panel, so the console reflects theIMAGE_STR_TGT Managed Disk (LUN) is not allocated anymore to the SVC, as it isnow directly assigned by the FastT management tool, to the SAN340_1 Host.
7/26/2019 Volume Migration Using Svc 2.1 July2005
52/52
SVC VOLUME MIGRATION