A year ago I moved from OpenVZ to Vserver - it was all good - no
regrets whatsoever. Somehow I found memory management easier for
VServer. It could be just my perception but to me Vserver is easier to
configure and use. Debian make VServer installation trivial. I have
more than 20 VMs for about a year now - all working flawlessly.
One of my problems with OpenVZ was understanding of how its memory
limits work. it is indeed a problem related to lack of experience but
number of times services inside OpenVZ VM were failing to allocate
required amount of RAM so a tweaked some parameter until it happen,
then I had to tweak another setting and so on and so on. After week of
struggling I had no confidence regarding settings I used and I had to
read a lot to get a detailed understanding of all those parameters.
Obviously defaults was not good.
Then I had a chat with the guy from another company who tried to adopt
OpenVZ for large Java-based application spanned across a dozen VMs.
They gave up after running into problems with Java memory management
in OpenVZ so they end up using KVM for a project. (Personally I do
believe they just hadn't enough patience to chase all the problems).
When I decided to try VServer - I already had 5 or 6 OpenVZ VMs.
Using VServer was surprisingly easy (perhaps only documentation
lacking some up-to-date examples) so soon enough I found myself
virtualizing physical servers to VServer and creating more VMs mostly
Debian or CentOS based.
Migration to VServer was trivial for me - for a year I had no problems
with memory allocations in any of more than 20 VServer VMs, many of
which have Java application servers running. Defaults are not
restrictive in VServer so it is easier to set up a VM and restrict it
later upon finalizing its configuration whey memory usage already
known.
I still have OpenVZ-based VPS which works very well, however I didn't
configure it myself so my experience with OpenVZ is limited. I just
like VServer more, particularly the way we do things in VServer.
To me administration efforts less for VServer but you may argue that
this is a matter of experience.
Regards,
Onlyjob.
On 10 December 2010 07:11, John A. Sullivan III
<jsullivan@opensourcedevel.com> wrote:
> On Thu, 2010-12-09 at 14:59 -0500, John A. Sullivan III wrote:
>> On Thu, 2010-12-09 at 19:31 +0000, Gordan Bobic wrote:
>> > On 12/09/2010 06:14 PM, mourad.alia@orange-ftgroup.com wrote:
>> > > Dear VServers,
>> > >
>> > > As introduced in my previsous post, wa are about using VServer to emaulate P2P like VoIP peers. This is used for sacalability and performance testing of our VoIP application.
>> > >
>> > > Here are our needs :
>> > >
>> > > A) We want to have a maximum of VMs per server. Our server are 24 hyperthreded machine with 6 physical network interfaces :
>> > > IP Network Server NSN2U (Ballenger-NH)
>> > > Single 600W AC PSU
>> > > Memory 24 GB
>> > > CPU Dual Xeon E5645
>> > > SATA HDD 500GB
>> > > Ethernet I/O Module (four Gigabit rear ports)
>> > >
>> > > B) Each VM hosts a JVM which run one or many instances of our applications.
>> > >
>> > > C) The applications (VoIP peers) communicate basically through multicast.
>> > >
>> > > D) Each n VMs (m applications) will use one given Eth physical interface to distribute correctly the network traffic.
>> > >
>> > > Currently, there is a hot discussion in my departement on OpenVZ vs VServer : " VServer is more tooled, simpler, virtualise the network, supports hot VM migration".
>> >
>> > AFAIK, vserver doesn't support live/hot migration of VMs. Do you really
>> > need it, though? Startup time on my VMs (based on RHEL6) is on the order
>> > of 5s for the complete system including services (mysql, apache, etc.).
>> >
>> > > What do you think about this versus ?
>> > >
>> > > Any particular advise towards my use case ?
>> >
>> > The absolute killer feature of vservers for me is hashify. In a
>> > nutshell, it adds a feature to provide copy-on-write hard-links, which
>> > means that once you have hashified your guests, all the DLLs have the
>> > same inode number and mmap into the same memory. That means that if you
>> > have 100 guests running the same base setup, you don't have 100
>> > instances of glibc wasting RAM, but only one. On top of that, since
>> > identical files are hard-linked, it makes the cache efficiency much
>> > greater. This means you can overbook your memory way, way more than you
>> > otherwise could and gain some performance at the same time.
>> >
>> > Gordan
>> I concur exactly. We debated heavily between the two. OpenVZ did seem
>> to have more commercial refinement and we were concerned at the small
>> developer pool for VServer. The two things that won us over to vserver
>> were that it is truly and fully open source rather than an excuse to
>> upsell into a commercial version and hashify as Gordan pointed out -
>> John
>>
> I should mention that I believe hashify is available for OpenVZ but as a
> commercial add-on - John
>
>
Received on Fri Dec 10 00:37:39 2010