Re: OpenVZ upgrade path?
On Tue, 2010-10-19 at 02:27 -0400, Ivan Jager wrote:
> Hi,
>
> I'm not sure if this is the best place to ask this, but I am
> wondering what the best plan is to upgrade my openvz system.
>
> A short summary of how I got here follows: I installed etch when
> that was the stable release, and openvz was supported. When lenny
> was released, the release notes claimed better openvz support,
> but in fact openvz support had been silently dropped. So, I still
> feel somewhat betrayed, and still have lenny system running on an
> etch kernel with openvz on it. With the upcoming release of
> squeeze, etch will go from being oldstable to being ancient and
> completely unsupported, so I don't want to continue running an
> etch kernel.
>
> So, I suppose my options are:
> 1. Take up maintaining openvz sparc support. (I wwould consider
> this if there are other users who would also contribute, but if
> I'm the only one it seems like a waste of time. I did have to
> patch the patches so I have a tiny bit of experience.)
> 2. Switch to vservers and hope not to get dropped again.
> 3. Switch to FreeBSD jails and be sad that I'm not running
> Debian but happy I have ZFS.
> 4. Switch to OpenSlolaris containers and be even more sad I'm not
> running Debian.
> 5. Start a Debian/kFreeBSD/sparc port... (Seems like it would be
> more work than 1, although it may have more users too.)
> 6. Use some other virtualization thing I haven't heard of on
> Debian. (lxc seems like it should be platform independent, but
> seems to be mysteriously missing a sparc package)
>
> So, any advice on which way to go? What are other people using?
> Should I be asking or CCing somewhere else?
I have used vserver on SPARC in a production system. It worked and the
developers seemed keen on supporting x86 architecture. Note that many
vserver users use the project's packages for kernel and tools as they
track vserver development in a more timely fashion. Thus having vserver
kernels included in the main Debian repositories is less of an issue
than you'd imagine.
Longer term, if you go with a technology that is in squeeze then you
should have at least a handful of years before you are in a similar
situation - even in the worst case. When the future has been discussed
on the vserver mailing list there was a suggestion that once cgroups
were capable of everything required, vserver would slowly become a set
of userspace tools. There is no definate timeline for this but the
amount of code required in the kernel patches does seem to be
decreasing.
I would have thought vserver or lxc would have be the best effort vs
future security trade off.
Good luck and let us know what you pick.
Cheers,
- Martin
Reply to: