Topic
  • 6 replies
  • Latest Post - ‏2013-08-21T13:22:47Z by robinsguk
robinsguk
robinsguk
31 Posts

Pinned topic SVC migratetoimage command

‏2013-08-21T09:27:49Z |

Hello,

I'm migrating LUNs from an SVC (v6.2) to V7000 (V6.4).

According to the guidelines provided by IBM I need to run a migratetoimage command on the SVC.

When I run this command does the source disk need to be unmapped from the host or can I run the command whilst the host is updating the source disk?

Here's the process IBM have provided me with:

  • SVC                  Create the V7000 as a host
  • V7000               Create the required storage pool(s) of mdisks
  • V7000               Create the SVC as a host
  • V7000               Create replica sized volumes matching the vdisks currently presented via the SVC
  • V7000               Present the vdisks to the SVC
  • SVC                 Export vdisks to Image Mode for the volumes created on the V7000. Use the SVC CLI command "migratetoimage".
  • Host                 Upgrade SDDDSM driver
  • Host                 Shutdown
  • SVC                 Remove vdisk mapping to host
  • V7000               Remove V7000 VDisk mapping to SVC
  • V7000               Map V7000 volume to same LUN number on host
  • Host                 Start up host
                            Amend SAN boot parameters if necessary
                            Confirm via datapath query's that the relevant drives and paths are connected to the host via the V7000 

 

 

 

 

Thanks

