Migrating 6.x Cluster to 7.x

E

EagleTG

Active Member
Proxmox Subscriber
Jun 18, 2020
31
5
28
48
Hi everyone,

I read all of the relevant documentation and quite a few forum posts regarding upgrading from 6.x to 7.x. I know the recommended approach is generally to back up the VM, copy it to the new host/cluster, and restore, but I think I settled on a faster/better migration process (for my specific application/need) and wanted to get a sanity check from everyone on the Proxmox Forum.

Current production 6.x cluster has shared storage on a separate ZFS device (FreeNAS). VMs are stored on the ZFS device, Proxmox communicates over iSCSI.

I installed Proxmox 7.4 on two new/spare servers, created a new cluster on those servers, attached those to the same ZFS device via iSCSI.

Since both clusters are seeing the same VM disks on the same storage, I tested a migration by snapshotting an offline VM (just in case), copied the Conf file for this VM to a server on the new cluster (via the /etc/pve/qemu-server folder), the VM appeared and booted properly on the new cluster.

Everything seems awesome with this, and the outage/downtime is very quick for the VM. Shut it down, copy the conf file, boot it up.

Does anyone see a potential issue with this plan? I have manually replicated the entire configuration between the clusters to ensure things are the same, including firewall, etc. I wanted to ask here just as confirmation that I'm not missing anything.

Side note: I then rolled back the migration test by deleting the config file on the new cluster, then reverting to and deleting the storage snapshot.

Thoughts? Thanks!
-Todd
 
I read all of the relevant documentation and quite a few forum posts regarding upgrading from 6.x to 7.x. I know the recommended approach is generally to back up the VM, copy it to the new host/cluster, and restore, but I think I settled on a faster/better migration process (for my specific application/need) and wanted to get a sanity check from everyone on the Proxmox Forum.
Click to expand...

You don't need to create a new cluster, you have have a cluster with proxmox6 and proxmox7 nodes.

simply upgrade 1 node to proxmox7
live migrate vm from proxmox6 node to proxmox7 node
upgrade second node to proxmox7
live migrate vm from proxmox6 to proxmox7
....
https://pve.proxmox.com/wiki/Upgrade_from_6.x_to_7.0#In-place_upgrade

(I have some old cluster migrated from proxmox4->5->6->7 , without any vm downtime)
 
Last edited:
  • Like
Reactions: servada
spirit said:
You don't need to create a new cluster, you have have a cluster with proxmox6 and proxmox7 nodes.

simply upgrade 1 node to proxmox7
live migrate vm from proxmox6 node to proxmox7 node
upgrade second node to proxmox7
live migrate vm from proxmox6 to proxmox7
....
https://pve.proxmox.com/wiki/Upgrade_from_6.x_to_7.0#In-place_upgrade

(I have some old cluster migrated from proxmox4->5->6->7 , without any vm downtime)
Click to expand...

Ahh, I was hesitant to do this based on some of the forum posts I found regarding mixing 6.x and 7.x versions within the same cluster. There were quite a few posts that seemed to recommend against mixing versions, or maybe more accurately did not necessarily endorse it. I also found this thread which is sort of "on the fence" about it: https://forum.proxmox.com/threads/can-i-mix-promxox-6-and-proxmox-7-in-the-same-cluster.92214/

The documentation at the link provided doesn't provide much comfort surrounding the process to upgrade in a cluster. The one passage here mentions it, but still didn't give me much confidence:
https://pve.proxmox.com/wiki/Upgrade_from_6.x_to_7.0#Move_important_Virtual_Machines_and_Containers

I think I was looking for more clarity in the documentation that mixing 6.x and 7.x in the same cluster is "100% OK for the duration of the migration process" and upon digging through the forums, saw some people saying it works fine, and others that appeared hesitant. Quite a few forum posts seemed to prefer the backup and restore method.

Thanks for your input, I'll give the in-place method a try.
 
A bit of a delayed reaction, but for the record, we proceeded exactly like Spirit indicated, and it worked like a charm. Thank you so much for the help. We also moved quickly during the upgrade process to mitigate potential issues with mixing versions within the cluster.
 
You must log in or register to reply here.
Top Bottom