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
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
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,
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?
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
On Mon, Jan 15, 2018 at 6:28 PM, Derek Atkins wrote:
> 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
Hi all, I didn't find any working ovirt-guest-agent for atomic7, and it
is a requirement for launching atomic from vagrant-ovirt4 plugin.
I tried installing ovirt-guest-agent inside, I tried installing
ovirtguestagent/centos7-atomic, but I had no success
Does any official project exist for it?
I will look into it.
Is it also not working also for non-iso images?
On Jan 14, 2018 8:16 PM, "Gianluca Cecchi"
> I see in release notes this
> BZ 1530730 [downstream clone - 4.2.1] [RFE] Allow uploading ISO images to
Hey, thanks for sending this to me. Works like a charm. I have this tied
in with a UPS script that monitors the UPS on another system, and fires off
your script before a shutdown command. Works pretty well so far!
I am using the default certificates. Took me a second to find out where
I actually do not agree with Simone here. The fix he talks about adds
a call to prepareImage, but your log clearly shows that prepareImage
is the call that fails:
Jan 12 16:52:36 cultivar0 journal: vdsm storage.Dispatcher ERROR
FINISH prepareImage error=Volume does not exist:
On Fri, Jan 12, 2018 at 9:54 PM, Jayme wrote:
> recently upgraded to 4.2 and had some problems with engine vm running, got
> that cleared up now my only remaining issue is that now it seems
> ovirt-ha-broker and ovirt-ha-agent are continually crashing on all three of
Mount logs will be in below format inside /var/log/glusterfs :
On Mon, Jan
Can you check if glusterd service is running on host1 and all the
peers are in connected state ? If yes, can you restart ovirt-ha-agent and
broker services and check if things are working fine ?
On Sat, Jan 13, 2018 at 12:33 AM, Artem Tambovskiy <
Can you attach ovirt-ha-agent and ovirt-ha-broker logs ?
On Fri, Jan 12, 2018 at 9:38 PM, Artem Tambovskiy <
> Trying to fix one thing I broke another :(
> I fixed mnt_options for hosted engine storage domain and installed latest
I have uploaded 2 archives with all relevant logs to shared hosting
files from host 1 (which is currently running all VM's including
hosted_engine) - https://yadi.sk/d/PttRoYV63RTvhK
files from second host - https://yadi.sk/d/UBducEsV3RTvhc
I have tried to restart both ovirt-ha-agent
Mail list logo