Seamless Veritas volume migration

Question

Hi all,
I appreciate if any of you can offer me some advice on the following :

I have some Veritas volumes that are currently residing on local disks and I would to migrate these volumes to SAN.
Since these volumes are oracle data volumes and its almost impossible to get a downtime on the database instances using these volumes, I'd like to find a way (if possible) to migrate these volumes seamlessly &nbsp;without any downtime/unmount/etc.

I'm not an expert with Storage foundation, but I did try to do the following :
1) Mirror the&nbsp; local disk containing the diskgroups&nbsp;with the volumes with a SAN disk (new location)
2) Once mirroring completes, remove the local disk and let the SAN disk remain

Using this way, I was able to do the migration seamlessly. Unfortunately I discovered that I would have to migrate all volumes that are contained within the diskgroup that was mirrored, since all the volumes were 'sharing' the local disk. This is quite logical, however I do not want to migrate ALL volumes (I would like volume A and B to&nbsp; migrate to SAN but volume C should stay on local disk).

Is there another way I could achieve this? My goal is to migrate volume A and B (residing on testdg diskgroup) to SAN, but not volume C (also on testdg diskgroup). And this migration must be seamless (no downtime or unmount of current filesystems).&nbsp; The server is Solaris 9 and using Storage Foundation 5.0

Thanks!
Posie

gaurav_s · Accepted Answer

Hello,

What I said looks feasible .... you already have a mirror on oradata12 volume .... where first plex (oradata9-01) resides with c1t2d0 &amp; second plex (oradata12-01) resides on c1t5d0 ...

So here would be the precise steps:
-- Make sure SAN disk is visible in&nbsp; VxVM, also it should have size atleast equivalent to your volume size
# vxdisk list

-- If SAN disk is not initialized with VxVM , initialize it...
# vxdisksetup -i &lt;SAN_disk&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (default format would be cdsdisk)

-- Add the SAN disk to diskgroup
# vxdg -g&nbsp; testdg adddisk&nbsp; testdg03=&lt;SAN_disk&gt;

-- Mirror the oradata12 volume
# vxassist -g testdg mirror oradata12 &lt;SAN_disk&gt;

-- check that sync in completed
# vxtask list

-- Verify from vxprint , you should see a new plex added to oradata12 volume...
# vxprint -qthg testdg oradata12

-- If above looks good, then go ahead &amp; detach old plex
# vxmend -g testdg off oradata9-01
# vxplex -g testdg dis oradata9-01

-- If you see vxprint command now, you should see plex oradata9-01 is disassociated... If looks OK, go &amp; delete the plex
# vxedit -g testdg -rf rm oradata9-1

-- Repeat the previous two steps of another plex oradata12-01

One more thing to notice, I see you have added a log plex, what was this log plex added for ? If it was DCO logs for snapshots, it would be advisable to move that also to SAN disk, also recommended to keep a mirror copy of log plex as well...

Hope this helps..

Gaurav

gaurav_s · Answer

Hello

If I understand this correctly, I think its possible ..... so for e.g you have a diskgroup called testdg which initially had 4 volumes for e.g&nbsp; vol A, B C &amp; D ... all the 4 lie on local disks...

Now you wanted to migrate 2 of volumes to SAN lets say A &amp; B ...

Follow the steps which you mentioned above, i.e&nbsp; mirror the A &amp; B volumes using SAN disks.... once sync is complete, remove the old plex from local disk...

now this leaves your diskgroup like A &amp; B volumes are on SAN. C &amp; D volumes on local disk ....&nbsp; Is that OK ?

Point here to note is, you are not mirroring disk, you have to mirror volumes .... you can do this by:
# vxassist -g &lt;diskgroup&gt; mirror &lt;vol&gt; &lt;san_disk&gt;

Check if sync in complete, using
# vxtask list

Once sync in complete, remove old plex (lying on local disk) from volume, to do this:

