On Wed, Jan 12, 2011 at 16:11, onlyjob <only...@gmail.com> wrote:
> Regarding virtual loopback it seems that in standard builds of
> VServer-enabled 2.6.32 kernels available from Debian repositories this
> problem do not exist. I'm not too sure though but I don't remember
> experiencing it.
It was definitely there is the stable releases of Debian before Lenny,
when they presumably decided the experimental VServer patches were
sufficiently stable or whatever. Anyway, nice they have solved it. :)
> Besides it is possible to change localhost address in /etc/hosts
...but not to remap 127.0.0.1, or easily create another interface
named lo, or bind to 0.0.0.0, all of which a surprisingly large number
of packages assumed would always be present and operational in Debian
(and, for which, Ubuntu is generally worse. :)
> Absence of network virtualization in VServer is deliberate and for a
> good reason.
I can't find much useful information on this on their website about
why, but wikipedia claims that this is based on isolation rather than
virtualization to "avoid overhead", which seems relatively bogus to me
given the in-kernel network namespace support is pretty much directly
"isolation" based.
Do you know of a good source of information on the VServer side? I am
curious to know what the technical differences are (and if that is,
indeed, the correct argument from their side) so I can better
understand what the trade-off here might atually be.
[...]
> I don't see how kernel support relevant to RHEL upstream - a year ago
> there was no OpenVZ support for 2.6.32 whatsoever. And frankly this
> was one of the reasons I've chosen VServer for a machine hosting
> around 20 VMs.
...er, OK. So, the use of the RHEL kernel is relevant because RedHat
invest substantially in stabilizing the kernel and backporting newer
drivers to it. This means that unlike the Linus 2.6.18 kernel (for
example) you can get support for modern Intel NICs and other
controllers, so it doesn't suffer nearly the trouble running on modern
hardware that the version number might suggest.
Given that, in many cases, security and driver support are the primary
motivators for using a newer kernel this can, indeed, help with
(though not universally solve) the issue that the OpenVZ kernel
version lags the upstream kernel version available in distributions.
> Obviously 2.6.32 have a number of important features notably KSM which
> makes a lot of sense for virtual host and also EXT4.
Er, as of 2.6.36 the KSM feature still scans only memory specifically
registered to it by the application. So far as I can see the VServer
patches don't do anything special to mark memory as possible to share
for code running in them, and pretty much nothing other than KVM/qemu
does out in user-space, so I wouldn't have thought that KSM made much
difference.
As to ext4 ... *shrug* I think that is a religious debate that would
distract from the real discussion at hand; I regard anyone running
ext4 on a production system as vaguely strange since it is still so
young and experimental compared to more tested code but, obviously,
you don't share that reluctance to move. :)
[...]
> "*more performant": I agree with you that difference in network
> performance between VServer and OpenVZ is not terribly different.
> Perhaps it can be manifested with some sort of artificial testing.
> However here I was quoting Herbert Poetzl (VServer developer).
> While performance difference is not too big there is another thing
> which I believe is equally important - simplicity. If the same result
> can be achieved easier, without even little virtualization overhead it
> is certainly better, more maintainable, probably has less bugs etc.
> Simplicity matters.
*nod* Part of my view on the subject is that VServer made some bad
technical decisions that kept their kernel code simple in exchange for
adding a huge amount of complexity to every container; part of that
(lo virtualization) they have obviously decided can be corrected these
days.
So, I agree, but I think that whole system complexity is a much more
important metric than just kernel complexity. (OTOH, I also think
that a bunch of the OpenVZ bits – like UBC – are disasters of
complexity and I am very glad they will not make it in to the mainline
kernel. :)
Anyway, thanks for sharing your experiences and discussing this. I
like to talk through these issues so I can better understand where
things stand – and I already learned some useful stuff I didn't know
from you. :)
Regards,
Daniel
--
✉ Daniel Pittman <dan...@rimspace.net>
⌨ dan...@rimspace.net (XMPP)
☎ +1 503 893 2285
♻ made with 100 percent post-consumer electrons
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
