Thank You for Your time and great answers, Steve: >> I want to separate diver services and make NAT to them - so that >> it be more secure in case if one of them will be hacked - I still > > Right so you want a host which has a public IP (or more than one) > and each guest will have private IPs on seperate ranges, such that > they cannot talk to each other?
> That sounds like a good setup. Actually, I did not think on different IP ranges... :) I just thought to set them on different IPs withing the same range... What will I get having different ranges? > If you're going to assume that a machine will be hacked, and then > assume a kernel bug will come into play on one of the guests that > strongly suggests you want to ensure that they aren't sharing a > single kernel - ie. Don't choose vserver. Logically, it is correct. But I guess practically, it will never happen. Can I ask here, if here are the people who had experienced kernel bug security that from their guest (vserver) crack affected home OS? >> I know that KVM offers much less respond comparing w/ >> vserver. How about Xen? Can I turn the guests on/off on the fly? > > Both Xen and KVM will let you start/stop guests independently of > each other. > KVM works as a process, so you just stop it. I'm speaking about networked guests - will their interfaces will not be mixed up? Or will I ever have the same ifaces names for the guests? > Probably not worth the overhead I'd have thought; historically the > common squid proxy has had a good security record. Ok, web/email/ftp remain. > Best is still going to be a personal preference. I'd choose KVM, > then Xen, then vmware then vserver. Well. With KVM I guess will be a problem w/ a output device - as it will run in console though... >> Why nobody says about packaging problem in Debian, net >> interfaces at guests turning off?! > > If you use something like Xen/vmware/kvm you'd not concern yourself > with the interfaces. Instead you'd shutdown a guest if you wanted it > to be unreachable and disabled. Here I was speaking about vserver. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
