AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:
CFG:
PT:0
S:andy.sharp@lsi.com
RQ:
SSV:mhbs.lsil.com
NSV:
SSH:
R:<Chuck.Nichols@lsi.com>
MAID:2
X-Sylpheed-Privacy-System:
X-Sylpheed-Sign:0
SCF:#mh/Mailbox/sent
RMID:#imap/LSI/INBOX	0	F468E78762250B478EB5BE2BB2AA2C9E097576@cosmail01.lsi.com
X-Sylpheed-End-Special-Headers: 1
Date: Mon, 12 Oct 2009 11:35:02 -0700
From: Andrew Sharp <andy.sharp@lsi.com>
To: "Nichols, Chuck" <Chuck.Nichols@lsi.com>
Subject: Re: Xen alignment options
Message-ID: <20091012113502.327df3a4@ripper.onstor.net>
In-Reply-To: <F468E78762250B478EB5BE2BB2AA2C9E097576@cosmail01.lsi.com>
References: <20091009104956.598697fe@ripper.onstor.net>
	<F468E78762250B478EB5BE2BB2AA2C9E097576@cosmail01.lsi.com>
Organization: LSI
X-Mailer: Sylpheed-Claws 2.6.0 (GTK+ 2.8.20; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Fri, 9 Oct 2009 13:36:29 -0600 "Nichols, Chuck"
<Chuck.Nichols@lsi.com> wrote:

> Heh.  Well, at least now you have an idea of what I'm dealing
> with.  :)

I had no idea.  I thought I did have an idea.  I was wrong.  That
-person- really cheesed me off, I have to say.

> I think I mentioned to Bruce that it's difficult to explain why,
> exactly, we're at this point with Citrix without being at least a bit
> impolitic.  There's a lot of FUD out there, and I think Craig just
> about hit on all of it.  In terms of dealing with Engineering
> management, the best I can do is to keep nudging the iceberg in the
> direction that I think it should go, and hope that eventually I can
> get the heading changed.  Believe me, I completely understand (and
> share) the frustration that a group such as yours would have with an
> organization suffering so badly from the fear of the unknown.  And,
> no matter how loudly I remind them that this isn't an "unknown", that
> it's in fact a solved problem because there are hundreds of Linux
> shops out there, for the Engineering management team, it comes down
> to an attitude of, "because 'we' haven't ever done this, and because
> of the stability expectations we believe we've established for our
> product, it feels too risky".  I'm not saying that's the correct
> perspective, I'm just saying it's the perspective I encounter.
> 
> Personally, you and Bruce make some very good points, and if we were
> starting from ground zero right now, the outcome might be different.
> That being said, good or bad, we're standing here right now with
> Citrix and I'm being asked to supply guidance as to what Linux
> distros/kernels we should use for our DomUs.  My guidance right now,
> based largely on input from you and Bruce, is that we should continue
> down the Debian/2.6.31 path and cross some of these other bridges
> when we get to them.

I say we endorse over to Bruce's group the Citrix check and have them
do the deal ~:^)

> -Chuck
>  
> 
> -----Original Message-----
> From: Andrew Sharp [mailto:andy.sharp@lsi.com] 
> Sent: Friday, October 09, 2009 12:50 PM
> To: Nichols, Chuck
> Cc: Edge, Bruce; Henry, Jason; Stark, Brian; Nahum, Nelson
> Subject: Re: Xen alignment options
> 
> Hi Chuck,
> 
> Holy cow, what a complete tool.  What's this guy's deal?  Chuck, you
> mentioned that there's some learning curve with regard to the open
> source model at LSI, but this email hits them all: community
> developers (of which I'm one) are a bunch of shiftless hippies who
> wouldn't know a product if it ran them over; it's about features; we
> aren't in the XXXX business, therefore YYYY unrelated conclusion;
> paying a company a STUPID amount of money (.5 mil? more?) guarantees
> quality, support and service exactly as we imagine we want.
> 
> I *seriously* don't have time for this n0b.
> 
> On Fri, 9 Oct 2009 11:02:03 -0600 "Rolandelli, Craig"
> <Craig.Rolandelli@lsi.com> wrote:
> 
> > The problem with folks who "own" code in the open source is that
> > they typically don't have to deliver products to customers.  We are
> > in the business of delivering storage products that must work 100%
> > of the time.  We are not in the business of shipping the latest and
> > greatest virtualization software.  We need to develop and test on
> > stable, tested, hardened platforms.
> > 
> > We need to pick a release and move forward with it.  If Xen 3.4.1
> > has the features we need for this product today, then we should use
> > it. If it doesn't, then we need to know that now and deal with it.
> > I haven't heard that there are any feature set issues with 3.4.1
> > for what we need to deliver for Orion.
> > 
> > If new features come up in Xen 3.5 that we could use, then I would 
> > consider that feature creep and should be kept out of this release
> > of the product.
> > 
> > If there is a stability issue with 3.4.1 and we need a fix in 3.5, 
> > then that fix needs to be back ported by Citrix to 3.4.1.  Citrix
> > is being paid a lot of money by us to support us and to deliver a
> > stable, tested hardened release of Xen.
> > 
> > Again, we aren't in the business of shipping the latest and greats 
> > virtualization software.  We are in the business of shipping
> > storage platforms that have 100% availability (or at least 5 9's 
> > availability).
> > 
> > Craig
> > 
> > 
> > -----Original Message-----
> > From: Andrew Sharp [mailto:andy.sharp@lsi.com]
> > Sent: Friday, October 09, 2009 9:30 AM
> > To: Edge, Bruce
> > Cc: Rolandelli, Craig; Nichols, Chuck
> > Subject: Re: Xen alignment options
> > 
> > On Fri, 9 Oct 2009 08:53:25 -0600 "Edge, Bruce" <Bruce.Edge@lsi.com>
> > wrote:
> > 
> > > Craig, Chuck, Andy,
> > > 
> > > I'm not convinced that a Citrix XenServer is the best option for
> > > LSI even if support is the primary reason. If we were using Xen
> > > for server consolidation in an IT environment that would be a
> > > different story, but we're not.
> > > 
> > > We have recently been working through a problem with the MSI in
> > > Xen relating to IRQ affinity. One day after posting the problems
> > > details on the xen-devel list, we were directed to the author of
> > > that code within Xen, who subsequently told us what debug options
> > > to add, and a request for more information. This Xen developer
> > > also states that we're better off with the leading edge, Xen 3.5
> > > (unstable), for new development work especially for new hardware
> > > support.
> > > 
> > > The fact is that we're developing kernel code on leading edge 
> > > hardware that's pushing the development envelope of Xen itself. I 
> > > can't see how committing to using an earlier static version of
> > > Xen is the best option for those requirements.
> > > 
> > > -Bruce
> > 
> > I concur.  This sort of thing will be continuing occurance.  Put 
> > another way, I don't believe there's a "no-brainer" way of doing
> > this.
> > 
> > a
