[ovirt-users] Re: oVirt 4.4.4 not dislaying Sign-on Screen
Hi, Could you please create a bug for the oVirt project on https://bugzilla.redhat.com and attach logs from your oVirt Engine using sos logcollector? https://www.ovirt.org/documentation/administration_guide/#sect-The_Log_Collector_Tool Thanks, Martin On Thu, Mar 11, 2021 at 11:40 PM wrote: > I've re-installed oVirt 4.4.4 without capital letter, I continue to get > the same results. Do you have any idea of where to start looking for a > solution? What could the error message "Internal Server Error" be coming > from, "oVirt", "FireFox Browser" or "Apache Server". Where do I start > looking? Nothing seems to be working at this point, my OS is "RHEL 8.3" > with all security patches and fixes applied. > > Can you think anything or a place to start working towards a solution? > > Thanks > > ___ > 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/4VIE4ZHHHUZKBEPJH55BSU6JEUEKE6WD/ > -- Martin Perina Manager, Software Engineering Red Hat Czech s.r.o. ___ 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/XISLCUMZK25RZYGMLC4HFKUWMA5I3IG4/
[ovirt-users] Re: oVirt 4.4.4 not dislaying Sign-on Screen
I've re-installed oVirt 4.4.4 without capital letter, I continue to get the same results. Do you have any idea of where to start looking for a solution? What could the error message "Internal Server Error" be coming from, "oVirt", "FireFox Browser" or "Apache Server". Where do I start looking? Nothing seems to be working at this point, my OS is "RHEL 8.3" with all security patches and fixes applied. Can you think anything or a place to start working towards a solution? Thanks ___ 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/4VIE4ZHHHUZKBEPJH55BSU6JEUEKE6WD/
[ovirt-users] Re: Gluster volume engine stuck in healing with 1 unsynched entry & HostedEngine paused
Just move it away (to be on the safe side) and trigger a full heal. Best Regards, Strahil Nikolov В сряда, 10 март 2021 г., 13:01:21 ч. Гринуич+2, Maria Souvalioti написа: Should I delete the file and restart glusterd on the ov-no1 server? Thank you very much On 3/10/21 10:21 AM, Strahil Nikolov via Users wrote: > It seems to me that ov-no1 didn't update the file properly. What was the output of the gluster volume heal command ? Best Regards, Strahil Nikolov > > > > The output of the getfattr command on the nodes was the following: > > Node1: > [root@ov-no1 ~]# getfattr -d -m . -e hex > /gluster_bricks/engine/engine/80f6e393-9718-4738-a14a-64cf43c3d8c2/images/d5de54b6-9f8e-4fba-819b-ebf6780757d2/a48555f4-be23-4467-8a54-400ae7baf9d7 > getfattr: Removing leading '/' from absolute path names > # file: > gluster_bricks/engine/engine/80f6e393-9718-4738-a14a-64cf43c3d8c2/images/d5de54b6-9f8e-4fba-819b-ebf6780757d2/a48555f4-be23-4467-8a54-400ae7baf9d7 > security.selinux=0x73797374656d5f753a6f626a6563745f723a676c7573746572645f627269636b5f743a733000 > trusted.afr.dirty=0x0394 > trusted.afr.engine-client-2=0x > trusted.gfid=0x3fafabf3d0cd4b9a8dd743145451f7cf > trusted.gfid2path.06f4f1065c7ed193=0x36313936323032302d386431342d343261372d613565332d3233346365656635343035632f61343835353566342d626532332d343436372d386135342d343030616537626166396437 > trusted.glusterfs.mdata=0x015fec62872f5849585fec62872f5849585d791c1a00ba286e > trusted.glusterfs.shard.block-size=0x0400 > trusted.glusterfs.shard.file-size=0x00190092040b > > > Node2: > [root@ov-no2 ~]# getfattr -d -m . -e hex > /gluster_bricks/engine/engine/80f6e393-9718-4738-a14a-64cf43c3d8c2/images/d5de54b6-9f8e-4fba-819b-ebf6780757d2/a48555f4-be23-4467-8a54-400ae7baf9d7 > getfattr: Removing leading '/' from absolute path names > # file: > gluster_bricks/engine/engine/80f6e393-9718-4738-a14a-64cf43c3d8c2/images/d5de54b6-9f8e-4fba-819b-ebf6780757d2/a48555f4-be23-4467-8a54-400ae7baf9d7 > security.selinux=0x73797374656d5f753a6f626a6563745f723a676c7573746572645f627269636b5f743a733000 > trusted.afr.dirty=0x > trusted.afr.engine-client-0=0x043a > trusted.afr.engine-client-2=0x > trusted.gfid=0x3fafabf3d0cd4b9a8dd743145451f7cf > trusted.gfid2path.06f4f1065c7ed193=0x36313936323032302d386431342d343261372d613565332d3233346365656635343035632f61343835353566342d626532332d343436372d386135342d343030616537626166396437 > trusted.glusterfs.mdata=0x015fec62872f5849585fec62872f5849585d791c1a00ba286e > trusted.glusterfs.shard.block-size=0x0400 > trusted.glusterfs.shard.file-size=0x00190092040b > > > Node3: > [root@ov-no3 ~]# getfattr -d -m . -e hex > /gluster_bricks/engine/engine/80f6e393-9718-4738-a14a-64cf43c3d8c2/images/d5de54b6-9f8e-4fba-819b-ebf6780757d2/a48555f4-be23-4467-8a54-400ae7baf9d7 > getfattr: Removing leading '/' from absolute path names > # file: > gluster_bricks/engine/engine/80f6e393-9718-4738-a14a-64cf43c3d8c2/images/d5de54b6-9f8e-4fba-819b-ebf6780757d2/a48555f4-be23-4467-8a54-400ae7baf9d7 > security.selinux=0x73797374656d5f753a6f626a6563745f723a676c7573746572645f627269636b5f743a733000 > trusted.afr.dirty=0x > trusted.afr.engine-client-0=0x0444 > trusted.gfid=0x3fafabf3d0cd4b9a8dd743145451f7cf > trusted.gfid2path.06f4f1065c7ed193=0x36313936323032302d386431342d343261372d613565332d3233346365656635343035632f61343835353566342d626532332d343436372d386135342d343030616537626166396437 > trusted.glusterfs.mdata=0x015fec62872f5849585fec62872f5849585d791c1a00ba286e > trusted.glusterfs.shard.block-size=0x0400 > trusted.glusterfs.shard.file-size=0x00190092040b > > > ___ > 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/PUVBESAIZEJ7URDMDQ7LDUPNS6YDBVAS/ > > > > > ___ 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/R3ODLVEODDFWP3IVLPFNQXNLBCPPSZTR/
[ovirt-users] Re: Gluster volume engine stuck in healing with 1 unsynched entry & HostedEngine paused
It seems that the affected file can be moved away on ov-no1.ariadne-t.local, as the other 2 bricks "blame" the entry on ov-no1.ariadne-t.local . After that , you will need to "gluster volume heal full" to trigger the heal. Best Regards, Strahil Nikolov В сряда, 10 март 2021 г., 12:58:10 ч. Гринуич+2, Maria Souvalioti написа: The gluster volume heal engine command didn't output anything in the CLI. The gluster volume heal engine info gives: # gluster volume heal engine info Brick ov-no1.ariadne-t.local:/gluster_bricks/engine/engine Status: Connected Number of entries: 0 Brick ov-no2.ariadne-t.local:/gluster_bricks/engine/engine /80f6e393-9718-4738-a14a-64cf43c3d8c2/images/d5de54b6-9f8e-4fba-819b-ebf6780757d2/a48555f4-be23-4467-8a54-400ae7baf9d7 Status: Connected Number of entries: 1 Brick ov-no3.ariadne-t.local:/gluster_bricks/engine/engine /80f6e393-9718-4738-a14a-64cf43c3d8c2/images/d5de54b6-9f8e-4fba-819b-ebf6780757d2/a48555f4-be23-4467-8a54-400ae7baf9d7 Status: Connected Number of entries: 1 And gluster volume heal engine info summary gives: # gluster volume heal engine info summary Brick ov-no1.ariadne-t.local:/gluster_bricks/engine/engine Status: Connected Total Number of entries: 1 Number of entries in heal pending: 1 Number of entries in split-brain: 0 Number of entries possibly healing: 0 Brick ov-no2.ariadne-t.local:/gluster_bricks/engine/engine Status: Connected Total Number of entries: 1 Number of entries in heal pending: 1 Number of entries in split-brain: 0 Number of entries possibly healing: 0 Brick ov-no3.ariadne-t.local:/gluster_bricks/engine/engine Status: Connected Total Number of entries: 1 Number of entries in heal pending: 1 Number of entries in split-brain: 0 Number of entries possibly healing: 0 Also I found the following warning message in the logs that has been repeating itself since the problem started: [2021-03-10 10:08:11.646824] W [MSGID: 114061] [client-common.c:2644:client_pre_fsync_v2] 0-engine-client-0: (3fafabf3-d0cd-4b9a-8dd7-43145451f7cf) remote_fd is -1. EBADFD [File descriptor in bad state] And from what I see in the logs, the healing process seems to be still trying to fix the volume. [2021-03-10 10:47:34.820229] I [MSGID: 108026] [afr-self-heal-common.c:1741:afr_log_selfheal] 0-engine-replicate-0: Completed data selfheal on 3fafabf3-d0cd-4b9a-8dd7-43145451f7cf. sources=1 [2] sinks=0 The message "I [MSGID: 108026] [afr-self-heal-common.c:1741:afr_log_selfheal] 0-engine-replicate-0: Completed data selfheal on 3fafabf3-d0cd-4b9a-8dd7-43145451f7cf. sources=1 [2] sinks=0 " repeated 8 times between [2021-03-10 10:47:34.820229] and [2021-03-10 10:48:00.088805] On 3/10/21 10:21 AM, Strahil Nikolov via Users wrote: > It seems to me that ov-no1 didn't update the file properly. What was the output of the gluster volume heal command ? Best Regards, Strahil Nikolov > > > > The output of the getfattr command on the nodes was the following: > > Node1: > [root@ov-no1 ~]# getfattr -d -m . -e hex > /gluster_bricks/engine/engine/80f6e393-9718-4738-a14a-64cf43c3d8c2/images/d5de54b6-9f8e-4fba-819b-ebf6780757d2/a48555f4-be23-4467-8a54-400ae7baf9d7 > getfattr: Removing leading '/' from absolute path names > # file: > gluster_bricks/engine/engine/80f6e393-9718-4738-a14a-64cf43c3d8c2/images/d5de54b6-9f8e-4fba-819b-ebf6780757d2/a48555f4-be23-4467-8a54-400ae7baf9d7 > security.selinux=0x73797374656d5f753a6f626a6563745f723a676c7573746572645f627269636b5f743a733000 > trusted.afr.dirty=0x0394 > trusted.afr.engine-client-2=0x > trusted.gfid=0x3fafabf3d0cd4b9a8dd743145451f7cf > trusted.gfid2path.06f4f1065c7ed193=0x36313936323032302d386431342d343261372d613565332d3233346365656635343035632f61343835353566342d626532332d343436372d386135342d343030616537626166396437 > trusted.glusterfs.mdata=0x015fec62872f5849585fec62872f5849585d791c1a00ba286e > trusted.glusterfs.shard.block-size=0x0400 > trusted.glusterfs.shard.file-size=0x00190092040b > > > Node2: > [root@ov-no2 ~]# getfattr -d -m . -e hex > /gluster_bricks/engine/engine/80f6e393-9718-4738-a14a-64cf43c3d8c2/images/d5de54b6-9f8e-4fba-819b-ebf6780757d2/a48555f4-be23-4467-8a54-400ae7baf9d7 > getfattr: Removing leading '/' from absolute path names > # file: > gluster_bricks/engine/engine/80f6e393-9718-4738-a14a-64cf43c3d8c2/images/d5de54b6-9f8e-4fba-819b-ebf6780757d2/a48555f4-be23-4467-8a54-400ae7baf9d7 >
[ovirt-users] Re: VM CPU Pinning
Hi Arik, You are right. I tried this syntax and it worked: olvm-vmcontrol -m -u api_cpu_pin@internal -v -c setvcpu -s 0-19,40-59 -e (Pinning to 40 Physical cpus). Will see how to convert a long list of digits to the shorten syntax... Thanks, Lavi ___ 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/QA3TX7FDH62DF4OYHTYURMSWDT75MVSL/
[ovirt-users] Re: VM CPU Pinning
On Thu, Mar 11, 2021 at 5:20 PM lavi.buchnik--- via Users wrote: > Hi Arik, > > I'm using this tool to pin the VM cpu's: > olvm-vmcontrol -m -u api_cpu_pin@internal -v -c setvcpu -s > 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55 > -e > So there's probably a bug in that olvm-vmcontrol thingie, I don't know how it generates the pinning string You can write your own script to generate a shorter one :) or update to 4.4 and use the auto-pinning feature > > Thanks, > Lavi > ___ > 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/NLZX6QLZ4IWUPG4G6TWHYRYLYXVYQMSV/ > ___ 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/LYL7NDWPGXI5HX2BYSQAKBOMI4NECDE5/
[ovirt-users] Re: VM CPU Pinning
Hi Arik, I'm using this tool to pin the VM cpu's: olvm-vmcontrol -m -u api_cpu_pin@internal -v -c setvcpu -s 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55 -e Thanks, Lavi ___ 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/NLZX6QLZ4IWUPG4G6TWHYRYLYXVYQMSV/
[ovirt-users] Re: VM CPU Pinning
On Thu, Mar 11, 2021 at 4:27 PM lavi.buchnik--- via Users wrote: > Hi, > > When trying to pin a VM CPU's to Physical CPU's, I'm getting this error in > case the number of physical CPU slots are > 35 (e.g. 40): > > Error attempting to pin CPUs. > Full error: Fault reason is "Operation Failed". Fault detail is "[size > must be between 0 and 4000, Attribute: vmStatic.cpuPinning]". HTTP response > code is "400". HTTP response message is "Bad Request". > > It is working for me up to 35 physical CPU's. but above it, I get that > error. > > Can you please tell what this error means and how to overcome it? > Version we are using is: 4.3.6.6-1.0.9.el7 > You've specified a pinning-string that is longer than 4K characters - the pinning string shouldn't be that long.. > > Thanks, > Lavi > ___ > 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/TBC5WUEKU7Y4KGKFG4JFU7IGSXJL6K7R/ > ___ 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/HTBQ4Y6QF2W6H3YSV4ITXREG25NAUKQM/
[ovirt-users] VM CPU Pinning
Hi, When trying to pin a VM CPU's to Physical CPU's, I'm getting this error in case the number of physical CPU slots are > 35 (e.g. 40): Error attempting to pin CPUs. Full error: Fault reason is "Operation Failed". Fault detail is "[size must be between 0 and 4000, Attribute: vmStatic.cpuPinning]". HTTP response code is "400". HTTP response message is "Bad Request". It is working for me up to 35 physical CPU's. but above it, I get that error. Can you please tell what this error means and how to overcome it? Version we are using is: 4.3.6.6-1.0.9.el7 Thanks, Lavi ___ 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/TBC5WUEKU7Y4KGKFG4JFU7IGSXJL6K7R/
