storage migration.

Latest response

Dear Sir,

 

We are using RHEV 2.2 in our environment and we are planning to do a storage migration. We have already presented 28 LUN’s from our enterprise storage EMC VMAX and we are using those LUN’s in 4 storage domains.

 

We have another three storage domains with is attached to our midrange storage IBM DS 4800. We are doing an upgrade on our enterprise storage EMC VMAX and we are planning to remove all the LUN’s which we have presented to the RHEV and going to present new LUN’s.

 

We are planning to copy data to the new devises by using the storage itself. We are cloning all the LUN’s by using the emc storage. After all the data sync, we are planning to remove the old devises and present new LUN’s.

 

The OLD LUN ID will get change and please let us know how to do this task in RHEV level.

 

Best Regards,

shantha

SP
Log in to join the conversation

Responses

Sadique Puthen's picture Red Hat Guru 4649 points
6 April 2012 5:10 AM

The recommended method is to shut down guests one by one and "Move" it to a different storage domain.

 

All the current images of guests are represented in db as having the storage_id pointing to the old sd. If you clone from EMC side and the new sd is getting a new storage_id, I don't know how this change will happen in db.

SP Active Contributor 192 points
6 April 2012 10:15 AM

Yes, we have use that method when we were doing the first migration from IBM DS4800 storage to EMC VMAX storage.

 

But now you are talking about around 90 VM guests and & TB of storage. We have to do this migration twise and i don't think it is a paraticle thing.We might have to get downtime for each server and move them through host side. This will take weeks.

 

Why can we update the new LUN ID's in the RHEV-M db?

 

Since we are having same data i don't think we have to create new sd. can't we attach same cloned device to the dame sd?

 

In the RHEV-M db we found a table reralted to LUN ID's and volume group id's. Can't we update that table with new device ID's?

 

Best Regards,

shantha

Sadique Puthen's picture Red Hat Guru 4649 points
6 April 2012 10:29 AM

Reference in the database to luns is not the only problem.

 

We have lvm metadata which points old luns as the device for the PV. Altering this may be very difficult and not supported for production RHEV environment.

DY Guru 5340 points
6 April 2012 10:33 AM

Hi Shantha,

 

What you are saying definitely makes sense, and can be done, however, we do not support editing the database, and the procedure has never been tested.

In order to stay within support boundaries, you will either need to follow the plan Sadique outlined, or open a support case, and request assistance with moving the VMs using the SAN based LUN cloning. The idea is to be sure that the move is supervised, and well tested - this is not only a matter of changing a LUN ID - the LUNs have to be identical at the block level, the amount of LUNs under each SD should also be the same. The only difference we can tolerate in this case is the WWIDs of the LUNs in use, but nothing else, and even then, we need to walk you through this change, and not just tell you "alter table xyz and you're ok".

 

What I described, derives mainly from the limitations on the storage format in RHEV 2 (which has to keep the list and extents of every LUN in use), in RHEV3, the storage format is different, and it will allow for more flexibility, so if you're considering an upgrade, this is definitely a factor. 

 

There is another way, which wasn't mentioned - using an export domain. This is slower than simply moving VMs, but allows for more flexibility, in terms of where you import the VMs to afterwards.

 

In any case, this is a complex topic, which will require planning ahead and very precise execution, so please open a support case for this.

 

 

Thanks,

Dan

SP Active Contributor 192 points
6 April 2012 2:05 PM

Thank you for the reply Dan.

 

Yes, we have already opened a case regarding this. But still we didn't get an answer for the above mentioned method.

 

We have already done 3 RHEL migrations. Some oracle databases by using the SAN based clone. It was successful. Those server are on LVM based file systems.

 

SAN based clone will definitely create identical blocks and of course amount of LUNs under each SD will be  the same.

 

We do understand the complexity of this method and we do have a test environment for RHEV. We also can test this method.

 

We were planning to do the RHEV 3 upgrade and we have already tested it. Unfortunately to do the storage pool upgrade there isn't any method than export all the domain’s, erase the current DC and recreate it and import than exported storage domain.

 

We cannot afford that down time. We are a telco and some of our critical systems are running on this. (We can accommodate the storage now.)

 

I have opened a ticket regarding this upgrade also. But the tool that they can do this task is still not published.

But if it is going to help us on this storage migration, as can ask RedHat to provide us that tool.

 

If we use export domain, can we turn on the exported VM after exporting?

Anyway will also take more time and will not work on this situation.

 

Thanks

shantha

 

 

Close

Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.