With FreeBSD jails, there's only one kernel. In UML, the guest has its own kernel. OpenVZ looks to have a single shared kernel. <br><br>
<div class="gmail_quote">On Tue, Jun 2, 2009 at 1:46 PM, David Snider <span dir="ltr"><<a href="mailto:david@davidsnider.net">david@davidsnider.net</a>></span> wrote:<br>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">Sorry, by sandboxing I mean being able to apply a kernel patch on one<br>server without applying it to all servers. Can you do that?<br>
<div>
<div></div>
<div class="h5"><br>On Tue, 2 Jun 2009 13:42:41 -0700, Daniel Margolis <<a href="mailto:dan@af0.net">dan@af0.net</a>> wrote:<br>> It doesn't eliminate sandboxing. The sandboxing is just done at a<br>different<br>
> level (i.e., the kernel enforces sandboxing at the syscall level, vs.<br>> having<br>> multiple kernels and having the sandboxing enforced in the hypervisor).<br>> Jails are an effective security mechanism.<br>
><br>> That said, I think Xen provides a more desirable abstraction layer, but<br>> I'm<br>> not an expert at this.<br>> On Tue, Jun 2, 2009 at 11:28 AM, David Snider <<a href="mailto:david@davidsnider.net">david@davidsnider.net</a>><br>
> wrote:<br>><br>>> It looks like OpenVZ has managed to make this not as much of a problem.<br>>> This is still a problem with FreeBSD jails though. It does have<br>> per-server<br>>> CPU\Memory\IO quotas. You still have the disadvantage of having all<br>
> servers<br>>> run the exact same OS w\ Kernel patch which seems to eliminate<br>> sandboxing.<br>>><br>>> On Tue, 02 Jun 2009 13:42:23 -0400, Adam Chlipala <<a href="mailto:adamc@hcoop.net">adamc@hcoop.net</a>><br>
> wrote:<br>>> > David Snider wrote:<br>>> >> Operating System Level Virtualization: (Ex. OpenVZ, FreeBSD Jails,<br>>> > Solaris<br>>> >> Containers) The name "jail" that FreeBSD makes it pretty clear what<br>
> this<br>>> >> does. Each server shares an underlying operating system but it is<br>>> >> partitioned in such a way to make it look and feel like it is on it's<br>>> > own<br>>> >> server. The advantage to this is that you don't have to duplicate a<br>
> lot<br>>> > of<br>>> >> commonly shared resources. The disadvantage is that it is difficult<br>> to<br>>> >> control individual utilization of each server. (I.E If your web<br>> server<br>
>> > is<br>>> >> getting hammered your mail server's performance suffers too.)<br>>> >><br>>> ><br>>> > This last disadvantage, if accurate, kills the attractiveness of the<br>
>> > approach for me. docelic, do you agree that OpenVZ has this problem?<br>>> > If so, why do you think OpenVZ would still be a good choice for us?<br>>> ><br>>> > _______________________________________________<br>
>> > HCoop-Discuss mailing list<br>>> > <a href="mailto:HCoop-Discuss@lists.hcoop.net">HCoop-Discuss@lists.hcoop.net</a><br>>> > <a href="https://lists.hcoop.net/listinfo/hcoop-discuss" target="_blank">https://lists.hcoop.net/listinfo/hcoop-discuss</a><br>
>><br>>><br>>> _______________________________________________<br>>> HCoop-Discuss mailing list<br>>> <a href="mailto:HCoop-Discuss@lists.hcoop.net">HCoop-Discuss@lists.hcoop.net</a><br>>> <a href="https://lists.hcoop.net/listinfo/hcoop-discuss" target="_blank">https://lists.hcoop.net/listinfo/hcoop-discuss</a><br>
>><br><br><br>_______________________________________________<br>HCoop-Discuss mailing list<br><a href="mailto:HCoop-Discuss@lists.hcoop.net">HCoop-Discuss@lists.hcoop.net</a><br><a href="https://lists.hcoop.net/listinfo/hcoop-discuss" target="_blank">https://lists.hcoop.net/listinfo/hcoop-discuss</a><br>
</div></div></blockquote></div><br>