RHEV - Live Migration between arrays (to evacuate an array)

Latest response

Live Migration between arrays (to evacuate an array)

Our VMs (and VDs) currently reside on an Enterprise Array (BIGDISK01) and need to evacuate it.
My Data Center was setup as FC and BIGDISK01 is currently the “master”

My plan is to add a second domain (attached to the new array – NEWDISK02) and live migrate all the VMs Virtual Disks over to the new array.
After all the migrations are complete, I want to remove the original domain (BIGDISK01).

Do I -ABSOLUTELY- need to add a second domain to be able to migrate the Virtual Disks?
Is there a way to remove the (master) designation from the first domain, once the VDs have been migrated?

Responses

I have discovered that if I put the original domain in maintenance, RHEV would assign the (master) to the other/new domain. I would still love to hear opinions on whether I need to create separate domains for this task.

Some additional things I noticed:
- the migration auto-generates a snapshot. I believe you have to take down the VM to "collapse" all the snapshots :-(
- All the heavy-lifting of I/O seems to take place on the SPM, regardless of which hypervisor the VM is currently running on. I don't know why this surprises me, but it does.

Yes you absolutely need to add a second domain. Once you add it and move all the VMs over to that disk. You can detach/deactivate the old master (BIGDISK01). At which point the second domain (NEWDISK02) will be promoted to new master.

James - I had to carry out the very same process that you describe last year. Movign from one SAN FC based solution to another.

Yes - you will need to create a new storage domain using your new array.

I would advise against using the storage live-migration method of moving between the SD's, however.
Storage live-migration is carried out at a vDisk level, not VM. This can be very time consuming when migrating VMs with multiple disks.
Migration of disks can only be carried out in a serial fashion (per VM)
Removal/merge of the subsequent auto-generated snapshots can only be carried out with the VM offline (powered down) and can take an extremly long time and can affect storage subsystem performance.
I'm told that if you have not selected "Wipe on delete" on the underlying disk, the merged snapshot LV metadata will remain on your storage domain. This metadata can reappear on any new VM disks which is a huge security risk.
Worst still, we encountered a bug whereby it rendered the VM unable to locate its boot device upon the removal/merge of the auto-generated snapshots.

Cold (non live) storage migration should be considered.
Alternatively, you could always add new disks to your VM from your new SD and use pvmove natively to migrate LV from old to new and then remove old, use dd for /boot. You might have to check with GSS that this is a supported/sane method though.

Oh wow - a year later and a new RHEV version and now I'm in the same boat. It's my own stuff and my old and new storage arrays are, well, on a budget. I just live storage migrated the VM holding my website today and noticed it left that snapshot lying around. I want the snapshot gone and want everything nice and clean in the new storage. I see some clown from Russia is trying to penetrate my website right now anyway, so now might be a good time to power that VM off and see about merging back that snapshot.

And I guess I'll just shut down my other VMs and cold-migrate them later.

- Greg Scott

Wasn't so bad. I shut down my website VM, deleted the snapshot, and booted it right back up. It's a 50 GB virtual hard drive, populated with about 3 GB of data. But I fully provisioned it so it consumes all 50 GB. Next time I'll go a little smaller. Anyway, it took about 20 minutes to collapse the snapshot. But earlier today, it took around 9 minutes to copy other 50 GB disk images, including this one that I live migrated. So instead of shutting down for 10 minutes and getting the whole thing over with, I live storage migrated and shut down later for 20 minutes tonight. Lesson - there ain't no free lunch.

- Greg Scott

Close

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