Proxmox version comparison for compatibility

[zecas]

Hi,

I need your opinion to understanding the compatibility between two proxmox machine versions, or how can I check for any possible compatibility issues.

I have the following machines:

pve-0:

• A proxmox originally installed with 6.0-4 ISO, then upgraded a few days ago to version 7.3-6 (version shown on the GUI);
• Since I had to activate the no-subscription repository, it ended with a higher version (7.3-6);
• The no-subscription repository is now disabled.

pve-1:

• A proxmox recently installed with 7.3-1 ISO, but after installation is now showing 7.3-3 (version shown on the GUI);
• It does not have any subscription, and the no-subscription repository is not active;
• The no-subscription repository was never activated, so the version is a lower one (7.3-3).

Moving a VM from a lower version to a higher version should work ok, but I guess it may not work quite as well the other way.

Since I'm thinking of using pve-0 to create, test and prepare VMs prior to moving them to the pve-1 machine (a much more capable machine), seeing that version difference alerted me of a possible problem.

So the questions that go though my mind at the moment are:

1. Is that version displayed related to the GUI version and not the pve engine version? Seems to be exactly that...
2. How can I be sure I have compatible systems?
3. What should I compare to assure best compatibility? Only the proxmox-ve version or also the running kernel version?

There are quite some version differences looking at the reported results:

pve-0 pveversion:

root@pve-0:~# pveversion
pve-manager/7.3-6/723bb6ec (running kernel: 5.15.85-1-pve)
root@pve-0:~# pveversion -v
proxmox-ve: 7.3-1 (running kernel: 5.15.85-1-pve)
pve-manager: 7.3-6 (running version: 7.3-6/723bb6ec)
pve-kernel-helper: 7.3-4
pve-kernel-5.15: 7.3-2
pve-kernel-5.4: 6.4-20
pve-kernel-5.0: 6.0-11
pve-kernel-5.15.85-1-pve: 5.15.85-1
pve-kernel-5.4.203-1-pve: 5.4.203-1
pve-kernel-5.0.21-5-pve: 5.0.21-10
pve-kernel-5.0.15-1-pve: 5.0.15-1
ceph-fuse: 14.2.21-1
corosync: 3.1.7-pve1
criu: 3.15-1+pve-1
glusterfs-client: 9.2-1
ifupdown: 0.8.36+pve2
ksm-control-daemon: 1.4-1
libjs-extjs: 7.0.0-1
libknet1: 1.24-pve2
libproxmox-acme-perl: 1.4.3
libproxmox-backup-qemu0: 1.3.1-1
libpve-access-control: 7.3-1
libpve-apiclient-perl: 3.2-1
libpve-common-perl: 7.3-2
libpve-guest-common-perl: 4.2-3
libpve-http-server-perl: 4.1-5
libpve-storage-perl: 7.3-2
libqb0: 1.0.5-1
libspice-server1: 0.14.3-2.1
lvm2: 2.03.11-2.1
lxc-pve: 5.0.2-1
lxcfs: 5.0.3-pve1
novnc-pve: 1.3.0-3
proxmox-backup-client: 2.3.3-1
proxmox-backup-file-restore: 2.3.3-1
proxmox-mail-forward: 0.1.1-1
proxmox-mini-journalreader: 1.3-1
proxmox-offline-mirror-helper: 0.5.1-1
proxmox-widget-toolkit: 3.5.5
pve-cluster: 7.3-2
pve-container: 4.4-2
pve-docs: 7.3-1
pve-edk2-firmware: 3.20220526-1
pve-firewall: 4.2-7
pve-firmware: 3.6-3
pve-ha-manager: 3.5.1
pve-i18n: 2.8-2
pve-qemu-kvm: 7.1.0-4
pve-xtermjs: 4.16.0-1
qemu-server: 7.3-3
smartmontools: 7.2-pve3
spiceterm: 3.2-2
swtpm: 0.8.0~bpo11+2
vncterm: 1.7-1
zfsutils-linux: 2.1.9-pve1
root@pve-0:~#

pve-1 pveversion:

