When will 3.x become EOL?

As stated proxmox 3.4 will receive updates as long as Debian security team offers support for Debian Wheezy. Debian security team will end there support for Debian Wheezy one year after the release of Debian Jessie and since Debian Jessie was released 2015-04-25 then the support for Debian Wheezy will end 2016-04-25.
well wheezy will be transferred to the LTS team afterwards (even though they haven't made ANY announcements on when the regular support will end yet). So security updates will be released til 2018 as mentioned above. And while I assume there will be no more development on Proxmox 3.4, there will probably still be community support on these forums for it since people don't just forget all their experience in April 2016 ;)

This is somewhat of a followup topic of the "lxc vs openvz" thread I guess. Id have to concur that dropping 3.4 support in April might be much too soon. But thats just a side note and could go off-topic really fast.
Last edited:
well wheezy will be transferred to the LTS team afterwards (even though they haven't made ANY announcements on when the regular support will end yet). So security updates will be released til 2018 as mentioned above.
This is true but LTS team does only support af limited number of packages in Wheezy so chances are that a number of packages part of Proxmox 3.4 will not receive security fixes from LTS team.
At a minimum I think Proxmox should consider providing kvm/kernel updates for 3.x until wheezy LTS ends or OpenVZ stops providing kernel updates.

FWIW, the current planned dates for these are:

Wheezy LTS EOL: May 2018
OpenVZ RHEL6 kernel EOL: Nov 2019

(sources: https://wiki.debian.org/LTS and https://wiki.openvz.org/Download/kernel/rhel6 )

Perhaps an option is to adopt a similar model to Debian LTS - i.e. support is on a "best-effort" basis. Those who need continued support for 3.x (or just for particular packages within it, which aren't covered by either OVZ/RHEL6 or Wheezy LTS itself) can help provide it by either working on it directly themselves, or by making a financial contribution. This model seems to have worked well for Debian LTS?

Might be best to actually call it Proxmox 3.x LTS, and give the same sort of disclaimer that Debian does, plus process for turning it on (so that users are "opt-in" to the lower support level)?
  • Like
Reactions: e100 and sumsum
Just thinking a bit about what effective continued support would mean for Proxmox 3.x in our use case (and I'd guess most other deployed users' too).

Generally it just means security updates, so lets break that down:

The attack surface of the environment overall comprises:

1. Management infrastructure:
a. Proxmox specific tools (<10% ?)
b. Debian infrastructure used to access those tools e.g. web servers, ssh servers etc. (>90%).

2. Parts which are accessible to processes running on the containers themselves:
a. The kernel (approx 99%)
b. Management tools which deal with data container "user data" (approx 1%)

I'm happy we can firewall off or otherwise secure "1." the management infrastructure (and most of that is probably accounted for by Debian LTS anyway), so that's not of a great deal of concern. Of what's left, it's mostly the kernel, which is (I believe) mostly the OpenVZ one (and supported by Virtuozzo out to 2019 according to their Wiki, and the non-VZ parts out to 2020 by Redhat).

I'm not sure how much the Proxmox kernel differs from the OpenVZ one, but the options would appear to be:

1. Security support for the OpenVZ kernel, and all customisations
2. Security support for the OpenVZ kernel, but not any customisations
3. Security support for the OpenVZ kernel only (customisations will be removed - admins will need to opt-in to this kernel series)

So, really when I'm asking for long term support, all I'm asking for is kernel security support (as this is the vast majority of the "attack surface" for my use-case), and if that means foregoing customisations not supplied by upstream OpenVZ, then I'll put up with that too.

The user-space updates which Wheezy-LTS will provide are a nice bonus, but probably don't matter much as the hardware nodes aren't going to be accessible by the Great Unwashed Internet anyway.

So I suppose the question is:

How much is Proxmox willing to carry out this kernel support, and how could they organise community help to accomplish this (and/or solicit financial assistance to get this done - which could even be something creative like paying a Debian or CentOS developer to do-so for x hours per week)?


  • Like
Reactions: fibo_fr and sumsum


The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!