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