Start a Conversation

Unsolved

This post is more than 5 years old

1013

May 2nd, 2013 09:00

Copy a LUN from 1 FASTVP Pool to another Pool on the same 5300 array?

I've got a LUN that houses many gigs of ISO type data FC connected to a ESX 4.1 cluster. Since I can't use svmotion to move the data, is there any way on the array to copy the LUN to the other pool? I'd rather not go through the long process of downloading all the data to a client then up loading to a new LUN..

Thanks

Ron

2.1K Posts

May 2nd, 2013 10:00

Have you tried using the Virtual LUN migration? You should be able to create a LUN in the other pool that is the same size and configuration and just let the array do the work for you non-disruptively. Your host doesn't have to come down and you don't need to copy any data or change any Storage Groups or anything.

2.1K Posts

May 2nd, 2013 11:00

No need to reregister anything. The array does all the work and when you are done the host thinks the new LUN is the old LUN. The host never knows anything changed.

23 Posts

May 2nd, 2013 11:00

Allen,

Thanks for your reply. I was hoping SAN copy (aka virtual storage migration) for block was the answer but was assuming it was only for migrating across arrays.. looks like you can use it internally too. I'll give it a shot.

I imagine the only thing I'd need to do is re-register all the templates from the new LUN.

2.1K Posts

May 2nd, 2013 11:00

If you have never done it before, you can try it out by provisioning a small LUN to the ESX host and putting some data on it then doing the LUN migration. You will see that you don't need to do anything beyond building the target LUN and starting the migration. After that you are done your work and the array handles the rest. It even destroys the old LUNwhen it is done migrating (which it kind of has to anyway since it assigns the identity of the old LUN to the new one as part of the process).

2.1K Posts

May 2nd, 2013 11:00

And what if I told you you could use it for LUNs hosting datastores with live VMs while they are up and running? That sounds even cooler, eh?

Sorry, but I do love this peice of tech in the VNX. When you need it, there is nothing else quite like it to do the job.

As for the requirements of the target LUN, you are correct in that it doesn't matter what you call it.. the full identity gets transferred in the process. I can't remember if the target LUN can be larger off the top of my head, but I'll bet you Rainer knows without looking.

23 Posts

May 2nd, 2013 11:00

Sounding cooler all the time. So regardless of what name and LUN ID you use on the destination (as long as the destination is equal or larger in size than the source) that info gets wiped and replaced with the source LUN name and ID? I'm assuming this will work with ESX 4.1 clusters.

I assume I could use it for VM's as well as long as they are shut down?

I'll try a test LUN with junk data on it since this is production stuff.

Appreciate the responses guys.

8.6K Posts

May 2nd, 2013 11:00

LUN migration is a lot better for this since its transparent – no need to change anything

8.6K Posts

May 2nd, 2013 11:00

No need to shutdown the VM – you can do it all online

Its like establishing a mirror and when the mirror is in sync removing the old LUN

Just try it

23 Posts

May 2nd, 2013 11:00

So happy I posted this question.. I was dreading a long drawn out svmotion of 20T of VM's. This must be a lot faster than that process!

1 Rookie

 • 

20.4K Posts

May 2nd, 2013 12:00

new LUN will assume old LUN attributes, (LUN #, name ..etc). If you were migrating traditional flare LUNs it would it keep the attribute of what raid configuration it was. Some platforms (AIX) are very sensitive to those fields so in order not to break LVM on AIX,  LUN being migrated from raid-5 to raid 1/0 would still be reported to the host as raid-5. You are using pools so there nothing to worry about ..just some trivia for ya

2.1K Posts

May 2nd, 2013 12:00

It's always worth asking :-) Doing it this way it doesn't matter how long it takes because it's all online.

4.5K Posts

May 2nd, 2013 13:00

One thing to keep in mind is the rate that you set for the Migration - you have a couple of choices - low, med, high, asap - try it at low first and if no impact, up the speed to med and see if you have any impact. ASAP will impact performance, but finish a lot sooner.

Also, when you create the new LUN in the other Pool make sure that when you create it you pick the same SP owner as the source LUN (check the source LUN Properties and see if the Default SP Owner matches the Allocated SP Owner). This ensure that all the hosts will see the new LUN on the same SP and the background copy will take place on the same SP. In Pools you must be careful not to change the Default SP Owner once the Pool LUN is created (it has performance implications).

glen

1 Rookie

 • 

20.4K Posts

May 2nd, 2013 15:00

you can crank it up on the fly

23 Posts

May 2nd, 2013 15:00

I'm doing a 100G LUN with a #2 throttle and it is slow as snot.. svmotion would be 10x faster. Guess I need to monkey with throttle settings.

23 Posts

May 2nd, 2013 16:00

Yeah I'm up to 6 and it is moving a bit better. I'm dropping a nar file too to see how SPA is doing during this.

No Events found!

Top