| |
|
 |
|
 |
|
|
|
| |
|
|
xen-users
RE: [Xen-users] Xen + VServer
> Dominique Rousseau Wrote
> Sent: Friday, 19 August 2005 9:21 p.m.
> Le Fri, Aug 19, 2005 at 11:12:25AM +0200, Dirk H. Schulz
> [dirk.schulz@xxxxxxxxxxxxx] a écrit:
> > >That's great to hear! Xen and Vserver are IMHO highly complimentary
> > >and it'd be great to be able to use them together. The VServer patch
> > >(last time I checked) was very nicely arch independent but I think
> > >it's quite a long time since anybody has tried to run it on Xen - well
done!
> > >
> > What advantage does Vserver have compared to Xen ??? why should it
> > make sense to use both?
I tend to think of Vservers as basically a "super" chroot on steroids. AFAIK
the standard linux chroot mechanism can be broken out of using the double
chdir(?) method (among others). However the Vserver patch effectively
provide you with very well isolated environments with practically no
overhead (mostly owing to the fact that a) all Vservers allocate memory from
the server as needed, rather than being allocated a "chunk" at startup and
b) on there is only one copy of the kernel running).
> Vserver makes it possible to share on-disk and in-memory the
> footprint of a given program between separate contexts.
> The kernel being shared, if you make your different contexts
> with hardlinks "copies" of the files, you can have the same
> code of libc, damemons, ... loaded only once in memory, only
> the "data" part of memory allocated is charged for each
> virtual server.
> So, you get virtual servers that are very efficient on memory
> and disk usage.
Yep the higher memory usage is definitely one of the most noticable
differences when you convert from Vservers to Xen.
i.e. Instead of lots and lots of Vservers co-existing quite nicely and
sharing 1GB of RAM, you suddenly find yourself adding more memory to the
server! But RAM is cheap these days so it's not really an issue.
> On the other hand, you get less control on the
> allocation/limitation of ressources used (memory, cpu, ...)
> and since you have all contexts running in the same kernel a
> potential security hole ine the kernel would be open to every
> of the virtual servers.
The security aspect is my major motivation for looking at moving from
Vservers to Xen. I imagine that the isolation provided by *BSD's Jails and
Solaris 10 Zones/Containers would fare equally badly from kernel level
security holes.
Whereas you would hope that the extra layers of isolation used by Xen would
protect you better! Not that people won't try to find exploits for Xen once
it gets widely adopted!
I see that OpenSolaris has been made to boot as a Xen guest by Sun's
developers. That opens the possiblity of people mixing the two approaches
(Vserver-like functionality + Xen) as well! Hmm, if Sun ever gets its Janus
project (linux emulation) going you could do something REALLY twisted like
run your Linux apps in separate secure OpenSolaris Zones inside a Xen Guest!
/shiver
Anyway... Xen is cool. Vservers are cool. Vservers + Xen would also be cool
but in reality I see Xen being mainlined into the kernel shortly and
supported WAY more widely so I'm looking at switching our Production servers
from Vservers to Xen. Mostly for ease of maintainence reasons. We run SuSE
Enterprise Linux 9 and they've going to include Xen in their next release
(ETA 2006Q1) so rather than mucking about with ANY custom kernel patches,
etc I will be able to update my Xen server OS's and guest OS's by simply
connecting to their update server!
Less effort to stay patched = Heaven (at least in my books!!!)
Cheers
Mike
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
|
|
| |
|
Home