RHEV - Live Migration between arrays (to evacuate an array)
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
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
Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.