# vxmend -g &lt;diskgroup&gt; off &lt;plex-name&gt;&nbsp; --- offline plex from mirror
# vxplex -g &lt;diskgroup&gt; dis &lt;plex-name&gt;&nbsp;&nbsp; ---- Disassociate plex from volume
# vxedit -g &lt;diskgroup&gt; -rf rm &lt;plex-name&gt;&nbsp; --- delete the plex

One thing to note here would be, you can't use this diskgroup in Cluster, because if diskgroup wants to failover to other node, it won't succeed since volumes on local disk will fail to import on other node..

Gaurav

marianne · Answer

In addition to Gaurav's advice - please share diskgroup layout:
vxprint -g &lt;diskgroup&gt; -htr

Also see this TN: http://seer.entsupport.symantec.com/docs/316475.htm

posie80 · Answer

Hi Gaurav and Marianne,
Thank you for your advices! I will try Gaurav's suggestion and see whether thats possible in my case.

Here is the vxprint output, let me know your comments?
I would like to migrate only oradata12 volume and leave restore volume in its original place.

vxprint output :
-------------------

DG NAME&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NCONFIG&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NLOG&nbsp;&nbsp;&nbsp;&nbsp; MINORS&nbsp;&nbsp; GROUP-ID
ST NAME&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; STATE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; DM_CNT&nbsp;&nbsp; SPARE_CNT&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; APPVOL_CNT
DM NAME&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; DEVICE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; TYPE&nbsp;&nbsp;&nbsp;&nbsp; PRIVLEN&nbsp; PUBLEN&nbsp;&nbsp; STATE
RV NAME&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; RLINK_CNT&nbsp;&nbsp;&nbsp; KSTATE&nbsp;&nbsp; STATE&nbsp;&nbsp;&nbsp; PRIMARY&nbsp; DATAVOLS&nbsp; SRL
RL NAME&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; RVG&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; KSTATE&nbsp;&nbsp; STATE&nbsp;&nbsp;&nbsp; REM_HOST REM_DG&nbsp;&nbsp;&nbsp; REM_RLNK
CO NAME&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CACHEVOL&nbsp;&nbsp;&nbsp;&nbsp; KSTATE&nbsp;&nbsp; STATE
VT NAME&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; RVG&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; KSTATE&nbsp;&nbsp; STATE&nbsp;&nbsp;&nbsp; NVOLUME
V&nbsp; NAME&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; RVG/VSET/CO&nbsp; KSTATE&nbsp;&nbsp; STATE&nbsp;&nbsp;&nbsp; LENGTH&nbsp;&nbsp; READPOL&nbsp;&nbsp; PREFPLEX UTYPE
PL NAME&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; VOLUME&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; KSTATE&nbsp;&nbsp; STATE&nbsp;&nbsp;&nbsp; LENGTH&nbsp;&nbsp; LAYOUT&nbsp;&nbsp;&nbsp; NCOL/WID MODE
SD NAME&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PLEX&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; DISK&nbsp;&nbsp;&nbsp;&nbsp; DISKOFFS LENGTH&nbsp;&nbsp; [COL/]OFF DEVICE&nbsp;&nbsp; MODE
SV NAME&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PLEX&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; VOLNAME&nbsp; NVOLLAYR LENGTH&nbsp;&nbsp; [COL/]OFF AM/NM&nbsp;&nbsp;&nbsp; MODE
SC NAME&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PLEX&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CACHE&nbsp;&nbsp;&nbsp; DISKOFFS LENGTH&nbsp;&nbsp; [COL/]OFF DEVICE&nbsp;&nbsp; MODE
DC NAME&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PARENTVOL&nbsp;&nbsp;&nbsp; LOGVOL
SP NAME&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SNAPVOL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; DCO
EX NAME&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ASSOC&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; VC&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PERMS&nbsp;&nbsp;&nbsp; MODE&nbsp;&nbsp;&nbsp;&nbsp; STATE
SR NAME&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; KSTATE

dg&nbsp;testdg&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; default&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; default&nbsp; 22000&nbsp;&nbsp;&nbsp; 1124862954.47.server1