Glenn

  • chriscanto
    chriscanto
    291 Posts
    ACCEPTED ANSWER

    Re: SVC migratetoimage command

    ‏2013-08-21T13:12:29Z  
    • robinsguk
    • ‏2013-08-21T12:34:53Z

    But surely the SVC needs to "see" the V7000 and the vdisks presented by the V7000 so that I can run the migratetoimage command from the source vdisk on the SVC to the image mode disk presented by the V7000???

     

    Glenn

    Yep, but keep in mind that SVC only needs to "see" the V7000 as an external storage controller -- something that presents LUs up to SVC to use as mdisks.

    When you prod SVC to discover new devices (detectmdisk) then SVC will login to all SCSI targets visible on the SAN and query for LUs.  The things controlling which LUs/mdisks are discovered are the vdisk-host mapping on the V7000 and the fibre channel zoning.

    I don't see how having none/some/all of the V7000 ports defined as a host object on SVC would affect this;  the process doesn't map a vdisk from SVC to the V7000 so I think that host definition is unnecessary.

  • chriscanto
    chriscanto
    291 Posts

    Re: SVC migratetoimage command

    ‏2013-08-21T12:01:51Z  

    I've not seen that procedure before...  do you know if it has been tested with those particular code levels on those types of system?

    The first step confuses me: "SVC - Create the V7000 as a host"   Why?  None of the following steps present a volume from the SVC to the V7000.

    If that sort of approach does work, it appears to be missing a step after you have run the 'migratetoimage' action (and before you remove the V7000 vdisk mapping to SVC) where you would delete the image mode vdisk on the SVC.  But maybe you omitted that in your post for simplicity?

    Do the instructions say if it matters what system layer the V7000 is configured in?

    Could you say a bit more about where the instructions came from?

     

    To answer your specific question about the migratetoimage command: that can run concurrent with host I/O, there is no need to stop or unmap the host while the volume is being migrated.

  • robinsguk
    robinsguk
    31 Posts

    Re: SVC migratetoimage command

    ‏2013-08-21T12:17:06Z  

    I've not seen that procedure before...  do you know if it has been tested with those particular code levels on those types of system?

    The first step confuses me: "SVC - Create the V7000 as a host"   Why?  None of the following steps present a volume from the SVC to the V7000.

    If that sort of approach does work, it appears to be missing a step after you have run the 'migratetoimage' action (and before you remove the V7000 vdisk mapping to SVC) where you would delete the image mode vdisk on the SVC.  But maybe you omitted that in your post for simplicity?

    Do the instructions say if it matters what system layer the V7000 is configured in?

    Could you say a bit more about where the instructions came from?

     

    To answer your specific question about the migratetoimage command: that can run concurrent with host I/O, there is no need to stop or unmap the host while the volume is being migrated.

    Hello,

    Thanks for the info on migratetoimage.

    I'm migrating LUNs from SVC to V7000. I got the procedure from Techline back in January with a recommendation that we do a PoC first. This is what I'm setting up now.

    Looking at the procedure again I think step 3 is incorrect. There's no need to create the SVC as a host on the V7000.

    I also received this which was from a specialist in Mainz:

    "I see the point: Because there are two virtualization layers in the game, the question is at which layer we talk about image mode volumes. 

    It's the SVC layer. The V7000 volumes must be considered by the SVC as MDisks that contain image mode VDisks. After creating the new V7000 volumes and presenting them to the 
     SVC, the customer starts a migration from managed mode VDisks (= the current SVC volumes) to image mode (= the new V7000 volumes). I don't know yet if the GUI can do that, so 
    I would do it with the CLI command "migratetoimage" at the SVC layer. The command migrates the data from the existing SVC VDisk by consolidating its extents onto the new V7000 
    volume as SVC target MDisk. After migration is complete, the V7000 volume is classified by SVC as an image mode VDisk. Removing then the SVC from the I/O path gives a V7000 
    volume that is an exact image of the former SVC VDisk, but you don't need the SVC anymore. 

    Because the V7000 volume is image mode only from the SVC's point of view, but not for the V7000, there are no restrictions regarding the V7000-internal configuration of this volume. 
    The customer can use any V7000-internal setup of arrays and pools --- the SVC does not see that. The SVC sees only a LUN and gets the task "please migrate your SVC VDisk to 
    this new LUN into image mode". 

     

    Glenn

    Updated on 2013-08-21T12:27:05Z at 2013-08-21T12:27:05Z by robinsguk
  • chriscanto
    chriscanto
    291 Posts

    Re: SVC migratetoimage command

    ‏2013-08-21T12:30:47Z  
    • robinsguk
    • ‏2013-08-21T12:17:06Z

    Hello,

    Thanks for the info on migratetoimage.

    I'm migrating LUNs from SVC to V7000. I got the procedure from Techline back in January with a recommendation that we do a PoC first. This is what I'm setting up now.

    Looking at the procedure again I think step 3 is incorrect. There's no need to create the SVC as a host on the V7000.

    I also received this which was from a specialist in Mainz:

    "I see the point: Because there are two virtualization layers in the game, the question is at which layer we talk about image mode volumes. 

    It's the SVC layer. The V7000 volumes must be considered by the SVC as MDisks that contain image mode VDisks. After creating the new V7000 volumes and presenting them to the 
     SVC, the customer starts a migration from managed mode VDisks (= the current SVC volumes) to image mode (= the new V7000 volumes). I don't know yet if the GUI can do that, so 
    I would do it with the CLI command "migratetoimage" at the SVC layer. The command migrates the data from the existing SVC VDisk by consolidating its extents onto the new V7000 
    volume as SVC target MDisk. After migration is complete, the V7000 volume is classified by SVC as an image mode VDisk. Removing then the SVC from the I/O path gives a V7000 
    volume that is an exact image of the former SVC VDisk, but you don't need the SVC anymore. 

    Because the V7000 volume is image mode only from the SVC's point of view, but not for the V7000, there are no restrictions regarding the V7000-internal configuration of this volume. 
    The customer can use any V7000-internal setup of arrays and pools --- the SVC does not see that. The SVC sees only a LUN and gets the task "please migrate your SVC VDisk to 
    this new LUN into image mode". 

     

    Glenn

    The comments from the specialist in Mainz make sense.

    However, they don't address why you would need to take the action of creating a host object on the SVC for the V7000 ports.  I would think that doing so is harmless, but it just rings alarm bells in my head when I see a step of a procedure that doesn't appear to fit as it makes me wonder what I'm missing, or whether the author was misunderstanding something...

    If in doubt then I guess you could do a dry run through the procedure using a newly created dummy volume, or perhaps even a copy of an existing volume (using FlashCopy or split vdisk mirror) to check the process works as expected before doing it for real with production volumes.

  • robinsguk
    robinsguk
    31 Posts

    Re: SVC migratetoimage command

    ‏2013-08-21T12:34:53Z  

    The comments from the specialist in Mainz make sense.

    However, they don't address why you would need to take the action of creating a host object on the SVC for the V7000 ports.  I would think that doing so is harmless, but it just rings alarm bells in my head when I see a step of a procedure that doesn't appear to fit as it makes me wonder what I'm missing, or whether the author was misunderstanding something...

    If in doubt then I guess you could do a dry run through the procedure using a newly created dummy volume, or perhaps even a copy of an existing volume (using FlashCopy or split vdisk mirror) to check the process works as expected before doing it for real with production volumes.

    But surely the SVC needs to "see" the V7000 and the vdisks presented by the V7000 so that I can run the migratetoimage command from the source vdisk on the SVC to the image mode disk presented by the V7000???

     

    Glenn

  • chriscanto
    chriscanto
    291 Posts

    Re: SVC migratetoimage command

    ‏2013-08-21T13:12:29Z  
    • robinsguk
    • ‏2013-08-21T12:34:53Z

    But surely the SVC needs to "see" the V7000 and the vdisks presented by the V7000 so that I can run the migratetoimage command from the source vdisk on the SVC to the image mode disk presented by the V7000???

     

    Glenn

    Yep, but keep in mind that SVC only needs to "see" the V7000 as an external storage controller -- something that presents LUs up to SVC to use as mdisks.

    When you prod SVC to discover new devices (detectmdisk) then SVC will login to all SCSI targets visible on the SAN and query for LUs.  The things controlling which LUs/mdisks are discovered are the vdisk-host mapping on the V7000 and the fibre channel zoning.

    I don't see how having none/some/all of the V7000 ports defined as a host object on SVC would affect this;  the process doesn't map a vdisk from SVC to the V7000 so I think that host definition is unnecessary.

  • robinsguk
    robinsguk
    31 Posts

    Re: SVC migratetoimage command

    ‏2013-08-21T13:22:47Z  

    Yep, but keep in mind that SVC only needs to "see" the V7000 as an external storage controller -- something that presents LUs up to SVC to use as mdisks.

    When you prod SVC to discover new devices (detectmdisk) then SVC will login to all SCSI targets visible on the SAN and query for LUs.  The things controlling which LUs/mdisks are discovered are the vdisk-host mapping on the V7000 and the fibre channel zoning.

    I don't see how having none/some/all of the V7000 ports defined as a host object on SVC would affect this;  the process doesn't map a vdisk from SVC to the V7000 so I think that host definition is unnecessary.

    Yup, that all makes sense.

    I'll drop the "create host" steps.

     

    Thanks a lot.

     

    Glenn