date:20201215

Ok it's done bugzilla 1907973, i found this message 
"Guest CPU doesn't match specification: missing features: tsx-ctrl 
(migration:294)" it's seems you're theory is good. 



De: "Arik Hadas"  
À: "Lionel Caignec"  
Cc: "users"  
Envoyé: Mardi 15 Décembre 2020 15:50:26 
Objet: Re: [ovirt-users] Re: Bad CPU TYPE after Centos 8.3 



On Tue, Dec 15, 2020 at 4:41 PM Lionel Caignec < [ mailto:caig...@cines.fr | 
caig...@cines.fr ] > wrote: 



Hi Arik, 

Yes, my problem about cpu type, seems linked to the fact i've upgraded a host 
in 8.3 before ugprade ovirt in 4.3... 

I've done another test, for my problem of vm migration. 
I start a guest directly on the 8.3 nodes then it can be migrate from/to 
8.2/83. 
I've also tried to force it to start on a 8.2 nodes then migrate to 8.3 nodes, 
and it also work. 



BQ_BEGIN


So it seems a full power cycle on guest resolve issue. 

BQ_END

Thanks for checking this - it makes sense that when the VM starts with CPU type 
and flags that are derived from the new cluster configuration, the issue 
doesn't happen anymore. 

BQ_BEGIN


Ok for opening a bug on vdsm, could you please let me know where? 

BQ_END

Sure - [ https://bugzilla.redhat.com/enter_bug.cgi?product=vdsm | 
https://bugzilla.redhat.com/enter_bug.cgi?product=vdsm ] 

BQ_BEGIN



Thank you. 


De: "Arik Hadas" < [ mailto:aha...@redhat.com | aha...@redhat.com ] > 
À: "Lionel Caignec" < [ mailto:caig...@cines.fr | caig...@cines.fr ] > 
Cc: "Lucia Jelinkova" < [ mailto:ljeli...@redhat.com | ljeli...@redhat.com ] >, 
"thomas" < [ mailto:tho...@hoberg.net | tho...@hoberg.net ] >, "users" < [ 
mailto:users@ovirt.org | users@ovirt.org ] > 
Envoyé: Mardi 15 Décembre 2020 15:21:22 
Objet: Re: [ovirt-users] Re: Bad CPU TYPE after Centos 8.3 


On Tue, Dec 15, 2020 at 3:29 PM Lionel Caignec < [ mailto:caig...@cines.fr | 
caig...@cines.fr ] > wrote: 

BQ_BEGIN

Hi 

thank you it's work now. All my host 8.2/8.3 are up and running. During 
reactivation of 8.2 host i saw the log line "updating cluster CPU..." 

BQ_END

Good to see that it works for you now (the credit to Lucia). 
So the cluster configuration didn't change because not all hosts were UP when 
starting the 4.4.3 engine? 

BQ_BEGIN


I tried to move guest from 8.2 host to 8.3 one but it failed. 


Engine.log : 
ERROR [org.ovirt.engine.core.vdsbroker.monitoring.VmAnalyzer] 
(ForkJoinPool-1-worker-27) [] Migration of VM 'pc115dev' to host ' [ 
http://bombur-adm.cines.fr/ | bombur-adm.cines.fr ] ' failed: VM destroyed 
during the startup. 
ERROR [org.ovirt.engine.core.vdsbroker.monitoring.VmsMonitoring] 
(ForkJoinPool-1-worker-19) [] Rerun VM '4fd61e41-ea48-4ba8-b78f-dba5acb87c9e'. 
Called from VDS ' [ http://dis-adm.cines.fr/ | dis-adm.cines.fr ] ' 
ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] 
(EE-ManagedThreadFactory-engine-Thread-4) [] EVENT_ID: 
VM_MIGRATION_TO_SERVER_FAILED(120), Migration failed (VM: pc115dev, Source: [ 
http://dis-adm.cines.fr/ | dis-adm.cines.fr ] , Destination: [ 
http://bombur-adm.cines.fr/ | bombur-adm.cines.fr ] ). 
ERROR [org.ovirt.engine.core.vdsbroker.monitoring.VmAnalyzer] 
(ForkJoinPool-1-worker-13) [] Migration of VM 'pc115dev' to host ' [ 
http://bombur-adm.cines.fr/ | bombur-adm.cines.fr ] ' failed: VM destroyed 
during the startup. 
ERROR [org.ovirt.engine.core.vdsbroker.monitoring.VmsMonitoring] 
(EE-ManagedScheduledExecutorService-engineScheduledThreadPool-Thread-39) [] 
Rerun VM '4fd61e41-ea48-4ba8-b78f-dba5acb87c9e'. Called from VDS ' [ 
http://dis-adm.cines.fr/ | dis-adm.cines.fr ] ' 
ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] 
(EE-ManagedThreadFactory-engine-Thread-38) [] EVENT_ID: 
VM_MIGRATION_TO_SERVER_FAILED(120), Migration failed (VM: pc115dev, Source: [ 
http://dis-adm.cines.fr/ | dis-adm.cines.fr ] , Destination: [ 
http://bombur-adm.cines.fr/ | bombur-adm.cines.fr ] ). 


vdsm.log (target host) : 
WARN (Reactor thread) [vds.dispatcher] unhandled write event 
(betterAsyncore:184) 
WARN (jsonrpc/7) [root] ping was deprecated in favor of ping2 and 
confirmConnectivity (API:1349) 
WARN (vm/4fd61e41) [virt.vm] (vmId='4fd61e41-ea48-4ba8-b78f-dba5acb87c9e') 
Couldn't destroy incoming VM: Domaine non trouvé : aucun domaine ne correspond 
à l'UUID '4fd61e41-ea48-4ba8-b78f-dba5acb87c9e' (vm:3738) 

BQ_END

The migration probably fails due to incompatible CPU flags - please file a bug 
and attach VDSM and libvirt logs from both source and destination hosts. 

BQ_BEGIN


Another think i've noticed on event log of 8.3 host : 
VDSM [ http://bombur-adm.cines.fr/ | bombur-adm.cines.fr ] command SpmStatusVDS 
failed: Cannot inquire Lease(name='SDM', 
path='/dev/7586152d-338c-415d-93f4-74efd09c02fa/leases', offset=1048576): (2, 
'Sanlock get hosts failure', 'No such file or directory') 


But file seems to exist on host : 
ls -l /dev/7586152d-338c-415d-93f4-74efd09c02fa/leases 
lrwxrwxrwx. 1 root root 7 Dec 15 14:14 
/dev/7586152d-338c-415d-93f4-74efd09c02fa/lease

[ovirt-users] Re: Bad CPU TYPE after Centos 8.3

2020-12-15 Thread Arik Hadas

On Tue, Dec 15, 2020 at 4:41 PM Lionel Caignec  wrote:

> Hi Arik,
>
> Yes, my problem about cpu type, seems linked to the fact i've upgraded a
> host in 8.3 before ugprade ovirt in 4.3...
>
> I've done another test, for my problem of vm migration.
> I start a guest directly on the 8.3 nodes then it can be migrate from/to
> 8.2/83.
> I've also tried to force it to start on a 8.2 nodes then migrate to 8.3
> nodes, and it also work.
>

> So it seems a full power cycle on guest resolve issue.
>

Thanks for checking this - it makes sense that when the VM starts with CPU
type and flags that are derived from the new cluster configuration, the
issue doesn't happen anymore.


>
> Ok for opening a bug on vdsm, could you please let me know where?
>

Sure - https://bugzilla.redhat.com/enter_bug.cgi?product=vdsm


>
>
> Thank you.
>
> --
> *De: *"Arik Hadas" 
> *À: *"Lionel Caignec" 
> *Cc: *"Lucia Jelinkova" , "thomas" ,
> "users" 
> *Envoyé: *Mardi 15 Décembre 2020 15:21:22
> *Objet: *Re: [ovirt-users] Re: Bad CPU TYPE after Centos 8.3
>
>
> On Tue, Dec 15, 2020 at 3:29 PM Lionel Caignec  wrote:
>
>> Hi
>>
>> thank you it's work now. All my host 8.2/8.3 are up and running. During
>> reactivation of 8.2 host i saw the log line "updating cluster CPU..."
>>
>
> Good to see that it works for you now (the credit to Lucia).
> So the cluster configuration didn't change because not all hosts were UP
> when starting the 4.4.3 engine?
>
>
>>
>> I tried to move guest from 8.2 host to 8.3 one but it failed.
>>
>>
>> Engine.log :
>> ERROR [org.ovirt.engine.core.vdsbroker.monitoring.VmAnalyzer]
>> (ForkJoinPool-1-worker-27) [] Migration of VM 'pc115dev' to host '
>> bombur-adm.cines.fr' failed: VM destroyed during the startup.
>> ERROR [org.ovirt.engine.core.vdsbroker.monitoring.VmsMonitoring]
>> (ForkJoinPool-1-worker-19) [] Rerun VM
>> '4fd61e41-ea48-4ba8-b78f-dba5acb87c9e'. Called from VDS 'dis-adm.cines.fr
>> '
>> ERROR
>> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
>> (EE-ManagedThreadFactory-engine-Thread-4) [] EVENT_ID:
>> VM_MIGRATION_TO_SERVER_FAILED(120), Migration failed  (VM: pc115dev,
>> Source: dis-adm.cines.fr, Destination: bombur-adm.cines.fr).
>> ERROR [org.ovirt.engine.core.vdsbroker.monitoring.VmAnalyzer]
>> (ForkJoinPool-1-worker-13) [] Migration of VM 'pc115dev' to host '
>> bombur-adm.cines.fr' failed: VM destroyed during the startup.
>> ERROR [org.ovirt.engine.core.vdsbroker.monitoring.VmsMonitoring]
>> (EE-ManagedScheduledExecutorService-engineScheduledThreadPool-Thread-39) []
>> Rerun VM '4fd61e41-ea48-4ba8-b78f-dba5acb87c9e'. Called from VDS '
>> dis-adm.cines.fr'
>> ERROR
>> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
>> (EE-ManagedThreadFactory-engine-Thread-38) [] EVENT_ID:
>> VM_MIGRATION_TO_SERVER_FAILED(120), Migration failed  (VM: pc115dev,
>> Source: dis-adm.cines.fr, Destination: bombur-adm.cines.fr).
>>
>>
>> vdsm.log (target host) :
>> WARN  (Reactor thread) [vds.dispatcher] unhandled write event
>> (betterAsyncore:184)
>> WARN  (jsonrpc/7) [root] ping was deprecated in favor of ping2 and
>> confirmConnectivity (API:1349)
>> WARN  (vm/4fd61e41) [virt.vm]
>> (vmId='4fd61e41-ea48-4ba8-b78f-dba5acb87c9e') Couldn't destroy incoming VM:
>> Domaine non trouvé : aucun domaine ne correspond à l'UUID
>> '4fd61e41-ea48-4ba8-b78f-dba5acb87c9e' (vm:3738)
>>
>
> The migration probably fails due to incompatible CPU flags - please file a
> bug and attach VDSM and libvirt logs from both source and destination hosts.
>
>
>>
>> Another think i've noticed on event log of 8.3 host :
>> VDSM bombur-adm.cines.fr command SpmStatusVDS failed: Cannot inquire
>> Lease(name='SDM', path='/dev/7586152d-338c-415d-93f4-74efd09c02fa/leases',
>> offset=1048576): (2, 'Sanlock get hosts failure', 'No such file or
>> directory')
>>
>>
>> But file seems to exist on host :
>> ls -l /dev/7586152d-338c-415d-93f4-74efd09c02fa/leases
>> lrwxrwxrwx. 1 root root 7 Dec 15 14:14
>> /dev/7586152d-338c-415d-93f4-74efd09c02fa/leases -> ../dm-7
>>
>>
>> I tried to reboot host  & restart engine, set my 8.3 host as SPM ... same
>> error.
>>
>>
>> Lionel.
>>
>
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/EDCFMNH33MK2I5H2EZSLU2DPZHDHVY7F/

[ovirt-users] Re: Bad CPU TYPE after Centos 8.3

Hi Arik, 

Yes, my problem about cpu type, seems linked to the fact i've upgraded a host 
in 8.3 before ugprade ovirt in 4.3... 

I've done another test, for my problem of vm migration. 
I start a guest directly on the 8.3 nodes then it can be migrate from/to 
8.2/83. 
I've also tried to force it to start on a 8.2 nodes then migrate to 8.3 nodes, 
and it also work. 

So it seems a full power cycle on guest resolve issue. 

Ok for opening a bug on vdsm, could you please let me know where? 


Thank you. 


De: "Arik Hadas"  
À: "Lionel Caignec"  
Cc: "Lucia Jelinkova" , "thomas" , 
"users"  
Envoyé: Mardi 15 Décembre 2020 15:21:22 
Objet: Re: [ovirt-users] Re: Bad CPU TYPE after Centos 8.3 


On Tue, Dec 15, 2020 at 3:29 PM Lionel Caignec < [ mailto:caig...@cines.fr | 
caig...@cines.fr ] > wrote: 



Hi 

thank you it's work now. All my host 8.2/8.3 are up and running. During 
reactivation of 8.2 host i saw the log line "updating cluster CPU..." 



Good to see that it works for you now (the credit to Lucia). 
So the cluster configuration didn't change because not all hosts were UP when 
starting the 4.4.3 engine? 

BQ_BEGIN


I tried to move guest from 8.2 host to 8.3 one but it failed. 


Engine.log : 
ERROR [org.ovirt.engine.core.vdsbroker.monitoring.VmAnalyzer] 
(ForkJoinPool-1-worker-27) [] Migration of VM 'pc115dev' to host ' [ 
http://bombur-adm.cines.fr/ | bombur-adm.cines.fr ] ' failed: VM destroyed 
during the startup. 
ERROR [org.ovirt.engine.core.vdsbroker.monitoring.VmsMonitoring] 
(ForkJoinPool-1-worker-19) [] Rerun VM '4fd61e41-ea48-4ba8-b78f-dba5acb87c9e'. 
Called from VDS ' [ http://dis-adm.cines.fr/ | dis-adm.cines.fr ] ' 
ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] 
(EE-ManagedThreadFactory-engine-Thread-4) [] EVENT_ID: 
VM_MIGRATION_TO_SERVER_FAILED(120), Migration failed (VM: pc115dev, Source: [ 
http://dis-adm.cines.fr/ | dis-adm.cines.fr ] , Destination: [ 
http://bombur-adm.cines.fr/ | bombur-adm.cines.fr ] ). 
ERROR [org.ovirt.engine.core.vdsbroker.monitoring.VmAnalyzer] 
(ForkJoinPool-1-worker-13) [] Migration of VM 'pc115dev' to host ' [ 
http://bombur-adm.cines.fr/ | bombur-adm.cines.fr ] ' failed: VM destroyed 
during the startup. 
ERROR [org.ovirt.engine.core.vdsbroker.monitoring.VmsMonitoring] 
(EE-ManagedScheduledExecutorService-engineScheduledThreadPool-Thread-39) [] 
Rerun VM '4fd61e41-ea48-4ba8-b78f-dba5acb87c9e'. Called from VDS ' [ 
http://dis-adm.cines.fr/ | dis-adm.cines.fr ] ' 
ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] 
(EE-ManagedThreadFactory-engine-Thread-38) [] EVENT_ID: 
VM_MIGRATION_TO_SERVER_FAILED(120), Migration failed (VM: pc115dev, Source: [ 
http://dis-adm.cines.fr/ | dis-adm.cines.fr ] , Destination: [ 
http://bombur-adm.cines.fr/ | bombur-adm.cines.fr ] ). 


vdsm.log (target host) : 
WARN (Reactor thread) [vds.dispatcher] unhandled write event 
(betterAsyncore:184) 
WARN (jsonrpc/7) [root] ping was deprecated in favor of ping2 and 
confirmConnectivity (API:1349) 
WARN (vm/4fd61e41) [virt.vm] (vmId='4fd61e41-ea48-4ba8-b78f-dba5acb87c9e') 
Couldn't destroy incoming VM: Domaine non trouvé : aucun domaine ne correspond 
à l'UUID '4fd61e41-ea48-4ba8-b78f-dba5acb87c9e' (vm:3738) 

BQ_END

The migration probably fails due to incompatible CPU flags - please file a bug 
and attach VDSM and libvirt logs from both source and destination hosts. 

BQ_BEGIN


Another think i've noticed on event log of 8.3 host : 
VDSM [ http://bombur-adm.cines.fr/ | bombur-adm.cines.fr ] command SpmStatusVDS 
failed: Cannot inquire Lease(name='SDM', 
path='/dev/7586152d-338c-415d-93f4-74efd09c02fa/leases', offset=1048576): (2, 
'Sanlock get hosts failure', 'No such file or directory') 


But file seems to exist on host : 
ls -l /dev/7586152d-338c-415d-93f4-74efd09c02fa/leases 
lrwxrwxrwx. 1 root root 7 Dec 15 14:14 
/dev/7586152d-338c-415d-93f4-74efd09c02fa/leases -> ../dm-7 


I tried to reboot host & restart engine, set my 8.3 host as SPM ... same error. 


Lionel. 

BQ_END




smime.p7s
Description: S/MIME Cryptographic Signature
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/JANTRBX7ECZ2XXTTBASISAW56ASRZAAO/

[ovirt-users] Re: Bad CPU TYPE after Centos 8.3

2020-12-15 Thread Arik Hadas

On Tue, Dec 15, 2020 at 3:29 PM Lionel Caignec  wrote:

> Hi
>
> thank you it's work now. All my host 8.2/8.3 are up and running. During
> reactivation of 8.2 host i saw the log line "updating cluster CPU..."
>

Good to see that it works for you now (the credit to Lucia).
So the cluster configuration didn't change because not all hosts were UP
when starting the 4.4.3 engine?


>
> I tried to move guest from 8.2 host to 8.3 one but it failed.
>
>
> Engine.log :
> ERROR [org.ovirt.engine.core.vdsbroker.monitoring.VmAnalyzer]
> (ForkJoinPool-1-worker-27) [] Migration of VM 'pc115dev' to host '
> bombur-adm.cines.fr' failed: VM destroyed during the startup.
> ERROR [org.ovirt.engine.core.vdsbroker.monitoring.VmsMonitoring]
> (ForkJoinPool-1-worker-19) [] Rerun VM
> '4fd61e41-ea48-4ba8-b78f-dba5acb87c9e'. Called from VDS 'dis-adm.cines.fr'
> ERROR
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> (EE-ManagedThreadFactory-engine-Thread-4) [] EVENT_ID:
> VM_MIGRATION_TO_SERVER_FAILED(120), Migration failed  (VM: pc115dev,
> Source: dis-adm.cines.fr, Destination: bombur-adm.cines.fr).
> ERROR [org.ovirt.engine.core.vdsbroker.monitoring.VmAnalyzer]
> (ForkJoinPool-1-worker-13) [] Migration of VM 'pc115dev' to host '
> bombur-adm.cines.fr' failed: VM destroyed during the startup.
> ERROR [org.ovirt.engine.core.vdsbroker.monitoring.VmsMonitoring]
> (EE-ManagedScheduledExecutorService-engineScheduledThreadPool-Thread-39) []
> Rerun VM '4fd61e41-ea48-4ba8-b78f-dba5acb87c9e'. Called from VDS '
> dis-adm.cines.fr'
> ERROR
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> (EE-ManagedThreadFactory-engine-Thread-38) [] EVENT_ID:
> VM_MIGRATION_TO_SERVER_FAILED(120), Migration failed  (VM: pc115dev,
> Source: dis-adm.cines.fr, Destination: bombur-adm.cines.fr).
>
>
> vdsm.log (target host) :
> WARN  (Reactor thread) [vds.dispatcher] unhandled write event
> (betterAsyncore:184)
> WARN  (jsonrpc/7) [root] ping was deprecated in favor of ping2 and
> confirmConnectivity (API:1349)
> WARN  (vm/4fd61e41) [virt.vm]
> (vmId='4fd61e41-ea48-4ba8-b78f-dba5acb87c9e') Couldn't destroy incoming VM:
> Domaine non trouvé : aucun domaine ne correspond à l'UUID
> '4fd61e41-ea48-4ba8-b78f-dba5acb87c9e' (vm:3738)
>

The migration probably fails due to incompatible CPU flags - please file a
bug and attach VDSM and libvirt logs from both source and destination hosts.


>
> Another think i've noticed on event log of 8.3 host :
> VDSM bombur-adm.cines.fr command SpmStatusVDS failed: Cannot inquire
> Lease(name='SDM', path='/dev/7586152d-338c-415d-93f4-74efd09c02fa/leases',
> offset=1048576): (2, 'Sanlock get hosts failure', 'No such file or
> directory')
>
>
> But file seems to exist on host :
> ls -l /dev/7586152d-338c-415d-93f4-74efd09c02fa/leases
> lrwxrwxrwx. 1 root root 7 Dec 15 14:14
> /dev/7586152d-338c-415d-93f4-74efd09c02fa/leases -> ../dm-7
>
>
> I tried to reboot host  & restart engine, set my 8.3 host as SPM ... same
> error.
>
>
> Lionel.
>
> --
> *De: *"Lucia Jelinkova" 
> *À: *"Lionel Caignec" 
> *Cc: *"thomas" , "users" 
> *Envoyé: *Mardi 15 Décembre 2020 13:46:11
> *Objet: *Re: [ovirt-users] Re: Bad CPU TYPE after Centos 8.3
>
> Hi Lionel,
>
> if you managed to remove the host (or move it to a different cluster) so
> that all hosts in your cluster are UP - you could try to put one of your
> running hosts to the maintenance and then back to active - the cluster
> settings should be updated on the host activation. You can look for the log
> "Updating cluster CPU flags and verb according to the configuration of the
> [cluster name]".
>
> If that does not help, you can try to restart the engine.
>
> Please let me know if that helps.
>
> Lucia
>
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/YCL3UBDQWSHXKUDYXXUOBIUUFHQPM3LK/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/HBC4HRTGGOTZ7ZL2XW46SIP7322J4ZCD/

[ovirt-users] Re: Bad CPU TYPE after Centos 8.3

Hi 

thank you it's work now. All my host 8.2/8.3 are up and running. During 
reactivation of 8.2 host i saw the log line "updating cluster CPU..." 

I tried to move guest from 8.2 host to 8.3 one but it failed. 


Engine.log : 
ERROR [org.ovirt.engine.core.vdsbroker.monitoring.VmAnalyzer] 
(ForkJoinPool-1-worker-27) [] Migration of VM 'pc115dev' to host 
'bombur-adm.cines.fr' failed: VM destroyed during the startup. 
ERROR [org.ovirt.engine.core.vdsbroker.monitoring.VmsMonitoring] 
(ForkJoinPool-1-worker-19) [] Rerun VM '4fd61e41-ea48-4ba8-b78f-dba5acb87c9e'. 
Called from VDS 'dis-adm.cines.fr' 
ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] 
(EE-ManagedThreadFactory-engine-Thread-4) [] EVENT_ID: 
VM_MIGRATION_TO_SERVER_FAILED(120), Migration failed (VM: pc115dev, Source: 
dis-adm.cines.fr, Destination: bombur-adm.cines.fr). 
ERROR [org.ovirt.engine.core.vdsbroker.monitoring.VmAnalyzer] 
(ForkJoinPool-1-worker-13) [] Migration of VM 'pc115dev' to host 
'bombur-adm.cines.fr' failed: VM destroyed during the startup. 
ERROR [org.ovirt.engine.core.vdsbroker.monitoring.VmsMonitoring] 
(EE-ManagedScheduledExecutorService-engineScheduledThreadPool-Thread-39) [] 
Rerun VM '4fd61e41-ea48-4ba8-b78f-dba5acb87c9e'. Called from VDS 
'dis-adm.cines.fr' 
ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] 
(EE-ManagedThreadFactory-engine-Thread-38) [] EVENT_ID: 
VM_MIGRATION_TO_SERVER_FAILED(120), Migration failed (VM: pc115dev, Source: 
dis-adm.cines.fr, Destination: bombur-adm.cines.fr). 


vdsm.log (target host) : 
WARN (Reactor thread) [vds.dispatcher] unhandled write event 
(betterAsyncore:184) 
WARN (jsonrpc/7) [root] ping was deprecated in favor of ping2 and 
confirmConnectivity (API:1349) 
WARN (vm/4fd61e41) [virt.vm] (vmId='4fd61e41-ea48-4ba8-b78f-dba5acb87c9e') 
Couldn't destroy incoming VM: Domaine non trouvé : aucun domaine ne correspond 
à l'UUID '4fd61e41-ea48-4ba8-b78f-dba5acb87c9e' (vm:3738) 

Another think i've noticed on event log of 8.3 host : 
VDSM bombur-adm.cines.fr command SpmStatusVDS failed: Cannot inquire 
Lease(name='SDM', path='/dev/7586152d-338c-415d-93f4-74efd09c02fa/leases', 
offset=1048576): (2, 'Sanlock get hosts failure', 'No such file or directory') 


But file seems to exist on host : 
ls -l /dev/7586152d-338c-415d-93f4-74efd09c02fa/leases 
lrwxrwxrwx. 1 root root 7 Dec 15 14:14 
/dev/7586152d-338c-415d-93f4-74efd09c02fa/leases -> ../dm-7 


I tried to reboot host & restart engine, set my 8.3 host as SPM ... same error. 


Lionel. 


De: "Lucia Jelinkova"  
À: "Lionel Caignec"  
Cc: "thomas" , "users"  
Envoyé: Mardi 15 Décembre 2020 13:46:11 
Objet: Re: [ovirt-users] Re: Bad CPU TYPE after Centos 8.3 

Hi Lionel, 

if you managed to remove the host (or move it to a different cluster) so that 
all hosts in your cluster are UP - you could try to put one of your running 
hosts to the maintenance and then back to active - the cluster settings should 
be updated on the host activation. You can look for the log "Updating cluster 
CPU flags and verb according to the configuration of the [cluster name]". 

If that does not help, you can try to restart the engine. 

Please let me know if that helps. 

Lucia 



smime.p7s
Description: S/MIME Cryptographic Signature
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/YCL3UBDQWSHXKUDYXXUOBIUUFHQPM3LK/

[ovirt-users] Re: Bad CPU TYPE after Centos 8.3

2020-12-15 Thread Lucia Jelinkova

Hi Lionel,

if you managed to remove the host (or move it to a different cluster) so
that all hosts in your cluster are UP - you could try to put one of your
running hosts to the maintenance and then back to active - the cluster
settings should be updated on the host activation. You can look for the log
"Updating cluster CPU flags and verb according to the configuration of the
[cluster name]".

If that does not help, you can try to restart the engine.

Please let me know if that helps.

Lucia

On Tue, Dec 15, 2020 at 12:53 PM Lionel Caignec  wrote:

> Thank you i understand now.
>
> I double checked all my 8.2 host about cababilities and they seems ok.
>
> I think i foudn the source of this "bug".
>
> For this time i've updated one host in 8.3 (the non operative one), and
> then i update engine and run engine-setup (with all host up and activated
> except the 8.3 one). Maybe this is why the cluster table is not updated?
>
> What do you think, if y remove the 8.3 host, rerun "engine-setup" an
> re-add the 8.3 host?
>
>
> Lionel.
>
> --
> *De: *"Lucia Jelinkova" 
> *À: *"Lionel Caignec" 
> *Cc: *"thomas" , "users" 
> *Envoyé: *Mardi 15 Décembre 2020 11:31:47
> *Objet: *Re: [ovirt-users] Re: Bad CPU TYPE after Centos 8.3
>
> Hi Lionel,
>
> in oVirt 4.4.2 the Secure Intel Cascadelake Server Family was configured
> to use the Cascadelake-Server libvirt/qemu CPU. In oVirt 4.4.3, this has
> been changed to Cascadelake-Server-noTSX libvirt/qemu CPU (since the TSX
> was dropped in 8.3).
>
> The problem you're facing is caused by this transition. In the cluster
> table you can see that the running hosts still use the old configuration -
> Cascadelake-Server. That is why the new 8.3 host is non operative.
>
> Now the question is why the configuration in the cluster table was not
> updated. This should be the correct workflow:
> 1. engine update from 4.4.2 to 4.4.3
> 2. during engine-setup, the configuration values should be updated in the
> vdc_table in the database
> 3. during engine startup, the cluster value should be updated IF all hosts
> are UP AND all hosts comply to the new configuration
>
> Could anything from the below cause the configuration in the cluster table
> not to be updated?
> a) engine-setup was not performed
> b) not all hosts in the cluster were UP
> c) some of the 8.2 hosts do not support the Cascadelake-Server-noTSX (I
> can see that the 8.2 you've checked does support it, maybe it would be
> worth checking the others as well).
>
> Based on your answer we can try a workaround in the Webadmin before
> changing the kernel values.
>
> Regards,
>
> Lucia
>
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/MTMD7EHO3MDTYKTVVCK7VTCYNH2LHDVD/

[ovirt-users] Re: fence_xvm for testing

2020-12-15 Thread Martin Perina

On Tue, Dec 15, 2020 at 12:59 PM Alex K  wrote:

>
>
> On Tue, Dec 15, 2020 at 1:43 PM emesika  wrote:
>
>> The problem is that the custom fencing configuration is not defined well
>>
>> Please follow [1] and retry
>>
>> [1]
>> https://www.ovirt.org/develop/developer-guide/engine/custom-fencing.html
>>
> Yes, I followed that.
> I cannot see what I am missing:
>
> [root@manager ~]# engine-config -g CustomVdsFenceType
> CustomVdsFenceType: fence_xvm version: general
> [root@manager ~]# engine-config -g CustomFenceAgentMapping
> CustomFenceAgentMapping: fence_xvm=xvm version: general
> [root@manager ~]# engine-config -g CustomVdsFenceOptionMapping
> CustomVdsFenceOptionMapping: fence_xvm: version: general
>
>
>>
>> On Tue, Dec 15, 2020 at 12:56 PM Alex K  wrote:
>>
>>>
>>>
>>> On Tue, Dec 15, 2020 at 12:34 PM Martin Perina 
>>> wrote:
>>>


 On Tue, Dec 15, 2020 at 11:18 AM Alex K 
 wrote:

>
>
> On Tue, Dec 15, 2020 at 11:59 AM Martin Perina 
> wrote:
>
>> Hi,
>>
>> could you please provide engine.log? And also vdsm.log from a host
>> which was acting as a fence proxy?
>>
>
> At proxy host (kvm1) I see the following vdsm.log:
>
> 2020-12-15 10:13:03,933+ INFO  (jsonrpc/0) [jsonrpc.JsonRpcServer]
> RPC call Host.fenceNode failed (error 1) in 0.01 seconds (__init__:312)
> 2020-12-15 10:13:04,376+ INFO  (jsonrpc/7) [jsonrpc.JsonRpcServer]
> RPC call Host.fenceNode failed (error 1) in 0.01 seconds (__init__:312)
>

 Isn't there stdout and stderr content of fence_xvm execution a few
 lines above, which should reveal the exact error? If not, then could you
 please turn on debug logging using below command:

 vdsm-client Host setLogLevel level=DEBUG

 This should be executed on the host which acts as a fence proxy (if you 
 have multiple hosts, then you would need to turn on debug on all, because 
 the fence proxy is selected randomly).

 Once we will have vdsm.log with fence_xvm execution details, then you can 
 change log level to INFO again by running:

 I had to set engine-config -s CustomFenceAgentMapping="fence_xvm=xvm"
>>> at engine, as it seems the host prepends fence_.
>>> After that I got the following at the proxy host with DEBUG enabled:
>>>
>>> 2020-12-15 10:51:57,891+ DEBUG (jsonrpc/7) [jsonrpc.JsonRpcServer]
>>> Calling 'Host.fenceNode' in bridge with {u'username': u'root', u'addr':
>>> u'225.0.0.12', u'agent': u'xvm', u'options': u'port=ovirt-node0',
>>> u'action': u'status', u'password': '', u'port': u'0'} (__init__:329)
>>> 2020-12-15 10:51:57,892+ DEBUG (jsonrpc/7) [root] /usr/bin/taskset
>>> --cpu-list 0-3 /usr/sbin/fence_xvm (cwd None) (commands:198)
>>> 2020-12-15 10:51:57,911+ INFO  (jsonrpc/7) [jsonrpc.JsonRpcServer]
>>> RPC call Host.fenceNode failed (error 1) in 0.02 seconds (__init__:312)
>>> 2020-12-15 10:51:58,339+ DEBUG (jsonrpc/5) [jsonrpc.JsonRpcServer]
>>> Calling 'Host.fenceNode' in bridge with {u'username': u'root', u'addr':
>>> u'225.0.0.12', u'agent': u'xvm', u'options': u'port=ovirt-node0',
>>> u'action': u'status', u'password': '', u'port': u'0'} (__init__:329)
>>>
>>
Yes, that's the most probable issue. Eli, do we have a way to prevent
passing default port value 0 for custom fence agent?

> 2020-12-15 10:51:58,340+ DEBUG (jsonrpc/5) [root] /usr/bin/taskset
>>> --cpu-list 0-3 /usr/sbin/fence_xvm (cwd None) (commands:198)
>>> 2020-12-15 10:51:58,356+ INFO  (jsonrpc/5) [jsonrpc.JsonRpcServer]
>>> RPC call Host.fenceNode failed (error 1) in 0.01 seconds (__init__:312
>>>
>>> while at engine at got:
>>> 2020-12-15 10:51:57,873Z INFO
>>>  [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
>>> (default task-5) [a4f30921-37a9-45c1-97e5-26152f844d72] EVENT_ID:
>>> FENCE_OPERATION_USING_AGENT_AND_PROXY_STARTED(9,020), Executing power
>>> management status on Host kvm0.lab.local using Proxy Host kvm1.lab.local
>>> and Fence Agent xvm:225.0.0.12.
>>> 2020-12-15 10:51:57,888Z INFO
>>>  [org.ovirt.engine.core.vdsbroker.vdsbroker.FenceVdsVDSCommand] (default
>>> task-5) [a4f30921-37a9-45c1-97e5-26152f844d72] START,
>>> FenceVdsVDSCommand(HostName = kvm1.lab.local,
>>> FenceVdsVDSCommandParameters:{hostId='91c81bbe-5933-4ed0-b9c5-2c8c277e44c7',
>>> targetVdsId='b5e8fe3d-cbea-44cb-835a-f88d6d70c163', action='STATUS',
>>> agent='FenceAgent:{id='null', hostId='null', order='1', type='xvm',
>>> ip='225.0.0.12', port='0', user='root', password='***',
>>> encryptOptions='false', options='port=ovirt-node0'}', policy='null'}), log
>>> id: e6d3e8c
>>> 2020-12-15 10:51:58,008Z WARN
>>>  [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
>>> (default task-5) [a4f30921-37a9-45c1-97e5-26152f844d72] EVENT_ID:
>>> VDS_ALERT_FENCE_TEST_FAILED(9,001), Power Management test failed for Host
>>> kvm0.lab.local.Internal JSON-RPC error
>>> 2020-12-15 10:51:58,008Z INFO
>>>  [or

[ovirt-users] Re: fence_xvm for testing

On Tue, Dec 15, 2020 at 1:43 PM emesika  wrote:

> The problem is that the custom fencing configuration is not defined well
>
> Please follow [1] and retry
>
> [1]
> https://www.ovirt.org/develop/developer-guide/engine/custom-fencing.html
>
Yes, I followed that.
I cannot see what I am missing:

[root@manager ~]# engine-config -g CustomVdsFenceType
CustomVdsFenceType: fence_xvm version: general
[root@manager ~]# engine-config -g CustomFenceAgentMapping
CustomFenceAgentMapping: fence_xvm=xvm version: general
[root@manager ~]# engine-config -g CustomVdsFenceOptionMapping
CustomVdsFenceOptionMapping: fence_xvm: version: general


>
> On Tue, Dec 15, 2020 at 12:56 PM Alex K  wrote:
>
>>
>>
>> On Tue, Dec 15, 2020 at 12:34 PM Martin Perina 
>> wrote:
>>
>>>
>>>
>>> On Tue, Dec 15, 2020 at 11:18 AM Alex K  wrote:
>>>


 On Tue, Dec 15, 2020 at 11:59 AM Martin Perina 
 wrote:

> Hi,
>
> could you please provide engine.log? And also vdsm.log from a host
> which was acting as a fence proxy?
>

 At proxy host (kvm1) I see the following vdsm.log:

 2020-12-15 10:13:03,933+ INFO  (jsonrpc/0) [jsonrpc.JsonRpcServer]
 RPC call Host.fenceNode failed (error 1) in 0.01 seconds (__init__:312)
 2020-12-15 10:13:04,376+ INFO  (jsonrpc/7) [jsonrpc.JsonRpcServer]
 RPC call Host.fenceNode failed (error 1) in 0.01 seconds (__init__:312)

>>>
>>> Isn't there stdout and stderr content of fence_xvm execution a few lines
>>> above, which should reveal the exact error? If not, then could you please
>>> turn on debug logging using below command:
>>>
>>> vdsm-client Host setLogLevel level=DEBUG
>>>
>>> This should be executed on the host which acts as a fence proxy (if you 
>>> have multiple hosts, then you would need to turn on debug on all, because 
>>> the fence proxy is selected randomly).
>>>
>>> Once we will have vdsm.log with fence_xvm execution details, then you can 
>>> change log level to INFO again by running:
>>>
>>> I had to set engine-config -s CustomFenceAgentMapping="fence_xvm=xvm"
>> at engine, as it seems the host prepends fence_.
>> After that I got the following at the proxy host with DEBUG enabled:
>>
>> 2020-12-15 10:51:57,891+ DEBUG (jsonrpc/7) [jsonrpc.JsonRpcServer]
>> Calling 'Host.fenceNode' in bridge with {u'username': u'root', u'addr':
>> u'225.0.0.12', u'agent': u'xvm', u'options': u'port=ovirt-node0',
>> u'action': u'status', u'password': '', u'port': u'0'} (__init__:329)
>> 2020-12-15 10:51:57,892+ DEBUG (jsonrpc/7) [root] /usr/bin/taskset
>> --cpu-list 0-3 /usr/sbin/fence_xvm (cwd None) (commands:198)
>> 2020-12-15 10:51:57,911+ INFO  (jsonrpc/7) [jsonrpc.JsonRpcServer]
>> RPC call Host.fenceNode failed (error 1) in 0.02 seconds (__init__:312)
>> 2020-12-15 10:51:58,339+ DEBUG (jsonrpc/5) [jsonrpc.JsonRpcServer]
>> Calling 'Host.fenceNode' in bridge with {u'username': u'root', u'addr':
>> u'225.0.0.12', u'agent': u'xvm', u'options': u'port=ovirt-node0',
>> u'action': u'status', u'password': '', u'port': u'0'} (__init__:329)
>> 2020-12-15 10:51:58,340+ DEBUG (jsonrpc/5) [root] /usr/bin/taskset
>> --cpu-list 0-3 /usr/sbin/fence_xvm (cwd None) (commands:198)
>> 2020-12-15 10:51:58,356+ INFO  (jsonrpc/5) [jsonrpc.JsonRpcServer]
>> RPC call Host.fenceNode failed (error 1) in 0.01 seconds (__init__:312
>>
>> while at engine at got:
>> 2020-12-15 10:51:57,873Z INFO
>>  [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
>> (default task-5) [a4f30921-37a9-45c1-97e5-26152f844d72] EVENT_ID:
>> FENCE_OPERATION_USING_AGENT_AND_PROXY_STARTED(9,020), Executing power
>> management status on Host kvm0.lab.local using Proxy Host kvm1.lab.local
>> and Fence Agent xvm:225.0.0.12.
>> 2020-12-15 10:51:57,888Z INFO
>>  [org.ovirt.engine.core.vdsbroker.vdsbroker.FenceVdsVDSCommand] (default
>> task-5) [a4f30921-37a9-45c1-97e5-26152f844d72] START,
>> FenceVdsVDSCommand(HostName = kvm1.lab.local,
>> FenceVdsVDSCommandParameters:{hostId='91c81bbe-5933-4ed0-b9c5-2c8c277e44c7',
>> targetVdsId='b5e8fe3d-cbea-44cb-835a-f88d6d70c163', action='STATUS',
>> agent='FenceAgent:{id='null', hostId='null', order='1', type='xvm',
>> ip='225.0.0.12', port='0', user='root', password='***',
>> encryptOptions='false', options='port=ovirt-node0'}', policy='null'}), log
>> id: e6d3e8c
>> 2020-12-15 10:51:58,008Z WARN
>>  [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
>> (default task-5) [a4f30921-37a9-45c1-97e5-26152f844d72] EVENT_ID:
>> VDS_ALERT_FENCE_TEST_FAILED(9,001), Power Management test failed for Host
>> kvm0.lab.local.Internal JSON-RPC error
>> 2020-12-15 10:51:58,008Z INFO
>>  [org.ovirt.engine.core.vdsbroker.vdsbroker.FenceVdsVDSCommand] (default
>> task-5) [a4f30921-37a9-45c1-97e5-26152f844d72] FINISH, FenceVdsVDSCommand,
>> return: FenceOperationResult:{status='ERROR', powerStatus='UNKNOWN',
>> message='Internal JSON-RPC error'}, log id: e6d3e8c
>> 2020-12-15 10:51:58,133Z WAR

[ovirt-users] Re: Bad CPU TYPE after Centos 8.3

Thank you i understand now. 

I double checked all my 8.2 host about cababilities and they seems ok. 

I think i foudn the source of this "bug". 

For this time i've updated one host in 8.3 (the non operative one), and then i 
update engine and run engine-setup (with all host up and activated except the 
8.3 one). Maybe this is why the cluster table is not updated? 

What do you think, if y remove the 8.3 host, rerun "engine-setup" an re-add the 
8.3 host? 


Lionel. 


De: "Lucia Jelinkova"  
À: "Lionel Caignec"  
Cc: "thomas" , "users"  
Envoyé: Mardi 15 Décembre 2020 11:31:47 
Objet: Re: [ovirt-users] Re: Bad CPU TYPE after Centos 8.3 

Hi Lionel, 

in oVirt 4.4.2 the Secure Intel Cascadelake Server Family was configured to use 
the Cascadelake-Server libvirt/qemu CPU. In oVirt 4.4.3, this has been changed 
to Cascadelake-Server-noTSX libvirt/qemu CPU (since the TSX was dropped in 
8.3). 

The problem you're facing is caused by this transition. In the cluster table 
you can see that the running hosts still use the old configuration - 
Cascadelake-Server. That is why the new 8.3 host is non operative. 

Now the question is why the configuration in the cluster table was not updated. 
This should be the correct workflow: 
1. engine update from 4.4.2 to 4.4.3 
2. during engine-setup, the configuration values should be updated in the 
vdc_table in the database 
3. during engine startup, the cluster value should be updated IF all hosts are 
UP AND all hosts comply to the new configuration 

Could anything from the below cause the configuration in the cluster table not 
to be updated? 
a) engine-setup was not performed 
b) not all hosts in the cluster were UP 
c) some of the 8.2 hosts do not support the Cascadelake-Server-noTSX (I can see 
that the 8.2 you've checked does support it, maybe it would be worth checking 
the others as well). 

Based on your answer we can try a workaround in the Webadmin before changing 
the kernel values. 

Regards, 

Lucia 



smime.p7s
Description: S/MIME Cryptographic Signature
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/KVUZP22DRFYG52LAMM3BQPTPCRUGKIJG/

[ovirt-users] Re: fence_xvm for testing

2020-12-15 Thread emesika

The problem is that the custom fencing configuration is not defined well

Please follow [1] and retry

[1] https://www.ovirt.org/develop/developer-guide/engine/custom-fencing.html


On Tue, Dec 15, 2020 at 12:56 PM Alex K  wrote:

>
>
> On Tue, Dec 15, 2020 at 12:34 PM Martin Perina  wrote:
>
>>
>>
>> On Tue, Dec 15, 2020 at 11:18 AM Alex K  wrote:
>>
>>>
>>>
>>> On Tue, Dec 15, 2020 at 11:59 AM Martin Perina 
>>> wrote:
>>>
 Hi,

 could you please provide engine.log? And also vdsm.log from a host
 which was acting as a fence proxy?

>>>
>>> At proxy host (kvm1) I see the following vdsm.log:
>>>
>>> 2020-12-15 10:13:03,933+ INFO  (jsonrpc/0) [jsonrpc.JsonRpcServer]
>>> RPC call Host.fenceNode failed (error 1) in 0.01 seconds (__init__:312)
>>> 2020-12-15 10:13:04,376+ INFO  (jsonrpc/7) [jsonrpc.JsonRpcServer]
>>> RPC call Host.fenceNode failed (error 1) in 0.01 seconds (__init__:312)
>>>
>>
>> Isn't there stdout and stderr content of fence_xvm execution a few lines
>> above, which should reveal the exact error? If not, then could you please
>> turn on debug logging using below command:
>>
>> vdsm-client Host setLogLevel level=DEBUG
>>
>> This should be executed on the host which acts as a fence proxy (if you have 
>> multiple hosts, then you would need to turn on debug on all, because the 
>> fence proxy is selected randomly).
>>
>> Once we will have vdsm.log with fence_xvm execution details, then you can 
>> change log level to INFO again by running:
>>
>> I had to set engine-config -s CustomFenceAgentMapping="fence_xvm=xvm" at
> engine, as it seems the host prepends fence_.
> After that I got the following at the proxy host with DEBUG enabled:
>
> 2020-12-15 10:51:57,891+ DEBUG (jsonrpc/7) [jsonrpc.JsonRpcServer]
> Calling 'Host.fenceNode' in bridge with {u'username': u'root', u'addr':
> u'225.0.0.12', u'agent': u'xvm', u'options': u'port=ovirt-node0',
> u'action': u'status', u'password': '', u'port': u'0'} (__init__:329)
> 2020-12-15 10:51:57,892+ DEBUG (jsonrpc/7) [root] /usr/bin/taskset
> --cpu-list 0-3 /usr/sbin/fence_xvm (cwd None) (commands:198)
> 2020-12-15 10:51:57,911+ INFO  (jsonrpc/7) [jsonrpc.JsonRpcServer] RPC
> call Host.fenceNode failed (error 1) in 0.02 seconds (__init__:312)
> 2020-12-15 10:51:58,339+ DEBUG (jsonrpc/5) [jsonrpc.JsonRpcServer]
> Calling 'Host.fenceNode' in bridge with {u'username': u'root', u'addr':
> u'225.0.0.12', u'agent': u'xvm', u'options': u'port=ovirt-node0',
> u'action': u'status', u'password': '', u'port': u'0'} (__init__:329)
> 2020-12-15 10:51:58,340+ DEBUG (jsonrpc/5) [root] /usr/bin/taskset
> --cpu-list 0-3 /usr/sbin/fence_xvm (cwd None) (commands:198)
> 2020-12-15 10:51:58,356+ INFO  (jsonrpc/5) [jsonrpc.JsonRpcServer] RPC
> call Host.fenceNode failed (error 1) in 0.01 seconds (__init__:312
>
> while at engine at got:
> 2020-12-15 10:51:57,873Z INFO
>  [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> (default task-5) [a4f30921-37a9-45c1-97e5-26152f844d72] EVENT_ID:
> FENCE_OPERATION_USING_AGENT_AND_PROXY_STARTED(9,020), Executing power
> management status on Host kvm0.lab.local using Proxy Host kvm1.lab.local
> and Fence Agent xvm:225.0.0.12.
> 2020-12-15 10:51:57,888Z INFO
>  [org.ovirt.engine.core.vdsbroker.vdsbroker.FenceVdsVDSCommand] (default
> task-5) [a4f30921-37a9-45c1-97e5-26152f844d72] START,
> FenceVdsVDSCommand(HostName = kvm1.lab.local,
> FenceVdsVDSCommandParameters:{hostId='91c81bbe-5933-4ed0-b9c5-2c8c277e44c7',
> targetVdsId='b5e8fe3d-cbea-44cb-835a-f88d6d70c163', action='STATUS',
> agent='FenceAgent:{id='null', hostId='null', order='1', type='xvm',
> ip='225.0.0.12', port='0', user='root', password='***',
> encryptOptions='false', options='port=ovirt-node0'}', policy='null'}), log
> id: e6d3e8c
> 2020-12-15 10:51:58,008Z WARN
>  [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> (default task-5) [a4f30921-37a9-45c1-97e5-26152f844d72] EVENT_ID:
> VDS_ALERT_FENCE_TEST_FAILED(9,001), Power Management test failed for Host
> kvm0.lab.local.Internal JSON-RPC error
> 2020-12-15 10:51:58,008Z INFO
>  [org.ovirt.engine.core.vdsbroker.vdsbroker.FenceVdsVDSCommand] (default
> task-5) [a4f30921-37a9-45c1-97e5-26152f844d72] FINISH, FenceVdsVDSCommand,
> return: FenceOperationResult:{status='ERROR', powerStatus='UNKNOWN',
> message='Internal JSON-RPC error'}, log id: e6d3e8c
> 2020-12-15 10:51:58,133Z WARN
>  [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> (default task-5) [a4f30921-37a9-45c1-97e5-26152f844d72] EVENT_ID:
> FENCE_OPERATION_USING_AGENT_AND_PROXY_FAILED(9,021), Execution of power
> management status on Host kvm0.lab.local using Proxy Host kvm1.lab.local
> and Fence Agent xvm:225.0.0.12 failed.
> 2020-12-15 10:51:58,134Z WARN
>  [org.ovirt.engine.core.bll.pm.FenceAgentExecutor] (default task-5)
> [a4f30921-37a9-45c1-97e5-26152f844d72] Fence action failed using proxy host
> 'kvm1.lab.local', trying another

[ovirt-users] Re: How to unlock disk images?

Unlocked the snapshot, deleted the VM... done!
That was easiser than I thought.

Thanks for your help in any case!
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/GFSXLHMJD57L3Q6U6N5KI4ED4GY6OAOG/

[ovirt-users] Re: fence_xvm for testing

On Tue, Dec 15, 2020 at 12:34 PM Martin Perina  wrote:

>
>
> On Tue, Dec 15, 2020 at 11:18 AM Alex K  wrote:
>
>>
>>
>> On Tue, Dec 15, 2020 at 11:59 AM Martin Perina 
>> wrote:
>>
>>> Hi,
>>>
>>> could you please provide engine.log? And also vdsm.log from a host which
>>> was acting as a fence proxy?
>>>
>>
>> At proxy host (kvm1) I see the following vdsm.log:
>>
>> 2020-12-15 10:13:03,933+ INFO  (jsonrpc/0) [jsonrpc.JsonRpcServer]
>> RPC call Host.fenceNode failed (error 1) in 0.01 seconds (__init__:312)
>> 2020-12-15 10:13:04,376+ INFO  (jsonrpc/7) [jsonrpc.JsonRpcServer]
>> RPC call Host.fenceNode failed (error 1) in 0.01 seconds (__init__:312)
>>
>
> Isn't there stdout and stderr content of fence_xvm execution a few lines
> above, which should reveal the exact error? If not, then could you please
> turn on debug logging using below command:
>
> vdsm-client Host setLogLevel level=DEBUG
>
> This should be executed on the host which acts as a fence proxy (if you have 
> multiple hosts, then you would need to turn on debug on all, because the 
> fence proxy is selected randomly).
>
> Once we will have vdsm.log with fence_xvm execution details, then you can 
> change log level to INFO again by running:
>
> I had to set engine-config -s CustomFenceAgentMapping="fence_xvm=xvm" at
engine, as it seems the host prepends fence_.
After that I got the following at the proxy host with DEBUG enabled:

2020-12-15 10:51:57,891+ DEBUG (jsonrpc/7) [jsonrpc.JsonRpcServer]
Calling 'Host.fenceNode' in bridge with {u'username': u'root', u'addr':
u'225.0.0.12', u'agent': u'xvm', u'options': u'port=ovirt-node0',
u'action': u'status', u'password': '', u'port': u'0'} (__init__:329)
2020-12-15 10:51:57,892+ DEBUG (jsonrpc/7) [root] /usr/bin/taskset
--cpu-list 0-3 /usr/sbin/fence_xvm (cwd None) (commands:198)
2020-12-15 10:51:57,911+ INFO  (jsonrpc/7) [jsonrpc.JsonRpcServer] RPC
call Host.fenceNode failed (error 1) in 0.02 seconds (__init__:312)
2020-12-15 10:51:58,339+ DEBUG (jsonrpc/5) [jsonrpc.JsonRpcServer]
Calling 'Host.fenceNode' in bridge with {u'username': u'root', u'addr':
u'225.0.0.12', u'agent': u'xvm', u'options': u'port=ovirt-node0',
u'action': u'status', u'password': '', u'port': u'0'} (__init__:329)
2020-12-15 10:51:58,340+ DEBUG (jsonrpc/5) [root] /usr/bin/taskset
--cpu-list 0-3 /usr/sbin/fence_xvm (cwd None) (commands:198)
2020-12-15 10:51:58,356+ INFO  (jsonrpc/5) [jsonrpc.JsonRpcServer] RPC
call Host.fenceNode failed (error 1) in 0.01 seconds (__init__:312

while at engine at got:
2020-12-15 10:51:57,873Z INFO
 [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
(default task-5) [a4f30921-37a9-45c1-97e5-26152f844d72] EVENT_ID:
FENCE_OPERATION_USING_AGENT_AND_PROXY_STARTED(9,020), Executing power
management status on Host kvm0.lab.local using Proxy Host kvm1.lab.local
and Fence Agent xvm:225.0.0.12.
2020-12-15 10:51:57,888Z INFO
 [org.ovirt.engine.core.vdsbroker.vdsbroker.FenceVdsVDSCommand] (default
task-5) [a4f30921-37a9-45c1-97e5-26152f844d72] START,
FenceVdsVDSCommand(HostName = kvm1.lab.local,
FenceVdsVDSCommandParameters:{hostId='91c81bbe-5933-4ed0-b9c5-2c8c277e44c7',
targetVdsId='b5e8fe3d-cbea-44cb-835a-f88d6d70c163', action='STATUS',
agent='FenceAgent:{id='null', hostId='null', order='1', type='xvm',
ip='225.0.0.12', port='0', user='root', password='***',
encryptOptions='false', options='port=ovirt-node0'}', policy='null'}), log
id: e6d3e8c
2020-12-15 10:51:58,008Z WARN
 [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
(default task-5) [a4f30921-37a9-45c1-97e5-26152f844d72] EVENT_ID:
VDS_ALERT_FENCE_TEST_FAILED(9,001), Power Management test failed for Host
kvm0.lab.local.Internal JSON-RPC error
2020-12-15 10:51:58,008Z INFO
 [org.ovirt.engine.core.vdsbroker.vdsbroker.FenceVdsVDSCommand] (default
task-5) [a4f30921-37a9-45c1-97e5-26152f844d72] FINISH, FenceVdsVDSCommand,
return: FenceOperationResult:{status='ERROR', powerStatus='UNKNOWN',
message='Internal JSON-RPC error'}, log id: e6d3e8c
2020-12-15 10:51:58,133Z WARN
 [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
(default task-5) [a4f30921-37a9-45c1-97e5-26152f844d72] EVENT_ID:
FENCE_OPERATION_USING_AGENT_AND_PROXY_FAILED(9,021), Execution of power
management status on Host kvm0.lab.local using Proxy Host kvm1.lab.local
and Fence Agent xvm:225.0.0.12 failed.
2020-12-15 10:51:58,134Z WARN
 [org.ovirt.engine.core.bll.pm.FenceAgentExecutor] (default task-5)
[a4f30921-37a9-45c1-97e5-26152f844d72] Fence action failed using proxy host
'kvm1.lab.local', trying another proxy
2020-12-15 10:51:58,258Z ERROR
[org.ovirt.engine.core.bll.pm.FenceProxyLocator] (default task-5)
[a4f30921-37a9-45c1-97e5-26152f844d72] Can not run fence action on host
'kvm0.lab.local', no suitable proxy host was found.
2020-12-15 10:51:58,258Z WARN
 [org.ovirt.engine.core.bll.pm.FenceAgentExecutor] (default task-5)
[a4f30921-37a9-45c1-97e5-26152f844d72] Failed to find another

[ovirt-users] Re: How to unlock disk images?

And I should have guessed, that this is only how trouble starts =:-O

I immediately removed the locked snapshot image (actually they pretty much 
seemed to disappear by themselves as delete operations might have been pending) 
but the VM that was doing the snapshot, is still there, even if the disks are 
long gone.

But there are still references in the VM to two (now gone) snapshot images with 
a status 'illegal' (because they don't exist anymore) that I cannot delete from 
the VM... without which I cannot delete the VM.

Any idea how to fix that?
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/XFYYH3DOOUPGZRY6Y64VSMCZICPPHMCE/

[ovirt-users] Re: fence_xvm for testing

2020-12-15 Thread Martin Perina

On Tue, Dec 15, 2020 at 11:18 AM Alex K  wrote:

>
>
> On Tue, Dec 15, 2020 at 11:59 AM Martin Perina  wrote:
>
>> Hi,
>>
>> could you please provide engine.log? And also vdsm.log from a host which
>> was acting as a fence proxy?
>>
>
> At proxy host (kvm1) I see the following vdsm.log:
>
> 2020-12-15 10:13:03,933+ INFO  (jsonrpc/0) [jsonrpc.JsonRpcServer] RPC
> call Host.fenceNode failed (error 1) in 0.01 seconds (__init__:312)
> 2020-12-15 10:13:04,376+ INFO  (jsonrpc/7) [jsonrpc.JsonRpcServer] RPC
> call Host.fenceNode failed (error 1) in 0.01 seconds (__init__:312)
>

Isn't there stdout and stderr content of fence_xvm execution a few lines
above, which should reveal the exact error? If not, then could you please
turn on debug logging using below command:

vdsm-client Host setLogLevel level=DEBUG

This should be executed on the host which acts as a fence proxy (if
you have multiple hosts, then you would need to turn on debug on all,
because the fence proxy is selected randomly).

Once we will have vdsm.log with fence_xvm execution details, then you
can change log level to INFO again by running:

vdsm-client Host setLogLevel level=INFO

Thanks,

Martin

2020-12-15 10:13:06,722+ INFO  (jsonrpc/4) [api.host] FINISH getStats
> return={'status': {'message': 'Done', 'code': 0}, 'info': {'cpuStatistics':
> {'1': {'cpuUser': '2.33', 'nodeIndex': 0, 'cpuSys': '1.13', 'cpuIdle':
> '96.54'}, '0': {'cpuUser': '1.66', 'nodeIndex': 0, 'cpuSys': '0.47',
> 'cpuIdle': '97.87'}, '3': {'cpuUser': '0.73', 'nodeIndex': 0, 'cpuSys':
> '0.60', 'cpuIdle': '98.67'}, '2': {'cpuUser': '1.20', 'nodeIndex': 0,
> 'cpuSys': '0.40', 'cpuIdle': '98.40'}}, 'numaNodeMemFree': {'0':
> {'memPercent': 14, 'memFree': '8531'}}, 'memShared': 0, 'haScore': 3400,
> 'thpState': 'always', 'ksmMergeAcrossNodes': True, 'vmCount': 0, 'memUsed':
> '8', 'storageDomains': {u'b4d25e5e-7806-464f-b2e1-4d4ab5a54dee': {'code':
> 0, 'actual': True, 'version': 5, 'acquired': True, 'delay': '0.0027973',
> 'lastCheck': '2.7', 'valid': True},
> u'dc4d507b-954f-4da6-bcc3-b4f2633d0fa1': {'code': 0, 'actual': True,
> 'version': 5, 'acquired': True, 'delay': '0.00285824', 'lastCheck': '5.7',
> 'valid': True}}, 'incomingVmMigrations': 0, 'network': {'ovirtmgmt':
> {'rxErrors': '0', 'txErrors': '0', 'speed': '1000', 'rxDropped': '149',
> 'name': 'ovirtmgmt', 'tx': '2980375', 'txDropped': '0', 'duplex':
> 'unknown', 'sampleTime': 1608027186.703727, 'rx': '27524740', 'state':
> 'up'}, 'lo': {'rxErrors': '0', 'txErrors': '0', 'speed': '1000',
> 'rxDropped': '0', 'name': 'lo', 'tx': '1085188922', 'txDropped': '0',
> 'duplex': 'unknown', 'sampleTime': 1608027186.703727, 'rx': '1085188922',
> 'state': 'up'}, 'ovs-system': {'rxErrors': '0', 'txErrors': '0', 'speed':
> '1000', 'rxDropped': '0', 'name': 'ovs-system', 'tx': '0', 'txDropped':
> '0', 'duplex': 'unknown', 'sampleTime': 1608027186.703727, 'rx': '0',
> 'state': 'down'}, ';vdsmdummy;': {'rxErrors': '0', 'txErrors': '0',
> 'speed': '1000', 'rxDropped': '0', 'name': ';vdsmdummy;', 'tx': '0',
> 'txDropped': '0', 'duplex': 'unknown', 'sampleTime': 1608027186.703727,
> 'rx': '0', 'state': 'down'}, 'br-int': {'rxErrors': '0', 'txErrors': '0',
> 'speed': '1000', 'rxDropped': '0', 'name': 'br-int', 'tx': '0',
> 'txDropped': '0', 'duplex': 'unknown', 'sampleTime': 1608027186.703727,
> 'rx': '0', 'state': 'down'}, 'eth1': {'rxErrors': '0', 'txErrors': '0',
> 'speed': '1000', 'rxDropped': '0', 'name': 'eth1', 'tx': '83685154',
> 'txDropped': '0', 'duplex': 'unknown', 'sampleTime': 1608027186.703727,
> 'rx': '300648288', 'state': 'up'}, 'eth0': {'rxErrors': '0', 'txErrors':
> '0', 'speed': '1000', 'rxDropped': '0', 'name': 'eth0', 'tx': '2980933',
> 'txDropped': '0', 'duplex': 'unknown', 'sampleTime': 1608027186.703727,
> 'rx': '28271472', 'state': 'up'}}, 'txDropped': '149', 'anonHugePages':
> '182', 'ksmPages': 100, 'elapsedTime': '5717.99', 'cpuLoad': '0.42',
> 'cpuSys': '0.63', 'diskStats': {'/var/log': {'free': '16444'},
> '/var/run/vdsm/': {'free': '4909'}, '/tmp': {'free': '16444'}},
> 'cpuUserVdsmd': '1.33', 'netConfigDirty': 'False', 'memCommitted': 0,
> 'ksmState': False, 'vmMigrating': 0, 'ksmCpu': 0, 'memAvailable': 9402,
> 'bootTime': '1608021428', 'haStats': {'active': True, 'configured': True,
> 'score': 3400, 'localMaintenance': False, 'globalMaintenance': True},
> 'momStatus': 'active', 'multipathHealth': {}, 'rxDropped': '0',
> 'outgoingVmMigrations': 0, 'swapTotal': 6015, 'swapFree': 6015,
> 'hugepages': defaultdict(, {1048576: {'resv_hugepages': 0,
> 'free_hugepages': 0, 'nr_overcommit_hugepages': 0, 'surplus_hugepages': 0,
> 'vm.free_hugepages': 0, 'nr_hugepages': 0, 'nr_hugepages_mempolicy': 0},
> 2048: {'resv_hugepages': 0, 'free_hugepages': 0, 'nr_overcommit_hugepages':
> 0, 'surplus_hugepages': 0, 'vm.free_hugepages': 0, 'nr_hugepages': 0,
> 'nr_hugepages_mempolicy': 0}}), 'dateTime': '2020-12-15T10:13:06 GMT',
> 'cpuUser': '1.50', 'memFree': 9146, 'cpuIdle': '97.87', 'vmActive': 0,
> 'v2vJobs

[ovirt-users] Re: Bad CPU TYPE after Centos 8.3

2020-12-15 Thread Lucia Jelinkova

Hi Lionel,

in oVirt 4.4.2 the Secure Intel Cascadelake Server Family was configured to
use the Cascadelake-Server libvirt/qemu CPU. In oVirt 4.4.3, this has been
changed to Cascadelake-Server-noTSX libvirt/qemu CPU (since the TSX was
dropped in 8.3).

The problem you're facing is caused by this transition. In the cluster
table you can see that the running hosts still use the old configuration -
Cascadelake-Server. That is why the new 8.3 host is non operative.

Now the question is why the configuration in the cluster table was not
updated. This should be the correct workflow:
1. engine update from 4.4.2 to 4.4.3
2. during engine-setup, the configuration values should be updated in the
vdc_table in the database
3. during engine startup, the cluster value should be updated IF all hosts
are UP AND all hosts comply to the new configuration

Could anything from the below cause the configuration in the cluster table
not to be updated?
a) engine-setup was not performed
b) not all hosts in the cluster were UP
c) some of the 8.2 hosts do not support the Cascadelake-Server-noTSX (I can
see that the 8.2 you've checked does support it, maybe it would be worth
checking the others as well).

Based on your answer we can try a workaround in the Webadmin before
changing the kernel values.

Regards,

Lucia

On Tue, Dec 15, 2020 at 11:01 AM Lionel Caignec  wrote:

> Hi All,
> and thanks for helping me
>
> So if i does not mistakte, we cannot use anymore cascadelake Server in
> centos 8.3?
> Cluster configuration is Secure CascadeLake Server Family
>
>
>
> Here is output of the sql query :
>
> name|cpu_name|
> cpu_flags   |
> cpu_verb
>
> ++--+-
>  moria | Secure Intel Cascadelake Server Family |
> vmx,mds-no,md-clear,model_Cascadelake-Server |
> Cascadelake-Server,+md-clear,+mds-no,-hle,-rtm,+tsx-ctrl,+arch-capabilities
>
>
> So in your link they said TSX is disabled by default, may i enable it? or
> the best option is to change cluster cpu type to lower value?
>
> Sorry for all my question i'm quite lost
>
>
> Regards,
> Lionel.
> --
> *De: *"Lucia Jelinkova" 
> *À: *tho...@hoberg.net
> *Cc: *"users" 
> *Envoyé: *Mardi 15 Décembre 2020 10:20:08
> *Objet: *[ovirt-users] Re: Bad CPU TYPE after Centos 8.3
>
> Hi Lionel,
>
> Thank you for the output from the virsh command. The interesting part is
> this:
>
> Cascadelake-Server-noTSX
> Cascadelake-Server
>
> The Cascadelake-Server is not usable any more in 8.3 [1] yet that is what the 
> cluster is probably configured with.
>
> Could you please run the following query for your cluster to be sure?
>
> select name, cpu_name, cpu_flags, cpu_verb from cluster;
>
> Could you please also run the virsh domcapabilities command on one of your 
> active and running 8.2 hosts to see if they support Cascadelake-Server-noTSX?
>
> 1: https://www.phoronix.com/scan.php?page=news_item&px=Red-Hat-RHEL-8.3
>
> Thank you,
>
> Lucia
>
>
>
>
>
>
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/PWYZH3SK2WALLMWYS45EDAENP4IJQLSZ/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/4QUDRL6NMRVNAZ2KO52THOJLOK2IZFJT/

[ovirt-users] Re: How to unlock disk images?

Thanks Shani,

I had just found that myself and even managed to unlock and remove the images.

Somehow the reference to https://ovirt.org/develop/developer-guide/ seems to 
not be available from the ovirt site navigation but now I have discovered it 
via another post here and found a treasure trove.
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/UWN6AP2T4KFSYHEOV42GTM634WFAGYOR/

[ovirt-users] Re: fence_xvm for testing

On Tue, Dec 15, 2020 at 11:59 AM Martin Perina  wrote:

> Hi,
>
> could you please provide engine.log? And also vdsm.log from a host which
> was acting as a fence proxy?
>

At proxy host (kvm1) I see the following vdsm.log:

2020-12-15 10:13:03,933+ INFO  (jsonrpc/0) [jsonrpc.JsonRpcServer] RPC
call Host.fenceNode failed (error 1) in 0.01 seconds (__init__:312)
2020-12-15 10:13:04,376+ INFO  (jsonrpc/7) [jsonrpc.JsonRpcServer] RPC
call Host.fenceNode failed (error 1) in 0.01 seconds (__init__:312)
2020-12-15 10:13:06,722+ INFO  (jsonrpc/4) [api.host] FINISH getStats
return={'status': {'message': 'Done', 'code': 0}, 'info': {'cpuStatistics':
{'1': {'cpuUser': '2.33', 'nodeIndex': 0, 'cpuSys': '1.13', 'cpuIdle':
'96.54'}, '0': {'cpuUser': '1.66', 'nodeIndex': 0, 'cpuSys': '0.47',
'cpuIdle': '97.87'}, '3': {'cpuUser': '0.73', 'nodeIndex': 0, 'cpuSys':
'0.60', 'cpuIdle': '98.67'}, '2': {'cpuUser': '1.20', 'nodeIndex': 0,
'cpuSys': '0.40', 'cpuIdle': '98.40'}}, 'numaNodeMemFree': {'0':
{'memPercent': 14, 'memFree': '8531'}}, 'memShared': 0, 'haScore': 3400,
'thpState': 'always', 'ksmMergeAcrossNodes': True, 'vmCount': 0, 'memUsed':
'8', 'storageDomains': {u'b4d25e5e-7806-464f-b2e1-4d4ab5a54dee': {'code':
0, 'actual': True, 'version': 5, 'acquired': True, 'delay': '0.0027973',
'lastCheck': '2.7', 'valid': True},
u'dc4d507b-954f-4da6-bcc3-b4f2633d0fa1': {'code': 0, 'actual': True,
'version': 5, 'acquired': True, 'delay': '0.00285824', 'lastCheck': '5.7',
'valid': True}}, 'incomingVmMigrations': 0, 'network': {'ovirtmgmt':
{'rxErrors': '0', 'txErrors': '0', 'speed': '1000', 'rxDropped': '149',
'name': 'ovirtmgmt', 'tx': '2980375', 'txDropped': '0', 'duplex':
'unknown', 'sampleTime': 1608027186.703727, 'rx': '27524740', 'state':
'up'}, 'lo': {'rxErrors': '0', 'txErrors': '0', 'speed': '1000',
'rxDropped': '0', 'name': 'lo', 'tx': '1085188922', 'txDropped': '0',
'duplex': 'unknown', 'sampleTime': 1608027186.703727, 'rx': '1085188922',
'state': 'up'}, 'ovs-system': {'rxErrors': '0', 'txErrors': '0', 'speed':
'1000', 'rxDropped': '0', 'name': 'ovs-system', 'tx': '0', 'txDropped':
'0', 'duplex': 'unknown', 'sampleTime': 1608027186.703727, 'rx': '0',
'state': 'down'}, ';vdsmdummy;': {'rxErrors': '0', 'txErrors': '0',
'speed': '1000', 'rxDropped': '0', 'name': ';vdsmdummy;', 'tx': '0',
'txDropped': '0', 'duplex': 'unknown', 'sampleTime': 1608027186.703727,
'rx': '0', 'state': 'down'}, 'br-int': {'rxErrors': '0', 'txErrors': '0',
'speed': '1000', 'rxDropped': '0', 'name': 'br-int', 'tx': '0',
'txDropped': '0', 'duplex': 'unknown', 'sampleTime': 1608027186.703727,
'rx': '0', 'state': 'down'}, 'eth1': {'rxErrors': '0', 'txErrors': '0',
'speed': '1000', 'rxDropped': '0', 'name': 'eth1', 'tx': '83685154',
'txDropped': '0', 'duplex': 'unknown', 'sampleTime': 1608027186.703727,
'rx': '300648288', 'state': 'up'}, 'eth0': {'rxErrors': '0', 'txErrors':
'0', 'speed': '1000', 'rxDropped': '0', 'name': 'eth0', 'tx': '2980933',
'txDropped': '0', 'duplex': 'unknown', 'sampleTime': 1608027186.703727,
'rx': '28271472', 'state': 'up'}}, 'txDropped': '149', 'anonHugePages':
'182', 'ksmPages': 100, 'elapsedTime': '5717.99', 'cpuLoad': '0.42',
'cpuSys': '0.63', 'diskStats': {'/var/log': {'free': '16444'},
'/var/run/vdsm/': {'free': '4909'}, '/tmp': {'free': '16444'}},
'cpuUserVdsmd': '1.33', 'netConfigDirty': 'False', 'memCommitted': 0,
'ksmState': False, 'vmMigrating': 0, 'ksmCpu': 0, 'memAvailable': 9402,
'bootTime': '1608021428', 'haStats': {'active': True, 'configured': True,
'score': 3400, 'localMaintenance': False, 'globalMaintenance': True},
'momStatus': 'active', 'multipathHealth': {}, 'rxDropped': '0',
'outgoingVmMigrations': 0, 'swapTotal': 6015, 'swapFree': 6015,
'hugepages': defaultdict(, {1048576: {'resv_hugepages': 0,
'free_hugepages': 0, 'nr_overcommit_hugepages': 0, 'surplus_hugepages': 0,
'vm.free_hugepages': 0, 'nr_hugepages': 0, 'nr_hugepages_mempolicy': 0},
2048: {'resv_hugepages': 0, 'free_hugepages': 0, 'nr_overcommit_hugepages':
0, 'surplus_hugepages': 0, 'vm.free_hugepages': 0, 'nr_hugepages': 0,
'nr_hugepages_mempolicy': 0}}), 'dateTime': '2020-12-15T10:13:06 GMT',
'cpuUser': '1.50', 'memFree': 9146, 'cpuIdle': '97.87', 'vmActive': 0,
'v2vJobs': {}, 'cpuSysVdsmd': '0.60'}} from=::1,55238 (api:54)
2020-12-15 10:13:07,093+ INFO  (jsonrpc/1) [api] FINISH getStats
error=Virtual machine does not exist: {'vmId':
u'0167fedb-7445-46bb-a39d-ea4471c86bf4'} (api:129)
2020-12-15 10:13:07,094+ INFO  (jsonrpc/1) [jsonrpc.JsonRpcServer] RPC
call VM.getStats failed (error 1) in 0.00 seconds (__init__:312)
2020-12-15 10:13:07,631+ INFO  (jsonrpc/3) [api.host] FINISH getStats
return={'status': {'message': 'Done', 'code': 0}, 'info': {'cpuStatistics':
{'1': {'cpuUser': '2.33', 'nodeIndex': 0, 'cpuSys': '1.13', 'cpuIdle':
'96.54'}, '0': {'cpuUser': '1.66', 'nodeIndex': 0, 'cpuSys': '0.47',
'cpuIdle': '97.87'}, '3': {'cpuUser': '0.73', 'nodeIndex': 0, 'cpuSys':
'0.60', 'cpuIdle': '98.67'}, '2': {'cpuUser': '1.20',

[ovirt-users] Re: Bad CPU TYPE after Centos 8.3

Hi All, 
and thanks for helping me 

So if i does not mistakte, we cannot use anymore cascadelake Server in centos 
8.3? 
Cluster configuration is Secure CascadeLake Server Family 



Here is output of the sql query : 

name | cpu_name | cpu_flags | cpu_verb 
++--+-
 
moria | Secure Intel Cascadelake Server Family | 
vmx,mds-no,md-clear,model_Cascadelake-Server | 
Cascadelake-Server,+md-clear,+mds-no,-hle,-rtm,+tsx-ctrl,+arch-capabilities 


So in your link they said TSX is disabled by default, may i enable it? or the 
best option is to change cluster cpu type to lower value? 

Sorry for all my question i'm quite lost 


Regards, 
Lionel. 

De: "Lucia Jelinkova"  
À: tho...@hoberg.net 
Cc: "users"  
Envoyé: Mardi 15 Décembre 2020 10:20:08 
Objet: [ovirt-users] Re: Bad CPU TYPE after Centos 8.3 

Hi Lionel, 

Thank you for the output from the virsh command. The interesting part is this: 
Cascadelake-Server-noTSX
Cascadelake-Server 
The Cascadelake-Server is not usable any more in 8.3 [1] yet that is what the 
cluster is probably configured with. 
Could you please run the following query for your cluster to be sure? 

select name, cpu_name, cpu_flags, cpu_verb from cluster; 

Could you please also run the virsh domcapabilities command on one of your 
active and running 8.2 hosts to see if they support Cascadelake-Server-noTSX? 

1: [ https://www.phoronix.com/scan.php?page=news_item&px=Red-Hat-RHEL-8.3 | 
https://www.phoronix.com/scan.php?page=news_item&px=Red-Hat-RHEL-8.3 ] 

Thank you, 

Lucia 






___ 
Users mailing list -- users@ovirt.org 
To unsubscribe send an email to users-le...@ovirt.org 
Privacy Statement: https://www.ovirt.org/privacy-policy.html 
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/ 
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/PWYZH3SK2WALLMWYS45EDAENP4IJQLSZ/
 

  /usr/libexec/qemu-kvm
  kvm
  pc-i440fx-rhel7.6.0
  x86_64
  
  
  


  /usr/share/OVMF/OVMF_CODE.secboot.fd
  
rom
pflash
  
  
yes
no
  
  
no
  

  
  


  Cascadelake-Server
  Intel
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  


  qemu64
  qemu32
  phenom
  pentium3
  pentium2
  pentium
  n270
  kvm64
  kvm32
  coreduo
  core2duo
  athlon
  Westmere-IBRS
  Westmere
  Skylake-Server-noTSX-IBRS
  Skylake-Server-IBRS
  Skylake-Server
  Skylake-Client-noTSX-IBRS
  Skylake-Client-IBRS
  Skylake-Client
  SandyBridge-IBRS
  SandyBridge
  Penryn
  Opteron_G5
  Opteron_G4
  Opteron_G3
  Opteron_G2
  Opteron_G1
  Nehalem-IBRS
  Nehalem
  IvyBridge-IBRS
  IvyBridge
  Icelake-Server-noTSX
  Icelake-Server
  Icelake-Client-noTSX
  Icelake-Client
  Haswell-noTSX-IBRS
  Haswell-noTSX
  Haswell-IBRS
  Haswell
  EPYC-IBPB
  EPYC
  Dhyana
  Cooperlake
  Conroe
  Cascadelake-Server-noTSX
  Cascadelake-Server
  Broadwell-noTSX-IBRS
  Broadwell-noTSX
  Broadwell-IBRS
  Broadwell
  486

  
  

  
disk
cdrom
floppy
lun
  
  
ide
fdc
scsi
virtio
usb
sata
  
  
virtio
virtio-transitional
virtio-non-transitional
  


  
sdl
vnc
spice
  


  
vga
cirrus
qxl
virtio
none
bochs
ramfb
  


  
subsystem
  
  
default
mandatory
requisite
optional
  
  
usb
pci
scsi
  
  
  


  
virtio
virtio-transitional
virtio-non-transitional
  
  
random
egd
  

  
  






  



smime.p7s
Description: S/MIME Cryptographic Signature
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/4AXAZ6NCMC2UCOPJSGCBJPW47YPHABI6/

[ovirt-users] Re: fence_xvm for testing

2020-12-15 Thread Martin Perina

Hi,

could you please provide engine.log? And also vdsm.log from a host which
was acting as a fence proxy?

Thanks,
Martin


On Tue, Dec 15, 2020 at 10:23 AM Alex K  wrote:

>
>
> On Tue, Dec 15, 2020 at 11:07 AM Alex K  wrote:
>
>>
>>
>> On Mon, Dec 14, 2020 at 8:59 PM Strahil Nikolov 
>> wrote:
>>
>>> Fence_xvm requires a key is deployed on both the Host and the VMs in
>>> order to succeed. What is happening when you use the cli on any of the VMs ?
>>> Also, the VMs require an open tcp port to receive the necessary output
>>> of each request.I
>>
>> I deployed keys at the physical host and virtual hosts, as per
>> https://github.com/rightkick/Notes/blob/master/Ovirt-fence_xmv.md
>> I can get the VM status from the virtual hosts:
>>
>> [root@kvm1 cluster]# fence_xvm -a 225.0.0.12 -k
>> /etc/cluster/fence_xvm.key -H ovirt-node0 -o status
>> Status: ON
>> You have new mail in /var/spool/mail/root
>> [root@kvm1 cluster]# fence_xvm -a 225.0.0.12 -k
>> /etc/cluster/fence_xvm.key -H ovirt-node1 -o status
>> Status: ON
>>
>> kvm0 and kvm1 are the hostnames of each virtual host, while ovirt-node0
>> and ovirt-node1 are the domain names of the same virtual hosts as defined
>> at virsh.
>>
>
> I am passing also the port/domain option at GUI, but from logs it seems it
> is being ignored as it is not being logged from engine.
>
> [image: image.png]
> tried also domain=ovirt-node0 with same results.
>
>
>
>>> Best Regards,
>>> Strahil Nikolov
>>>
>>>
>>>
>>>
>>>
>>>
>>> В понеделник, 14 декември 2020 г., 10:57:11 Гринуич+2, Alex K <
>>> rightkickt...@gmail.com> написа:
>>>
>>>
>>>
>>>
>>>
>>> Hi friends,
>>>
>>> I was wondering what is needed to setup fence_xvm in order to use for
>>> power management in virtual nested environments for testing purposes.
>>>
>>> I have followed the following steps:
>>> https://github.com/rightkick/Notes/blob/master/Ovirt-fence_xmv.md
>>>
>>> I tried also engine-config -s
>>> CustomFenceAgentMapping="fence_xvm=_fence_xvm"
>>> From command line all seems fine and I can get the status of the host
>>> VMs, but I was not able to find what is needed to set this up at engine UI:
>>>
>>>
>>> At username and pass I just filled dummy values as they should not be
>>> needed for fence_xvm.
>>> I always get an error at GUI while engine logs give:
>>>
>>>
>>> 2020-12-14 08:53:48,343Z WARN
>>>  [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
>>> (default task-4) [07c1d540-6d8d-419c-affb-181495d75759] EVENT_ID:
>>> VDS_ALERT_FENCE_TEST_FAILED(9,001), Power Management test failed for Host
>>> kvm0.lab.local.Internal JSON-RPC error
>>> 2020-12-14 08:53:48,343Z INFO
>>>  [org.ovirt.engine.core.vdsbroker.vdsbroker.FenceVdsVDSCommand] (default
>>> task-4) [07c1d540-6d8d-419c-affb-181495d75759] FINISH, FenceVdsVDSCommand,
>>> return: FenceOperationResult:{status='ERROR', powerStatus='UNKNOWN',
>>> message='Internal JSON-RPC error'}, log id: 2437b13c
>>> 2020-12-14 08:53:48,400Z WARN
>>>  [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
>>> (default task-4) [07c1d540-6d8d-419c-affb-181495d75759] EVENT_ID:
>>> FENCE_OPERATION_USING_AGENT_AND_PROXY_FAILED(9,021), Execution of power
>>> management status on Host kvm0.lab.local using Proxy Host kvm1.lab.local
>>> and Fence Agent fence_xvm:225.0.0.12 failed.
>>> 2020-12-14 08:53:48,400Z WARN
>>>  [org.ovirt.engine.core.bll.pm.FenceAgentExecutor] (default task-4)
>>> [07c1d540-6d8d-419c-affb-181495d75759] Fence action failed using proxy host
>>> 'kvm1.lab.local', trying another proxy
>>> 2020-12-14 08:53:48,485Z ERROR 
>>> [org.ovirt.engine.core.bll.pm.FenceProxyLocator]
>>> (default task-4) [07c1d540-6d8d-419c-affb-181495d75759] Can not run fence
>>> action on host 'kvm0.lab.local', no suitable proxy host was found.
>>> 2020-12-14 08:53:48,486Z WARN
>>>  [org.ovirt.engine.core.bll.pm.FenceAgentExecutor] (default task-4)
>>> [07c1d540-6d8d-419c-affb-181495d75759] Failed to find another proxy to
>>> re-run failed fence action, retrying with the same proxy 'kvm1.lab.local'
>>> 2020-12-14 08:53:48,582Z WARN
>>>  [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
>>> (default task-4) [07c1d540-6d8d-419c-affb-181495d75759] EVENT_ID:
>>> VDS_ALERT_FENCE_TEST_FAILED(9,001), Power Management test failed for Host
>>> kvm0.lab.local.Internal JSON-RPC error
>>> 2020-12-14 08:53:48,582Z INFO
>>>  [org.ovirt.engine.core.vdsbroker.vdsbroker.FenceVdsVDSCommand] (default
>>> task-4) [07c1d540-6d8d-419c-affb-181495d75759] FINISH, FenceVdsVDSCommand,
>>> return: FenceOperationResult:{status='ERROR', powerStatus='UNKNOWN',
>>> message='Internal JSON-RPC error'}, log id: 8607bc9
>>> 2020-12-14 08:53:48,637Z WARN
>>>  [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
>>> (default task-4) [07c1d540-6d8d-419c-affb-181495d75759] EVENT_ID:
>>> FENCE_OPERATION_USING_AGENT_AND_PROXY_FAILED(9,021), Execution of power
>>> management status on Host kvm0.lab.local using Proxy Host kvm1.lab.local
>>> and Fence

[ovirt-users] Re: illegal disk status

2020-12-15 Thread Benny Zlotnik

you can use:
$ vdsm-client Volume delete (you can use --help to see the params)

After this you'll need to remove the corresponding image manually from
the database images table, mark the parent image as active, remove the
snapshot from the snapshots table and fix the parent snapshot

Be sure to backup before trying this


On Sun, Dec 13, 2020 at 5:00 PM Daniel Menzel
 wrote:
>
> Hi,
>
> we have a problem with some VMs which cannot be started anymore due to an 
> illegal disk status of a snapshot.
>
> What happend (most likely)? we tried to snapshot those vms some days ago but 
> the storage domain didn't have enough free space left. Yesterday we shut 
> those vms down - and from then on they didn't start anymore.
>
> What have I tried so far?
>
> Via the web interface I tried to remove the snapshot - didn't work.
> Searched the internet. Found (among other stuff) this: 
> https://bugzilla.redhat.com/show_bug.cgi?id=1649129
> via vdsm-tool dump-volume-chains I managed to list those 5 snapshots (see 
> below).
>
> The output for one machine was:
>
>image:2d707743-4a9e-40bb-b223-83e3be672dfe
>
>  - 9ae6ea73-94b4-4588-9a6b-ea7a58ef93c9
>status: OK, voltype: INTERNAL, format: RAW, legality: LEGAL, 
> type: PREALLOCATED, capacity: 32212254720, truesize: 32212254720
>
>  - f7d2c014-e8f5-4413-bfc5-4aa1426cb1e2
>status: ILLEGAL, voltype: LEAF, format: COW, legality: 
> ILLEGAL, type: SPARSE, capacity: 32212254720, truesize: 29073408
>
> So my idea was to follow the said bugzilla thread and update the volume - but 
> I didn't manage to find input for the job_id and generation.
>
> So my question is: Does anyone have an idea on how to (force) remove a given 
> snapshot via vsdm-{tool|client}?
>
> Thanks in advance!
> Daniel
>
> --
> Daniel Menzel
> Geschäftsführer
>
> Menzel IT GmbH
> Charlottenburger Str. 33a
> 13086 Berlin
>
> +49 (0) 30 / 5130 444 - 00
> daniel.men...@menzel-it.net
> https://menzel-it.net
>
> Geschäftsführer: Daniel Menzel, Josefin Menzel
> Unternehmenssitz: Berlin
> Handelsregister: Amtsgericht Charlottenburg
> Handelsregister-Nummer: HRB 149835 B
> USt-ID: DE 309 226 751
>
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct: 
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives: 
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/5ZRHPBH6PKWUXSQIEKT4352D5RVNH6G6/
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/LTXEQDZSFUTOHFIAOQBMTCA2NMICCBUQ/

[ovirt-users] Re: How to unlock disk images?

2020-12-15 Thread Shani Leviim

Hi Thomas,
You can use unlock_entity.sh[1] to list the unlock entities and remove them.
[1]
https://www.ovirt.org/develop/developer-guide/db-issues/helperutilities.html


*Regards,*

*Shani Leviim*


On Tue, Dec 15, 2020 at 10:45 AM  wrote:

> On one oVirt 4.3 farm I have three locked images I'd like to clear out.
>
> One is an ISO image, that somehow never completed the transfer due to a
> slow network. It's occupying little space, except in the GUI where it
> sticks out and irritates. I guess it would just be an update somewhere on
> the Postgress database to unlock it and have it deletable: But since the
> schema isn't documented, I'd rather ask here: How to I unlock the image?
>
> Two are left-overs from a snapshot that somehow never completed, one for
> the disk another for the RAM part. I don't know how my colleague managed to
> get into that state, but impatience/concurrency probably was a factor, a
> transient failure of a node could have been another.
>
> In any case the snapshot operation logically has been going on for weeks
> without any real activity, survived several restarts (after patches) of all
> nodes and the ME and shows no sign of disappearing voluntarily.
>
> Again, I'd assume that I need to clear out the snapshot job, unlock the
> images and then delete what's left. Some easy SQL and most likely a
> management engine restart afterwards... if you knew what you were doing (or
> there was an option in the GUI).
>
> So how do I list/delete snapshot jobs that aren't really running any more?
> And how do I unlock the images so I can delete them?
>
> Thanks for your help!
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/XHC5GNLOZO2WFECII7AZX3QV2YEZ4NPO/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/Y6ZQEOSG74D4H6Y4ZB2GHOHX5RQIPVVF/

[ovirt-users] Re: Nodes install Python3 every day

2020-12-15 Thread Sandro Bonazzola

Il giorno mar 15 dic 2020 alle ore 10:16 jb  ha scritto:

>
> Am 15.12.20 um 09:06 schrieb Dana Elfassy:
>
> Yes, I'll edit the title.
>
> Jonathan, you can see in the log you pasted:
> *'task': 'Install Python3 for CentOS/RHEL8 hosts'*, 'task_uuid':
> '00163e33-f845-ee64-acee-0013', 'task_action': 'yum', 'task_args':
> '', 'task_path':
> '/usr/share/ovirt-engine/ansible-runner-service-project/project/roles/ovirt-host-deploy-facts/tasks/main.yml:20',
> 'role': 'ovirt-host-deploy-facts', 'host': 'onode1.example.org',
> 'remote_addr': 'onode1.example.org', *'res': {'msg': 'Nothing to do',
> 'changed': False, 'results': [], 'rc': 0,*
>
> This means it wasn't installed (will be only if the package doesn't exist)
>
> Thank you for the explanation, I should have unfolded the log... Sorry for
> the effort!
>
You pointed out a messaging issue, it was worth the effort :-)



>
> Thanks,
> Dana
>
> On Mon, Dec 14, 2020 at 3:36 PM Sandro Bonazzola 
> wrote:
>
>>
>>
>> Il giorno lun 14 dic 2020 alle ore 11:26 jb  ha
>> scritto:
>>
>>> Hello,
>>>
>>> I notice a strange thing in the logs. All Nodes (ovirt 4.4.3.12-1.el8)
>>> install every days again Python3, after checking for updates. The GUI log
>>> shows this entries:
>>>
>>> 13.12.2020, 11:39Check for update of host onode1.example.org.
>>> Gathering Facts.
>>> 13.12.2020, 11:39Check for update of host onode1.example.org.
>>> include_tasks.
>>> 13.12.2020, 11:39Check for update of host onode1.example.org.
>>> Detect host operating system.
>>> 13.12.2020, 11:39Check for update of host onode1.example.org. Fetch
>>> installed packages.
>>> 13.12.2020, 11:39Check for update of host onode1.example.org. Check
>>> if vdsm is preinstalled.
>>> 13.12.2020, 11:39Check for update of host onode1.example.org. Parse
>>> operating system release.
>>> 13.12.2020, 11:39Check for update of host onode1.example.org.
>>> Detect if host is a prebuilt image.
>>> 13.12.2020, 11:39Check for update of host onode1.example.org.
>>> Install Python3 for CentOS/RHEL8 hosts.
>>> 13.12.2020, 11:39Check for update of host onode1.example.org. Set
>>> facts.
>>>
>>> +Dana Elfassy  can you please check? Maybe just a
>> matter of wording, something like "Ensuring Python3 is installed
>> for CentOS/RHEL8 hosts"
>>
>>
>>
>>
>>
>>
>>> /var/log/ovirt-engine/ansible-runner-service.log shows:
>>>
>>> 2020-12-13 11:39:20,849 - runner_service.services.playbook - DEBUG -
>>> cb_event_handler event_data={'uuid':
>>> '7c4b039d-6212-4b52-95fd-40d85036ed98', 'counter': 33, 'stdout': 'ok: [
>>> onode1.example.org]', 'start_line': 31, 'end_line': 32, 'runner_ident':
>>> '72737578-3d2f-11eb-b955-00163e33f845', 'event': 'runner_on_ok', 'pid':
>>> 603696, 'created': '2020-12-13T10:39:20.847869', 'parent_uuid':
>>> '00163e33-f845-ee64-acee-0013', 'event_data': {'playbook':
>>> 'ovirt-host-check-upgrade.yml', 'playbook_uuid':
>>> '0eb5c935-9f17-4b07-961e-7e0a866dd5ed', 'play': 'all', 'play_uuid':
>>> '00163e33-f845-ee64-acee-0008', 'play_pattern': 'all', 'task':
>>> 'Install Python3 for CentOS/RHEL8 hosts', 'task_uuid':
>>> '00163e33-f845-ee64-acee-0013', 'task_action': 'yum', 'task_args':
>>> '', 'task_path':
>>> '/usr/share/ovirt-engine/ansible-runner-service-project/project/roles/ovirt-host-deploy-facts/tasks/main.yml:20',
>>> 'role': 'ovirt-host-deploy-facts', 'host': 'onode1.example.org',
>>> 'remote_addr': 'onode1.example.org', 'res': {'msg': 'Nothing to do',
>>> 'changed': False, 'results': [], 'rc': 0, 'invocation': {'module_args':
>>> {'name': ['python3'], 'state': 'present', 'allow_downgrade': False,
>>> 'autoremove': False, 'bugfix': False, 'disable_gpg_check': False,
>>> 'disable_plugin': [], 'disablerepo': [], 'download_only': False,
>>> 'enable_plugin': [], 'enablerepo': [], 'exclude': [], 'installroot': '/',
>>> 'install_repoquery': True, 'install_weak_deps': True, 'security': False,
>>> 'skip_broken': False, 'update_cache': False, 'update_only': False,
>>> 'validate_certs': True, 'lock_timeout': 30, 'conf_file': None,
>>> 'disable_excludes': None, 'download_dir': None, 'list': None, 'releasever':
>>> None}}, '_ansible_no_log': False}, 'start': '2020-12-13T10:39:19.872585',
>>> 'end': '2020-12-13T10:39:20.847636', 'duration': 0.975051, 'event_loop':
>>> None, 'uuid': '7c4b039d-6212-4b52-95fd-40d85036ed98'}}
>>>
>>> Is this a bug?
>>>
>>>
>>> Best regards
>>>
>>> Jonathan
>>> ___
>>> Users mailing list -- users@ovirt.org
>>> To unsubscribe send an email to users-le...@ovirt.org
>>> Privacy Statement: https://www.ovirt.org/privacy-policy.html
>>> oVirt Code of Conduct:
>>> https://www.ovirt.org/community/about/community-guidelines/
>>> List Archives:
>>> https://lists.ovirt.org/archives/list/users@ovirt.org/message/IXSN54JLD32ADEYJ3UHXUHJUIG3U7S25/
>>>
>>
>>
>> --
>>
>> Sandro Bonazzola
>>
>> MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV
>>
>> Red Hat EMEA 
>>
>> sbona...@redhat

[ovirt-users] Re: Bad CPU TYPE after Centos 8.3

2020-12-15 Thread Lucia Jelinkova

Hi Lionel,

Thank you for the output from the virsh command. The interesting part is
this:

Cascadelake-Server-noTSX
Cascadelake-Server

The Cascadelake-Server is not usable any more in 8.3 [1] yet that is
what the cluster is probably configured with.

Could you please run the following query for your cluster to be sure?

select name, cpu_name, cpu_flags, cpu_verb from cluster;

Could you please also run the virsh domcapabilities command on one of
your active and running 8.2 hosts to see if they support
Cascadelake-Server-noTSX?

1: https://www.phoronix.com/scan.php?page=news_item&px=Red-Hat-RHEL-8.3

Thank you,

Lucia





On Mon, Dec 14, 2020 at 7:37 PM  wrote:

> Hi, that CPU looks rather good to me: KVM/oVirt should love it (as would
> I)!
>
> I am actually more inclined to believe that it may be a side channel
> mitigation issue: KVM is distingiuishing between base CPUs and CPUs with
> enabled mitigations to ensure that you won't accidentally migrate a VM from
> a 'safe' CPU to one that's vulnerable.
>
> So I suggest you have a look at that, seen what's enabled in BIOS and via
> microcode updates and check that against what the cluster wants. Perhaps it
> may involve as little as ensuring all current patches are in (with reboots)
> after the update to 8.3.
>
> E.g. you might see this when the cluster was previously running on a
> system with mitigations active, but now mitigations are off (e.g. because
> the latest microcode updates are not loaded yet).
>
> My personal impression is that it wasn't a terribly good idea to mix
> mitigations and CPU capabilities, but that they didn't have time/means for
> a full redesign to what they might have hoped was a singular/one shot
> issue, before it developed into a whole family of cancers.
>
>
> Bonne chance!
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/OHLWLUG23QST3NJCVIX57RR6ZRMSY6VM/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/PWYZH3SK2WALLMWYS45EDAENP4IJQLSZ/

[ovirt-users] Re: fence_xvm for testing

On Tue, Dec 15, 2020 at 11:07 AM Alex K  wrote:

>
>
> On Mon, Dec 14, 2020 at 8:59 PM Strahil Nikolov 
> wrote:
>
>> Fence_xvm requires a key is deployed on both the Host and the VMs in
>> order to succeed. What is happening when you use the cli on any of the VMs ?
>> Also, the VMs require an open tcp port to receive the necessary output of
>> each request.I
>
> I deployed keys at the physical host and virtual hosts, as per
> https://github.com/rightkick/Notes/blob/master/Ovirt-fence_xmv.md
> I can get the VM status from the virtual hosts:
>
> [root@kvm1 cluster]# fence_xvm -a 225.0.0.12 -k
> /etc/cluster/fence_xvm.key -H ovirt-node0 -o status
> Status: ON
> You have new mail in /var/spool/mail/root
> [root@kvm1 cluster]# fence_xvm -a 225.0.0.12 -k
> /etc/cluster/fence_xvm.key -H ovirt-node1 -o status
> Status: ON
>
> kvm0 and kvm1 are the hostnames of each virtual host, while ovirt-node0
> and ovirt-node1 are the domain names of the same virtual hosts as defined
> at virsh.
>

I am passing also the port/domain option at GUI, but from logs it seems it
is being ignored as it is not being logged from engine.

[image: image.png]
tried also domain=ovirt-node0 with same results.



>> Best Regards,
>> Strahil Nikolov
>>
>>
>>
>>
>>
>>
>> В понеделник, 14 декември 2020 г., 10:57:11 Гринуич+2, Alex K <
>> rightkickt...@gmail.com> написа:
>>
>>
>>
>>
>>
>> Hi friends,
>>
>> I was wondering what is needed to setup fence_xvm in order to use for
>> power management in virtual nested environments for testing purposes.
>>
>> I have followed the following steps:
>> https://github.com/rightkick/Notes/blob/master/Ovirt-fence_xmv.md
>>
>> I tried also engine-config -s
>> CustomFenceAgentMapping="fence_xvm=_fence_xvm"
>> From command line all seems fine and I can get the status of the host
>> VMs, but I was not able to find what is needed to set this up at engine UI:
>>
>>
>> At username and pass I just filled dummy values as they should not be
>> needed for fence_xvm.
>> I always get an error at GUI while engine logs give:
>>
>>
>> 2020-12-14 08:53:48,343Z WARN
>>  [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
>> (default task-4) [07c1d540-6d8d-419c-affb-181495d75759] EVENT_ID:
>> VDS_ALERT_FENCE_TEST_FAILED(9,001), Power Management test failed for Host
>> kvm0.lab.local.Internal JSON-RPC error
>> 2020-12-14 08:53:48,343Z INFO
>>  [org.ovirt.engine.core.vdsbroker.vdsbroker.FenceVdsVDSCommand] (default
>> task-4) [07c1d540-6d8d-419c-affb-181495d75759] FINISH, FenceVdsVDSCommand,
>> return: FenceOperationResult:{status='ERROR', powerStatus='UNKNOWN',
>> message='Internal JSON-RPC error'}, log id: 2437b13c
>> 2020-12-14 08:53:48,400Z WARN
>>  [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
>> (default task-4) [07c1d540-6d8d-419c-affb-181495d75759] EVENT_ID:
>> FENCE_OPERATION_USING_AGENT_AND_PROXY_FAILED(9,021), Execution of power
>> management status on Host kvm0.lab.local using Proxy Host kvm1.lab.local
>> and Fence Agent fence_xvm:225.0.0.12 failed.
>> 2020-12-14 08:53:48,400Z WARN
>>  [org.ovirt.engine.core.bll.pm.FenceAgentExecutor] (default task-4)
>> [07c1d540-6d8d-419c-affb-181495d75759] Fence action failed using proxy host
>> 'kvm1.lab.local', trying another proxy
>> 2020-12-14 08:53:48,485Z ERROR 
>> [org.ovirt.engine.core.bll.pm.FenceProxyLocator]
>> (default task-4) [07c1d540-6d8d-419c-affb-181495d75759] Can not run fence
>> action on host 'kvm0.lab.local', no suitable proxy host was found.
>> 2020-12-14 08:53:48,486Z WARN
>>  [org.ovirt.engine.core.bll.pm.FenceAgentExecutor] (default task-4)
>> [07c1d540-6d8d-419c-affb-181495d75759] Failed to find another proxy to
>> re-run failed fence action, retrying with the same proxy 'kvm1.lab.local'
>> 2020-12-14 08:53:48,582Z WARN
>>  [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
>> (default task-4) [07c1d540-6d8d-419c-affb-181495d75759] EVENT_ID:
>> VDS_ALERT_FENCE_TEST_FAILED(9,001), Power Management test failed for Host
>> kvm0.lab.local.Internal JSON-RPC error
>> 2020-12-14 08:53:48,582Z INFO
>>  [org.ovirt.engine.core.vdsbroker.vdsbroker.FenceVdsVDSCommand] (default
>> task-4) [07c1d540-6d8d-419c-affb-181495d75759] FINISH, FenceVdsVDSCommand,
>> return: FenceOperationResult:{status='ERROR', powerStatus='UNKNOWN',
>> message='Internal JSON-RPC error'}, log id: 8607bc9
>> 2020-12-14 08:53:48,637Z WARN
>>  [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
>> (default task-4) [07c1d540-6d8d-419c-affb-181495d75759] EVENT_ID:
>> FENCE_OPERATION_USING_AGENT_AND_PROXY_FAILED(9,021), Execution of power
>> management status on Host kvm0.lab.local using Proxy Host kvm1.lab.local
>> and Fence Agent fence_xvm:225.0.0.12 failed.
>>
>>
>> Any idea?
>>
>> Thanx,
>> Alex
>>
>>
>> ___
>> Users mailing list -- users@ovirt.org
>> To unsubscribe send an email to users-le...@ovirt.org
>> Privacy Statement: https://www.ovirt.org/privacy-policy.html
>> o

[ovirt-users] Re: Nodes install Python3 every day

2020-12-15 Thread jb



Am 15.12.20 um 09:06 schrieb Dana Elfassy:

Yes, I'll edit the title.

Jonathan, you can see in the log you pasted:
*'task': 'Install Python3 for CentOS/RHEL8 hosts'*, 'task_uuid': 
'00163e33-f845-ee64-acee-0013', 'task_action': 'yum', 
'task_args': '', 'task_path': 
'/usr/share/ovirt-engine/ansible-runner-service-project/project/roles/ovirt-host-deploy-facts/tasks/main.yml:20', 
'role': 'ovirt-host-deploy-facts', 'host': 'onode1.example.org 
', 'remote_addr': 'onode1.example.org 
', *'res': {'msg': 'Nothing to do', 
'changed': False, 'results': [], 'rc': 0,*

*
*
This means it wasn't installed (will be only if the package doesn't exist)


Thank you for the explanation, I should have unfolded the log... Sorry 
for the effort!




Thanks,
Dana

On Mon, Dec 14, 2020 at 3:36 PM Sandro Bonazzola > wrote:




Il giorno lun 14 dic 2020 alle ore 11:26 jb mailto:jonba...@gmail.com>> ha scritto:

Hello,

I notice a strange thing in the logs. All Nodes (ovirt
4.4.3.12-1.el8) install every days again Python3, after
checking for updates. The GUI log shows this entries:

13.12.2020, 11:39    Check for update of host
onode1.example.org . Gathering
Facts.
13.12.2020, 11:39    Check for update of host
onode1.example.org . include_tasks.
13.12.2020, 11:39    Check for update of host
onode1.example.org . Detect
host operating system.
13.12.2020, 11:39    Check for update of host
onode1.example.org . Fetch
installed packages.
13.12.2020, 11:39    Check for update of host
onode1.example.org . Check if
vdsm is preinstalled.
13.12.2020, 11:39    Check for update of host
onode1.example.org . Parse
operating system release.
13.12.2020, 11:39    Check for update of host
onode1.example.org . Detect if
host is a prebuilt image.
13.12.2020, 11:39    Check for update of host
onode1.example.org . Install
Python3 for CentOS/RHEL8 hosts.
13.12.2020, 11:39    Check for update of host
onode1.example.org . Set facts.

+Dana Elfassy  can you please check?
Maybe just a matter of wording, something like "Ensuring Python3
is installed for CentOS/RHEL8 hosts"




/var/log/ovirt-engine/ansible-runner-service.log shows:

2020-12-13 11:39:20,849 - runner_service.services.playbook
- DEBUG - cb_event_handler event_data={'uuid':
'7c4b039d-6212-4b52-95fd-40d85036ed98', 'counter': 33,
'stdout': 'ok: [onode1.example.org
]', 'start_line': 31,
'end_line': 32, 'runner_ident':
'72737578-3d2f-11eb-b955-00163e33f845', 'event':
'runner_on_ok', 'pid': 603696, 'created':
'2020-12-13T10:39:20.847869', 'parent_uuid':
'00163e33-f845-ee64-acee-0013', 'event_data':
{'playbook': 'ovirt-host-check-upgrade.yml',
'playbook_uuid': '0eb5c935-9f17-4b07-961e-7e0a866dd5ed',
'play': 'all', 'play_uuid':
'00163e33-f845-ee64-acee-0008', 'play_pattern':
'all', 'task': 'Install Python3 for CentOS/RHEL8 hosts',
'task_uuid': '00163e33-f845-ee64-acee-0013',
'task_action': 'yum', 'task_args': '', 'task_path':

'/usr/share/ovirt-engine/ansible-runner-service-project/project/roles/ovirt-host-deploy-facts/tasks/main.yml:20',
'role': 'ovirt-host-deploy-facts', 'host':
'onode1.example.org ',
'remote_addr': 'onode1.example.org
', 'res': {'msg': 'Nothing to
do', 'changed': False, 'results': [], 'rc': 0,
'invocation': {'module_args': {'name': ['python3'],
'state': 'present', 'allow_downgrade': False,
'autoremove': False, 'bugfix': False, 'disable_gpg_check':
False, 'disable_plugin': [], 'disablerepo': [],
'download_only': False, 'enable_plugin': [], 'enablerepo':
[], 'exclude': [], 'installroot': '/',
'install_repoquery': True, 'install_weak_deps': True,
'security': False, 'skip_broken': False, 'update_cache':
False, 'update_only': False, 'validate_certs': True,
'lock_timeout': 30, 'conf_file': None, 'disable_excludes':
None, 'download_dir': None, 'list': None, 'releasever':

[ovirt-users] Re: fence_xvm for testing

On Mon, Dec 14, 2020 at 8:59 PM Strahil Nikolov 
wrote:

> Fence_xvm requires a key is deployed on both the Host and the VMs in order
> to succeed. What is happening when you use the cli on any of the VMs ?
> Also, the VMs require an open tcp port to receive the necessary output of
> each request.I

I deployed keys at the physical host and virtual hosts, as per
https://github.com/rightkick/Notes/blob/master/Ovirt-fence_xmv.md
I can get the VM status from the virtual hosts:

[root@kvm1 cluster]# fence_xvm -a 225.0.0.12 -k /etc/cluster/fence_xvm.key
-H ovirt-node0 -o status
Status: ON
You have new mail in /var/spool/mail/root
[root@kvm1 cluster]# fence_xvm -a 225.0.0.12 -k /etc/cluster/fence_xvm.key
-H ovirt-node1 -o status
Status: ON

kvm0 and kvm1 are the hostnames of each virtual host, while ovirt-node0 and
ovirt-node1 are the domain names of the same virtual hosts as defined at
virsh.

>
> Best Regards,
> Strahil Nikolov
>
>
>
>
>
>
> В понеделник, 14 декември 2020 г., 10:57:11 Гринуич+2, Alex K <
> rightkickt...@gmail.com> написа:
>
>
>
>
>
> Hi friends,
>
> I was wondering what is needed to setup fence_xvm in order to use for
> power management in virtual nested environments for testing purposes.
>
> I have followed the following steps:
> https://github.com/rightkick/Notes/blob/master/Ovirt-fence_xmv.md
>
> I tried also engine-config -s
> CustomFenceAgentMapping="fence_xvm=_fence_xvm"
> From command line all seems fine and I can get the status of the host VMs,
> but I was not able to find what is needed to set this up at engine UI:
>
>
> At username and pass I just filled dummy values as they should not be
> needed for fence_xvm.
> I always get an error at GUI while engine logs give:
>
>
> 2020-12-14 08:53:48,343Z WARN
>  [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> (default task-4) [07c1d540-6d8d-419c-affb-181495d75759] EVENT_ID:
> VDS_ALERT_FENCE_TEST_FAILED(9,001), Power Management test failed for Host
> kvm0.lab.local.Internal JSON-RPC error
> 2020-12-14 08:53:48,343Z INFO
>  [org.ovirt.engine.core.vdsbroker.vdsbroker.FenceVdsVDSCommand] (default
> task-4) [07c1d540-6d8d-419c-affb-181495d75759] FINISH, FenceVdsVDSCommand,
> return: FenceOperationResult:{status='ERROR', powerStatus='UNKNOWN',
> message='Internal JSON-RPC error'}, log id: 2437b13c
> 2020-12-14 08:53:48,400Z WARN
>  [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> (default task-4) [07c1d540-6d8d-419c-affb-181495d75759] EVENT_ID:
> FENCE_OPERATION_USING_AGENT_AND_PROXY_FAILED(9,021), Execution of power
> management status on Host kvm0.lab.local using Proxy Host kvm1.lab.local
> and Fence Agent fence_xvm:225.0.0.12 failed.
> 2020-12-14 08:53:48,400Z WARN
>  [org.ovirt.engine.core.bll.pm.FenceAgentExecutor] (default task-4)
> [07c1d540-6d8d-419c-affb-181495d75759] Fence action failed using proxy host
> 'kvm1.lab.local', trying another proxy
> 2020-12-14 08:53:48,485Z ERROR 
> [org.ovirt.engine.core.bll.pm.FenceProxyLocator]
> (default task-4) [07c1d540-6d8d-419c-affb-181495d75759] Can not run fence
> action on host 'kvm0.lab.local', no suitable proxy host was found.
> 2020-12-14 08:53:48,486Z WARN
>  [org.ovirt.engine.core.bll.pm.FenceAgentExecutor] (default task-4)
> [07c1d540-6d8d-419c-affb-181495d75759] Failed to find another proxy to
> re-run failed fence action, retrying with the same proxy 'kvm1.lab.local'
> 2020-12-14 08:53:48,582Z WARN
>  [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> (default task-4) [07c1d540-6d8d-419c-affb-181495d75759] EVENT_ID:
> VDS_ALERT_FENCE_TEST_FAILED(9,001), Power Management test failed for Host
> kvm0.lab.local.Internal JSON-RPC error
> 2020-12-14 08:53:48,582Z INFO
>  [org.ovirt.engine.core.vdsbroker.vdsbroker.FenceVdsVDSCommand] (default
> task-4) [07c1d540-6d8d-419c-affb-181495d75759] FINISH, FenceVdsVDSCommand,
> return: FenceOperationResult:{status='ERROR', powerStatus='UNKNOWN',
> message='Internal JSON-RPC error'}, log id: 8607bc9
> 2020-12-14 08:53:48,637Z WARN
>  [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> (default task-4) [07c1d540-6d8d-419c-affb-181495d75759] EVENT_ID:
> FENCE_OPERATION_USING_AGENT_AND_PROXY_FAILED(9,021), Execution of power
> management status on Host kvm0.lab.local using Proxy Host kvm1.lab.local
> and Fence Agent fence_xvm:225.0.0.12 failed.
>
>
> Any idea?
>
> Thanx,
> Alex
>
>
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/B7IHC4MYY5LJFJMEJMLRRFSTMD7IK23I/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/pri

[ovirt-users] How to unlock disk images?

On one oVirt 4.3 farm I have three locked images I'd like to clear out.

One is an ISO image, that somehow never completed the transfer due to a slow
network. It's occupying little space, except in the GUI where it sticks out and
irritates. I guess it would just be an update somewhere on the Postgress
database to unlock it and have it deletable: But since the schema isn't
documented, I'd rather ask here: How to I unlock the image?

Two are left-overs from a snapshot that somehow never completed, one for the
disk another for the RAM part. I don't know how my colleague managed to get
into that state, but impatience/concurrency probably was a factor, a transient
failure of a node could have been another.

In any case the snapshot operation logically has been going on for weeks
without any real activity, survived several restarts (after patches) of all
nodes and the ME and shows no sign of disappearing voluntarily.

Again, I'd assume that I need to clear out the snapshot job, unlock the images
and then delete what's left. Some easy SQL and most likely a management engine
restart afterwards... if you knew what you were doing (or there was an option
in the GUI).

So how do I list/delete snapshot jobs that aren't really running any more?
And how do I unlock the images so I can delete them?

Thanks for your help!
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct:
https://www.ovirt.org/community/about/community-guidelines/
List Archives:
https://lists.ovirt.org/archives/list/users@ovirt.org/message/XHC5GNLOZO2WFECII7AZX3QV2YEZ4NPO/

[ovirt-users] Re: CentOS 8 is dead

I am glad you think so and it works for you. But I'd also guess that you put 
more than a partial FTE to the project.

I got attracted via the HCI angle they started pushing as a result of Nutanix 
creating a bit of a stir. The ability to use discarded production boxes for a 
lab with the flexibility of just adding boxes as they were released and 
discarding them as they died eventually, was what I had in mind for oVirt. The 
inherent flexibility of Gluster would seen to support that, KVM's 
live-migration and the fundamental design of the management engine and the VDSM 
agents, fit, too.

Then come the details... and they fall quite short of that vision. I thought I 
had found another golden nugget like OpenVZ, but HCI is still more of a hack 
for three nodes without a natural n+1 path beyond, when Gluster was supposed to 
outscale Lustre.
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/LB5RIP5RZV5NOBOQ5GSX7KSBVAEEMV7S/

[ovirt-users] Re: CentOS 8 is dead

2020-12-15 Thread James Loker-Steele via Users

Also we have begun using OLVM based on tests we conducted with ovirt a while 
ago.
Only issue is olvm is currently stuck on 4.3.6 and waiting for oracle to 
release updates is a slow process.
Personally I would have liked to use ovirt but apparently using oracle is 
better for the Databases.
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/GOAJY36LTUESTFOWCYWOCQON5ZMAXNCS/

[ovirt-users] Re: Nodes install Python3 every day

2020-12-15 Thread Dana Elfassy

Yes, I'll edit the title.

Jonathan, you can see in the log you pasted:
*'task': 'Install Python3 for CentOS/RHEL8 hosts'*, 'task_uuid':
'00163e33-f845-ee64-acee-0013', 'task_action': 'yum', 'task_args':
'', 'task_path':
'/usr/share/ovirt-engine/ansible-runner-service-project/project/roles/ovirt-host-deploy-facts/tasks/main.yml:20',
'role': 'ovirt-host-deploy-facts', 'host': 'onode1.example.org',
'remote_addr': 'onode1.example.org', *'res': {'msg': 'Nothing to do',
'changed': False, 'results': [], 'rc': 0,*

This means it wasn't installed (will be only if the package doesn't exist)
Thanks,
Dana

On Mon, Dec 14, 2020 at 3:36 PM Sandro Bonazzola 
wrote:

>
>
> Il giorno lun 14 dic 2020 alle ore 11:26 jb  ha
> scritto:
>
>> Hello,
>>
>> I notice a strange thing in the logs. All Nodes (ovirt 4.4.3.12-1.el8)
>> install every days again Python3, after checking for updates. The GUI log
>> shows this entries:
>>
>> 13.12.2020, 11:39Check for update of host onode1.example.org.
>> Gathering Facts.
>> 13.12.2020, 11:39Check for update of host onode1.example.org.
>> include_tasks.
>> 13.12.2020, 11:39Check for update of host onode1.example.org. Detect
>> host operating system.
>> 13.12.2020, 11:39Check for update of host onode1.example.org. Fetch
>> installed packages.
>> 13.12.2020, 11:39Check for update of host onode1.example.org. Check
>> if vdsm is preinstalled.
>> 13.12.2020, 11:39Check for update of host onode1.example.org. Parse
>> operating system release.
>> 13.12.2020, 11:39Check for update of host onode1.example.org. Detect
>> if host is a prebuilt image.
>> 13.12.2020, 11:39Check for update of host onode1.example.org.
>> Install Python3 for CentOS/RHEL8 hosts.
>> 13.12.2020, 11:39Check for update of host onode1.example.org. Set
>> facts.
>>
>> +Dana Elfassy  can you please check? Maybe just a
> matter of wording, something like "Ensuring Python3 is installed
> for CentOS/RHEL8 hosts"
>
>
>
>
>
>
>> /var/log/ovirt-engine/ansible-runner-service.log shows:
>>
>> 2020-12-13 11:39:20,849 - runner_service.services.playbook - DEBUG -
>> cb_event_handler event_data={'uuid':
>> '7c4b039d-6212-4b52-95fd-40d85036ed98', 'counter': 33, 'stdout': 'ok: [
>> onode1.example.org]', 'start_line': 31, 'end_line': 32, 'runner_ident':
>> '72737578-3d2f-11eb-b955-00163e33f845', 'event': 'runner_on_ok', 'pid':
>> 603696, 'created': '2020-12-13T10:39:20.847869', 'parent_uuid':
>> '00163e33-f845-ee64-acee-0013', 'event_data': {'playbook':
>> 'ovirt-host-check-upgrade.yml', 'playbook_uuid':
>> '0eb5c935-9f17-4b07-961e-7e0a866dd5ed', 'play': 'all', 'play_uuid':
>> '00163e33-f845-ee64-acee-0008', 'play_pattern': 'all', 'task':
>> 'Install Python3 for CentOS/RHEL8 hosts', 'task_uuid':
>> '00163e33-f845-ee64-acee-0013', 'task_action': 'yum', 'task_args':
>> '', 'task_path':
>> '/usr/share/ovirt-engine/ansible-runner-service-project/project/roles/ovirt-host-deploy-facts/tasks/main.yml:20',
>> 'role': 'ovirt-host-deploy-facts', 'host': 'onode1.example.org',
>> 'remote_addr': 'onode1.example.org', 'res': {'msg': 'Nothing to do',
>> 'changed': False, 'results': [], 'rc': 0, 'invocation': {'module_args':
>> {'name': ['python3'], 'state': 'present', 'allow_downgrade': False,
>> 'autoremove': False, 'bugfix': False, 'disable_gpg_check': False,
>> 'disable_plugin': [], 'disablerepo': [], 'download_only': False,
>> 'enable_plugin': [], 'enablerepo': [], 'exclude': [], 'installroot': '/',
>> 'install_repoquery': True, 'install_weak_deps': True, 'security': False,
>> 'skip_broken': False, 'update_cache': False, 'update_only': False,
>> 'validate_certs': True, 'lock_timeout': 30, 'conf_file': None,
>> 'disable_excludes': None, 'download_dir': None, 'list': None, 'releasever':
>> None}}, '_ansible_no_log': False}, 'start': '2020-12-13T10:39:19.872585',
>> 'end': '2020-12-13T10:39:20.847636', 'duration': 0.975051, 'event_loop':
>> None, 'uuid': '7c4b039d-6212-4b52-95fd-40d85036ed98'}}
>>
>> Is this a bug?
>>
>>
>> Best regards
>>
>> Jonathan
>> ___
>> Users mailing list -- users@ovirt.org
>> To unsubscribe send an email to users-le...@ovirt.org
>> Privacy Statement: https://www.ovirt.org/privacy-policy.html
>> oVirt Code of Conduct:
>> https://www.ovirt.org/community/about/community-guidelines/
>> List Archives:
>> https://lists.ovirt.org/archives/list/users@ovirt.org/message/IXSN54JLD32ADEYJ3UHXUHJUIG3U7S25/
>>
>
>
> --
>
> Sandro Bonazzola
>
> MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV
>
> Red Hat EMEA 
>
> sbona...@redhat.com
> 
>
> *Red Hat respects your work life balance. Therefore there is no need to
> answer this email out of your office hours.
> *
>
>
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-po

[ovirt-users] Re: CentOS 8 is dead