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

[davide.depaoli]

Hello all and sorry for my absence.
I try to briefly summarize the situation:

this is a typical small Italian company, where the owner sees IT as a necessary evil and not as an investment for the company.
Consequently the less they spend on IT the better is.
It has already happened that some years ago, on the current infrastructure they lost an entire raidset resulting in the loss of all production vm. They left all employees at home for a week until I recovered what I could from an old backup (they still do a file level backup).

Again to save money, the new infrastructure does not provide 10Gb switches but a direct-attached server to the storage controller.
So I necessarily need a solution that allows me to migrate vm's from the old infrastructure to the new one since I cannot interconnect them.

[RubinCompServ]

@davide.depaoli,

If these are all Windows machines, using the VMware Converter agent installed directly in the machines could work. Or build a separate VM and install the Converter in that and perform a V2V migration. If you're dead set on using a backup/restore methodology, tell the company that you're going to do it "their way" and build brand new servers in the new environment and restore their data to it and then schedule a cutover. I don't know what the last version of Veeam was that even supported ESXi 4.1 (v6? v6.5?), and it sounds like you wouldn't have any place to put those backups anyway.

[davide.depaoli]

Hello RubinCompServ,

<VMware Converter agent installed directly in the machines could work> and <build brand new servers in the new environment and restore their data> are not a viable options, because:
- VMs (about 12 VMs) are windows but all old release (There is still a WinXP 32bit...), and the customer does not have MS Software Assurance to upgrade them.
- the customer (and I) is not able to reinstall/reconfigure the applications.

However the last Veeam supporting ESXi 4.1 is 9.5 U3a, that I have alreary downloaded, but most importantly the customer is absolutely aware that they are "in the wrong" that they are willing to accept any solution and any timeline to do the migration.

[RubinCompServ]

@davide,

I'm going to ask you a question, and this question probably needs to go to your customer: If their ESXi 4.1 environment crashes today, what is their recovery process? You said earlier that the process was recover from a file-level backup. What prevents you from doing that to a newly-built VM in the new environment? I grant that that is an absolutely awful process, but it sounds like the customer is going out of their way to sabotage any modern solution.

I see that you found a download for 9.5U3. To answer your (updated) question: yes, Veeam v12 will read backups created by older versions. But even once you get your VMs to the new environment, you're not out of the woods: you're going to run into issues with VM Hardware versions and VMware Tools. Not to mention that the OSes are inherently unsupported by ANYONE, so there's really no way to predict how they'll react to the new hypervisor.

[davide.depaoli]

Hello RubinCompserv,
I'll try to answer to your questions:

<You said earlier that the process was recover from a file-level backup. What prevents you from doing that to a newly-built VM in the new environment?>
The customer had old VMs copies with all applications installed. I have restored them and applied the latest available data restore point.
Also, the customer (and I) is not able to reinstall/reconfigure the applications, and I also suppose that it most likely it does not even have the installation packages.

<OSes are inherently unsupported by ANYONE, so there's really no way to predict how they'll react to the new hypervisor.>
As I said, the customer is absolutely aware that they are "in the wrong" that they are willing to accept any solution.

And finally, don't forget that this is a typical small Italian company, where the owner sees IT as a necessary evil and not as an investment for the company. Consequently the less they spend on IT the better is. Unfortunately, in Italy this kind of customer is is much more common than people think (especially in small businesses, market sector where I'm working with).

[RubinCompServ]

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

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.

I couldn't figure out why this wasn't going to be a viable option until I looked it up. The last version of VMware Converter to support ESXi 4.1 is v6.1.1, but the first version to support ESXi 8 is v6.4, so he would need, at the minimum, a 6.0.0U3 swing host to migrate to, then upgrade that host to 7.0, and then use VMware Converter 6.4 to take it the rest of the way.

Interoperability Result

[tyler.jurgens]

Get the old Veeam version installed on the old infrastructure. Install it on a desktop/laptop, something/anything that can access that old infrastructure. Create a repository on this external HDD (USB, etc, whatever you can make work with what you have). Take backups of those VMs to that external HDD. Take the initial backup while that VM is powered on, then shut the VM down and take an incremental - this way you get the latest changed data.

Install the new version of Veeam on the new infrastructure. Again, could be some VM or laptop/workstation, etc. Attach the external HDD as a repository to the new Veeam. Import the backups into Veeam and restore to the new infrastructure.

You could use this method to swing migrate one VM at a time, or multiple at once. It won't be fast, there will be downtime, it will be very manual, but it should work. Good luck.

[Seve CH]

I would create a VM in the old environment with the latest virtual hardware available.
Remove from the inventory and using a laptop, copy it to the new host using ssh (Bitwise SSH is much much much better than winscp).
Import it. If the exported VM is not working on the new host (it should, but who knows), use ESX 7. If it still doesn't work, use ESX 6.x.

Once you find a configuration that works, try to schedule it during the weekend. If you are a small Italian company, you are most probably closing for summer holidays. Use that time for the biggest VMs.
When importing, make sure to select "I moved it" or you will get new MAC addresses and may break licensing of the running software.

[davide.depaoli]

Hi all,
finally the mission impossible became possible and ended more easily than expected. I have manually done a VeeamZip backup from old ESX to a new QNAP on its network share.
The same share was mounted on a new veeam server. From this I have restored vbk files on a new location (the nevsphere 8 servers).

From today all old VMs are running on a new vsphere 8 infrastructure.

[tyler.jurgens]

Amazing! Well done! Thanks for looping back to us with your solution.

[RubinCompServ]

Well done, and very elegant! Thanks for letting us know!