Hi all, I used to run VServer in the past and recently gave Xen a try. I pretty much like both of these technologies - each of them has some advantages that the other one can''t offer. I appreciate the real independence of Xen domains but the memory overhead of running a kernel for each domain and the need to partition the memory space may become a limitation. On the other hand in VServer the contexts run on top of the same kernel and may share the available memory which may come handy in some deployments. So I decided to merge both patches and surprisingly enough - it works! I don''t now (yet) how stable it is but the kernel booted as domU and a guest vserver context was created, some prcosses are running inside and everything looks just fine. Versions used: * Linux kernel 2.6.11 * Xen 2.0-testing from yesterday * VServer 2.0-rc4 (last version for 2.6.11) Apply the attached patch on top of these. Xen userspace is 2.0-testing as well, util-vserver 0.30.204 (debian build), running on Debian Sarge. My configuration was x86, statically compiled without modules, domU with no physdev access, 3G/1G memspace split on x86, no preempt, no selinux. What else? This is the very first shot, I don''t guarantee that it is stable, secure, etc, but if you''re brave enough give it a try ;-) Michal Ludvig -- * Personal homepage: http://www.logix.cz/michal _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Michal, 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! It''d be good if a reference to this patch could be added to the Xen wiki at http://wiki.xensource.com so that other people know where to find it. Can anybody tell me if Vserver is aiming for inclusion in the mainline at any stage? I''d love to see it there and for it to coexist well with Xen. Cheers, Mark On Wednesday 03 August 2005 11:20, Michal Ludvig wrote:> Hi all, > > I used to run VServer in the past and recently gave Xen a try. I pretty > much like both of these technologies - each of them has some advantages > that the other one can''t offer. I appreciate the real independence of > Xen domains but the memory overhead of running a kernel for each domain > and the need to partition the memory space may become a limitation. On > the other hand in VServer the contexts run on top of the same kernel and > may share the available memory which may come handy in some deployments. > > So I decided to merge both patches and surprisingly enough - it works! I > don''t now (yet) how stable it is but the kernel booted as domU and a > guest vserver context was created, some prcosses are running inside and > everything looks just fine. > > Versions used: > * Linux kernel 2.6.11 > * Xen 2.0-testing from yesterday > * VServer 2.0-rc4 (last version for 2.6.11) > > Apply the attached patch on top of these. > > Xen userspace is 2.0-testing as well, util-vserver 0.30.204 (debian > build), running on Debian Sarge. > > My configuration was x86, statically compiled without modules, domU with > no physdev access, 3G/1G memspace split on x86, no preempt, no selinux. > What else? > > This is the very first shot, I don''t guarantee that it is stable, > secure, etc, but if you''re brave enough give it a try ;-) > > Michal Ludvig > -- > * Personal homepage: http://www.logix.cz/michal_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Thu, Aug 04, 2005 at 04:01:29PM +0100, Mark Williamson wrote:> Michal, > > 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!yes, xen is just _another_ arch and once it will be in mainline (IIRC they are working on it), we will of course support it out of the box (as we do for UML now)> It''d be good if a reference to this patch could be added to the Xen > wiki at http://wiki.xensource.com so that other people know where to > find it.well, feel free to add links to linux-vserver or to patches there ... we have a link to Xen (not the wiki) on our wiki since ... hmm, well for a very long time now> Can anybody tell me if Vserver is aiming for inclusion in the mainline > at any stage? I''d love to see it there and for it to coexist well with > Xen.well, we all would love to see linux-vserver in mainline, but I guess the disadvantages of trying to get it into mainline (less performant code, only partial implementation, two branches to maintain) would easily outweight the advantages ... HTH, Herbert> Cheers, > Mark > > On Wednesday 03 August 2005 11:20, Michal Ludvig wrote: > > Hi all, > > > > I used to run VServer in the past and recently gave Xen a try. I pretty > > much like both of these technologies - each of them has some advantages > > that the other one can''t offer. I appreciate the real independence of > > Xen domains but the memory overhead of running a kernel for each domain > > and the need to partition the memory space may become a limitation. On > > the other hand in VServer the contexts run on top of the same kernel and > > may share the available memory which may come handy in some deployments. > > > > So I decided to merge both patches and surprisingly enough - it works! I > > don''t now (yet) how stable it is but the kernel booted as domU and a > > guest vserver context was created, some prcosses are running inside and > > everything looks just fine. > > > > Versions used: > > * Linux kernel 2.6.11 > > * Xen 2.0-testing from yesterday > > * VServer 2.0-rc4 (last version for 2.6.11) > > > > Apply the attached patch on top of these. > > > > Xen userspace is 2.0-testing as well, util-vserver 0.30.204 (debian > > build), running on Debian Sarge. > > > > My configuration was x86, statically compiled without modules, domU with > > no physdev access, 3G/1G memspace split on x86, no preempt, no selinux. > > What else? > > > > This is the very first shot, I don''t guarantee that it is stable, > > secure, etc, but if you''re brave enough give it a try ;-) > > > > Michal Ludvig > > -- > > * Personal homepage: http://www.logix.cz/michal > _______________________________________________ > Vserver mailing list > Vserver@list.linux-vserver.org > http://list.linux-vserver.org/mailman/listinfo/vserver_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
> yes, xen is just _another_ arch and once it will be in > mainline (IIRC they are working on it), we will of course > support it out of the box (as we do for UML now)Yep, they''re working on it now. It''s in the Real Soon Now category, just needs some restructuring. Of possible interest to you is that Xen will be a sub arch of i386 rather than a separate architecture when it''s properly merged. IIRC only really arch dep stuff in Vserver is the addition of the syscalls - that code should all be common to Xen and i386 so you probably won''t have to do much (anything) to support it.> > It''d be good if a reference to this patch could be added to the Xen > > wiki at http://wiki.xensource.com so that other people know where to > > find it. > > well, feel free to add links to linux-vserver or to > patches there ... we have a link to Xen (not the wiki) > on our wiki since ... hmm, well for a very long time nowI saw it a while back. If Michal is agreeable (i.e. if he''s reasonably happy with the patch) I''ll make sure it goes onto the Xen wiki so that people can ue the two together.> well, we all would love to see linux-vserver in mainline, > but I guess the disadvantages of trying to get it into > mainline (less performant code, only partial implementation, > two branches to maintain) would easily outweight the > advantages ...Ack. In the meantime I''ll continue hoping that one day we''ll see the mainline incorporate vserver in a way that makes everyone happy :-) Cheers, Mark _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On 8/5/05, Mark Williamson <mark.williamson@cl.cam.ac.uk> wrote:> > yes, xen is just _another_ arch and once it will be in > > mainline (IIRC they are working on it), we will of course > > support it out of the box (as we do for UML now) > > Yep, they''re working on it now. It''s in the Real Soon Now category, just > needs some restructuring. Of possible interest to you is that Xen will be a > sub arch of i386 rather than a separate architecture when it''s properly > merged. IIRC only really arch dep stuff in Vserver is the addition of the > syscalls - that code should all be common to Xen and i386 so you probably > won''t have to do much (anything) to support it. > > > > It''d be good if a reference to this patch could be added to the Xen > > > wiki at http://wiki.xensource.com so that other people know where to > > > find it. > > > > well, feel free to add links to linux-vserver or to > > patches there ... we have a link to Xen (not the wiki) > > on our wiki since ... hmm, well for a very long time now > > I saw it a while back. If Michal is agreeable (i.e. if he''s reasonably happy > with the patch) I''ll make sure it goes onto the Xen wiki so that people can > ue the two together. > > > well, we all would love to see linux-vserver in mainline, > > but I guess the disadvantages of trying to get it into > > mainline (less performant code, only partial implementation, > > two branches to maintain) would easily outweight the > > advantages ... > > Ack. In the meantime I''ll continue hoping that one day we''ll see the mainline > incorporate vserver in a way that makes everyone happy :-)Vserver people tried to push it into mainline for several times, but got some objections. I heard that SElinux people were against it, as they said that they could extend SElinux to cover Vserver function, so including Vserver into kernel was not necessary ;-) Looks like Vserver people dont mind it, so I guess we will not see Vserver in mainline very soon. regards, aq _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Fri, Aug 05, 2005 at 05:24:44PM +0900, aq wrote:> On 8/5/05, Mark Williamson <mark.williamson@cl.cam.ac.uk> wrote: > > > yes, xen is just _another_ arch and once it will be in > > > mainline (IIRC they are working on it), we will of course > > > support it out of the box (as we do for UML now) > > > > Yep, they''re working on it now. It''s in the Real Soon Now category, > > just needs some restructuring. Of possible interest to you is that > > Xen will be a sub arch of i386 rather than a separate architecture > > when it''s properly merged. IIRC only really arch dep stuff in > > Vserver is the addition of the syscalls - that code should all > > be common to Xen and i386 so you probably won''t have to do much > > (anything) to support it. > > > > > > It''d be good if a reference to this patch could be added to the > > > > Xen wiki at http://wiki.xensource.com so that other people know > > > > where to find it. > > > > > > well, feel free to add links to linux-vserver or to > > > patches there ... we have a link to Xen (not the wiki) > > > on our wiki since ... hmm, well for a very long time now > > > > I saw it a while back. If Michal is agreeable (i.e. if he''s > > reasonably happy with the patch) I''ll make sure it goes onto the Xen > > wiki so that people can ue the two together. > > > > > well, we all would love to see linux-vserver in mainline, > > > but I guess the disadvantages of trying to get it into > > > mainline (less performant code, only partial implementation, > > > two branches to maintain) would easily outweight the > > > advantages ... > > > > Ack. In the meantime I''ll continue hoping that one day we''ll see the > > mainline incorporate vserver in a way that makes everyone happy :-) > > Vserver people tried to push it into mainline for several times, but > got some objections.they did? interesting ...> I heard that SElinux people were against it, as they said that they > could extend SElinux to cover Vserver function, so including Vserver > into kernel was not necessary ;-)really? well that would be nice to have ...> Looks like Vserver people dont mind it, so I guess we will not see > Vserver in mainline very soon.best, Herbert> regards, > aq_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Mark Williamson schrieb:>Michal, > >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 never looked into Vserver, so every information is welcome. Dirk _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Le Fri, Aug 19, 2005 at 11:12:25AM +0200, Dirk H. Schulz [dirk.schulz@kinzesberg.de] 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?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. 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. Dom -- Dominique Rousseau Neuronnexion, Prestataire Internet & Intranet 57, route de Paris 80000 Amiens tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.fr _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
> 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@kinzesberg.de] 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 - welldone!> > > > > 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@lists.xensource.com http://lists.xensource.com/xen-users
> > What advantage does Vserver have compared to Xen ??? why should it > > make sense to use both?2 words... vps resellers. Whole new market which i''m looking into heavily. John Fairbairn.>> 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@kinzesberg.de] 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@lists.xensource.com > http://lists.xensource.com/xen-users >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
> What advantage does Vserver have compared to Xen – why should it make > sense to use both? > > I never looked into Vserver, so every information is welcome.Everyone else seems to have given a pretty good account of this, but I''ll give my summary anyhow: Adv of Xen over VServer: * Stronger isolation * Stronger accounting * Heterogeneous guests * Live migration Adv of VServer over Xen: * Very simple to manipulate guest filesystems * Maximal resource sharing * Don''t have to "preallocate" disk space and memory space * Even lower performance penalty (though for many workloads it won''t make much / any difference) Similar arguments apply to Solaris Zones and FreeBSD Jails (both of which are similar to VServer) in functionality. Cheers, Mark _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users