Topic
IC4NOTICE: developerWorks Community will be offline May 29-30, 2015 while we upgrade to the latest version of IBM Connections. For more information, read our upgrade FAQ.
6 replies Latest Post - ‏2012-03-11T16:42:01Z by SystemAdmin
ERICCCCC
ERICCCCC
6 Posts
ACCEPTED ANSWER

Pinned topic V7000 migrate volume (N6040 DataOnTap OS Volume) to other Pool

‏2012-02-24T04:51:52Z |
Hello!

Currently, in V7000 we have a Pool (PoolA) with a Volume (PoolAVol1) assigned to N6040 for DataOnTap(8.0) system.

Now, we have a new Pool (PoolB) in V7000, using other disks, could we use “Migrate to Another Pool” real time migrate PoolAVol1 to PoolB with no down time? Is it a correct way to relocate DataOnTap system volume?

I tested, Migrate volume with Data is fine, but I am not sure if volume with OS.

thank you very much!
Updated on 2012-03-11T16:42:01Z at 2012-03-11T16:42:01Z by SystemAdmin
  • ERICCCCC
    ERICCCCC
    6 Posts
    ACCEPTED ANSWER

    Re: V7000 migrate volume (N6040 DataOnTap OS Volume) to other Pool

    ‏2012-02-28T06:39:14Z  in response to ERICCCCC
    Can anyone help here?
    My local support said they didn't try this action and can't answer me what will happen.. =__=" very bad feeling.
  • minhan
    minhan
    2 Posts
    ACCEPTED ANSWER

    Re: V7000 migrate volume (N6040 DataOnTap OS Volume) to other Pool

    ‏2012-02-29T03:59:58Z  in response to ERICCCCC
    I think you means using nSeries gateway to access V7000 volume. If this is the situation, it is not supported officially. But it maybe still work as you experienced.
  • ERICCCCC
    ERICCCCC
    6 Posts
    ACCEPTED ANSWER

    Re: V7000 migrate volume (N6040 DataOnTap OS Volume) to other Pool

    ‏2012-02-29T06:25:44Z  in response to ERICCCCC
    Hello~
    Yes we are using nSeries gateway connect V7000 and it was recommended by local IBM last year. We now want to move all DataOnTap OS+Data volumes from PoolA to PoolB. Tested migrated data volume was success. But we are not sure the OS volume and we have no way to test. That's why I want to get support from IBM but seem no people from my local support can answer till now. Maybe it is really not support so I need to find another way. thanks!
    • al_from_indiana
      al_from_indiana
      28 Posts
      ACCEPTED ANSWER

      Re: V7000 migrate volume (N6040 DataOnTap OS Volume) to other Pool

      ‏2012-02-29T15:04:31Z  in response to ERICCCCC
      1) Validate the current root volume (usually vol0) and the new root volume:
      vol status

      2) Ensure that the ndmpd daemon is turned on using the ndmpd on command on the filer.

      3) Copy the entire /etc directory from the current root volume to the new root volume:
      ndmpcopy /etc /vol/new_rootvol/etc

      4) Flag the new root volume as the root volume:
      vol options new_rootvol root

      5) If desired, rename the old and new root volume. The following command renames the volume :
      vol rename

      6) Verify that the shares and exports are updated accordingly, by running the following commands:
      cifs shares
      exportfs
      Reboot the filer
      Verify the new root volume settings:
      vol status
      • ERICCCCC
        ERICCCCC
        6 Posts
        ACCEPTED ANSWER

        Re: V7000 migrate volume (N6040 DataOnTap OS Volume) to other Pool

        ‏2012-03-01T01:32:03Z  in response to al_from_indiana
        thank you so much for your reply!!!
        I think these commands run in N6040, right? will try, thanks!!
        • SystemAdmin
          SystemAdmin
          4779 Posts
          ACCEPTED ANSWER

          Re: V7000 migrate volume (N6040 DataOnTap OS Volume) to other Pool

          ‏2012-03-11T16:42:01Z  in response to ERICCCCC
          Hi,

          Not really sure if I have catch your question correctly. I understand you have a StoragePool A and B; then you have a vdisk created on StoragePool A and now you want to move to StoragePool B ?

          The pre-requisite to migrate vdisk around StoragePool is the size of extent, they must match (exactly the same).

          I'd recommend to run in low I/O activity to avoid major issue; the migration supposed to be transparent.

          Thanks !