Thanks. I guess that means I need to upgrade both OS and Ovirt simultaneously. And if I recall correctly I need to upgrade my hosted engine first and then upgrade the host? (This is a single-host hosted-engine setup).
I've never actually upgraded an ovirt release beyond point releases (I started with 4.0, and currently run 4.0.6). I did upgrade from 7.2 to 7.3, which was relatively straightforward. My plan is to follow the instructions at https://www.ovirt.org/release/4.1.0/ -- will the engine-setup also wind up pulling in the OS update? I suppose I can run a yum update after running engine-setup? Thanks, -derek On Mon, January 15, 2018 1:10 pm, Yaniv Kaul wrote: > On Mon, Jan 15, 2018 at 6:28 PM, Derek Atkins <[email protected]> wrote: > >> Thanks. >> >> I guess it still boils down to updating to 7.4. :( >> >> In the short term, will Ovirt 4.0 continue to run in 7.4? Or MUST I >> > > We don't know, but I would assume NO. Every minor release of EL required > some small adjustments to expected and unexpected changes in the platform. > We have worked with 4.1 to support 7.3 and then 7.4, I would not presume > 4.0 works with it. > Y. > > >> upgrade both the OS and ovirt simultaneously? My time is very short >> over >> the next few weeks (I'm moving) so I'd like to get as much bang for the >> buck with as little down time as possible. I can't spend 12 hours of my >> time working to repair a botched upgrade from 4.0 to 4.1 or 4.2. >> >> Thanks again! >> >> -derek >> >> On Mon, January 15, 2018 11:05 am, Arman Khalatyan wrote: >> > If you see that after the update of your OS dmesg shows RED alert in >> > the spectra check script in the second position then you should follow >> > the intel's read.me. >> > As in readme described on Centos 7.4: >> > rsync -Pa intel-ucode /lib/firmware/ >> > On the recent kernels(>2.6.xx) the dd method does not work, dont do >> that. >> > To confirm that microcode loaded: >> > dmesg | grep micro >> > look for the release dates. >> > But I beleve that v4 should be already in the microcode_ctl package of >> > the CentOS7.4 ( in my case 2650v2 was not inside, but the v3 and v4 >> > were there) >> > I have a script to enable or disable the protection so you can see the >> > performance impact on your case: >> > https://arm2armcos.blogspot.de/2018/01/lustrefs-big- >> performance-hit-on-lfs.html >> > >> > >> > >> > On Mon, Jan 15, 2018 at 4:28 PM, Derek Atkins <[email protected]> wrote: >> >> Arman, >> >> >> >> Thanks for the info... And sorry for taking so long to reply. It's >> >> been a busy weekend. >> >> >> >> First, thank you for the links. Useful information. >> >> >> >> However, could you define "recent"? My system is from Q3 2016. Is >> that >> >> considered recent enough to not need a bios updte? >> >> >> >> My /proc/cpuinfo reports: >> >> model name : Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz >> >> >> >> I downloaded the microcode.tgz file, which is dated Jan 8. I noticed >> >> that the microcode_ctl package in my repo is dated Jan 4, which >> implies >> >> it probably does NOT contain the Jan 8 tgz from Intel. It LOOKS like >> I >> >> can just replace the intel-ucode files with those from the tgz, but >> I'm >> >> not sure what, if anything, I need to do with the microcode.dat file >> in >> >> the tgz? >> >> >> >> Thanks, >> >> >> >> -derek >> >> >> >> Arman Khalatyan <[email protected]> writes: >> >> >> >>> if you have recent supermicro you dont need to update the bios, >> >>> >> >>> Some tests: >> >>> Crack test: >> >>> https://github.com/IAIK/meltdown >> >>> >> >>> Check test: >> >>> https://github.com/speed47/spectre-meltdown-checker >> >>> >> >>> the intel microcodes you can find here: >> >>> https://downloadcenter.intel.com/download/27431/Linux- >> Processor-Microcode-Data-File?product=41447 >> >>> good luck. >> >>> Arman. >> >>> >> >>> >> >>> >> >>> On Thu, Jan 11, 2018 at 4:32 PM, Derek Atkins <[email protected]> >> wrote: >> >>>> Hi, >> >>>> >> >>>> On Thu, January 11, 2018 9:53 am, Yaniv Kaul wrote: >> >>>> >> >>>>> No one likes downtime but I suspect this is one of those serious >> >>>>> vulnerabilities that you really really must be protected against. >> >>>>> That being said, before planning downtime, check your HW vendor >> for >> >>>>> firmware or Intel for microcode for the host first. >> >>>>> Without it, there's not a lot of protection anyway. >> >>>>> Note that there are 4 steps you need to take to be fully >> protected: >> >>>>> CPU, >> >>>>> hypervisor, guests and guest CPU type - plan ahead! >> >>>>> Y. >> >>>> >> >>>> Is there a HOW-To written up somewhere on this? ;) >> >>>> >> >>>> I built the hardware from scratch myself, so I can't go off to Dell >> or >> >>>> someone for this. So which do I need, motherboard firmware or >> Intel >> >>>> microcode? I suppose I need to go to the motherboard manufacturer >> >>>> (Supermicro) to look for updated firmware? Do I also need to look >> at >> >>>> Intel? Is this either-or or a "both" situation? Of course I have >> no >> >>>> idea >> >>>> how to reflash new firmware onto this motherboard -- I don't have >> DOS. >> >>>> >> >>>> As you can see, planning I can do. Execution is more challenging >> ;) >> >>>> >> >>>> Thanks! >> >>>> >> >>>>>> > Y. >> >>>> >> >>>> -derek >> >>>> >> >>>> -- >> >>>> Derek Atkins 617-623-3745 >> >>>> [email protected] www.ihtfp.com >> >>>> Computer and Internet Security Consultant >> >>>> >> >>>> _______________________________________________ >> >>>> Users mailing list >> >>>> [email protected] >> >>>> http://lists.ovirt.org/mailman/listinfo/users >> >>> >> >>> >> >> >> >> -- >> >> Derek Atkins 617-623-3745 >> >> [email protected] www.ihtfp.com >> >> Computer and Internet Security Consultant >> > >> >> >> -- >> Derek Atkins 617-623-3745 >> [email protected] www.ihtfp.com >> Computer and Internet Security Consultant >> >> > -- Derek Atkins 617-623-3745 [email protected] www.ihtfp.com Computer and Internet Security Consultant _______________________________________________ Users mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/users
