Can Open Replicator be used to migrate Solaris 5.10 with SVM?

SPARC or x86 ?

OR will migrate data regardless of the operating system. The real question should be something like whether or not you can re-attach migrated LUNs. And the answer to that is "Uhm, I don't know".

But with OR you can migrate anything, since OR only looks at the blocks on the symdevs, not on the filesystems.




Ah... I now see I missed some crucial words.... the data is coming from a USP. I'd ask EMC about this or consult the elab navigator. I think you should ask EMC, since the OR needs to be installed by EMC anyway, so they are involved anyway, right ?

Message was edited by:
RRR

Yes OR can be used to migrate data from USP to DMX3 it is supported by EMC(elab navigator) and OR license already existed has already been used to migrate few Wintel , AIX, HPUX and Solaris with VXVM as well without any issues.

I am just curious to know about Solaris using Solaris Volume Manager

Hi Dynamox,

It is SunOS Generic_125100-10 sun4u sparc SUNW,Sun-Fire.

Thx

SPARC

Message was edited by:
SPC

ok, check with system admin if they are using disk sets ..you can import disk sets after migration. Take a look svm guide

http://docs.sun.com/app/docs/doc/816-4520

disk sets are not being used.

Will this procedure work even if the luns sizes of Hitachi and DMX are different? COuld you please let me know reg this..

Thanks stcba

Yes, I would also like to know if this will work when the target lun sizes are larger.

Thanks!

Yes, this procedure will work even if the target luns are larger. Note that the add'l capacity will NOT be accessible by Solaris Volume Manager upon completion of the Open Rep session.

In order to access the add'l capacity, you will need to take the following steps in an outage.

1) use "powerformat" to re-label the luns so that the SunOS recognizes the larger size. Just as an experiment, look at the output of "format" immediately after the Open Rep session is completed and you'll see that SunOS thinks the target lun is the same size as the smaller source, even though in reality, the target is larger. This is because Open Rep copies EVERY TRACK, including the disk label, from the source. "powerformat" updates the label to reflect reality.

2) The tricker step is to get SVM to recognize the add'l space after "powerformat" is complete. This takes a combination of metaclear and metainit.

Note that Step 2 bears quite a bit of risk. I've had mixed success with the Step 2 in our lab. If risk mitigation is an objective (and of course it is, since the application is clustered), then I recommend creating target luns that are equal to or slightly larger than the source.

Thanks stcba.

I am currently doing a project where we are replacing an HDS with a V-Max. There are quite a few Solaris servers using SVM.

My question is on the step where we use metaclear -p d# to delete all of the soft partitions and then metaclear d# to delete the metadevice.

The question is, is this step necessary? Will the metaclear remove the specified d# from the md.tab file? I guess I am unsure as to what this will do.

This is the procedure I have, and please add any comments if you have them.

//Update md.tab
1. metastat -p > md.tab
cp -p /etc/lvm/md.tab /etc/lvm/md.tab.new

//Verify State Replica Databases are on Local Disk
2. metadb -i

3. Unmount file systems

4. Comment out file systems in vfstab using HDS luns.

5. Reboot and come up with V-Max luns

6. Edit md.tab.new with emcpower devices replacing HDS luns

7. Update Solaris label with powerformat

8. Import SVM devices.
metainit -n -a
metainit -a

9. Verify metadevices and soft partitions
metastat -p
metastat | more

10. mount filesystems

11. Uncomment vfstab

Message was edited by:
spwvol1978

spwvol1978,
The procedure you wrote looks sound but I'd investigate a couple of things first. Without the metaclear, I'm not sure that SVM will allow you to do the metainit in step 8. If this works for you, please post!

Secondly, you may want to move the powerformat in step 7 to the end, after you've successfully migrated the data, or maybe not use it at all. We ran into an issue using it when trying to get SVM to metainit a lun after powerformat was run. I didn't commit a ton of time to investigate it but I think it is caused by how SVM defines its soft partitions. It works like a casette tape. You remember those, don't you? It basically says start at a certain sector number and go forward for so many sectors and this becomes your size. Well imagine if you started out with a 10GB lun and 2 soft partitions, each partition is 5 GB. When you used up that 10GB and had to grow, you added another 10GB. So the first soft partition has been told to start at 0 and go forward 5GB. The 2nd partition was told start at 5GB and go to 10GB. After adding the 2nd 10GB lun and expanding the first partition, then the first soft partition definition is something like "start at 0 and go 5GB, then start at 10GB and go another 5GB". Now, introduce the powerformat and LUN expansion in the middle of that. What I think is, the specifications given to the soft partitions are no longer valid. If the first partition follows its directions of starting at 0 and using 5GB but then starting at 10GB and using 5 more, then it will not find it's data when it gets to the 10GB milepost because that 10GB milepost is no longer in the same place as before. Milepost 10GB may be somewhere in the whitespace of the first LUN, which is now larger. In any event, that's how I reconcile the lun expansion problem. For those soft partitions that never grew to another lun, we tested out powerformat and it worked fine. But for those that were a little more complicated, the model breaks down. Hope this helps.

Thanks stcba. The powerformat will only be used to update the solaris label, and not to recognize the extra space.

Thanks!