Announcement Banner
UNSOLVED

hanacd

updated

15 years ago

H

hanacd

34 Posts

0

2738

January 26th, 2012 09:00

Experience and considerations when migrating VMs across storage?

We are looking at some options how to migrate existing VMFS / VMs from one storage to a virtualized storage platform (what a surprise: VPLEX is in the game). As we believe the task is a pretty generic one and we couldn't find any specfic experience here on "Everything VMware At EMC",

I would like to share some thoughts around that and ask for your comments and experience.

Peter Tschabitscher and Bas Raayman here at EMC have already contributed in the discussion:

Those are the facts shared:

Since ESX 4.1 you are able to do a resignature or a persistent mount per datastore when presenting a “cloned” VMFS datastore to an ESX host.

1: When using the force mount, you can only mount the datastore to one ESX(i) host at a time. Multiple hosts simultaneously is only possible after resignaturing of the disk.

2: Metadata change is done by the resignature. It recognizes that the disk has the same content, but the path to access the disk is different, that’s why ESX identifies it as a duplicate, and won’t allow force mounting it to more than one host, unless you perform a resignature.

More details:

http://www.vmware.com/support/pubs/vsphere-esxi-vcenter-server-pubs.html

vSphere Storage Guide

The scenario and considerations for VMFS / VM migration we looked at.

  1. Storage vMotion requires resources (manpower, time) and moves all data 1x -> big advantage, it's all 100% online. Make sure your backup is working, as if anything should go wrong, you need a way to restore.
  2. Using an encapsulated datastore can create a "real" VMFS. However you need to re-register all VMs (for a small environment o.k.). To consider all the information about resource pools, performance data and so on that are stored in the vCenter Server DB
  3. Force Mount, rather an option that doesn't seem to do the trick as you might have this signature story, we prefer to avoid

Any other elegant ways to do a migration?

For now our agreed preference is for Storage vMotion. However, we would be curious if anybody has discovered a reliable and smooth method without playing with resignaturing and / or the issue to lose vCenter Server DB information and configuration.

David