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
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.
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