>>from the tests:
>> "For benchs inside real 'guest' nodes (OpenVZ/VServer) you should
>> take into account that the FS tested is not the 'host' node one's."
>>at least for Linux-VServer it should not be hard to avoid the
>>chroot/filesystem namespace part and have it run on the host fs.
>>a bind mount into the guest might do the trick too, if you need
>>help to accomplish that, just let me know ...
> For the moment I just use the chcontext command to get rid of filesystem
> part. But even if the tested filesystem is not the host filesystem, I
> just keep in mind that all applications running inside a 'guest' will
> use _this_ filesystem and not the host one.
>>From what I understand about VServer, it looks flexible enougth to let
> us test different 'virtualisation' parts. A 'guest' looks like a stack
> of different 'virtualisation' layers (chcontext + ipv4root + chroot).
> But it's not the case for all solutions.
For OpenVZ it is also possible to test different subsytems separately (virtualization/isolation,
resource management, disk quota, CPU scheduler).
I would notice also, that in OpenVZ all these features are ON by default.
So I probably miss something, but why we test other technologies in modes when not
all the features are ON? in this case we compare not the real overhead,
but the one minimized for this concrete benchmark. It's just like comparing with
Xen Domain0 which doesn't have any overhead, but not because it is a good technology, but
rather because it doesn't do anything valuable.
BTW, comparing with Xen would be interesting as well. Just to show the difference.
Vserver mailing list
Received on Tue Jul 4 15:34:23 2006