Migrate ESX 2.5.X vm's to ESX 3.5.X server

Version 2

    I'm involved in a project to migrate several vm's that are currently on  an ESX 2.5.X server (SAN storage) over to an ESX 3.5.X server (different  SAN storage). I've read the Upgrade Guide. What I'd like to be able to  do is be able to perform the migration and be in a rollback position if  something goes awry.

    If both of my ESX 2.5 and 3.5 servers can see each other's SANS, would I  be able to do a cold migration from ESX 2.5 --> ESX 3.5? A live  migration is out of the question as the ESX 2.5 server is AMD and the  ESX 3.5 server is Intel. During the cold migration steps i'm presented  with a screen that states:

    Keep virtual machine configuration files and virtual disks in their current locations.

    Move virtual machine configuration files and virtual disks

    If I were to select 'Move virtual machines....' I'm assuming all the vm  files (vmx, vmdk, etc) would get moved over to whatever datastore I  select. So, now I've moved an ESX 2.5/vmfs2 vm over to ESX 3.5/vmfs3  datastore. Has that vm now been upgraded to vmfs3, or do I have to  perform another step? Should I be able to power up that vm now?

    If things don't work out would I now be able to cold migrate BACK to the ESX 2.5 server and vmfs2 datastore?



    You will need to perform two more steps first will be to upgrade the  VM's virtual hardware and second will be to upgrade the tools. You can  right click on the VM in inventory and can see these options.



    P.S : If you think this information is helpful consider rewarding points

    Hi kooltechies

    Thanks for the quick response. So, as far as versions of vmfs is  concerned. If I'm copying a vmfs2 vm into a vmfs3 datastore, the vm will  become vmfs3 format? Also, if I wanted to "rollback" would I be able to  do a cold migration back to the ESX 2.5 server/vmfs2 datastore and be  back to how I started?


    It's been a bit since I had to do this, but ESX 2.5 vs ESX 3.x, they  introcduct VMFS3. And they also re-configured the file layout. In 2.5  there was a separate location for the VMX, nvram etc and the VMDK's were  in a different location. in ESX 3.x, now all the files associated to  that VM resides under /vmfs/volumes/datastore/VMname. The cleanest way I  was able to do this was:

    Build ESX 3.x VM shells on your ESX3 host, using the same VM information as your 2.5's with memory, the OS flavor, NICs etc.

    Create those VMs with no disk attached. This will create your folder structure.

    Then use Veeam or WinSCP to copy the vmdk's from your 2.5 storage to the new folder structure.

    Then via VC add those vmdk's back your newly created VMs

    Power them up and it will prompt you to "Upgrade the vmdk to vmfs3"

    Probably worth mentioning if you "Remove from inventory" of your 2.5 VMs, I believe you can create the same name.

    Assuming you have enought space to do all of this...then if you need to  dump back to your 2.5, simply "Remove from inventory" and add in the 2.5  VMs again.

    I know this is sort of a long way around, but it worked and the safety  net is there if you have to move back because I don't believe you will  be able to cold migration from 3.x to 2.5.







    Hi Cruicer

    Thanks for the response. Instead of using WINSCP or a copy program could  I not log onto VC 2.5 and browse the ESX 2.5 datastore - open the vm  folder and select/copy all of the ESX 2.5 vm files over to the ESX 3.5  datastore/newly created folder structure?

    I'm just figuring if it might be easier to take advantage of the  capability of VC 2.5 to browse datastores and perform "windows explorer  like" copies.

    I do like the fact that this way seems to leave the door open to add back to the ESX 2.5 server.



    I would think so...worth a shot, what's the worst that can happen...you  copy fails. Veeam is a freeware in case you were wondering...

    You are going to have to take a one VM by one VM approach. since in 2.5  you stored all the VMDK's in one location (I believe again it's been  awhile) you are going to want to grab the VMDK from one VM on your 2.5  host, then copy it to the \vmfs\volumes\datastorename\VMon3.xname\ Again  create your shell first so you have the vmx, yada yada files. dump the  vmdk's into it re-attach bing bang boom....now where is that "easy  button"...


    Another option - use VMware Converter to move the ESX 2.5 guests to the  ESX 3.5 hosts - the converter creates the new image on the vmfs3  storage, upgrades the guest to vmfs2 format and installs the updated  tools.

    The only issue we've seen is that we have to go into the guest and remove the invisible NIC and reconfigure the IP addresses.

    Another option is to use the Converter function in VirtualCenter 2.5 -  Live conversion works in the right security environments. (We tested it  but had some security updates to .Net that boke the live conversion  feature.)



    Veeam is freeware? Cool. I thought it would cost something. I never used  it before. How would I use Veeam to copy the ESX 2.5 vm files from one  SAN to another SAN? Both ESX servers can see each other's stoarge btw.




    but if you want to preserve the VM name...can't do it w/  Converter...plus I didn't think converter worked w/ 2.5...could be wrong  or could have been with the beta version of converter.


    We're using version 3.0.3 and you can keep the name of the guest during the conversion.


    Once you get it installed, it basically resembles file manager for  windows...you can drap and drop from one ESX host to the other. If you  know the root password of your 3.x hosts, by default ssh is  disabled...you can enable it but if you have a local account as well,  veeam will also elivate your access to root level.


    But how does that work if you already have a VM with that same name in  the environment. Won't he get a duplicate name error? I've only used  converter for P2V...so pardon my questions.


    We have the ESX 2.5 guest/hosts still in VirtualCenter 2.0.x and the ESX 3.5 hosts in VirtualCenter 2.5.

    Converter logs into VC2.0.x - you choose the guest, and then it logs into VC2.5 where you add a virtual machine.

    So the guest is not part of the same VC environment - note for Converter  3.0.3, the guest servers being migrated must be turned off and the  speed of the migration depends on both your network and SAN.

    If the migration fails, you turn on the guest in VC2.0.x; if it works,  you're already up and running (assuming you checked the option to start  the guest upon completion.)



    Keep in mind that I'd be copying to a different datastore. I don't think  that having the same name would present problems - but I'm not sure.  So, the consensus is that Converter 3.0.3 works fine to migrate from ESX  2.5 to ESX 3.5? Other then the nic issue it shouldn't present any  problems?

    What about the Converter Enterprise that comes with VC 2.5? Will that work too?




    What if I don't have VC 2.0? Will Converter log onto an ESX server?


    Ok...that makes sense, two totally different VC environments...but if  one only had one Virtual Center server w/ 2.x and 3.x hosts...guessing  you would have to have different VM names? Datastores is not the issue,  it is the your overall ESX environment if all of your hosts are managed  by one Virtual Center server, then you can't have two VMs of the same  exact name.


    We've moved a couple of hundred guests using the process I've described and will be using it until we've completed our upgrade.

    We tested the Entreprise Converter withing VC and it offers a live  migration option. Unfortunately when we went to use it in production,  there had been some .Net patches and we got into the .Net equivalent of  dll hell. Since the cold migration process works with Converter 3.0.3,  we decided to use it rather than figure out which .Net component went  screwy.



    Crucier - My environment would just be one VC 2.5 - but the ESX 2.5  server is not part of VC. The plan was to add it to VC 2.5, but if that  might prsent problems with duplicate names then i'll keep it  stand-alone.

    It seems that I can run Converter and i believe Converter can log onto a  VC and/or an ESX server - so, hopefully it won't be a problem. Once  again I like the fact that if the upgrade is unsuccessful I should be  able to power up my ESX 2.5 vm and go about my business like nothing  happned.

    Thanks all for the great responses.....much appreciated!


    This document was generated from the following thread: Migrate ESX 2.5.X vm's to ESX 3.5.X server