Re: [Xen-devel] Xen 4.1.x security support

[Sander Eikelenboom <linux@xxxxxxxxxxxxxx>]

Thursday, September 19, 2013, 12:41:43 PM, you wrote:

> On Wed, Sep 18, 2013 at 04:42:05PM +0100, George Dunlap wrote:
>> On Wed, Sep 18, 2013 at 2:49 PM, Andres Lagar-Cavilla
>> <andreslc@xxxxxxxxxxxxxx> wrote:
>> >> On 09/18/13 10:39, Jan Beulich wrote:
>> >>>>>> On 17.09.13 at 19:44, Joanna Rutkowska 
>> >>>>>> <joanna@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>> >>>> And a somehow more general thought: what most people expect from
>> >>>> baremetal hypervisors, I think, is stability. Unlike the Linux kernel,
>> >>>> the Xen hypervisor does not need to support each and every device
>> >>>> invented on the planet, each and every possible filesystem, or
>> >>>> networking stack, etc. That's, in fact, (one of) the biggest advantage
>> >>>> of a hypervisor over a monolithic kernel. So, why, oh why, such a race
>> >>>> to keep bumping the major version over and over again?
>> >>>
>> >>> In fact I'm the (so far apparently only) one trying to stop further
>> >>> accelerating the release schedule from its original 9 month cycle.
>> >>> I don't recall you having chimed in when the release schedule for
>> >>> 4.4 in particular and the shortening of the release cycle in general
>> >>> was discussed on the mailing list. There were arguments in favor
>> >>> of the shortening which I certainly appreciate.
>> >>>
>> >>
>> >> Well, I'm not regular on xen-devel, because I'm not a Xen developer,
>> >> really. I'm a _user_ of Xen. In an ideal world we (Qubes OS project)
>> >> should not even maintain a fork of Xen, nor be at xen-devel at all.
>> >>
>> >> I just came here now because I'm worried that the team I'm leading, the
>> >> users of Xen, will now need to spend considerable amount of time on
>> >> upgrading our product to Xen 4.2, because Xen 4.1 security support is
>> >> ending soon.
>> >
>> > Several communities are adopting the notion of LTS releases. Ubuntu 
>> > Precise, for example, has been a major enabler in Openstack by offering a 
>> > steady platform for over 18 months now. Upstream kernel 3.10 is slated to 
>> > underpin major distros for a good while.
>> >
>> > I don't see why xen.org could not offer a similar cadence, and all the 
>> > down streams would naturally align to that.
>> >
>> > Jan's point about keeping many stable trees being a significant time sink 
>> > is extremely valid.
>> >
>> > I think the LTS solutions solves both of your problems. As a downstream, 
>> > Qubes won't have to move rapidly crossing minor versions. There will be a 
>> > reckoning day when transitioning to the next LTS, but you will have plenty 
>> > of advance notice to prepare.

I don't think crossing future minor version would have to be a problem.
The major problem with the current 4.2 and 4.3 minor versions is that they are 
released in the 'middle' of the major switch of toolstack && qemu-upstream.
As a consequence they do have rough edges.


>> >
>> > The stable tree maintainer needs to care about a single tree which is a 
>> > very well known quantity, and not have to deal with maybe two or even 
>> > three trees at a time.
>> >
>> > One could argue that an LTS approach lessens the value of non LTS 
>> > releases. In fact, discussions in Ubuntu have pointed at forgetting about 
>> > non LTS releases and doing nightly builds in between, given a strong 
>> > enough CI/CD environment. I for one think that's a bit too drastic and 
>> > there is value to 4.3, 4.4, etc marking completion of important features.
>> >
>> > If we were to appoint an LTS, I would vote for 4.2, which saw a 
>> > significant delta with respect to 4.1.
>> >
>> > If we were to appoint a 5.0, that would be a prime candidate for an LTS. 
>> > Xend deprecation as well as fully-baked PVH would be two major milestones 
>> > demarcating a clear before and after.

There are still some things which are not supported / do not work as documented 
in the libxl toolstack and/or upstream qemu.
Perhaps a testday should be spend on trying and validating all xend && xm && 
qemu-traditional options on xl && qemu-xen ?

Feature parity or at least corresponding documentation would be nice before 
doing an LTS or bumping the major.


>> Yes, I think we will need to go to designating a "stable hypervisor"
>> that will be supported for longer periods of time.  One aspect of
>> which one would be the best at this point is how many downstreams we
>> have using which release.  Debian, Ubuntu, and XenServer, for
>> instance, have older versions that use 4.1, I believe.  I'm not sure
>> how many downstreams we have using 4.2.
>> 

> At least the following rpm-based distros are currently shipping with Xen 4.2:

> - Fedora 19
> - CentOS6 Xen (not part of the distro, provided separately).


> -- Pasi

>> But this should be discussed in a way that will make sure all the
>> stakeholders are involved.
>> 
>>  -George
>> 





_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel