Migrate VMs from ESX 3.5 to 4.0 on the same VC

[qwert1235]

Hello:

What is the best way to migrate VMs from ESX 3.5 to 4.0 on the same VC?

I can just use cold migration (there is no shared storage), but I want at the same time upgrade VM tools, new hardware (and whatever esle I might need).

What is the best way to do it?

I did few tests and did the following:

Migrated (cold) VM from ESX 3.5 to 4.0

Upgraded VMware tools

Upgraded VM hardware version (to 7)

everything looked nice and easy, but I loost the static IP configuration I had before upgrating VM hardware. How can I avoid it?

Is there any automated way to do it (I have a lot of VMs to migrate)?

Should I consider upgrade anything during migration from ESX 3.5 to 4.0?

Thanks a lot!

[weinstein5]

Did you install converter when your installed VC? You could also install the Standalone converter in your environment and us ethat to schedule and automate the migrations -

If you find this or any other answer useful please consider awarding points by marking the answer correct or helpful

[qwert1235]

No the converter does not really work. Yes, it will migrate, update VMware tools/VM Hardware, but (for example) static IP address will be gone again. Not too much difference from cold migration, just taking longer.

Any other ideas?

[weinstein5]

Another option would be to use FastSCP and copy the files directly - this way you would not lose the IP address but once added to the 4.0 ESX host you will be able to upgrade it -

If you find this or any other answer useful please consider awarding points by marking the answer correct or helpful

[VTsukanov]

Strange ... I have migrated above 100 VMs in the past month in this way, but from 3.5 to 4.1 :

1. VM migrated from 3.5 to 4.1 host

2. PowerOn VM

3. Update vmware tools

4. PowerOff VM

5. Upgrade hardware to version 7

Problems were only with the Windows NLB Cluster

[qwert1235]

did you do all 100 manually or used any automation? Did it keep static IPs after migration?

Thanks,

[VTsukanov]

Yes static IP addresses were kept (various OS : CentOS, RHEL, Windows, static IP was set on ~30 vms ). We used some PowerCLI & perl scripts as automation tools.

[qwert1235]

Valeriy,

Did you do any disk alignment during the move?

Thanks

[RParker]

Did you do any disk alignment during the move?

Disk alignment depends on 2 things, the SAN and IO. If VM's don't use much IO disk alignment has very little impact. If the SAN is configured for NFS, and not using block level (LUN) then disk alignment has very little impact as well.

Even if you do find that Disk Alignment SHOULD be used, testing will prove if it impacts performance, some SAN are able to make up the difference, some cannot... but Disk Alignment isn't necessarily critical.

Then too Windows 2008 / Windows 7 VM's are ALL aligned by default. (If they were installed as NEW not upgrades, and formatted by the OS)

[VTsukanov]

We did not do Disk Alignment, partly due to the lack of time, partly because our lab environment did not provide a significant increase in productivity.

I agree with point of the view that the Disk Alignment is desirable but not a necessary procedure.

[qwert1235]

Valeriy,

Is there any chance you can share the CLI scripts you used for migration VMs from VI 3.5 to vSphere?

Thanks a lot!!!

[VTsukanov]

PowerCLI - We created migration vm scripts (designed for our environment) based on the following scripts: PowerCLI: Upgrading vHardware to vSphere Part 2: VM’s and PowerCLI: Upgrading vHardware to vSphere Part 1: Templates

Perl - we use a perl script to monitor the status and performance monitoring vm, unfortunately, it also uses our vSphere custom fileds and is unlikely to be useful to you.

[colargol]

what problem did you have with microsoft nlb ?

we'je just migrated vm from 3.5 to 4.1 and we have nlb problems too.