No, buildsystemvm.sh does not run as part of maven. It pretty much runs only on a debian Squeeze/wheezy box. It has the PV drivers but not the xs tools required for live migration. The xs tools actually get in the way since they enforce checks on os/hv compatibility in the source/destination hypervisors. It has vmware tools as well.
On 12/13/12 3:20 PM, "Donal Lafferty" <donal.laffe...@citrix.com> wrote: >Hi Chiradeep, > >To clear up some confusion, does the current script (buildsystemvm.sh) >run as part of the maven build? > >Again, to clear up some confusion, can you comment on whether >buildsystem.sh adds pv-drivers need to a System VM? I was confused by >comments last week about whether the VMM-specific tools/guest >additions/integration services were required to be installed for a system >VM to operate properly. > >DL > > >-----Original Message----- >From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] >Sent: 13 December 2012 11:00 PM >To: CloudStack DeveloperList >Subject: Re: CentOS System Offering Thread > >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/ >>> >>> >>> >>> >>> >> >
