[HELP for a mission impossible] - move from ESXi 4.1 to ESXi 8

[davide.depaoli]

Hello,
our customer runs its production VMs on ESXi 4.1.0 infrastructure (no matter why, it would be a long story). Now it's time to refresh the hardware and I should install new server/storage and new software version (vSphere 8 and Veeam 12).

The actual infrastructure consists of two bladeserver (HP BL460) and one 1Gb iSCSI storage (MSA2000). The new will be two rackmount server (HPE DL360) and one 10Gb iSCSI direct attache storage (MSA2062).

The mission should be to bring VMs from ESXi 4.1 (vmfs 3) to new ESXi 8 (vmfs 5/6/8 ?), keeping in mind that:
- Is not possible to interconnect both storage to new server.
- Latest Veeam B&R supporting ESXi 4.1 is 9.5 U3a (it is still possible to download it ?)

To my knowledge the only possible solution would be to turn off the VMs and copy/paste across the network, but in this way the migration would be infinite...

[EDIT]
assuming is possibile to download veeam 9.5 u3a would it be possible to backup VMs with this version and restore with Version 12 ?
Found download link for 9.5 U3a here https://www.veeam.com/kb2646

Anyway, does anyone have any applicable ideas/solution ?

thanks in advance
Best regards
Davide

[MarkBoothmaa]

What about using the Veeam agents? you could do volume-level restores into the VM's on the new platform?
You would need a NAS or some storage that would be available as a network target but for me that would be the safest and most efficient way.

[davide.depaoli]

Agents could be a partial solution. Some VM are Win2003 server, that is not supported. Otehr VM are Win2008 R2 and Win7 32bit.
Nas is part of the new infrastructure.

Thank you.

[PTide]

Hi,

Rearding v9.5 download I think Internet Archive might have something.

As for the possibility to restore backups produced by v9 using v12 - yes, later versions are supposed to support backups produced by previous versions.

Otherwise we would have to update format of all backups every upgrade, and that we clearly don't do : )

Thanks!

[davide.depaoli]

Thank you PTide.
When the new infrastructure will be up and running, I will do some backup and restore tests, especially regarding the timing of operations.
Regards,
Davide

[PTide]

P.S. Here is the official link for 9.54b (should work fine with older ESXis)

https://www.veeam.com/download_add_pack ... ate4b_exe/

Thanks

[tyler.jurgens]

our customer runs its production VMs on ESXi 4.1.0 infrastructure (no matter why, it would be a long story). Now it's time to refresh the hardware and I should install new server/storage and new software version (vSphere 8 and Veeam 12).

No no no. You cannot leave us with a customer running their production environment on ESXi 4.1.0 (in 2024) and not share this backstory. I'm ready for story time, I've got my coffee prepped and I'm captivated.

Also, what a time to get licensing with VMware by Broadcom!

[Gostev]

P.S. Here is the official link for 9.54b (should work fine with older ESXis)

https://www.veeam.com/download_add_pack ... ate4b_exe/

Thanks

Except it does not at least not with the one in question https://www.veeam.com/kb2443

[karsten123]

why not just follow the official upgrade path?

[tyler.jurgens]

Man, I couldn't even imagine the pain and suffering they would have to face to jump through multiple upgrades and hardware refreshes to get to a vSphere 8 environment. Can it be done? Sure. Would you spend more time doing that then just migrating? Probably.

Depending on the scale of the environment, it might even be a better choice to simply build new VMs on the new environment and migrate services and data to those. Kill two birds with one stone - get a badly needed VMware refresh along with a badly needed OS refresh.

[karsten123]

true. OS is a thing, too.

[Origin 2000]

I do a lot of those "migration" and because we have a lot of iSCSI environments the plan A is always to have at least ONE ESXi Host which is connected to the old and new Storage and use this one as a migration point. When having iSCSI i never found a real door stopper... yes sometimes you need to ignore and violate "Best practices" like having only one Link/Path, Binding or Non-Binding swISCSI config within ESXi or what ever but thats just for a short peroid of time. Even when dealing with old Blade chassis i cant think what maybe can impossible.

Regards,
Joerg

[tyler.jurgens]

