Moving to LXC is a mistake!

[shukko]

We've had problems with it before (migration errors mainly), but it's still miles better than the backup-restore you are forced to use with LXC guests, causing several hours of downtime for large guests.


Consider yourself lucky... Unfortunately, we have many guests where the overhead caused by KVM would make them unusable.

Some of our MySQL guests simply stopped working under KVM (slowed down to a crawl) under high load, while the same workload under OpenVZ gives us 50% higher transactions per second, and much more graceful slowdown under extreme loads. We really need containers, unfortunately LXC is not there yet, so we are forced to stay with OpenVZ for the time being.

Being not alone makes me happy, but as always not a solution to "our" problems.

what can be done ? what is the solution ? I don't want to get rid of openvz, but I also want to use Proxmox 4.x.

I can not find any other alternatives to this beautiful Proxmox we have...

I have to agree these are all issues for the current state of Proxmox and that the OpenVZ ecosystem was "better" as far as we are concerned. As for the other posters comment that live migration of OpenVZ containers never worked properly that is complete garbage. We moved around 1000's of these from one device to another and it worked great. The need for downtime with LXC is terrible, yes it is minimal but downtime is downtime!

That is %100 true for me also..

 

[SamTzu]

Yes, we support 3.x and 4.x - seems you missed that or you mean something else.?

I actually meant running both versions side by side.

 

[wolfgang]

And how should this work?

LXC kernel min 3.12
OpenVZ kernel 2.6.32

 

[SamTzu]

That is the question...
Maybe some Migration version for Proxmox that would have modified kernel for both? Not meant for hosting but only for migration of containers. I don't know. Feel free to invite the "evil overlord" to the discussion

 

[tom]

You can run Proxmox VE 3.4 with 2.6.32 as a VM guest on Proxmox VE 4.x.

 

[SamTzu]

No use crying over a spilled milk. We all knew (or should have known) that this day was coming. Now we have ~3 months to migrate or stay with an old version that will not be updated. The question in my mind is... how to migrate with as little downtime and problems as possible? All our tests have been less than satisfactory. In my opinion the biggest problem is the forced migration to "Root Disk" on Proxmox LXC. That requires migration to ZFS disk images (hence the forced backup and restore and down time.) If Proxmox would support old style "host level" file system for LXC (like it does for OpenVZ) then migration would become much easier and most migrations could be done in seconds in stead of minutes or hours. I realize that support for quotas are important on some containers but most of us have hard drives to spare. Quota support can follow later.

 

[mipsH]

I have a question regarding production life of Proxmox VE 3.4.

In Debian official page : https://wiki.debian.org/LTS it is visible that security updates will EOL until May 2018 (this is EOL for Debian LTS team).
Does this mean that at least security updates will be available for Proxmox VE 3.x until that date (May 2018) or February 2016 (which is official support date from Debian support team)

I understand your reasons, but just want to be sure which date will be EOL for 3.x, because of migration planning in advance.
For me it will take a few months of planning ahead.

 

[tom]

See this announcement https://forum.proxmox.com/threads/proxmox-ve-4-0-released.23780/

Currently there is no plan to extend the support for the 3.x branch, unless there are very good reasons and people are interested in extended support agreements.

 

[ned]

Has anyone tried setting up proxmox on linux kernel 3.x as per this instructions https://ayufan.eu/projects/proxmox-for-upstream/ ?

 

[ned]

ovz kernel 2.6 will be supported till Feb 2018 as per this https://openvz.org/Download/kernel/rhel5/028stab119.6 link....

Also since there is openvz for Jessie I do not see why proxmox should not support openvz alongside lxc. I can see jessie on this link https://download.openvz.org/debian/dists/

 

[elurex]

- ZFS has stability and performance issues
- The 4.2 kernel has a data corruption bug with ZFS: https://github.com/zfsonlinux/zfs/issues/3990

Its very interesting issues that you had with ZFS on linux, this is because I have been using ZFS in production environment for the past 3 yrs and recently I have convert 4 vsphere exsi 6.0+zfs nodes to pve 4.1+zfs nodes without much hassle. And currently plan to add another 2 nodes into current pve-clusters

 

[tom]

ovz kernel 2.6 will be supported till Feb 2018 as per this https://openvz.org/Download/kernel/rhel5/028stab119.6 link....

Also since there is openvz for Jessie I do not see why proxmox should not support openvz alongside lxc. I can see jessie on this link https://download.openvz.org/debian/dists/

There are many reasons, maintaining a distribution in an enterprise support environment is a huge work load. BTW, your link shows a RHEL5 kernel, which is not used in Proxmox Ve 3.x.

There is no OpenVZ for Debian Jessie, this statement is just wrong.

 

[starnetwork]

Hi,
in general, I agree with the Issues raised here by our friends
but also, I Understand Proxmox team problem to continue with OpenVZ on the new release
in my opinion, the solution for that is:
1. keep maintain v3.x with OpenVZ support (As has been done)
2. continue with v4.x without OpenVZ, but announce that this support will be added as soon as Virtuozzo 7 will be in RC release
this will keep the "Heavy" OpenVZ users on 3.4 without hurry, switch to version 4 and be frustrated.