root@pve-1:~# pveversion
pve-manager/7.3-3/c3928077 (running kernel: 5.15.74-1-pve)
root@pve-1:~# pveversion -v
proxmox-ve: 7.3-1 (running kernel: 5.15.74-1-pve)
pve-manager: 7.3-3 (running version: 7.3-3/c3928077)
pve-kernel-5.15: 7.2-14
pve-kernel-helper: 7.2-14
pve-kernel-5.15.74-1-pve: 5.15.74-1
ceph-fuse: 15.2.17-pve1
corosync: 3.1.7-pve1
criu: 3.15-1+pve-1
glusterfs-client: 9.2-1
ifupdown2: 3.1.0-1+pmx3
ksm-control-daemon: 1.4-1
libjs-extjs: 7.0.0-1
libknet1: 1.24-pve2
libproxmox-acme-perl: 1.4.2
libproxmox-backup-qemu0: 1.3.1-1
libpve-access-control: 7.2-5
libpve-apiclient-perl: 3.2-1
libpve-common-perl: 7.2-8
libpve-guest-common-perl: 4.2-3
libpve-http-server-perl: 4.1-5
libpve-storage-perl: 7.2-12
libspice-server1: 0.14.3-2.1
lvm2: 2.03.11-2.1
lxc-pve: 5.0.0-3
lxcfs: 4.0.12-pve1
novnc-pve: 1.3.0-3
proxmox-backup-client: 2.2.7-1
proxmox-backup-file-restore: 2.2.7-1
proxmox-mini-journalreader: 1.3-1
proxmox-widget-toolkit: 3.5.3
pve-cluster: 7.3-1
pve-container: 4.4-2
pve-docs: 7.3-1
pve-edk2-firmware: 3.20220526-1
pve-firewall: 4.2-7
pve-firmware: 3.5-6
pve-ha-manager: 3.5.1
pve-i18n: 2.8-1
pve-qemu-kvm: 7.1.0-4
pve-xtermjs: 4.16.0-1
qemu-server: 7.3-1
smartmontools: 7.2-pve3
spiceterm: 3.2-2
swtpm: 0.8.0~bpo11+2
vncterm: 1.7-1
zfsutils-linux: 2.1.6-pve1
root@pve-1:~#

Thank you.

 

[t.lamprecht]

Moving a VM from a lower version to a higher version should work ok, but I guess it may not work quite as well the other way.

That's in general true for VM (live) migration, but the versions most relevant for this are the one from the pve-qemu and the qemu-server packages.

Is that version displayed related to the GUI version and not the pve engine version? Seems to be exactly that...

The version displayed at the top right of the Web UI is the one from pve-manager package, which hosts the whole GUI, the main API server entry points and then mostly node and ceph specific API endpoints - the other API endpoints are provided by their own packages, e.g., pve-container for CT stuff, libpve-storage-api-perl for the storage client access API, ...

How can I be sure I have compatible systems?

If you really want to be sure then you would need to set up the same active repositories on all, and update them periodically to ensure they are on the same package versions.

What should I compare to assure best compatibility? Only the proxmox-ve version or also the running kernel version?

For VM live-migration I already mentioned pve-qemu (QEMU) and the qemu-server, while we have active pre-checks for migrations in place to catch the cases that just cannot work (VM started on a node with a major new QEMU version, say 7.3, while target node only got QEMU 7.2 installed).

All that said, biggest question of my part is:

It does not have any subscription, and the no-subscription repository is not active;

Why? Enabling one Proxmox VE is heavily recommended, and if you do not have a subscription for the enterprise repository, the no-subscription one is the next best choice w.r.t. stability.

 

[zecas]

Why? Enabling one Proxmox VE is heavily recommended, and if you do not have a subscription for the enterprise repository, the no-subscription one is the next best choice w.r.t. stability.

Thank you for your reply.

Well, pve-1 is my production environment, the server were I'll be putting the VM machines to good use and I want to have the best stability possible. I don't have a subscription and assuming the no-subscription may bring some issues, I guess I'm being too cautious.

This warning did not help my mind to rest:
"This is the recommended repository for testing and non-production use. Its packages are not as heavily tested and validated."

But I'm sure many people have no-subscriptions on their production environments, with very minor problems, if any at all...

At this time it's just a matter of feeling safe, I guess. But I guess in the near future I'll have no choice but to go for the no-subs repo.

 

[Dunuin]

Well, pve-1 is my production environment, the server were I'll be putting the VM machines to good use and I want to have the best stability possible. I don't have a subscription and assuming the no-subscription may bring some issues, I guess I'm being too cautious.

Well, without a PVE repo you won't get security patches for those PVE packages. Running a server with vulnerabilities and bugs, that already got fixed, is also not that great.

 

[zecas]

Well, without a PVE repo you won't get security patches for those PVE packages. Running a server with vulnerabilities and bugs, that already got fixed, is also not that great.

Guess you're right, the server is a new install, so there may be no relevant updates at the moment, but it's a matter of time and so I'll have to enable no-subscription repository, even if it is a production environment.

Well, that way I'll be sure that both test and production environment will have the same updates when I move the VMs anyway...

Anyone had any relevant problem in a proxmox installation with some no-subscription repository update? Anything that brought some relevant instability?

 

[Dunuin]

Stuff is first tested internally. Then there is an inofficial bleeding edge repo. Stuff then gets to the test repo. From there to the no-subscription repo. Then free users run into the last problems, stuff gets fixed and sometime later these packages are included in the enterprise repo.
So if you want it as stable as possible, which is always recommended for a production system, it would be best to get a subscription, so you can use the enterprise repo. Otherwise you are some kind of betatester for the paying customers.

The no-subscription repo is stable enough for any homelab and problems that are breaking stuff are very rare. But PVE is no appliance and everyone might use different hardware or install custom software. So the more you customize your PVE installation and the less mainstream your hardware is, the more problems you might run into.