Well when the last upgrade 4.2 > 4.4 went live and XM was disabled by default it took many hosts down without warning. 4.4 > 4.6 may cause the same issues. It's a dangerous upgrade for sure. Why can't 4.4 be LTS for C6? as it's the last build with XM. Any XSA patches should not be hard to backport. and maybe the optional xen4.6 for C6. On 21 January 2016 at 13:09, President <president at caldwellglobal.com> wrote: > My .02 is to stay the course. As a server admin, I want to be able to > type things like: > > > yum upgrade php > > not > > yum upgrade php55-epel-rpmforge-fancy-package > > > Having to remember all the idiosyncrasies of a system is what causes some > type of major failure in the future whenever (1) you forget something or > (2) someone else has to pick up the box to adminster. > > > > -- > > Craig Thompson, President > > Caldwell Global Communications, Inc. > > +1 (423) 559-5465 > > caldwellglobal.com > > > -----Original message----- > *From:* George Dunlap <dunlapg at umich.edu> > *Sent:* Thursday 21st January 2016 7:32 > *To:* Discussion about the virtualization on CentOS < > centos-virt at centos.org> > *Subject:* Re: [CentOS-virt] CentOS 6 Virt SIG Xen 4.6 packages available > in centos-virt-xen-testing > > On Thu, Jan 21, 2016 at 12:01 PM, Peter <peter at pajamian.dhs.org> wrote: > > On 15/01/16 05:57, George Dunlap wrote: > >> As mentioned yesterday, Xen 4.6 packages are now available for > >> testing. These also include an update to libvirt 1.3.0, in line with > >> what's available for CentOS 7. Please test, particularly the upgrade > >> if you can, and report any problems here. > > > > Per conversation in IRC, Xen 4.6 no longer includes xend and therefore > > no longer has the "xm" command. This is problematic for people who may > > be using xm in various scripts on their host (such as home-brewed backup > > scripts). > > > > I think it's a bad idea to break this functionality without warning by > > allowing a simple "yum update" to remove it. You will take a lot of > > people by surprise and cause such scripts to stop working, if people are > > running yum cron the situation becomes even worse. > > Thanks, PJ, for your input. > > Just to be clear: > > 1. In the Xen 4.4 packages (first released October 2014), xend was > disabled by default; so anyone using xend at the moment has already > manually intervened to enable deprecated functionality > > 2. In 4.4, the first time xm was executed, it printed this warning: > --- > xend is deprecated and scheduled for removal. Please migrate to another > toolstack ASAP. > > See http://wiki.xen.org/wiki/Choice_of_Toolstacks for information on > other alternatives, including xl which is designed to be a drop in > replacement for xm (http://wiki.xen.org/wiki/XL). > --- > > 3. ...and on every subsequent invocation, it printed this warning: > "WARNING: xend/xm is deprecated" > > I think this constitutes "warning" that the functionality was going to > break at some point. :-) > > Also, in most cases "s/xm/xl/g;" Just Works; most people have reported > that changing from xm -> xl was pretty painless. So this isn't like > upgrading from Python 2 to Python 3 (or QT 4 to 5, or...). > > > I think that due to this lack of backwards compatibility with Xen 4.4 > > and earlier versions it would be a good idea to not force the upgrade on > > people who are not wary of it. I propose that the new packages carry > > the name "xen46" and they purposefully conflict with the old "xen" > > packages. That will require people to take positive action to do the > > upgrade and hence avoid breaking systems unintentionally. > > This would avoid breaking things for people still using xm, which > certainly has some value. However it has some costs: > > * The packages between C6 and C7 will now be slightly different, > increasing the maintenance burden. This is not only in the spec file, > but also in all the associated scripting machinery for managing > packages in the CBS and smoke-testing packages before pushing them > publicly. > > * Instructions for installing Xen are now differend between C6 and C7, > and slightly more complicated, as they have to explain about Xen 4.6 > vs alternatives. > > * Users who have heeded the warning and switched to xl will have to > make an extra effort to switch to Xen 4.6. If they don't follow > centos-virt, they may not notice that there's a new package to upgrade > to. > > I'm a developer, not a server admin, so I can't gauge how important > this issue is. Before making such a change, I'd like to hear opinions > from other people in the community about how important (or not) it is > to avoid breaking xm, given the ample warning (>1 year) users have > had. > > On the other hand, explicitly moving to a "xen${VER}" (both for C6 and > C7) would make it simpler for people to step up and maintain older > versions in parallel if anybody wanted to do so. > > Thanks again, Peter, for bringing this up. > > Peace, > -George > _______________________________________________ > CentOS-virt mailing list > CentOS-virt at centos.org > https://lists.centos.org/mailman/listinfo/centos-virt > > > _______________________________________________ > CentOS-virt mailing list > CentOS-virt at centos.org > https://lists.centos.org/mailman/listinfo/centos-virt > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos-virt/attachments/20160121/ea104146/attachment-0006.html>