Re: Which virtualization is the best for Debian?
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.
Reply to: