Re: [ovirt-users] oVirt 4.2.1 rc1 and upload iso to data domain test

[Fred Rolland]

Hi,
I will look into it.

Is it also not working also for non-iso images?

Thanks,
Fred

On Jan 14, 2018 8:16 PM, "Gianluca Cecchi" 
wrote:

> Hello,
> I see in release notes this
>
> BZ 1530730 [downstream clone - 4.2.1] [RFE] Allow uploading ISO images to
> data domains and using them in VMs
> It is now possible to upload an ISO file to a data domain and attach it to
> a VM as a CDROM device.
> In order to do so the user has to upload an ISO file via the UI (which
> will recognize the ISO by it's header and will upload it as ISO) or via the
> APIs in which case the request should define the disk container
> "content_type" property as "iso" before the upload.
> Once the ISO exists on an active storage domain in the data center it will
> be possible to attach it to a VM as a CDROM device either through the "Edit
> VM" dialog or through the APIs (see example in comment #27
>
> So I'm trying it on an HCI Gluster environment of mine for testing.
> I get this in image-proxy.log
>
> (Thread-39 ) INFO 2018-01-14 18:35:38,066 web:95:web:(log_start) START
> [192.168.150.101] PUT /images/0d852f7a-b19e-447d-82ad-966755070701
> (Thread-39 ) WARNING 2018-01-14 18:35:38,067 web:112:web:(log_error) ERROR
> [192.168.150.101] PUT /images/0d852f7a-b19e-447d-82ad-966755070701: [401]
> Not authorized (0.00s)
> (Thread-40 ) INFO 2018-01-14 18:35:38,106 web:95:web:(log_start) START
> [192.168.150.101] PUT /images/0d852f7a-b19e-447d-82ad-966755070701
> (Thread-40 ) WARNING 2018-01-14 18:35:38,106 web:112:web:(log_error) ERROR
> [192.168.150.101] PUT /images/0d852f7a-b19e-447d-82ad-966755070701: [401]
> Not authorized (0.00s)
>
>
> Does this mean the functionality is not completely ready yet or what?
> Any one has already tried on iSCSI and/or FC?
>
> Thanks,
> Gianluca
>
>
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Shutdown all VM's command line

[Wesley Stewart]

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
they are stored, but after pointing directly to it, everything is working
like a champ.

Thanks!


On Thu, Jan 11, 2018 at 6:47 AM, Giorgio Biacchi 
wrote:

> On 01/11/2018 11:44 AM, Kapetanakis Giannis wrote:
>
>> On 10/01/18 22:11, Wesley Stewart wrote:
>>
>>> Marcelo,
>>>
>>> I would greatly appreciate seeing a script!  It would be an excellent
>>> chance for me to learn a bit about using ovirt from the command line as
>>> well!
>>>
>>
>> I'm using something like this with ovirt-shell
>>
>> vm_shutdown:
>> #!/bin/sh
>> LOG=/root/ovirt/vm_shutdown_log
>> echo `date` >> $LOG
>> /usr/bin/ovirt-shell -f /root/ovirt/vm_shutdown_script >> $LOG
>> echo "" >> $LOG
>>
>> vm_shutdown_script:
>> list vms --kwargs status-state=up|grep name | sed s/'name
>>  :'/'action vm'/ | sed -e 's/$/ shutdown/' > /root/ovirt/new_vm_shutdown_sc
>> ript
>> file /root/ovirt/new_vm_shutdown_script
>>
>> new_vm_shutdown_script now lists entries like this:
>> action vm vm1 shutdown
>> action vm vm2 shutdown
>> etc.
>>
>> G
>>
>>
>> ___
>> Users mailing list
>> Users@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/users
>>
>>
> You can use python SDK.
>
> Somthing like this should work
>
> #!/usr/bin/env python
>
> import ovirtsdk4 as sdk
>
> ovaddress = ""
> username="admin@internal"
> password="*"
>
> connection = sdk.Connection(
>   url=ovaddress,
>   username=username,
>   password=password,
>   ca_file='ca.crt',
>   insecure=True
> )
>
> system_service = connection.system_service()
> vms_service = system_service.vms_service()
> vms = vms_service.list()
>
> for vm in vms:
> vm_service = vms_service.vm_service(vm.id)
> vm_service.shutdown()
>
> connection.close()
>
> --
> gb
>
> PGP Key: http://pgp.mit.edu/
> Primary key fingerprint: C510 0765 943E EBED A4F2 69D3 16CC DC90 B9CB 0F34
>
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Are Ovirt updates nessessary after CVE-2017-5754 CVE-2017-5753 CVE-2017-5715

[Derek Atkins]

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  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  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  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 
>> 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 

Re: [ovirt-users] Are Ovirt updates nessessary after CVE-2017-5754 CVE-2017-5753 CVE-2017-5715

[Yaniv Kaul]

On Mon, Jan 15, 2018 at 6:28 PM, Derek Atkins  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  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  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  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
> de...@ihtfp.com www.ihtfp.com
> Computer and Internet Security Consultant
> 
>  ___
>  Users mailing list
>  Users@ovirt.org
>  http://lists.ovirt.org/mailman/listinfo/users
> >>>
> >>>
> >>
> >> --
> >>Derek Atkins 617-623-3745
> >>de...@ihtfp.com www.ihtfp.com
> >>Computer and Internet Security Consultant
> >
>
>
> --
>Derek 

[ovirt-users] ovirt-guest-agent on atomic ?

[Nathanaël Blanchet]

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?

--
Nathanaël Blanchet

Supervision réseau
Pôle Infrastrutures Informatiques
227 avenue Professeur-Jean-Louis-Viala
34193 MONTPELLIER CEDEX 5   
Tél. 33 (0)4 67 54 84 55
Fax  33 (0)4 67 54 84 14
blanc...@abes.fr

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Are Ovirt updates nessessary after CVE-2017-5754 CVE-2017-5753 CVE-2017-5715

[Derek Atkins]

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
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  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  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  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
de...@ihtfp.com www.ihtfp.com
Computer and Internet Security Consultant

 ___
 Users mailing list
 Users@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/users
>>>
>>>
>>
>> --
>>Derek Atkins 617-623-3745
>>de...@ihtfp.com www.ihtfp.com
>>Computer and Internet Security Consultant
>


-- 
   Derek Atkins 617-623-3745
   de...@ihtfp.com www.ihtfp.com
   Computer and Internet Security Consultant

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Are Ovirt updates nessessary after CVE-2017-5754 CVE-2017-5753 CVE-2017-5715

[Arman Khalatyan]

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  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  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  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
>>>de...@ihtfp.com www.ihtfp.com
>>>Computer and Internet Security Consultant
>>>
>>> ___
>>> Users mailing list
>>> Users@ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/users
>>
>>
>
> --
>Derek Atkins 617-623-3745
>de...@ihtfp.com www.ihtfp.com
>Computer and Internet Security Consultant
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Are Ovirt updates nessessary after CVE-2017-5754 CVE-2017-5753 CVE-2017-5715

[Derek Atkins]

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  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  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
>>de...@ihtfp.com www.ihtfp.com
>>Computer and Internet Security Consultant
>>
>> ___
>> Users mailing list
>> Users@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/users
>
>

-- 
   Derek Atkins 617-623-3745
   de...@ihtfp.com www.ihtfp.com
   Computer and Internet Security Consultant
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] hosted-engine unknow stale-data

[Artem Tambovskiy]

Hello,

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 and ovirt-ha-broker but it
gives no effect. I have also tried to shutdown hosted_engine VM, stop
ovirt-ha-agent and ovirt-ha-broker  services disconnect storage and connect
it again  - no effect as well.
Also I tried to reinstall second host from WebGUI - this lead to the
interesting situation - now  hosted-engine --vm-status  shows that both
hosts have the same address.

[root@ovirt1 ~]# hosted-engine --vm-status

--== Host 1 status ==--

conf_on_shared_storage : True
Status up-to-date  : True
Hostname   : ovirt1.telia.ru
Host ID: 1
Engine status  : {"health": "good", "vm": "up",
"detail": "up"}
Score  : 3400
stopped: False
Local maintenance  : False
crc32  : a7758085
local_conf_timestamp   : 259327
Host timestamp : 259327
Extra metadata (valid at timestamp):
metadata_parse_version=1
metadata_feature_version=1
timestamp=259327 (Mon Jan 15 14:06:48 2018)
host-id=1
score=3400
vm_conf_refresh_time=259327 (Mon Jan 15 14:06:48 2018)
conf_on_shared_storage=True
maintenance=False
state=EngineUp
stopped=False


--== Host 2 status ==--

conf_on_shared_storage : True
Status up-to-date  : False
Hostname   : ovirt1.telia.ru
Host ID: 2
Engine status  : unknown stale-data
Score  : 0
stopped: True
Local maintenance  : False
crc32  : c7037c03
local_conf_timestamp   : 7530
Host timestamp : 7530
Extra metadata (valid at timestamp):
metadata_parse_version=1
metadata_feature_version=1
timestamp=7530 (Fri Jan 12 16:10:12 2018)
host-id=2
score=0
vm_conf_refresh_time=7530 (Fri Jan 12 16:10:12 2018)
conf_on_shared_storage=True
maintenance=False
state=AgentStopped
stopped=True

Gluster seems working fine. all gluster nodes showing connected state.

Any advises on how to resolve this situation are highly appreciated!

Regards,
Artem


On Mon, Jan 15, 2018 at 11:45 AM, Kasturi Narra  wrote:

> Hello Artem,
>
> 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 ?
>
> Thanks
> kasturi
>
> On Sat, Jan 13, 2018 at 12:33 AM, Artem Tambovskiy <
> artem.tambovs...@gmail.com> wrote:
>
>> Explored logs on both hosts.
>> broker.log shows no errors.
>>
>> agent.log looking not good:
>>
>> on host1 (which running hosted engine) :
>>
>> MainThread::ERROR::2018-01-12 21:51:03,883::agent::205::ovir
>> t_hosted_engine_ha.agent.agent.Agent::(_run_agent) Traceback (most
>> recent call last):
>>   File 
>> "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/agent.py",
>> line 191, in _run_agent
>> return action(he)
>>   File 
>> "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/agent.py",
>> line 64, in action_proper
>> return he.start_monitoring()
>>   File 
>> "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/hosted_engine.py",
>> line 411, in start_monitoring
>> self._initialize_sanlock()
>>   File 
>> "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/hosted_engine.py",
>> line 749, in _initialize_sanlock
>> "Failed to initialize sanlock, the number of errors has"
>> SanlockInitializationError: Failed to initialize sanlock, the number of
>> errors has exceeded the limit
>>
>> MainThread::ERROR::2018-01-12 21:51:03,884::agent::206::ovir
>> t_hosted_engine_ha.agent.agent.Agent::(_run_agent) Trying to restart
>> agent
>> MainThread::WARNING::2018-01-12 21:51:08,889::agent::209::ovir
>> t_hosted_engine_ha.agent.agent.Agent::(_run_agent) Restarting agent,
>> attempt '1'
>> MainThread::INFO::2018-01-12 21:51:08,919::hosted_engine::2
>> 42::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_get_hostname)
>> Found certificate common name: ovirt1.telia.ru
>> MainThread::INFO::2018-01-12 21:51:08,921::hosted_engine::6
>> 04::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_initialize_vdsm)
>> Initializing VDSM
>> MainThread::INFO::2018-01-12 21:51:11,398::hosted_engine::6
>> 30::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_initialize_storage_images)
>> Connecting the storage
>> 

Re: [ovirt-users] Problems with some vms

[Gobinda Das]

Hi Endre,
 Mount logs will be in below format inside  /var/log/glusterfs :

 /var/log/glusterfs/rhev-data-center-mnt-glusterSD-*\:_engine.log
/var/log/glusterfs/rhev-data-center-mnt-glusterSD-*\:_data.log
/var/log/glusterfs/rhev-data-center-mnt-glusterSD-*\:_vmstore.log

On Mon, Jan 15, 2018 at 11:57 AM, Endre Karlson 
wrote:

> Hi.
>
> What are the gluster mount logs ?
>
> I have these gluster logs.
> cli.log  etc-glusterfs-glusterd.vol.log  glfsheal-engine.log
> glusterd.lognfs.log
> rhev-data-center-mnt-glusterSD-ovirt0:_engine.log  rhev-data-center-mnt-
> glusterSD-ovirt3:_iso.log
> cmd_history.log  glfsheal-data.log   glfsheal-iso.log
>  glustershd.log  rhev-data-center-mnt-glusterSD-ovirt0:_data.log
> rhev-data-center-mnt-glusterSD-ovirt0:_iso.log statedump.log
>
>
> I am running version
> glusterfs-server-3.12.4-1.el7.x86_64
> glusterfs-geo-replication-3.12.4-1.el7.x86_64
> libvirt-daemon-driver-storage-gluster-3.2.0-14.el7_4.7.x86_64
> glusterfs-libs-3.12.4-1.el7.x86_64
> glusterfs-api-3.12.4-1.el7.x86_64
> python2-gluster-3.12.4-1.el7.x86_64
> glusterfs-client-xlators-3.12.4-1.el7.x86_64
> glusterfs-cli-3.12.4-1.el7.x86_64
> glusterfs-events-3.12.4-1.el7.x86_64
> glusterfs-rdma-3.12.4-1.el7.x86_64
> vdsm-gluster-4.20.9.3-1.el7.centos.noarch
> glusterfs-3.12.4-1.el7.x86_64
> glusterfs-fuse-3.12.4-1.el7.x86_64
>
> // Endre
>
> 2018-01-15 6:11 GMT+01:00 Gobinda Das :
>
>> Hi Endre,
>>  Can you please provide glusterfs mount logs?
>>
>> On Mon, Jan 15, 2018 at 6:16 AM, Darrell Budic 
>> wrote:
>>
>>> What version of gluster are you running? I’ve seen a few of these since
>>> moving my storage cluster to 12.3, but still haven’t been able to determine
>>> what’s causing it. Seems to be happening most often on VMs that haven’t
>>> been switches over to libgfapi mounts yet, but even one of those has paused
>>> once so far. They generally restart fine from the GUI, and nothing seems to
>>> need healing.
>>>
>>> --
>>> *From:* Endre Karlson 
>>> *Subject:* [ovirt-users] Problems with some vms
>>> *Date:* January 14, 2018 at 12:55:45 PM CST
>>> *To:* users
>>>
>>> Hi, we are getting some errors with some of our vms in a 3 node server
>>> setup.
>>>
>>> 2018-01-14 15:01:44,015+0100 INFO  (libvirt/events) [virt.vm]
>>> (vmId='2c34f52d-140b-4dbe-a4bd-d2cb467b0b7c') abnormal vm stop device
>>> virtio-disk0  error eother (vm:4880)
>>>
>>> We are running glusterfs for shared storage.
>>>
>>> I have tried setting global maintenance on the first server and then
>>> issuing a 'hosted-engine --vm-start' but that leads to nowhere.
>>> ___
>>> Users mailing list
>>> Users@ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/users
>>>
>>>
>>>
>>> ___
>>> Users mailing list
>>> Users@ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/users
>>>
>>>
>>
>>
>> --
>> Thanks,
>> Gobinda
>> +91-9019047912 <+91%2090190%2047912>
>>
>
>


-- 
Thanks,
Gobinda
+91-9019047912
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] ha-agent and broker continually crashing after 4.2 update

[Martin Sivak]

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:
(u'8582bdfc-ef54-47af-9f1e-f5b7ec1f1cf8',)

I have to ask how old the environment is. Was it by any chance
installed back in 3.3/3.4 days and upgraded since then?

Martin

On Mon, Jan 15, 2018 at 10:17 AM, Simone Tiraboschi  wrote:
>
>
> 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
>> my hosts.  Everything is up and working fine otherwise, all VMs running and
>> hosted engine VM is running along with interface etc.
>
>
> I think it's due to https://bugzilla.redhat.com/show_bug.cgi?id=1527394 with
> got recently fixed.
> ovirt-hosted-engine-ha-2.2.3 should address it, please let us know if not.
>
>
>>
>>
>> Jan 12 16:52:34 cultivar0 journal: vdsm storage.Dispatcher ERROR FINISH
>> prepareImage error=Volume does not exist:
>> (u'8582bdfc-ef54-47af-9f1e-f5b7ec1f1cf8',)
>> Jan 12 16:52:34 cultivar0 python: detected unhandled Python exception in
>> '/usr/share/ovirt-hosted-engine-ha/ovirt-ha-broker'
>> Jan 12 16:52:34 cultivar0 abrt-server: Not saving repeating crash in
>> '/usr/share/ovirt-hosted-engine-ha/ovirt-ha-broker'
>> Jan 12 16:52:34 cultivar0 systemd: ovirt-ha-broker.service: main process
>> exited, code=exited, status=1/FAILURE
>> Jan 12 16:52:34 cultivar0 systemd: Unit ovirt-ha-broker.service entered
>> failed state.
>> Jan 12 16:52:34 cultivar0 systemd: ovirt-ha-broker.service failed.
>> Jan 12 16:52:34 cultivar0 systemd: ovirt-ha-broker.service holdoff time
>> over, scheduling restart.
>> Jan 12 16:52:34 cultivar0 systemd: Cannot add dependency job for unit
>> lvm2-lvmetad.socket, ignoring: Unit is masked.
>> Jan 12 16:52:34 cultivar0 systemd: Started oVirt Hosted Engine High
>> Availability Communications Broker.
>> Jan 12 16:52:34 cultivar0 systemd: Starting oVirt Hosted Engine High
>> Availability Communications Broker...
>> Jan 12 16:52:36 cultivar0 journal: vdsm storage.TaskManager.Task ERROR
>> (Task='73141dec-9d8f-4164-9c4e-67c43a102eff') Unexpected error#012Traceback
>> (most recent call last):#012  File
>> "/usr/lib/python2.7/site-packages/vdsm/storage/task.py", line 882, in
>> _run#012return fn(*args, **kargs)#012  File "", line 2, in
>> prepareImage#012  File
>> "/usr/lib/python2.7/site-packages/vdsm/common/api.py", line 48, in
>> method#012ret = func(*args, **kwargs)#012  File
>> "/usr/lib/python2.7/site-packages/vdsm/storage/hsm.py", line 3162, in
>> prepareImage#012raise
>> se.VolumeDoesNotExist(leafUUID)#012VolumeDoesNotExist: Volume does not
>> exist: (u'8582bdfc-ef54-47af-9f1e-f5b7ec1f1cf8',)
>> Jan 12 16:52:36 cultivar0 journal: vdsm storage.Dispatcher ERROR FINISH
>> prepareImage error=Volume does not exist:
>> (u'8582bdfc-ef54-47af-9f1e-f5b7ec1f1cf8',)
>> Jan 12 16:52:36 cultivar0 python: detected unhandled Python exception in
>> '/usr/share/ovirt-hosted-engine-ha/ovirt-ha-broker'
>> Jan 12 16:52:36 cultivar0 abrt-server: Not saving repeating crash in
>> '/usr/share/ovirt-hosted-engine-ha/ovirt-ha-broker'
>> Jan 12 16:52:36 cultivar0 systemd: ovirt-ha-broker.service: main process
>> exited, code=exited, status=1/FAILURE
>> Jan 12 16:52:36 cultivar0 systemd: Unit ovirt-ha-broker.service entered
>> failed state.
>> Jan 12 16:52:36 cultivar0 systemd: ovirt-ha-broker.service failed.
>>
>> Jan 12 16:52:36 cultivar0 systemd: ovirt-ha-broker.service holdoff time
>> over, scheduling restart.
>> Jan 12 16:52:36 cultivar0 systemd: Cannot add dependency job for unit
>> lvm2-lvmetad.socket, ignoring: Unit is masked.
>> Jan 12 16:52:36 cultivar0 systemd: Started oVirt Hosted Engine High
>> Availability Communications Broker.
>> Jan 12 16:52:36 cultivar0 systemd: Starting oVirt Hosted Engine High
>> Availability Communications Broker...
>> Jan 12 16:52:37 cultivar0 journal: vdsm storage.TaskManager.Task ERROR
>> (Task='bc7af1e2-0ab2-4164-ae88-d2bee03500f9') Unexpected error#012Traceback
>> (most recent call last):#012  File
>> "/usr/lib/python2.7/site-packages/vdsm/storage/task.py", line 882, in
>> _run#012return fn(*args, **kargs)#012  File "", line 2, in
>> prepareImage#012  File
>> "/usr/lib/python2.7/site-packages/vdsm/common/api.py", line 48, in
>> method#012ret = func(*args, **kwargs)#012  File
>> "/usr/lib/python2.7/site-packages/vdsm/storage/hsm.py", line 3162, in
>> prepareImage#012raise
>> se.VolumeDoesNotExist(leafUUID)#012VolumeDoesNotExist: Volume does not
>> exist: (u'8582bdfc-ef54-47af-9f1e-f5b7ec1f1cf8',)
>> Jan 12 16:52:37 cultivar0 journal: vdsm storage.Dispatcher ERROR FINISH
>> prepareImage error=Volume does 

Re: [ovirt-users] ha-agent and broker continually crashing after 4.2 update

[Simone Tiraboschi]

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
> my hosts.  Everything is up and working fine otherwise, all VMs running and
> hosted engine VM is running along with interface etc.
>

I think it's due to https://bugzilla.redhat.com/show_bug.cgi?id=1527394
with got recently fixed.
ovirt-hosted-engine-ha-2.2.3 should address it, please let us know if not.



>
> Jan 12 16:52:34 cultivar0 journal: vdsm storage.Dispatcher ERROR FINISH
> prepareImage error=Volume does not exist: (u'8582bdfc-ef54-47af-9f1e-
> f5b7ec1f1cf8',)
> Jan 12 16:52:34 cultivar0 python: detected unhandled Python exception in
> '/usr/share/ovirt-hosted-engine-ha/ovirt-ha-broker'
> Jan 12 16:52:34 cultivar0 abrt-server: Not saving repeating crash in
> '/usr/share/ovirt-hosted-engine-ha/ovirt-ha-broker'
> Jan 12 16:52:34 cultivar0 systemd: ovirt-ha-broker.service: main process
> exited, code=exited, status=1/FAILURE
> Jan 12 16:52:34 cultivar0 systemd: Unit ovirt-ha-broker.service entered
> failed state.
> Jan 12 16:52:34 cultivar0 systemd: ovirt-ha-broker.service failed.
> Jan 12 16:52:34 cultivar0 systemd: ovirt-ha-broker.service holdoff time
> over, scheduling restart.
> Jan 12 16:52:34 cultivar0 systemd: Cannot add dependency job for unit
> lvm2-lvmetad.socket, ignoring: Unit is masked.
> Jan 12 16:52:34 cultivar0 systemd: Started oVirt Hosted Engine High
> Availability Communications Broker.
> Jan 12 16:52:34 cultivar0 systemd: Starting oVirt Hosted Engine High
> Availability Communications Broker...
> Jan 12 16:52:36 cultivar0 journal: vdsm storage.TaskManager.Task ERROR
> (Task='73141dec-9d8f-4164-9c4e-67c43a102eff') Unexpected
> error#012Traceback (most recent call last):#012  File
> "/usr/lib/python2.7/site-packages/vdsm/storage/task.py", line 882, in
> _run#012return fn(*args, **kargs)#012  File "", line 2, in
> prepareImage#012  File "/usr/lib/python2.7/site-packages/vdsm/common/api.py",
> line 48, in method#012ret = func(*args, **kwargs)#012  File
> "/usr/lib/python2.7/site-packages/vdsm/storage/hsm.py", line 3162, in
> prepareImage#012raise 
> se.VolumeDoesNotExist(leafUUID)#012VolumeDoesNotExist:
> Volume does not exist: (u'8582bdfc-ef54-47af-9f1e-f5b7ec1f1cf8',)
> Jan 12 16:52:36 cultivar0 journal: vdsm storage.Dispatcher ERROR FINISH
> prepareImage error=Volume does not exist: (u'8582bdfc-ef54-47af-9f1e-
> f5b7ec1f1cf8',)
> Jan 12 16:52:36 cultivar0 python: detected unhandled Python exception in
> '/usr/share/ovirt-hosted-engine-ha/ovirt-ha-broker'
> Jan 12 16:52:36 cultivar0 abrt-server: Not saving repeating crash in
> '/usr/share/ovirt-hosted-engine-ha/ovirt-ha-broker'
> Jan 12 16:52:36 cultivar0 systemd: ovirt-ha-broker.service: main process
> exited, code=exited, status=1/FAILURE
> Jan 12 16:52:36 cultivar0 systemd: Unit ovirt-ha-broker.service entered
> failed state.
> Jan 12 16:52:36 cultivar0 systemd: ovirt-ha-broker.service failed.
>
> Jan 12 16:52:36 cultivar0 systemd: ovirt-ha-broker.service holdoff time
> over, scheduling restart.
> Jan 12 16:52:36 cultivar0 systemd: Cannot add dependency job for unit
> lvm2-lvmetad.socket, ignoring: Unit is masked.
> Jan 12 16:52:36 cultivar0 systemd: Started oVirt Hosted Engine High
> Availability Communications Broker.
> Jan 12 16:52:36 cultivar0 systemd: Starting oVirt Hosted Engine High
> Availability Communications Broker...
> Jan 12 16:52:37 cultivar0 journal: vdsm storage.TaskManager.Task ERROR
> (Task='bc7af1e2-0ab2-4164-ae88-d2bee03500f9') Unexpected
> error#012Traceback (most recent call last):#012  File
> "/usr/lib/python2.7/site-packages/vdsm/storage/task.py", line 882, in
> _run#012return fn(*args, **kargs)#012  File "", line 2, in
> prepareImage#012  File "/usr/lib/python2.7/site-packages/vdsm/common/api.py",
> line 48, in method#012ret = func(*args, **kwargs)#012  File
> "/usr/lib/python2.7/site-packages/vdsm/storage/hsm.py", line 3162, in
> prepareImage#012raise 
> se.VolumeDoesNotExist(leafUUID)#012VolumeDoesNotExist:
> Volume does not exist: (u'8582bdfc-ef54-47af-9f1e-f5b7ec1f1cf8',)
> Jan 12 16:52:37 cultivar0 journal: vdsm storage.Dispatcher ERROR FINISH
> prepareImage error=Volume does not exist: (u'8582bdfc-ef54-47af-9f1e-
> f5b7ec1f1cf8',)
> Jan 12 16:52:37 cultivar0 python: detected unhandled Python exception in
> '/usr/share/ovirt-hosted-engine-ha/ovirt-ha-broker'
> Jan 12 16:52:38 cultivar0 abrt-server: Not saving repeating crash in
> '/usr/share/ovirt-hosted-engine-ha/ovirt-ha-broker'
> Jan 12 16:52:38 cultivar0 systemd: ovirt-ha-broker.service: main process
> exited, code=exited, status=1/FAILURE
> Jan 12 16:52:38 cultivar0 systemd: Unit ovirt-ha-broker.service entered
> failed state.
> Jan 12 16:52:38 cultivar0 systemd: ovirt-ha-broker.service failed.
> Jan 12 16:52:38 cultivar0 systemd: 

Re: [ovirt-users] hosted-engine unknow stale-data

[Kasturi Narra]

Hello Artem,

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 ?

Thanks
kasturi

On Sat, Jan 13, 2018 at 12:33 AM, Artem Tambovskiy <
artem.tambovs...@gmail.com> wrote:

> Explored logs on both hosts.
> broker.log shows no errors.
>
> agent.log looking not good:
>
> on host1 (which running hosted engine) :
>
> MainThread::ERROR::2018-01-12 21:51:03,883::agent::205::
> ovirt_hosted_engine_ha.agent.agent.Agent::(_run_agent) Traceback (most
> recent call last):
>   File 
> "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/agent.py",
> line 191, in _run_agent
> return action(he)
>   File 
> "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/agent.py",
> line 64, in action_proper
> return he.start_monitoring()
>   File 
> "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/hosted_engine.py",
> line 411, in start_monitoring
> self._initialize_sanlock()
>   File 
> "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/hosted_engine.py",
> line 749, in _initialize_sanlock
> "Failed to initialize sanlock, the number of errors has"
> SanlockInitializationError: Failed to initialize sanlock, the number of
> errors has exceeded the limit
>
> MainThread::ERROR::2018-01-12 21:51:03,884::agent::206::
> ovirt_hosted_engine_ha.agent.agent.Agent::(_run_agent) Trying to restart
> agent
> MainThread::WARNING::2018-01-12 21:51:08,889::agent::209::
> ovirt_hosted_engine_ha.agent.agent.Agent::(_run_agent) Restarting agent,
> attempt '1'
> MainThread::INFO::2018-01-12 21:51:08,919::hosted_engine::
> 242::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_get_hostname)
> Found certificate common name: ovirt1.telia.ru
> MainThread::INFO::2018-01-12 21:51:08,921::hosted_engine::
> 604::ovirt_hosted_engine_ha.agent.hosted_engine.
> HostedEngine::(_initialize_vdsm) Initializing VDSM
> MainThread::INFO::2018-01-12 21:51:11,398::hosted_engine::
> 630::ovirt_hosted_engine_ha.agent.hosted_engine.
> HostedEngine::(_initialize_storage_images) Connecting the storage
> MainThread::INFO::2018-01-12 21:51:11,399::storage_server::
> 220::ovirt_hosted_engine_ha.lib.storage_server.StorageServer::(validate_storage_server)
> Validating storage server
> MainThread::INFO::2018-01-12 21:51:13,725::storage_server::
> 239::ovirt_hosted_engine_ha.lib.storage_server.StorageServer::(connect_storage_server)
> Connecting storage server
> MainThread::INFO::2018-01-12 21:51:18,390::storage_server::
> 246::ovirt_hosted_engine_ha.lib.storage_server.StorageServer::(connect_storage_server)
> Connecting storage server
> MainThread::INFO::2018-01-12 21:51:18,423::storage_server::
> 253::ovirt_hosted_engine_ha.lib.storage_server.StorageServer::(connect_storage_server)
> Refreshing the storage domain
> MainThread::INFO::2018-01-12 21:51:18,689::hosted_engine::
> 663::ovirt_hosted_engine_ha.agent.hosted_engine.
> HostedEngine::(_initialize_storage_images) Preparing images
> MainThread::INFO::2018-01-12 21:51:18,690::image::126::
> ovirt_hosted_engine_ha.lib.image.Image::(prepare_images) Preparing images
> MainThread::INFO::2018-01-12 21:51:21,895::hosted_engine::
> 666::ovirt_hosted_engine_ha.agent.hosted_engine.
> HostedEngine::(_initialize_storage_images) Refreshing vm.conf
> MainThread::INFO::2018-01-12 21:51:21,895::config::493::
> ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine.config::(refresh_vm_conf)
> Reloading vm.conf from the shared storage domain
> MainThread::INFO::2018-01-12 21:51:21,896::config::416::
> ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine.
> config::(_get_vm_conf_content_from_ovf_store) Trying to get a fresher
> copy of vm configuration from the OVF_STORE
> MainThread::INFO::2018-01-12 21:51:21,896::ovf_store::132::
> ovirt_hosted_engine_ha.lib.ovf.ovf_store.OVFStore::(getEngineVMOVF)
> Extracting Engine VM OVF from the OVF_STORE
> MainThread::INFO::2018-01-12 21:51:21,897::ovf_store::134::
> ovirt_hosted_engine_ha.lib.ovf.ovf_store.OVFStore::(getEngineVMOVF)
> OVF_STORE volume path: /var/run/vdsm/storage/4a7f8717-9bb0-4d80-8016-
> 498fa4b88162/5cabd8e1-5f4b-469e-becc-227469e03f5c/8048cbd7-77e2-4805-9af4-
> d109fa36dfcf
> MainThread::INFO::2018-01-12 21:51:21,915::config::435::
> ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine.
> config::(_get_vm_conf_content_from_ovf_store) Found an OVF for HE VM,
> trying to convert
> MainThread::INFO::2018-01-12 21:51:21,918::config::440::
> ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine.
> config::(_get_vm_conf_content_from_ovf_store) Got vm.conf from OVF_STORE
> MainThread::INFO::2018-01-12 21:51:21,919::hosted_engine::
> 509::ovirt_hosted_engine_ha.agent.hosted_engine.
> HostedEngine::(_initialize_broker) Initializing ha-broker connection
> MainThread::INFO::2018-01-12 21:51:21,919::brokerlink::130:
> 

Re: [ovirt-users] (no subject)

[Kasturi Narra]

Hello,

Can you attach ovirt-ha-agent and ovirt-ha-broker logs ?

Thanks
kasturi

On Fri, Jan 12, 2018 at 9:38 PM, Artem Tambovskiy <
artem.tambovs...@gmail.com> wrote:

> Trying to fix one thing I broke another :(
>
> I fixed mnt_options for hosted engine storage domain and installed latest
> security patches to my hosts and hosted engine. All VM's up and running,
> but  hosted_engine --vm-status reports about issues:
>
> [root@ovirt1 ~]# hosted-engine --vm-status
>
>
> --== Host 1 status ==--
>
> conf_on_shared_storage : True
> Status up-to-date  : False
> Hostname   : ovirt2
> Host ID: 1
> Engine status  : unknown stale-data
> Score  : 0
> stopped: False
> Local maintenance  : False
> crc32  : 193164b8
> local_conf_timestamp   : 8350
> Host timestamp : 8350
> Extra metadata (valid at timestamp):
> metadata_parse_version=1
> metadata_feature_version=1
> timestamp=8350 (Fri Jan 12 19:03:54 2018)
> host-id=1
> score=0
> vm_conf_refresh_time=8350 (Fri Jan 12 19:03:54 2018)
> conf_on_shared_storage=True
> maintenance=False
> state=EngineUnexpectedlyDown
> stopped=False
> timeout=Thu Jan  1 05:24:43 1970
>
>
> --== Host 2 status ==--
>
> conf_on_shared_storage : True
> Status up-to-date  : False
> Hostname   : ovirt1.telia.ru
> Host ID: 2
> Engine status  : unknown stale-data
> Score  : 0
> stopped: True
> Local maintenance  : False
> crc32  : c7037c03
> local_conf_timestamp   : 7530
> Host timestamp : 7530
> Extra metadata (valid at timestamp):
> metadata_parse_version=1
> metadata_feature_version=1
> timestamp=7530 (Fri Jan 12 16:10:12 2018)
> host-id=2
> score=0
> vm_conf_refresh_time=7530 (Fri Jan 12 16:10:12 2018)
> conf_on_shared_storage=True
> maintenance=False
> state=AgentStopped
> stopped=True
> [root@ovirt1 ~]#
>
>
>
> from second host situation looks a bit different:
>
>
> [root@ovirt2 ~]# hosted-engine --vm-status
>
>
> --== Host 1 status ==--
>
> conf_on_shared_storage : True
> Status up-to-date  : True
> Hostname   : ovirt2
> Host ID: 1
> Engine status  : {"reason": "vm not running on this
> host", "health": "bad", "vm": "down", "detail": "unknown"}
> Score  : 0
> stopped: False
> Local maintenance  : False
> crc32  : 78eabdb6
> local_conf_timestamp   : 8403
> Host timestamp : 8402
> Extra metadata (valid at timestamp):
> metadata_parse_version=1
> metadata_feature_version=1
> timestamp=8402 (Fri Jan 12 19:04:47 2018)
> host-id=1
> score=0
> vm_conf_refresh_time=8403 (Fri Jan 12 19:04:47 2018)
> conf_on_shared_storage=True
> maintenance=False
> state=EngineUnexpectedlyDown
> stopped=False
> timeout=Thu Jan  1 05:24:43 1970
>
>
> --== Host 2 status ==--
>
> conf_on_shared_storage : True
> Status up-to-date  : False
> Hostname   : ovirt1.telia.ru
> Host ID: 2
> Engine status  : unknown stale-data
> Score  : 0
> stopped: True
> Local maintenance  : False
> crc32  : c7037c03
> local_conf_timestamp   : 7530
> Host timestamp : 7530
> Extra metadata (valid at timestamp):
> metadata_parse_version=1
> metadata_feature_version=1
> timestamp=7530 (Fri Jan 12 16:10:12 2018)
> host-id=2
> score=0
> vm_conf_refresh_time=7530 (Fri Jan 12 16:10:12 2018)
> conf_on_shared_storage=True
> maintenance=False
> state=AgentStopped
> stopped=True
>
>
> WebGUI shows that engine running on host ovirt1.
> Gluster looks fine
> [root@ovirt1 ~]# gluster volume status engine
> Status of volume: engine
> Gluster process TCP Port  RDMA Port  Online
>  Pid
> 
> --
> Brick ovirt1.telia.ru:/oVirt/engine 49169 0  Y
> 3244
> Brick ovirt2.telia.ru:/oVirt/engine 49179 0  Y
> 20372
> Brick ovirt3.telia.ru:/oVirt/engine 49206 0  Y