dm testdg01&nbsp;&nbsp;&nbsp;&nbsp; c1t2d0s2&nbsp;&nbsp;&nbsp;&nbsp; auto&nbsp;&nbsp;&nbsp;&nbsp; 2048&nbsp;&nbsp;&nbsp;&nbsp; 143347008 -
dm testdg02&nbsp;&nbsp;&nbsp;&nbsp; c1t5d0s2&nbsp;&nbsp;&nbsp;&nbsp; auto&nbsp;&nbsp;&nbsp;&nbsp; 2048&nbsp;&nbsp;&nbsp;&nbsp; 143347008 -

v&nbsp; oradata12&nbsp;&nbsp;&nbsp; -&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ENABLED&nbsp; ACTIVE&nbsp;&nbsp; 104857600 SELECT&nbsp;&nbsp; -&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; fsgen
pl oradata9-01&nbsp; oradata12&nbsp;&nbsp;&nbsp; ENABLED&nbsp; ACTIVE&nbsp;&nbsp; 104857600 CONCAT&nbsp;&nbsp; -&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; RW
sd testdg01-01&nbsp; oradata9-01&nbsp; testdg01 1056&nbsp;&nbsp;&nbsp;&nbsp; 104857600 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; c1t2d0&nbsp;&nbsp; ENA
pl oradata9-03&nbsp; oradata12&nbsp;&nbsp;&nbsp; ENABLED&nbsp; ACTIVE&nbsp;&nbsp; LOGONLY&nbsp; CONCAT&nbsp;&nbsp;&nbsp; -&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; RW
sd testdg01-02&nbsp; oradata9-03&nbsp; testdg01 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1056&nbsp;&nbsp;&nbsp;&nbsp; LOG&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; c1t2d0&nbsp;&nbsp; ENA
pl oradata12-01 oradata12&nbsp;&nbsp;&nbsp; ENABLED&nbsp; ACTIVE&nbsp;&nbsp; 104857600 CONCAT&nbsp;&nbsp; -&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; RW
sd testdg02-01&nbsp; oradata12-01 testdg02 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 104857600 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; c1t5d0&nbsp;&nbsp; ENA

v&nbsp; restore&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ENABLED&nbsp; ACTIVE&nbsp;&nbsp; 76976128 SELECT&nbsp;&nbsp;&nbsp; -&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; fsgen
pl restore-01&nbsp;&nbsp; restore&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ENABLED&nbsp; ACTIVE&nbsp;&nbsp; 76976128 CONCAT&nbsp;&nbsp;&nbsp; -&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; RW
sd testdg01-03&nbsp; restore-01&nbsp;&nbsp; testdg01 104858656 38488352 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; c1t2d0&nbsp;&nbsp; ENA
sd testdg02-02&nbsp; restore-01&nbsp;&nbsp; testdg02 104857600 38487776 38488352 c1t5d0&nbsp;&nbsp; ENA
&nbsp;

posie80 · Answer

Hi Gaurav,
Wow, thats very much for the detailed steps!!

I've simulated the same on a test server and confirmed that it was indeed feasible as you mentioned. Perfect!

The log plex was added previously by somebody else and I *think* it was DCO logs for snapshot (is there any way to make sure this is the case?). I will move this log plex also to SAN and create a mirror copy as you suggested.

Thanks again for your excellent guide,

- Posie

gaurav_s · Answer

Glad to have helped...

You can use following command to find the log type..

# vxprint -g testdg -mvphsr |grep -i log_type

Gaurav

Forum Discussion

Seamless Veritas volume migration

8 Replies

Related Content

Seamless migration to Microsoft Azure and Amazon Web Services with Veritas CloudMobility

Re: Re-provisioning EMC Clariion Storage to Pure Disk

Veritas Compliance Accelerator Configuration

Veritas BMR Virtual to Physical

Migrate from EMC SourceOne to Veritas EV

Recent Discussions

DataDomain To StoreOnce Migration

VCS ERROR V-16-1-10205 Group Mediation_NFS is faulted on system com1em03

vxprivutil

URGENT disk oublic region recover

super block corrupt