[Users] Re: lvm and openvz

[David Brown]

On 29/03/2012 14:16, Kir Kolyshkin wrote:
> On 03/29/2012 01:09 PM, David Brown wrote:
>> On 29/03/2012 11:04, Kir Kolyshkin wrote:
>>> On 03/28/2012 11:49 AM, David Brown wrote:
>>>> I /really/ wish the openvz developers would move beyond kernel
>>>> 2.6.32 - kernal 2.6.33 introduced snapshot merging to LVM which
>>>> would play wonderfully with this setup.
>>> I'm not sure why people think that RHEL6 kernel is pure 2.6.32. It is
>>> definitely not!
>>>
>>> For snapshot merging, I am not an expert here but googling for 'rhel6
>>> lvm snapshot merging' gave me this:
>>>
>>> http://www.linuxtopia.org/online_books/rhel6/rhel_6_lvm_admin/rhel_6_lvm_snapshot_merge.html
>>>
>>>
>>>
>>>
>>> and this:
>>>
>>> https://access.redhat.com/knowledge/solutions/58510
>>>
>>> Both articles suggest RHEL6 kernel supports LVM snapshot merging, and
>>> so should OpenVZ RHEL6-based kernel.
>>>
>>> PS If you are using non-rhel6 openvz kernel, it's definitely time to
>>> switch, and lots of reasons to do that besides LVM snapshot merging.
>>> Notable things are vswap, ploop, stability...
>>>
>>> Kir.
>> I am using a non-rhel6 openvz kernel because I don't use RHEL - I use
>> Debian on my servers. Are you suggesting that I should specifically use
>> the RHEL6 openvz kernel even though I use Debian? That's something I
>> haven't thought of trying, but if it is the recommendation of the OpenVZ
>> developers, then I will give it a shot.
>
> Yes please. This is the official recommendation, and many people already
> do this.
>
> We choose RHEL6 kernel as a base not because we are Red Hat fans or we
> plan to support
> RHEL distribution only. The reason is RHEL6 is truly a good,
> well-maintained, stable kernel with
> lots of Red Hat developer and QA resources invested into it. That is why
> we use it as a base,
> but that doesn't mean we only have RHEL in mind.
>
> Now to the practical point: we have modified post-install scripts in
> kernel rpm to be compatible
> with Debian as well, so all you need to do is to convert kernel rpm to
> deb using alien. Some
> info is provided at
> http://wiki.openvz.org/Install_kernel_from_RPM_on_Debian_6.0
>

Thank you for that pointer.  I will read through the information, and 
try it out.  I don't know when I will get the chance on my main servers 
- playing with the kernel on the host machine means taking all the guest 
systems off-line for a little while - but I'll find a spare system 
somewhere to test it.

>> More generally, I would hope that one day OpenVZ will change over to
>> following the current kernel (or perhaps the current long-term support
>> kernels) - there has been a lot of development since 2.6.32, not all of
>> which gets backported by Red Hat.
>
> Same as we did before - we do have such plans, although not immediate.
>
>> I'd expect that a lot of OpenVZ code
>> can be merged with or replaced by the container support in later
>> kernels.
>
> That is right, we are actively pushing our stuff upstream, and then we
> are rebasing our code to what is available in upstream, gradually
> reducing the size of openvz patchset.
>
> For example, if you will take a look at linux kernel git repo, you will
> see more than about 150 patches from OpenVZ developers were merged this
> year. Actually, here's a command to do that:
>
> $ git log -E --author='@parallels.com|@openvz.org' --since=2012-01-01 |
> grep -c ^commit
>
> Most of the recent patches are CRUI and NFS virtualization.
>
>> I also think that if OpenVZ doesn't catch up, then people will
>> migrate to other solutions such as Linux VServer or LXC (I know I
>> considered it for the last server I configured).
>
> Linux-VServer is totally obsolete from my POV, because they are not
> interested in pushing the stuff upstream. Of course they benefit from
> the code that is appearing in mainline (and since a good proportion of
> that code comes from OpenVZ developers, it is true to say that
> Linux-VServer benefits from OpenVZ).
>

OK.  Linux VServer struck me as being more limited, and less active than 
OpenVZ when I first looked at virtualisation solutions several years ago 
- from your comments, it looks like I made the right decision.

> As for the LXC, please do not forget that LXC is not something that is
> opposed to OpenVZ, but rather something that is complementary. I mean,
> having said that the good proportion of containers code in mainline
> comes from OpenVZ, it might be true to say that we are probably the
> biggest contributor to the LXC (kernel code).
>

Yes, I understand that a lot of LXC is based on OpenVZ ideas and code 
moved into the mainline.  To my uninformed mind, it looks like LXC has 
many of the basic features of OpenVZ, while OpenVZ provides more 
detailed control of the virtual machines and more useful tools and 
utilities for creating and controlling the guests.

The ideal situation from my viewpoint would be to continue the upstream 
pushes until all the kernel code for OpenVZ is in the mainline.  That 
would be the most flexible for users, giving them OpenVZ with whatever 
kernel they wanted.  But I guess it's a two-edged sword for the openvz 
developers - it would mean less effort supporting new kernels, but maybe 
more work since the kernel changes all the time, and more work for 
support and testing.  I don't know if such a merge would be possible, 
practical, or desirable (from your viewpoint or from the mainline 
viewpoint).

>> Of course, I fully appreciate that something like that takes a lot of
>> effort, and that means time, money, people to do the work, testing,
>> etc., etc. But one can still hope!
>
> Our current approach is to use RHEL kernels as a base, and push as much
> stuff to upstream as we can. So far it's working.

I'll give the RHEL kernel a try as soon as I get the chance.

Thank you very much for your explanations and advice.  (And of course, 
thank you for your work on openvz - it is a fantastic system and has 
made my job much easier.)

Best regards,

David