> If I have 4 virtual machines running on the same box simultaneously I > need 4 times the resources calculated on each virtual machine running > on its own box. *ish*... I have a small box here running as the office server which has 10-20 vserver instances on because instead of the old server which had Apache + Mysql + Samba, etc in the new setup I have a vserver doing samba, another doing apache, another doing mysql, etc. This is running idle on a quad Intel thing with 4G ram (couple hundred quid or so) The nice thing is that now if I want to shift mysql to a new machine I just migrate the vserver instance across and change the IP. If I want a new website then I can clone the apache instance and have both sites running physically separated from each other. etc > It sounds wonderful hundreds of guests running on one powerful PC. > I'll run them as daemons. > Exactly - so it's so lightweight you can almost run every service in it's own vserver. This is great for testing upgrades because you can clone the vserver, run the upgrade, see if anything broke and then upgrade the live instance! Cool! > I have following 2 thoughts to consider. > > 1) > If the PC is down because of hardware failure then hundreds of server > will be down. It needs a well established replication and load > balancing. > Sure - But equally it's only one physical bit of hardware to maintain now - keep an identical spare running with some way to clone the hard disks and you already have a pretty robust installation which is likely to be down less than 100 individual machines There are some hot replication strategies to keep a duplicate set of hardware going, eg drbd , or a SAN. Alternatively you can accept some lost data and use async strategies such as a snapshot every XX minutes (use LVM to assist with this). One tip is that I keep the OS separate from the vserver data (eg apache OS instance separate from /var/www data). This makes it easy to clone the data on one schedule and the OS on another schedule I can't stress how simple vservers make backups! You have one small 100-200MB or so host OS which is generic and clean, then you have a bunch of vserver instances which are basically directories that you can just backup using tar. Incredibly easy to shuffle them around, boot them on a new physical server, clone them to test config changes, etc! > 2) > It needs a range of fixed/public IP address serving hundreds of server > on the Virtual box. I'm investing whether there will be a way to > overcome this difficulty. Each server has its own hostname and domain. > If hundreds of domain pointing to one fixed/public IP address is there > a device able routing them to respective server. I have been posting > this question on Vyatta forum without response. Are there any > suggestions? TIA > Well there is no problem with lots of IP addresses - vserver handles that for you. In the office here I just pick an unused address and boot the vserver using that - the rest of the subnet can see it fine If your problem is RIPE not wanting to waste loads of IPs on you then use some form of NAT to hide machines behind fewer IPs A common strategy is to put ALL vservers on a private 10.x.y.z subnet and then use the host to apply NAT to expose only the exact ports and services that you want to see on the internet. This also makes for an extremely secure setup Good luck Ed W