for now, am stay with v3.4 in our clusters and am happy with that decision, but for the long run, as A technology company wants to remain at the forefront of technological innovation, we will move to the Virtuozzo 7 as it's will be ready to Production, as part of Proxmox GUI, or even as part of OpenStack / eucalyptus / Whatever GUI...

in my opinion, Proxmox team just need to announce about Virtuozzo 7 support (when it's will be ready) as part of the roadmap.

kind Regards,

 

[tom]

there is no plan to support virtuozzo 7 - as our framework is more advanced and future-proof and very important, Proxmox VE is fully open source.

if you take a look on the planned feature list of virtuozzo 7, you will see that a lot of features are missing and only available in the closed source "virtuozzo 7 plus" product.

but I do not want to discuss virtuozzo 7 in detail here again, as we are here in a Proxmox Support forum.

 

[starnetwork]

Hi Tom,
not in details, but just check Virtuozzo 7 and 7+ features and it's not look so bad: https://openvz.org/Comparison
anyway, Proxmox is the subject here, and In my opinion, Proxmox team should consider again to support and include virtuozzo 7 as linux containers option as part of the Roadmap.

Regards,

 

[mir]

At the time Virtuozzo 7 is ready for production LXC will have out number it in any way.

 

[chronos]

Switching from OpenVZ to LXC without keeping OpenVZ even just for old kernel 2.6.32 as optional was really surprise for me. But that is common in these days to introduce new product with new unfinished features and drop old favorite features imediatelly without even something like deprecation period. Proxmox VE should support both OpenVZ and LXC in same version according running kernel. This concept was used previously when we had option to use KVM+OpenVZ with old kernel or just KVM with newest kernel. But it is apparent that this would require more work so it is much simple to drop OpenVZ then keep it.

Also I prefer concept of separate file system in spare file for each container rather then quota (boot time recalculation) and files on base file system. This approach is much cleaner but with slightly more overhead and more complicated way to change max. size of CT filesystem.
So for simple server configuration and with kind of manual work LXC works ok. And now with LXC we are more closer to just migration to Ubuntu virtualization technologies like MAAS, LXD, Juju, OpenStack and others. So yeah, LCX is definitely way to go in Linux container virtualization.

 

[tom]

... But that is common in these days to introduce new product with new unfinished features and drop old favorite features imediatelly without even something like deprecation period.

Its just wrong what you state here. Proxmox VE 4.0 with LXC and also Proxmox VE 3.x are supported versions. So nothing is dropped without enough time for our users. Proxmox VE with LXC introduces a lot on new features (e.g. on the storage layer) which were never possible with OpenVZ and yes, with OpenVZ there were some things possible which are not yet in OpenVZ.

Its technically not possible to run OpenVZ on Debian Jessie, but yes, in a perfect world, OpenVZ would not have stopped development, but this is out of our area and you need to complain on the OpenVZ project.

 

[chronos]

....

I didn't know that latest OpenVZ kernel 2.6.32 can't work with newer debian. Previously it was just about switching to older kernel as option and it worked. But as you said it can be much more complicated that I would expect. To need too much work on kernel modification without significant benefits. So my statement was really too superficial. Dropping long used technology as OpenVZ which served us well is too big move for all of us users/customers. It is like if Window Vista/7 would support new nextgen API but dropped Win32 API immediately. Nobody would be happy about it.

Last best useful features since PVE 1.x for me were support for multiple storages in GUI/CLI and long awaited LXC support. So LXC, latest linux kernel, ext4 support, replacement of vzquota with sparse files are step forward for sure. There are just some missing features to name one LXC online migration (also to different storage) necessary for zero downtime during migration. I believe that if this would be easy you already added this feature.

It is reasonable to support both 4.x and 3.x branches in current situation but. Usually new version replaces old one. So in ideal world 4.x branch should support openvz as deprecated technology which will be dropped in future releases so customers have time to try it and convert virtual machines. But if somebody really need to have both LXC and OpenVZ support then one can use PVE 4.x and create KVM with big file system and install PVE 3.x inside to have OpenVZ support inside KVM VM. There will be additional virtualization overhead but it could be good as compromise

 

[e100]

The reality of the situation is that OpenVZ does not run on newer kernels needed for LXC.
Not only that, OpenVZ will NOT be ported to newer kernels a decision of the OpenVZ developers not Proxmox.

OpenVZ is a dead project, only maintained in its current state locked to old kernels with old technology. I'm glad Proxmox decided to keep up moving towards the future instead of keeping us locked to the past.

Eventually you will need to stop using OpenVZ and migrate to something else. Even if you stick with virtuozzo 7, the successor of OpenVZ, you still have to migrate away from OpenVZ. https://openvz.org/Upgrade_script_from_OpenVZ_to_Virtuozzo_7

It is like if Window Vista/7 would support new nextgen API but dropped Win32 API immediately.

It's more like letting you choose to run Windows XP (Proxmox 3.x) or Windows 7 ( Proxmox 4.x)