Yes, it is for performance reasons. CentOS -has a different place for network init scripts -has a different initialization scheme (chkconfig vs LSB init) -has a different place to initialize iptables
Centos also may use GRUB-legacy vs GRUB2 for booting. The current systemvm uses GRUB-legacy since XS 5.6 only supported GRUB-legacy, but it might be time to move on. A more suitable systemvm build script might be based on veewee/vagrant, along with qemu-img to do the final conversion to vhd/qcow2 -- Chiradeep On 12/13/12 10:29 AM, "Anthony Xu" <xuefei...@citrix.com> wrote: >32-bit PV might have better performance than 64-bit PV on XEN, >In 64 bit mode, there are only ring 0 and ring 3, both Guest OS and guest >application are running on ring3 , application system call needs to be >trapped into hypervisor and then be injected into guest OS. >In 32 bit mode, there are ring 0, 1, 2, 3. Guest OS is running on ring >1, application is running on ring 3, hypervisor doesn't need to trap >system call. > >That might be one of reasons dom0 is 32 bit in XenServer/XCP. > >Anthony > >> -----Original Message----- >> From: Donal Lafferty [mailto:donal.laffe...@citrix.com] >> Sent: Thursday, December 13, 2012 10:20 AM >> To: cloudstack-dev@incubator.apache.org >> Subject: RE: CentOS System Offering Thread >> >> The choice of 32-bit OS may be to support legacy servers, but I really >> don't know. >> >> >> -----Original Message----- >> From: Musayev, Ilya [mailto:imusa...@webmd.net] >> Sent: 13 December 2012 4:50 PM >> To: cloudstack-dev@incubator.apache.org >> Subject: RE: CentOS System Offering Thread >> >> I did.. reviewed buildsystemvm.sh script - seems self-explanatory. >> >> There are 2 major parts to this task as I see it. >> >> Part1 >> System Image Side: >> We need to alter the "debootsrap" to "mock" and change debian specific >> configs to redhat. Once functional - I need to create 3 versions of >> the template for VmWare, Xen and KVM. I have VmWare in house - no >> Xen/KVM yet - we can deal with this - once I get there. >> >> Part2 >> Systemvm.iso will need to be updated and include rhel version of the >> patch scripts we run on power on. >> >> >> What is the reason for running 32bit OS vs 64? Are we open to changing >> that to 64bit - which would probably benefit very large implementations >> using basic zones. Or should we keep it 32 bit for consistency reason? >> >> -----Original Message----- >> From: Donal Lafferty [mailto:donal.laffe...@citrix.com] >> Sent: Thursday, December 13, 2012 7:47 AM >> To: cloudstack-dev@incubator.apache.org >> Subject: RE: CentOS System Offering Thread >> >> WRT to CentOS. Did you survey the changes required? >> >> Would be great to have these on a wiki page for future reference and >> history tracking. >> >> >> DL >> >> >> -----Original Message----- >> From: Musayev, Ilya [mailto:imusa...@webmd.net] >> Sent: 12 December 2012 9:33 PM >> To: cloudstack-dev@incubator.apache.org >> Subject: RE: CentOS System Offering Thread >> >> Donal >> >> See response in line.. >> >> >> 1. Can you remind me of the download link for the Wheezy systemVM? >> I've only seen Squeeze. >> >> I confused the names - I think - its squeeze - wheezy is the latest >> offering with 3.x kernel. I guess by now you noticed I'm not debian >> user :) >> >> >> 2. In addition to a Debian system VM, I'd like to see one and only >> one CentOS VM in addition to Debian. I get the impression that CentOS >> has a different and desirable licensing regime, but do correct me if >> I'm wrong. >> >> I'm under impression CentOS has very liberal licensing structure. I >> don't believe we should have an issue here - but I'm by no means a >> licensing expert. >> >> I think it's reasonable to have 1 other offering only.. >> >> Thanks >> ilya >> >> >> -----Original Message----- >> From: Donal Lafferty [mailto:donal.laffe...@citrix.com] >> Sent: Wednesday, December 12, 2012 3:34 PM >> To: cloudstack-dev@incubator.apache.org >> Subject: RE: CentOS System Offering Thread >> >> 1. Can you remind me of the download link for the Wheezy systemVM? >> I've only seen Squeeze. >> >> 2. In addition to a Debian system VM, I'd like to see one and only one >> CentOS VM in addition to Debian. I get the impression that CentOS has >> a different and desirable licensing regime, but do correct me if I'm >> wrong. >> >> DL >> >> -----Original Message----- >> From: Musayev, Ilya [mailto:imusa...@webmd.net] >> Sent: 12 December 2012 8:06 PM >> To: cloudstack-dev@incubator.apache.org >> Subject: RE: CentOS System Offering Thread >> >> Joe >> >> Your point is clear and well taken. Nobody wants to be in business of >> maintaining myriad of distros out there for something that should not >> be changed anyway. >> >> I see two solutions then: >> >> 1) update the existing debian wheezy image to reflect latest fixes - >> which is probably something that should do anyway. >> >> 2) maybe have a section of - "user submitted and unsupported" system >> offerings? We can clearly state - we support 1 type of offering and >> other offerings are optional and unsupported - but your own >> responsibility and should be used by advanced users only. >> >> Thoughts? >> >> Regards >> -ilya >> >> -----Original Message----- >> From: Joe Brockmeier [mailto:j...@zonker.net] >> Sent: Wednesday, December 12, 2012 11:02 AM >> To: cloudstack-dev@incubator.apache.org >> Subject: Re: CentOS System Offering Thread >> >> On Tue, Dec 11, 2012, at 11:32 PM, Marcus Sorensen wrote: >> > This is pretty important. Anyone should be able to roll their own, >> > rather than relying on a single potentially out-of-date image. It >> > seems like it would be pretty simple and straightforward on the face >> > of it, however many of the scripts have been written specifically for >> > Debian. I'd honestly be ok with having to stick to a particular >> distro >> > if I at least had clear instructions on how to make my own, I >> > understand the need to program against a single defined userspace. >> >> I see a potential problem with this. >> >> Any scenario where users are customizing part of the stack means >> additional variables which means additional problems. If we target >> Debian, trying to create a system VM from CentOS/RHEL means different >> libraries, etc. - which means a number of potential problems cropping >> up where there were none before. >> >> I'm not saying users *shouldn't* be able to do this - just that I >> haven't noticed anyone raising the issue that we'll probably start >> seeing a fair number more bugs if replacing the system VM becomes a >> standard practice. There's a reason, for instance, that Linux vendors >> don't support custom kernels - and what's being proposed here is >> swapping out an entire OS. >> >> It's going to make things a bit more tricky when someone reports a bug >> and they're using a roll-your-own system VM and the people doing the >> testing are using a different one. >> >> Again - not saying we shouldn't do this, but I'd like to see that given >> a bit more consideration when we're discussing the issue. >> >> Best, >> >> jzb >> -- >> Joe Brockmeier >> j...@zonker.net >> Twitter: @jzb >> http://www.dissociatedpress.net/ >> >> >> >> >> >
