Temporary mix PVE7 and PVE8 in the same Cluster

[Razva]

Hey,

I'm looking to upgrade all our hosts to better hardware and PVE8. The plan is to purchase the new hardware, add it into the current cluster, migrate all VMs from the PVE7 hosts to the new PVE8 hosts then shut down the PVE7 hosts.

Please note that all VMs are stored locally (ZFS) so there's no shared storage, Ceph etc.

Is this a bad plan? Should I be aware of any roadblocks?

Thank you

 

[itNGO]

If you plan to Live-Migrate keep in mind the CPUs. However, if you plan to offline-migrate, I would rather go the Shutdown/Backup/Restore way.

So Shutdown VM on PVE7.... backup and restore on PVE8. In that case you have the least risk to loose any VMs or have any hickups and quirks.

In theory it should be possible to add PVE8 nodes to an existing PVE7-Cluster, but by what you describe I would go the "create" a fresh PVE-Cluster way....

 

[bbgeek17]

Its an OK plan, it should work. Keep an eye on your cluster Quorum and make sure you always have a majority as you add/remove nodes.

It may be safer to create a separate PVE8 cluster and move the VMs via backup/restore. That would allow you to test the startup/hardware compatibility on new nodes, while still keep the production going.
@itNGO beat me by few sec

---

Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox

 

[Razva]

Thank you for your fast replies!

I don't think it's possible to "live migrate" with local (ZFS) storage. From my experience this is possible only with shared storage, but I might be wrong. So my plan was to shutdown/migrate/start. All hosts (old and new) are using AMD, so there's no mix between Intel and AMD.

The reason for keeping the old cluster is the fact that I already have a decent number of users and resource pools, through which the billing system controls the VMs. Creating a new cluster would require me to manually regenerate everything, reset all passwords and reconnect each VM to the billing system with the new credentials. It's not impossible, but it's a process I was looking to avoid if possible.

 

[itNGO]

Thank you for your fast replies!

I don't think it's possible to "live migrate" with local (ZFS) storage. From my experience this is possible only with shared storage, but I might be wrong. So my plan was to shutdown/migrate/start. All hosts (old and new) are using AMD, so there's no mix between Intel and AMD.

The reason for keeping the old cluster is the fact that I already have a decent number of users and resource pools, through which the billing system controls the VMs. Creating a new cluster would require me to manually generate everything, reset all passwords and reconnect each VM to the billing system with the new credentials. It's not impossible, but it's a process I was looking to avoid if possible.

Live Migrate with ZFS local Storage on each node is possible, it just takes longer....

As said, you can join your new nodes if you need to, but there is "some" risk. The other way, your billing system is just more "work" but you are on the far safer way.... If you desire max uptime and min risk for your customers... I would go the more "work" way and keep it safe.... ;-)

 

[bbgeek17]

Creating a new cluster would require me to manually regenerate everything, reset all passwords and reconnect each VM to the billing system with the new credentials.

As said, you can join your new nodes if you need to, but there is "some" risk. The other way, your billing system is just more "work" but you are on the far safer way

I think only OP could know what carries a lower risk. Based on the description of the changes it may actually be more risk. This is a business decision.

All hosts (old and new) are using AMD,

That doesnt guarantee smooth migration. Especially if your VMs are Windows and you used "Host" CPU. This is why Backup/Restore may be still a safer method even within a mixed cluster. Restore to new VMID, so you can fallback to original VM if things dont work. You are shutting down the VMs anyway, so there should be no IP conflicts.

Given restrictions/timing of migration with local storage, you need to allocate a maintenance window that allows a full fall back, ie full copy back. It'd be much simpler with shared storage.

---

Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox

 

[Razva]

Based on your opinions I'll go with creating a new cluster. Thank you both for your advices and fast replies.

 

[itNGO]

Based on your opinions I'll go with creating a new cluster. Thank you both for your advices and fast replies.

You are welcome!

Please mark thread as solved, if possible....

 

[ubu]

I have done this without problem by accident, i had added 4 new nodes pm8 to a pm7 cluster, no problems. warning this would not have worked with older pm releases and might not work with future releases