Absolutely a swing host would be a good choice there Joerg, but he did mention its not possible to interconnect storage. So there must be some reason he's got a blocker there, hence not recommending it. Would be far easier if he had that of course.

Could always do a V2V migration as well with VMware vSphere Converter agent. Install on the OS and let it rip. Might have to find an older download to do that though with some of his older VMs. Would be nice if Veeam would have links to their older downloads with a giant red disclaimer that these should never be used as they're unsupported - one of those things where if you know what you're getting yourself into, then you can use it.

I've refreshed my coffee today. Still waiting on story time.

[mengl]

I would use vCenter Converter.
No need to install it in the guest VMs, just connect to the old/new host/vCenter and start the migration.

[TonioRoffo]

My 2 cents:

Definitely go greenfield in the new environment (at least hypervisor-wise) - if you don't have too many machines going.

As for the VM's, not sure what you will keep, but if something needs to be kept as-is, I'd treat it as a P2V migration. Use the new vmware converter or Starwind, eventually.

oh, and lots of backups before you start

>>> To my knowledge the only possible solution would be to turn off the VMs and copy/paste across the network, but in this way the migration would be infinite...

Vmware converter allows for staged migration, you could keep downtime to a minimum that way.

[wdbarker3]

You mention "network ... infinite", but the SCSI is only 1 G. Given that, a good way to speed up that sort of transfer is to use a USB stick or disk and move it that way.

To minimize down time, and/or speed up sparse disks, you can do the following.

Snapshot a VM
Copy everything over except the disk Delta. I'd use rsync with the SPARSE argument. Network or USB for transfer.
Suspend the VM
Copy over the Delta
Start the VM on the new host
Delete the snapshot on the new host

Rinse/repeat for other VMs.

To use rsync, you'll want to enable SSH, and drop an rsync in /bin. Mark it executable. If you don't have an rsync handy, I'll drop a statically-linked rsync on my server for you (ftp.visioncomm.com). Been using it since version 4!

Dan (Atlanta)

[derek.bannard]

Probably not the best reply on a Veeam forum, but here goes.

1. Don't use Veeam, don't worry about Veeam v9.
2. Setup your new VSphere cluster and make sure it has vCenter 8 installed.
3. Install VMware Converter Standalone onto a computer and connect it to the 10GB switch you are using for your new cluster. You are using a 10GB switch right and not directly connecting hardware to servers??
4. Using the converter, set your source to be your old vCenter, if you don't have vCenter point it to your ESXi host and set the destination to the new vCenter 8 server.
5. VMware Converter will do all the heavy lifting for you. Including upgrading vCenter Tools, resolving architecture difference between ESXi 4 to ESXi 8, etc.
6. When everything is copied over, the source machines will have been shut down during this process, test and make sure the server is functioning as intended.
7. Create a new VM and install Veeam 12.1 on it. Set it up to do your backups.

Done.

[a-tome]

I do a lot of those "migration" and because we have a lot of iSCSI environments the plan A is always to have at least ONE ESXi Host which is connected to the old and new Storage and use this one as a migration point. When having iSCSI i never found a real door stopper... yes sometimes you need to ignore and violate "Best practices" like having only one Link/Path, Binding or Non-Binding swISCSI config within ESXi or what ever but thats just for a short peroid of time. Even when dealing with old Blade chassis i cant think what maybe can impossible.

Regards,
Joerg

You are correct. If there is any way to upgrade even one host that is currently connected to the storage to a version of ESXi that supports storage vmotion, then the problem would be solved. I did not notice whether VCenter was being used, but it is required for any vmotion moves. Otherwise, it becomes a more manual process as others have described. If downtime is tolerable, the vms could be shutdown, unregistered, and SCP'd to the new hosts. Not sexy, but it works. Best solution is to find the lowest version of ESXi that supports storage vmotion, even if you have to shutdown the VM to move it. I think that was a capability in ESXi5, and maybe in ESX4. Live storage vmotion requires either v7 or higher.

[RubinCompServ]

Could always do a V2V migration as well with VMware vSphere Converter agent. Install on the OS and let it rip.

This is what my suggestion would be. Maybe even treat the ESXi 4.1 environment as a "black box" environment and deal with the machines at the OS level instead and use the VMware Converter as a P2V converter.