Chris's Wiki :: blog/sysadmin/OurVirtualizationUse Commentshttps://utcc.utoronto.ca/~cks/space/blog/sysadmin/OurVirtualizationUse?atomcommentsDWiki2010-11-04T10:44:21ZRecent comments in Chris's Wiki :: blog/sysadmin/OurVirtualizationUse.From 129.102.5.10 on /blog/sysadmin/OurVirtualizationUsetag:CSpace:blog/sysadmin/OurVirtualizationUse:336733ac0b84739550cfa7b5d5375d62d3dba10cFrom 129.102.5.10<div class="wikitext"><p>As far as I can tell, the environment I work in is quite similar in size to yours. We only run a few Xen VMs but we have lots of containers (currently <a href="http://www.linux-vserver.org/">linux-vserver</a>, considering switching to <a href="http://lxc.sf.net/">lxc</a> when we find it mature enough).</p>
<p>We have lots of small web sites (for teams, projects, conferences, intranet apps...) and it has proved easier to manage each one in its own container rather than as Apache vhosts on the same server. Mostly, we can tweak the configuration of one server with confidence we won't end up impacting anything else.</p>
<p>We also use containers for almost everything else except big, high-performance servers (a couple of high-traffic web sites) and file servers (because of limitations in linux-vserver, which can't run kernel-mode NFS server). To date we have not had any real problems with this. It just required some tuning, for instance ensuring puppet runs don't start at the same time on all containers.</p>
<p>It has downsides though; we still have a few RHL 7.x-based containers with PHP3 apps that we can't easily upgrade. This is not really related to virtualization, but we don't have to upgrade OSes as old hardware dies anymore. I'm still not sure of the solution to this problem: virtualization allows us to run more services, but I'm not sure we have the manpower to maintain them in the long term.</p>
</div>2010-11-04T10:44:21Z