Hi all, 4.1.6.1 was announced as the last 4.1.x release. Does it mean that further XSAs will not carry patches for 4.1? If they will - how long? -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
>>> On 17.09.13 at 00:01, Marek Marczykowski-Górecki<marmarek@invisiblethingslab.com> wrote: > 4.1.6.1 was announced as the last 4.1.x release. Does it mean that further > XSAs will not carry patches for 4.1?That's the way I view it, but that doesn't mean it has to be that way. Jan> If they will - how long?_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On 09/17/13 08:47, Jan Beulich wrote:>>>> On 17.09.13 at 00:01, Marek Marczykowski-Górecki<marmarek@invisiblethingslab.com> wrote: >> 4.1.6.1 was announced as the last 4.1.x release. Does it mean that further >> XSAs will not carry patches for 4.1? > > That''s the way I view it, but that doesn''t mean it has to be that way. >That would be rather unfortunate. E.g. we''re planning to stick to Xen 4.1 for our Qubes R2 release. There are some problems with Xen 4.2 such as the GPLPV Windows drivers not working with it correctly. I could imagine that it should not be very costly for xen.org to backport each XSA patch to 4.1, should it? Thanks, joanna. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On 09/17/13 19:38, Joanna Rutkowska wrote:> On 09/17/13 08:47, Jan Beulich wrote: >>>>> On 17.09.13 at 00:01, Marek Marczykowski-Górecki<marmarek@invisiblethingslab.com> wrote: >>> 4.1.6.1 was announced as the last 4.1.x release. Does it mean that further >>> XSAs will not carry patches for 4.1? >> >> That''s the way I view it, but that doesn''t mean it has to be that way. >> > > That would be rather unfortunate. E.g. we''re planning to stick to Xen > 4.1 for our Qubes R2 release. There are some problems with Xen 4.2 such > as the GPLPV Windows drivers not working with it correctly. > > I could imagine that it should not be very costly for xen.org to > backport each XSA patch to 4.1, should it? >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? joanna. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On Tue, 2013-09-17 at 19:44 +0200, Joanna Rutkowska wrote:> On 09/17/13 19:38, Joanna Rutkowska wrote: > > On 09/17/13 08:47, Jan Beulich wrote: > >>>>> On 17.09.13 at 00:01, Marek Marczykowski-Górecki<marmarek@invisiblethingslab.com> wrote: > >>> 4.1.6.1 was announced as the last 4.1.x release. Does it mean that further > >>> XSAs will not carry patches for 4.1? > >> > >> That's the way I view it, but that doesn't mean it has to be that way. > >> > > > > That would be rather unfortunate. E.g. we're planning to stick to Xen > > 4.1 for our Qubes R2 release. There are some problems with Xen 4.2 such > > as the GPLPV Windows drivers not working with it correctly. > > > > I could imagine that it should not be very costly for xen.org to > > backport each XSA patch to 4.1, should it?Well, it rather depends on nature of the patch doesn't it. Some are hard and some are easy. AFAIK the security team would be happy to receive and distribute additional backports to older versions done by community members e.g. those on the predisclosure list.> 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?What race are you talking about? Do you think we should do something other than bump the version when we cut a new release? or do you think we should add features to stable branches or something? The release cadence has been discussed on the list fairly recently. I would suggest you make your views known under that topic rather than here where people might miss it. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On 09/17/13 21:18, Ian Campbell wrote:> On Tue, 2013-09-17 at 19:44 +0200, Joanna Rutkowska wrote: >> On 09/17/13 19:38, Joanna Rutkowska wrote: >>> On 09/17/13 08:47, Jan Beulich wrote: >>>>>>> On 17.09.13 at 00:01, Marek Marczykowski-Górecki<marmarek@invisiblethingslab.com> wrote: >>>>> 4.1.6.1 was announced as the last 4.1.x release. Does it mean that further >>>>> XSAs will not carry patches for 4.1? >>>> >>>> That''s the way I view it, but that doesn''t mean it has to be that way. >>>> >>> >>> That would be rather unfortunate. E.g. we''re planning to stick to Xen >>> 4.1 for our Qubes R2 release. There are some problems with Xen 4.2 such >>> as the GPLPV Windows drivers not working with it correctly. >>> >>> I could imagine that it should not be very costly for xen.org to >>> backport each XSA patch to 4.1, should it? > > Well, it rather depends on nature of the patch doesn''t it. Some are hard > and some are easy. > > AFAIK the security team would be happy to receive and distribute > additional backports to older versions done by community members e.g. > those on the predisclosure list. > >> 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? > > What race are you talking about? Do you think we should do something > other than bump the version when we cut a new release? or do you think > we should add features to stable branches or something? >My point was that you should be adding very few features or none at all, keep the hypervisor as simple as possible, do not change the management stack all the time, etc. Otherwise it makes it difficult for other projects/products who use Xen to catch up. What version does Xen Client use, BTW? Really, who needs nested virtualization, or XSM -- these are of pure academic interest and only make the hypervisor unnecessary bloated, IMO. Why not keep everything that is not "core" as separate repos/projects, conditionally compiled/linked with the core hypervisor? When a hypervisor gets too complex it suddenly looses all its appeal over a traditional kernel, doesn''t it? joanna. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On 17.09.2013 21:55, Joanna Rutkowska wrote:> On 09/17/13 21:18, Ian Campbell wrote: >> On Tue, 2013-09-17 at 19:44 +0200, Joanna Rutkowska wrote: >>> On 09/17/13 19:38, Joanna Rutkowska wrote: >>>> On 09/17/13 08:47, Jan Beulich wrote: >>>>>>>> On 17.09.13 at 00:01, Marek Marczykowski-Górecki<marmarek@invisiblethingslab.com> wrote: >>>>>> 4.1.6.1 was announced as the last 4.1.x release. Does it mean that further >>>>>> XSAs will not carry patches for 4.1? >>>>> >>>>> That''s the way I view it, but that doesn''t mean it has to be that way. >>>>> >>>> >>>> That would be rather unfortunate. E.g. we''re planning to stick to Xen >>>> 4.1 for our Qubes R2 release. There are some problems with Xen 4.2 such >>>> as the GPLPV Windows drivers not working with it correctly. >>>> >>>> I could imagine that it should not be very costly for xen.org to >>>> backport each XSA patch to 4.1, should it? >> >> Well, it rather depends on nature of the patch doesn''t it. Some are hard >> and some are easy. >> >> AFAIK the security team would be happy to receive and distribute >> additional backports to older versions done by community members e.g. >> those on the predisclosure list. >> >>> 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? >> >> What race are you talking about? Do you think we should do something >> other than bump the version when we cut a new release? or do you think >> we should add features to stable branches or something? >> > > My point was that you should be adding very few features or none at all, > keep the hypervisor as simple as possible, do not change the management > stack all the time, etc.The only point that I agree with is do not change management *API* all the time. But this was recently discussed (libxl API stability) and things are going in the right direction. Libxl in 4.1 was marked as technology preview and starting from 4.2 should be stable. I haven''t tried 4.3 yet, but I believe that it is compatible with 4.2 in that matter. The other features (which you say shouldn''t exists) are for example[1]: * Scalability: 16TiB of RAM * CPUID-based idle (don''t rely on ACPI info f/ dom0) * NUMA scheduler affinity * Default to QEMU upstream (partial) - pci pass-thru (external) - enable dirtybit tracking during migration (external) - xl cd-{insert,eject} (external) * Serial console improvements -EHCI debug port Which of them are useless *for all Xen users*? Actually at least "CPUID-based idle" and "QEMU upstream" (when done for stubdom) are quite useful even for Qubes OS. And the former one is strictly hypervisor feature (the only place where is enough information to manage power for the whole system). [1] http://wiki.xen.org/wiki/Xen_Roadmap/4.3> Otherwise it makes it difficult for other > projects/products who use Xen to catch up. What version does Xen Client > use, BTW? > > Really, who needs nested virtualization, or XSM -- these are of pure > academic interest and only make the hypervisor unnecessary bloated, IMO.Uh, the fact that Qubes OS doesn''t need feature X doesn''t mean that nobody needs it. Actually nested virtualization is quite useful for some environments.> Why not keep everything that is not "core" as separate repos/projects, > conditionally compiled/linked with the core hypervisor? > > When a hypervisor gets too complex it suddenly looses all its appeal > over a traditional kernel, doesn''t it?-- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On Tue, 2013-09-17 at 21:55 +0200, Joanna Rutkowska wrote:> On 09/17/13 21:18, Ian Campbell wrote: > My point was that you should be adding very few features or none at all, > keep the hypervisor as simple as possible, do not change the management > stack all the time, etc.I think "all the time" is a gross exaggeration TBH.> Otherwise it makes it difficult for other > projects/products who use Xen to catch up. What version does Xen Client > use, BTW?I don''t know. I''m not sure why you think I would.> Really, who needs nested virtualization, or XSM -- these are of pure > academic interest and only make the hypervisor unnecessary bloated, IMO.Well, that''s *your* opinion. BTW if you want a version of Xen without those things to continue to be supported then you are very welcome to volunteer to take over maintenance of the 4.0 (or any, I don''t know how far back you''d need to go to predate XSM for example) stable branch once xen.org support runs out.> Why not keep everything that is not "core" as separate repos/projects, > conditionally compiled/linked with the core hypervisor?Because that would be an unmanageable nightmare for everyone involved?> When a hypervisor gets too complex it suddenly looses all its appeal > over a traditional kernel, doesn''t it?TBH I think you are either focused on only your own needs/requirements or maybe you are just trolling, in which case I sadly appear to have fallen for it. In any case I don''t think I''ll bother reading the rest of this thread. Ian.
On Tue, 2013-09-17 at 22:36 +0200, Marek Marczykowski-Górecki wrote:> On 17.09.2013 21:55, Joanna Rutkowska wrote: > > On 09/17/13 21:18, Ian Campbell wrote: > >> On Tue, 2013-09-17 at 19:44 +0200, Joanna Rutkowska wrote: > >>> On 09/17/13 19:38, Joanna Rutkowska wrote: > >>>> On 09/17/13 08:47, Jan Beulich wrote: > >>>>>>>> On 17.09.13 at 00:01, Marek Marczykowski-Górecki<marmarek@invisiblethingslab.com> wrote: > >>>>>> 4.1.6.1 was announced as the last 4.1.x release. Does it mean that further > >>>>>> XSAs will not carry patches for 4.1? > >>>>> > >>>>> That's the way I view it, but that doesn't mean it has to be that way. > >>>>> > >>>> > >>>> That would be rather unfortunate. E.g. we're planning to stick to Xen > >>>> 4.1 for our Qubes R2 release. There are some problems with Xen 4.2 such > >>>> as the GPLPV Windows drivers not working with it correctly. > >>>> > >>>> I could imagine that it should not be very costly for xen.org to > >>>> backport each XSA patch to 4.1, should it? > >> > >> Well, it rather depends on nature of the patch doesn't it. Some are hard > >> and some are easy. > >> > >> AFAIK the security team would be happy to receive and distribute > >> additional backports to older versions done by community members e.g. > >> those on the predisclosure list. > >> > >>> 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? > >> > >> What race are you talking about? Do you think we should do something > >> other than bump the version when we cut a new release? or do you think > >> we should add features to stable branches or something? > >> > > > > My point was that you should be adding very few features or none at all, > > keep the hypervisor as simple as possible, do not change the management > > stack all the time, etc. > > The only point that I agree with is do not change management *API* all the > time. But this was recently discussed (libxl API stability) and things are > going in the right direction. Libxl in 4.1 was marked as technology preview > and starting from 4.2 should be stable. I haven't tried 4.3 yet, but I believe > that it is compatible with 4.2 in that matter.Yes. If it isn't meeting the compatiblity guidelines written in libxl.h then we would like the know about it, please!> The other features (which you say shouldn't exists) are for example[1]: > * Scalability: 16TiB of RAM > * CPUID-based idle (don't rely on ACPI info f/ dom0) > * NUMA scheduler affinity > * Default to QEMU upstream (partial) > - pci pass-thru (external) > - enable dirtybit tracking during migration (external) > - xl cd-{insert,eject} (external) > * Serial console improvements > -EHCI debug port > > Which of them are useless *for all Xen users*?Exactly. None of them are useless for everyone, most of them are useful to a wide variety of people, although that doesn't necessarily always include client virtualisation.> Actually at least "CPUID-based > idle" and "QEMU upstream" (when done for stubdom) are quite useful even for > Qubes OS. And the former one is strictly hypervisor feature (the only place > where is enough information to manage power for the whole system). > > [1] http://wiki.xen.org/wiki/Xen_Roadmap/4.3 > > > Otherwise it makes it difficult for other > > projects/products who use Xen to catch up. What version does Xen Client > > use, BTW? > > > > Really, who needs nested virtualization, or XSM -- these are of pure > > academic interest and only make the hypervisor unnecessary bloated, IMO. > > Uh, the fact that Qubes OS doesn't need feature X doesn't mean that nobody > needs it.yes, thanks for putting it so succinctly ;-) I really am done with this thread now, honest ;-) Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
>>> On 17.09.13 at 19:38, Joanna Rutkowska <joanna@invisiblethingslab.com> wrote: > On 09/17/13 08:47, Jan Beulich wrote: >>>>> On 17.09.13 at 00:01, Marek Marczykowski-Górecki<marmarek@invisiblethingslab.com> wrote: >>> 4.1.6.1 was announced as the last 4.1.x release. Does it mean that further >>> XSAs will not carry patches for 4.1? >> >> That's the way I view it, but that doesn't mean it has to be that way. >> > > That would be rather unfortunate. E.g. we're planning to stick to Xen > 4.1 for our Qubes R2 release. There are some problems with Xen 4.2 such > as the GPLPV Windows drivers not working with it correctly. > > I could imagine that it should not be very costly for xen.org to > backport each XSA patch to 4.1, should it?Depends - there are cases (XSA-52, -53, and -55 for example) where the backport is not straightforward. And doing backports in the trivial cases, but not in the non-trivial ones would be sort of odd. That said, for the next few months at least we (SUSE) will need to do backports to 4.1 too. But it's not clear to me whether it would be sending the right sign if we were to include these in advisories - after all, from a xen.org perspective we _want_ people to recognize that dead trees are dead (unless someone steps up to continue maintaining them, in which case it would also be that someone to create the respective security fix backports, or at least coordinate this between the parties doing such backports anyway). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On 09/18/13 10:33, Jan Beulich wrote:>>>> On 17.09.13 at 19:38, Joanna Rutkowska <joanna@invisiblethingslab.com> wrote: >> On 09/17/13 08:47, Jan Beulich wrote: >>>>>> On 17.09.13 at 00:01, Marek Marczykowski-Górecki<marmarek@invisiblethingslab.com> wrote: >>>> 4.1.6.1 was announced as the last 4.1.x release. Does it mean that further >>>> XSAs will not carry patches for 4.1? >>> >>> That''s the way I view it, but that doesn''t mean it has to be that way. >>> >> >> That would be rather unfortunate. E.g. we''re planning to stick to Xen >> 4.1 for our Qubes R2 release. There are some problems with Xen 4.2 such >> as the GPLPV Windows drivers not working with it correctly. >> >> I could imagine that it should not be very costly for xen.org to >> backport each XSA patch to 4.1, should it? > > Depends - there are cases (XSA-52, -53, and -55 for example) > where the backport is not straightforward. And doing backports > in the trivial cases, but not in the non-trivial ones would be sort > of odd. > > That said, for the next few months at least we (SUSE) will need to > do backports to 4.1 too. But it''s not clear to me whether it would > be sending the right sign if we were to include these in advisories > - after all, from a xen.org perspective we _want_ people to > recognize that dead trees are dead (unless someone steps up to > continue maintaining them, in which case it would also be that > someone to create the respective security fix backports, or at > least coordinate this between the parties doing such backports > anyway). >Perhaps the decision to kill 4.1 branch so early should be revisited then? This forces people who used Xen 4.1 to build products (e.g. because back when they made the decision the 4.2 was still not released) to make a significant work now to adopt the 4.2. joanna. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
>>> On 17.09.13 at 19:44, Joanna Rutkowska <joanna@invisiblethingslab.com> 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. As a side note - last we bumped the _major_ version was in Spring 2010, so over 3 years ago. But I guess by "major" you really meant "minor", which corresponds to a major release (as opposed to a stable one). Jan
>>> On 18.09.13 at 10:37, Joanna Rutkowska <joanna@invisiblethingslab.com> wrote: > On 09/18/13 10:33, Jan Beulich wrote: >>>>> On 17.09.13 at 19:38, Joanna Rutkowska <joanna@invisiblethingslab.com> wrote: >>> On 09/17/13 08:47, Jan Beulich wrote: >>>>>>> On 17.09.13 at 00:01, Marek >Marczykowski-Górecki<marmarek@invisiblethingslab.com> wrote: >>>>> 4.1.6.1 was announced as the last 4.1.x release. Does it mean that further >>>>> XSAs will not carry patches for 4.1? >>>> >>>> That's the way I view it, but that doesn't mean it has to be that way. >>>> >>> >>> That would be rather unfortunate. E.g. we're planning to stick to Xen >>> 4.1 for our Qubes R2 release. There are some problems with Xen 4.2 such >>> as the GPLPV Windows drivers not working with it correctly. >>> >>> I could imagine that it should not be very costly for xen.org to >>> backport each XSA patch to 4.1, should it? >> >> Depends - there are cases (XSA-52, -53, and -55 for example) >> where the backport is not straightforward. And doing backports >> in the trivial cases, but not in the non-trivial ones would be sort >> of odd. >> >> That said, for the next few months at least we (SUSE) will need to >> do backports to 4.1 too. But it's not clear to me whether it would >> be sending the right sign if we were to include these in advisories >> - after all, from a xen.org perspective we _want_ people to >> recognize that dead trees are dead (unless someone steps up to >> continue maintaining them, in which case it would also be that >> someone to create the respective security fix backports, or at >> least coordinate this between the parties doing such backports >> anyway). >> > > Perhaps the decision to kill 4.1 branch so early should be revisited > then?Again - if you're willing to step up and maintain that tree, we could consider that (just like 3.4 got maintained for an extended period of time by a non-core-xen.org person). To me, who does the maintenance of the stable trees, keeping two of them up to date already requires non-neglectable amounts of time. Three is too much for more than a brief overlapping period - remember that there's other work I need and want to do. And again - terminating maintenance of the second to last major release tree after a last wrap-up stable release has been, if not a written rule, a model we've been following for at least the last couple of years. An intermediate solution might be to _only_ put security fixes in the least recently abandoned stable tree, and do another wrap-up release once even that activity stops. But whether that would be a good idea needs input from others (along with working out who's going to do the resulting work). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On 09/18/13 10:39, Jan Beulich wrote:>>>> On 17.09.13 at 19:44, Joanna Rutkowska <joanna@invisiblethingslab.com> 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. I can imagine there are more users of Xen who would share my worries, hopefully they will come to this threat sooner or later and back me up :) joanna. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Wednesday, September 18, 2013, 10:39:24 AM, you wrote:>>>> On 17.09.13 at 19:44, Joanna Rutkowska <joanna@invisiblethingslab.com> 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.> As a side note - last we bumped the _major_ version was in Spring > 2010, so over 3 years ago. But I guess by "major" you really > meant "minor", which corresponds to a major release (as opposed > to a stable one).I don''t think it''s about the version number, but more the number of major changes. But i think it''s quite clear they are for the better and if you argue you want a small core, i think all major changes that affect the core are pretty stable now, so it would be worthwhile to migrate to 4.3. The most current day problems and development seem to be with new stuff and incomplete support (as to former xm/xend toolstack and qemu-xen-traditional) for more ''exotic'' features as pci passthrough and the like. And about the real major version number, perhaps a major bump to 5.0 is in fact warranted now xend is perhaps removed from unstable before the release, i think that could be considered as a major milestone. -- Sander> Jan
On 09/17/2013 08:55 PM, Joanna Rutkowska wrote:> What version does Xen Client use, BTW?We are currently on 4.3.> Really, who needs nested virtualization, or XSM -- these are of pure > academic interest and only make the hypervisor unnecessary bloated, IMO.Not sure what you''re talking about here, since XenClient actually want (or already do) make use of both nested virtualization and XSM. -- Vincent
On 09/18/13 12:03, Vincent Hanquez wrote:> On 09/17/2013 08:55 PM, Joanna Rutkowska wrote: >> What version does Xen Client use, BTW? > > We are currently on 4.3. > >> Really, who needs nested virtualization, or XSM -- these are of pure >> academic interest and only make the hypervisor unnecessary bloated, IMO. > Not sure what you''re talking about here, since XenClient actually want > (or already do) make use of both > nested virtualization and XSM. >Features like those do weaken hypervisor security. joanna. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
> On 09/18/13 10:39, Jan Beulich wrote: >>>>> On 17.09.13 at 19:44, Joanna Rutkowska <joanna@invisiblethingslab.com> 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. 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. My two cents Andres> I can imagine there are more users of Xen who would share > my worries, hopefully they will come to this threat sooner or later and > back me up :) > > joanna. >
On Wed, Sep 18, 2013 at 2:49 PM, Andres Lagar-Cavilla <andreslc@gridcentric.ca> wrote:>> On 09/18/13 10:39, Jan Beulich wrote: >>>>>> On 17.09.13 at 19:44, Joanna Rutkowska <joanna@invisiblethingslab.com> 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. > > 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.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. But this should be discussed in a way that will make sure all the stakeholders are involved. -George
On Wed, Sep 18, 2013 at 10:19 AM, Sander Eikelenboom <linux@eikelenboom.it> wrote:> > Wednesday, September 18, 2013, 10:39:24 AM, you wrote: > >>>>> On 17.09.13 at 19:44, Joanna Rutkowska <joanna@invisiblethingslab.com> 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. > >> As a side note - last we bumped the _major_ version was in Spring >> 2010, so over 3 years ago. But I guess by "major" you really >> meant "minor", which corresponds to a major release (as opposed >> to a stable one). > > I don''t think it''s about the version number, but more the number of major changes. > But i think it''s quite clear they are for the better and if you argue you want a small core, > i think all major changes that affect the core are pretty stable now, so it would be worthwhile to migrate to 4.3.We have had people report that in the past upgrading was a fairly painful process, but that in recent releases, upgades have been pretty painless. We''ve added a lot of things to our process to try to make that the case; the switch to a new toolstack, with explicit API compatibility promises, was a part of that, as has been the addition of more extensive regression testing facilities, test days before releases, and so on. So it may be worth trying an update to 4.3 -- it may be easier than you imagine. -George
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@gridcentric.ca> wrote: > >> On 09/18/13 10:39, Jan Beulich wrote: > >>>>>> On 17.09.13 at 19:44, Joanna Rutkowska <joanna@invisiblethingslab.com> 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. > > > > 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. > > 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 >
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@gridcentric.ca> wrote: >> >> On 09/18/13 10:39, Jan Beulich wrote: >> >>>>>> On 17.09.13 at 19:44, Joanna Rutkowska <joanna@invisiblethingslab.com> 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 >>
>>> On 19.09.13 at 12:41, Pasi Kärkkäinen<pasik@iki.fi> wrote: > 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).- SLE11 SP3 Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On 18.09.2013 10:42, George Dunlap wrote:> On Wed, Sep 18, 2013 at 2:49 PM, Andres Lagar-Cavilla > <andreslc@gridcentric.ca> wrote: >>> On 09/18/13 10:39, Jan Beulich wrote: >>>>>>> On 17.09.13 at 19:44, Joanna Rutkowska >>>>>>> <joanna@invisiblethingslab.com> 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. >> >> 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. > > 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.Precise/12.04 is 4.1 based. Quantal/12.10 as well. Raring/13.04 is 4.2 based (though its not a LTS release). I am trying to get all of them follow the matching Xen stable releases during their life-time. The next LTS should have Xen 4.3. So solely from my point of view selecting 4.3 as a Xen LTS would work better but then I know this just started to introduce some quite big(ger) changes and probably from the Xen side a later version would work better.> > But this should be discussed in a way that will make sure all the > stakeholders are involved. > > -George > > _______________________________________________ Xen-devel mailing list > Xen-devel@lists.xen.org http://lists.xen.org/xen-devel >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel