Move VMs between ESX environments

[Jorg_fcs]

Hi everyone,

My company just took over a smaller competitor. We have migrate a couple of their ESX 3.01 VMs to our environment (3.5) given their infrastructure is being sold on short notice. The VMs to migrate contain a huge number of RAW data luns so simply copying them is not order. Does anybody have a best practive for such situations?

My idea was to do the following:

1. Convert the VMs to migrate to and place them on a portable disk or laptop (given the RAW data luns will have to converted to vmdk for transportation)

2. Transport them to the main office and stage them on a VMware Server (VMs still need to undergo some changes)

3. After staging convert the virtual machines running on VMware Server to VMware ESX 3.5 servers at the main office

Can you people give me any advice on my procedure or have other practices like that.

Thanks,

Jorg

[bradley4681]

I believe you should be able to use convertor to migrate them and turn the raw into vmdk files during the process.

Cheers,

Bradley Sessions

If you found this or other information useful, please consider awarding points for "Correct" or "Helpful".

[sbeaver]

Not knowing what kind if stuff you have see if any of this will work. Since you have RDM can you remove that from the VM and then use the SAN to migrate the LUN and re-connect on the flip side. This should be alot smaller amount or size vmdk you need to migrate in other ways

Steve Beaver

VMware Communities User Moderator

====

Co-Author of "VMware ESX Essentials in the Virtual Data Center"

Coming soon to a store near you!

*Virtualization is a journey, not a project.*

[bradley4681]

but since he is migrating vm's from another company most likely the SAN will not be accessable to both the new and old ESX servers.

Cheers,

Bradley Sessions

If you found this or other information useful, please consider awarding points for "Correct" or "Helpful".

[sbeaver]

Touché but that would be the easiest if it was possible

[jitendrakmr]

You can convert the VMs into image file (including RAW Data Luns) using Platespin PowerConvert.

In case you dont have that product then you can do following -

1. Create a new VM in their environment and add disks with equal for more size of RAW data LUNs (on a storage device which you can take to your new main office). //You can also configure a Windows or Linux box as iSCSI storage which can be added to their existing farm.

2. Connect that VM to network and copy the data from all RAW Data LUNs through network to this VM.

3. Export all vmdk files (non RAW Data Luns) using vmkfstools command to new storage device which you can take to your new main office. (OR you can also do storage motion of all important VMs to this new storage device)

Jitendra Kumar

MCSE 2003, VCP, CCNA, ITIL Foundation

[Jorg_fcs]

Great idea Jitendra.

Just got some questions.

If we wish to image to data luns to a windows/linux box to transport them and place them on the SAN at the main office would that work with for example dd (in ESX). And we also have some problems with finding the path on the ESX servers to the RAW data luns on the old environment.

So if any body can give us a hint om how to find the paths.

Allready thanks for all the feedback.

Jorg

[jitendrakmr]

In case you configure Windows/Linux box as iSCSI server/NFS server for copying data then after going back to your main office you can just present same storage (from same Windows/Linux box) to esx server and copy data to SAN using vmkfstools command.

To find path of RAW data Luns right click on Virtual Machine and select edit settings, then select the hard disk which says "Mapped RAW LUN" and then in the right side you can see the Physical LUN name which is mapped to vmdk file.

Jitendra Kumar

MCSE 2003, VCP, CCNA, ITIL Foundation

[adolopo]

From the CLI, if you user the "vmware-cmd -l" cmd that will give you the path to all the running VM's (vmx file) on that HOST, typically the VMDK's attached to that VM are located within the same directory, but sometimes that isn't the case, if it's not there "cat" the vmx file to see where it's pointed to.

I think you'll find that you'll have multiple solutions for what you are proposing. But I think you'll discover the 2 key factors when planning a migration, of any kind, will be:

The UPTIME and COST associated with the proposed move. for example; if (old) SITE1 requires minimal downtime, and basically needs to be up running while SITE2 is setup, for a (somewhat) seamless cutover, then you eliminate the CLI options. Most of the guys here will agree that Platespin puts out a solid product that will handle most any reqs you have, as far as migrations go, but it can be a bit pricey. Whether you go with CLI, Converter, Ranger, Platespin, etc....in the end I think you'll find the solution you choose will be tailor made for what you have going on.