Sponsored Content
Operating Systems AIX Migrating LUNs to new storage array Post 303038873 by rbatte1 on Monday 16th of September 2019 07:57:15 AM
Old 09-16-2019
Just a thought (and trying to avoid downtime) can you not add the new LUNs into the VG and then migrate them with the server still live? I've done this very successfully and prevented needless hours of downtime (three weekends-worth)

The team I was helping to do this were very nervous and wanted the belt & braces approach so we:-
  1. Added the new LUNs to the VG
  2. Mirrored the LVs (no sync) and confirmed the layout was correct (not spread to old disks etc.)
  3. Ran a syncvg and left if. Any problems, we would drop the new leaving the old intact.
When it had completed, we:-
  1. Removed the mirror from the old/original disk
  2. Removed the original disks from the volume group
Like I say, this was done with the server online and processing. The volume manager deals with this very well, and whilst it takes a long time to synchronise, it's probably no worse than waiting for something else to migrate the data. It is also reversible up to the point you commit by removing the mirror copies on the old disks.

Why do you not want to have both SANs connected at the same time? The usual arrangement is to have the SAN connections passed through a switch rather than direct to the AIX host. Is there a reason that you could not just add the new SAN connections to these switches?



I hope this gives you an alternative,
Robin

Last edited by rbatte1; 09-16-2019 at 09:03 AM..
 

6 More Discussions You Might Find Interesting

1. Filesystems, Disks and Memory

Storage array question

We just purchased a MOD30 disk array strage system. We have 15 drives and 2 hot spares. We're running a database app with 8 data sets. I'm trying to get the best i/o speed out of my disk configuration. Right now I have 3 raid5 arrays setup. This seems to offer the same performance as having the... (1 Reply)
Discussion started by: ncmurf00
1 Replies

2. Filesystems, Disks and Memory

how can I monitoring the LUNs in HP storage

Hi, How can i monitoring the LUN in HP Storage with korn shells? I would like to have a shell can monitoring the LUN, VGs, lvols and raw devices. Jesus (3 Replies)
Discussion started by: jgutierrez29
3 Replies

3. Solaris

storage array simulator

hi i haven't much experience in solaris. I would like to know about storage. how to configure,how it is working etc....can i get any simulator for doing these work? plaese send me the link . please help me advance thanks to all (2 Replies)
Discussion started by: sijocg
2 Replies

4. HP-UX

HP Storage Array

hi I need to check status and configure HP Storage Array device. HP Storageworks P2000 Please suggest (0 Replies)
Discussion started by: anand87
0 Replies

5. UNIX for Advanced & Expert Users

VxVM breaking mirror for migrating storage

We are in the process of migrating storage from one array to another. I know the commands I would use in LVM but I am not very familiar with VxVM. The goal is to attach the new LUNs from the new array and add them to the disk group. Then mirror the data online to these new LUNs using VxVM... (4 Replies)
Discussion started by: keelba
4 Replies

6. Red Hat

Migrating an Oracle database storage - REDHAT4

e have a RHEL4 server with an Oracle 10 ( RAC ) are migrating storage bank records. The copy is made by the storage they make a copy of the level of disk all blocks are copied and the file permissions. Problems we had Initially the Cluster service was not rising due to absence of OCR disks... (0 Replies)
Discussion started by: fausto.ncc1701
0 Replies
vgmove(1M)																vgmove(1M)

NAME
vgmove - move data from an old set of disks in a volume group to a new set of disks SYNOPSIS
autobackup] diskmapfile vg_name autobackup] diskfile diskmapfile vg_name DESCRIPTION
The command migrates data from the existing set of disks in a volume group to a new set of disks. After the command completes successfully, the new set of disks will belong to the same volume group. The command is intended to migrate data on a volume group from old storage to new storage. The diskmapfile specifies the list of source disks to move data from, and the list of destination disks to move data to. The user may choose to list only a subset of the existing physical volumes in the volume group that need to be migrated to a new set of disks. The format of the diskmapfile file is shown below: source_pv_1 destination_pv_1_1 destination_pv_1_2 .... source_pv_2 destination_pv_2_1 destination_pv_2_2 .... .... source_pv_n destination_pv_n_1 destination_pv_n_2 .... If a destination disk is not already part of the volume group, it will be added using see vgextend(1M). Upon successful completion of the source disk will be automatically removed from the volume group using see vgreduce(1M). After successful migration, the destination disks are added to the LVM configuration files; namely, or The source disks along with their alternate links are removed from the LVM configuration files. A sample diskmapfile is shown below: /dev/disk/disk1 /dev/disk/disk51 /dev/disk/disk52 /dev/disk/disk2 /dev/disk/disk51 /dev/disk/disk3 /dev/disk/disk53 The diskmapfile can be manually created, or it can be automatically generated using the diskfile and diskmapfile options. The argument diskfile contains a list of destination disks, one per line such as the sample file below: /dev/disk/disk51 /dev/disk/disk52 /dev/disk/disk53 When the option is given, reads a list of destination disks from diskfile, generates the source to destination mapping, and saves it to diskmapfile. The volume group must be activated before running the command. If the command is interrupted before it completes, the volume group is in the same state it was at the beginning of the command. The migration can be continued by running the command with the same options and disk mapping file. Options and Arguments The command recognizes the following options and arguments: vg_name The path name of the volume group. Set automatic backup for this invocation of autobackup can have one of the following values: Automatically back up configuration changes made to the volume group. This is the default. After this command executes, the command is executed for the volume group; see vgcfgbackup(1M). Do not back up configuration changes this time. Specify the name of the file containing the source to destination disk mapping. If the option is also given, will generate the disk mapping and save it to this filename. (Note that if the diskmapfile already exists, the file will be overwritten). Otherwise, will perform the data migration using this diskmapfile. Specify the name of the file containing the list of destination disks. This option is used with the option to generate the diskmapfile. When the option is used, no volume group data is moved. Preview the actions to be taken but do not move any volume group data. Shared Volume Group Considerations For volume group version 1.0 and 2.0, cannot be used if the volume group is activated in shared mode. For volume groups version 2.1 (or higher), can be performed when activated in either shared, exclusive, or standalone mode. Note that the daemon must be running on all the nodes sharing a volume group activated in shared mode. See lvmpud(1M). When a node wants to share the volume group, the user must first execute a if physical volumes were moved in or out of the volume group at the time the volume group was not activated on that node. LVM shared mode is currently only available in Serviceguard clusters. EXTERNAL INFLUENCES
Environment Variables determines the language in which messages are displayed. If is not specified or is null, it defaults to "C" (see lang(5)). If any internationalization variable contains an invalid setting, all internationalization variables default to "C" (see environ(5)). EXAMPLES
Move data in volume group from to After the migration, remove from the volume group: Generate a source to destination disk map file for where the destination disks are and SEE ALSO
lvmpud(1M), pvmove(1M), vgcfgbackup(1M), vgcfgrestore(1M), vgextend(1M), vgreduce(1M), intro(7), lvm(7). vgmove(1M)
All times are GMT -4. The time now is 03:38 AM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy