If you want a faster Kolab, read this.

[signaldeveloper at gmail.com]

I am running it in a container because of the density, and the elasticity. So let's say I assign 200 GB of space to the container. Now let's say it fills up. I can go on the hypervisor and adjust and give it more, it adjusts the disk AS IF it started out with that much in the first place while a VM you have to basically add partition after partition. Containers are high density so you can have many on a host, and also it's faster access to the kernel while a VM has a virtualized kernel which in turn increase CPU time. It also has faster access to memory. I did a lot of research on it before I chose the style of virtualization. The biggest thing for me was the space adjustment. It's so easy to adjust, and it's all live. So I can have a 200GB container go to 500GB just like that, no restarting the container even. It's really a beautiful system. 


- Paul

> On Sep 12, 2015, at 7:55 AM, Christian Hügel <christian.huegel at stonebyte.de> wrote:
> 
> Thats a good point. I´m too running kolab in a lxc. Besides what you
> mentioned, is the backup/recovery much simpler and straightforward.
> 
> Christian
> 
>> 
>> I found what I assume was your thread on serverfault :
>> 
>> http://serverfault.com/questions/721654/low-entropy-on-container
>> 
>> Why are you running kolab in a container instead of a VM?   I admit I'm not a 
>> virtualization expert, but isn't the purpose of containers to allow for 
>> multiple user space instances of the same application?  You are never going to 
>> have more than one instance of the kolab server.   I would think you should be 
>> running it in a VM, not a container.
> 
> _______________________________________________
> users mailing list
> users at lists.kolab.org
> https://lists.kolab.org/mailman/listinfo/users