[ovirt-users] Re: problems installing standard Linux as nodes in 4.4
On Fri, Oct 9, 2020 at 7:12 PM Martin Perina wrote: > > > Could you please share with us all logs from engine gathered by > logcollector? We will try to find out any clue what's wrong in your env ... > > Thanks, > Martin > > I will try to collect. In the mean time I've found that SSH could be in some way involved When I add the host and get the immediate failure and apparently nothing happens at all, I see these two lines in /var/log/ovirt-engine/server.log 2020-10-09 18:15:09,369+02 WARN [org.apache.sshd.client.session.ClientConnectionService] (sshd-SshClient[7cb54873]-nio2-thread-1) globalRequest(ClientConnectionService[ClientSessionImpl[root@ov200 /10.4.192.32:22]])[hostkeys...@openssh.com, want-reply=false] failed (SshException) to process: EdDSA provider not supported 2020-10-09 18:15:09,699+02 WARN [org.apache.sshd.client.session.ClientConnectionService] (sshd-SshClient[2cbceeab]-nio2-thread-1) globalRequest(ClientConnectionService[ClientSessionImpl[root@ov200 /10.4.192.32:22]])[hostkeys...@openssh.com, want-reply=false] failed (SshException) to process: EdDSA provider not supported could it be that the ssh client embedded is not able to connect to the CentOS 8.2 for some reason? On host at the moment when I try to add it I see again two sessions opened and immediately closed (tried several times), eg in the timeframe above I have: Oct 9 18:15:09 ov200 systemd-logind[1237]: New session 41 of user root. Oct 9 18:15:09 ov200 systemd[1]: Started Session 41 of user root. Oct 9 18:15:09 ov200 systemd-logind[1237]: Session 41 logged out. Waiting for processes to exit. Oct 9 18:15:09 ov200 systemd-logind[1237]: Removed session 41. Oct 9 18:15:09 ov200 systemd-logind[1237]: New session 42 of user root. Oct 9 18:15:09 ov200 systemd[1]: Started Session 42 of user root. Oct 9 18:15:09 ov200 systemd-logind[1237]: Session 42 logged out. Waiting for processes to exit. Oct 9 18:15:09 ov200 systemd-logind[1237]: Removed session 42. anyway at sshd service level it seems it is ok om the host: journalctl -u sshd.service has Oct 09 18:15:09 ov200 sshd[13379]: Accepted password for root from 10.4.192.43 port 46008 ssh2 Oct 09 18:15:09 ov200 sshd[13379]: pam_unix(sshd:session): session opened for user root by (uid=0) Oct 09 18:15:09 ov200 sshd[13379]: pam_unix(sshd:session): session closed for user root Oct 09 18:15:09 ov200 sshd[13398]: Accepted password for root from 10.4.192.43 port 46014 ssh2 Oct 09 18:15:09 ov200 sshd[13398]: pam_unix(sshd:session): session opened for user root by (uid=0) Oct 09 18:15:09 ov200 sshd[13398]: pam_unix(sshd:session): session closed for user root On the host I have not customized anything ssh related: [root@ov200 ssh]# ps -ef|grep sshd root1274 1 0 Oct08 ?00:00:00 /usr/sbin/sshd -D -oCiphers=aes256-...@openssh.com,chacha20-poly1...@openssh.com ,aes256-ctr,aes256-cbc,aes128-...@openssh.com,aes128-ctr,aes128-cbc -oMACs= hmac-sha2-256-...@openssh.com,hmac-sha1-...@openssh.com, umac-128-...@openssh.com,hmac-sha2-512-...@openssh.com ,hmac-sha2-256,hmac-sha1,umac-...@openssh.com,hmac-sha2-512 -oGSSAPIKexAlgorithms=gss-gex-sha1-,gss-group14-sha1- -oKexAlgorithms=curve25519-sha256,curve25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1 -oHostKeyAlgorithms=rsa-sha2-256,rsa-sha2-256-cert-...@openssh.com ,ecdsa-sha2-nistp256,ecdsa-sha2-nistp256-cert-...@openssh.com ,ecdsa-sha2-nistp384,ecdsa-sha2-nistp384-cert-...@openssh.com,rsa-sha2-512, rsa-sha2-512-cert-...@openssh.com,ecdsa-sha2-nistp521, ecdsa-sha2-nistp521-cert-...@openssh.com,ssh-ed25519, ssh-ed25519-cert-...@openssh.com,ssh-rsa,ssh-rsa-cert-...@openssh.com -oPubkeyAcceptedKeyTypes=rsa-sha2-256,rsa-sha2-256-cert-...@openssh.com ,ecdsa-sha2-nistp256,ecdsa-sha2-nistp256-cert-...@openssh.com ,ecdsa-sha2-nistp384,ecdsa-sha2-nistp384-cert-...@openssh.com,rsa-sha2-512, rsa-sha2-512-cert-...@openssh.com,ecdsa-sha2-nistp521, ecdsa-sha2-nistp521-cert-...@openssh.com,ssh-ed25519, ssh-ed25519-cert-...@openssh.com,ssh-rsa,ssh-rsa-cert-...@openssh.com -oCASignatureAlgorithms=rsa-sha2-256,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,rsa-sha2-512,ecdsa-sha2-nistp521,ssh-ed25519,ssh-rsa and in sshd_config HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_ecdsa_key HostKey /etc/ssh/ssh_host_ed25519_key Can I replicate the command that the engine would run on host through ssh? Gianluca ___ 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/QNZP6PA6XWFMXKYSUHBMH574ZUEE6PZH/
[ovirt-users] Re: How to make oVirt + GlusterFS bulletproof
A few things to consider, what is your RAID situation per host. If you're using mdadm based soft raid, you need to make sure your drives support power loss data protection. This is mostly only a feature on enterprise drives. Essenstially it ensures the drives reserve enough energy to flush the write cache to disk on power loss. Most modern drives have a non-trivial amount of built in write cache and losing that data on power loss will gladly corrupt files, especially on soft raid setups. If you're using hardware raid, make sure you have disabled drive based write cache, and that you have a battery / capacitor connected for the raid cards cache module. If you're using ZFS, which isn't really supported, you need a good UPS and to have it set up to shut systems down cleanly. ZFS will not take power outages well. Power loss data protection is really important too, but it's not a fixall for ZFS as it also caches writes in systems RAM quite a bit. A dedicated cache device with power loss data protection can help mitigate that, but really the power issues are a more pressing concern in this situation. As far as gluster is concerned, there is not much that can easily corrupt data on power loss. My only thought would be if your switches are not also battery backed, this would be an issue. On 2020-10-08 08:15, Jarosław Prokopowski wrote: Hi Guys, I had a situation 2 times that due to unexpected power outage something went wrong and VMs on glusterfs where not recoverable. Gluster heal did not help and I could not start the VMs any more. Is there a way to make such setup bulletproof? Does it matter which volume type I choose - raw or qcow2? Or thin provision versus reallocated? Any other advise? ___ 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/MRM6H2YENBP3AHQ5JWSFXH6UT6J6SDQS/ ___ 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/ZUMGUWDRATJERHSONGMQKHH3T457LVJC/
[ovirt-users] Re: How to make oVirt + GlusterFS bulletproof
Based on the logs you shared, it looks like a network issue - but it could always be something else. If you ever experience something like that situation, please share the logs immediately and add the gluster mailing list - in order to get assistance with the root cause. Best Regards, Strahil Nikolov В петък, 9 октомври 2020 г., 16:26:14 Гринуич+3, Jarosław Prokopowski написа: Hmm, I'm not sure. I just created glusterfs volumes on LVM volumes, changed ownership to vdsm.kvm and applied virt group. Then I added it to oVirt as storage for VMs ___ 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/DJEOW53SSPB4REFTJMZBVYQIDDXORLIT/ ___ 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/FIZN6U7XW4XXKQFZNFSQXKS3OAXLONZZ/
[ovirt-users] Re: problems installing standard Linux as nodes in 4.4
On Fri, Oct 9, 2020 at 6:47 PM Gianluca Cecchi wrote: > > > On Fri, Oct 9, 2020 at 6:29 PM Martin Perina wrote: > >> >> >> On Fri, Oct 9, 2020 at 5:54 PM Gianluca Cecchi >> wrote: >> >>> On Fri, Oct 9, 2020 at 4:58 PM Martin Perina wrote: >>> Hi Gianluca, could you please check selinux context of /var/log/ovirt-engine/ansible-runner-service.log to see if you are not affected by https://bugzilla.redhat.com/show_bug.cgi?id=1880171#c5 ? Thanks, Martin >>> >>> Thanks for answering. >>> It seems ok. On the engine: >>> [root@ovmgr1 ~]# ls -Z /var/log/ovirt-engine/ansible-runner-service.log >>> system_u:object_r:httpd_log_t:s0 >>> /var/log/ovirt-engine/ansible-runner-service.log >>> [root@ovmgr1 ~]# >>> >>> Gianluca >>> >> >> OK, so could you please apply the workaround mentioned in >> https://bugzilla.redhat.com/show_bug.cgi?id=1880171#c5 to resolve the >> issue until oVirt 4.4.3 is released? >> >> > Sorry, but isn't it already ok? The SELinux security context for the file > is already httpd_log_t, so I don't have to apply anything. > I also applied the more brutal workaround described in > https://bugzilla.redhat.com/show_bug.cgi?id=1880171#c4 without any > effect, so I'm not in this bugzilla context. > Do I have to apply also for the directory /var/log/ovirt-engine itself, > that currently has a context of var_log_t? I don't think so... > Ahh, sorry, I've misunderstood your reply, I thought you replied you are affected. Could you please share with us all logs from engine gathered by logcollector? We will try to find out any clue what's wrong in your env ... Thanks, Martin > Gianluca > > > -- 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/FM4AGM2OYTXAJCBZLGYJ7MAL7J2IKGCB/
[ovirt-users] Re: problems installing standard Linux as nodes in 4.4
On Fri, Oct 9, 2020 at 6:29 PM Martin Perina wrote: > > > On Fri, Oct 9, 2020 at 5:54 PM Gianluca Cecchi > wrote: > >> On Fri, Oct 9, 2020 at 4:58 PM Martin Perina wrote: >> >>> Hi Gianluca, >>> >>> could you please check selinux context of >>> /var/log/ovirt-engine/ansible-runner-service.log to see if you are not >>> affected by https://bugzilla.redhat.com/show_bug.cgi?id=1880171#c5 ? >>> >>> Thanks, >>> Martin >>> >> >> Thanks for answering. >> It seems ok. On the engine: >> [root@ovmgr1 ~]# ls -Z /var/log/ovirt-engine/ansible-runner-service.log >> system_u:object_r:httpd_log_t:s0 >> /var/log/ovirt-engine/ansible-runner-service.log >> [root@ovmgr1 ~]# >> >> Gianluca >> > > OK, so could you please apply the workaround mentioned in > https://bugzilla.redhat.com/show_bug.cgi?id=1880171#c5 to resolve the > issue until oVirt 4.4.3 is released? > > Sorry, but isn't it already ok? The SELinux security context for the file is already httpd_log_t, so I don't have to apply anything. I also applied the more brutal workaround described in https://bugzilla.redhat.com/show_bug.cgi?id=1880171#c4 without any effect, so I'm not in this bugzilla context. Do I have to apply also for the directory /var/log/ovirt-engine itself, that currently has a context of var_log_t? I don't think so... Gianluca ___ 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/LHS4W2QNGZYDMEXPWKUG5OCOEJDVLYJA/
[ovirt-users] Re: problems installing standard Linux as nodes in 4.4
On Fri, Oct 9, 2020 at 5:54 PM Gianluca Cecchi wrote: > On Fri, Oct 9, 2020 at 4:58 PM Martin Perina wrote: > >> Hi Gianluca, >> >> could you please check selinux context of >> /var/log/ovirt-engine/ansible-runner-service.log to see if you are not >> affected by https://bugzilla.redhat.com/show_bug.cgi?id=1880171#c5 ? >> >> Thanks, >> Martin >> > > Thanks for answering. > It seems ok. On the engine: > [root@ovmgr1 ~]# ls -Z /var/log/ovirt-engine/ansible-runner-service.log > system_u:object_r:httpd_log_t:s0 > /var/log/ovirt-engine/ansible-runner-service.log > [root@ovmgr1 ~]# > > Gianluca > OK, so could you please apply the workaround mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=1880171#c5 to resolve the issue until oVirt 4.4.3 is released? -- 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/7EKVKRO3CPQLHYI6FEC6BTAVJWNYRZZ2/
[ovirt-users] Re: problems installing standard Linux as nodes in 4.4
On Fri, Oct 9, 2020 at 4:58 PM Martin Perina wrote: > Hi Gianluca, > > could you please check selinux context of > /var/log/ovirt-engine/ansible-runner-service.log to see if you are not > affected by https://bugzilla.redhat.com/show_bug.cgi?id=1880171#c5 ? > > Thanks, > Martin > Thanks for answering. It seems ok. On the engine: [root@ovmgr1 ~]# ls -Z /var/log/ovirt-engine/ansible-runner-service.log system_u:object_r:httpd_log_t:s0 /var/log/ovirt-engine/ansible-runner-service.log [root@ovmgr1 ~]# Gianluca ___ 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/U4TWMLZFCM7UD6H6VKSEP75NXQVP5IPV/
[ovirt-users] Re: problems installing standard Linux as nodes in 4.4
Hi Gianluca, could you please check selinux context of /var/log/ovirt-engine/ansible-runner-service.log to see if you are not affected by https://bugzilla.redhat.com/show_bug.cgi?id=1880171#c5 ? Thanks, Martin On Fri, Oct 9, 2020 at 4:45 PM Gianluca Cecchi wrote: > On Thu, Oct 8, 2020 at 5:13 PM Gianluca Cecchi > wrote: > >> >> >> On Thu, Oct 8, 2020 at 5:08 PM Gianluca Cecchi >> wrote: >> >>> On Thu, Oct 8, 2020 at 4:59 PM Dana Elfassy wrote: >>> And also please attach the content of the file found at: /etc/ansible-runner-service/config.yaml On Thu, Oct 8, 2020 at 5:55 PM Dana Elfassy wrote: > Hi Gianluca, > Please execute the following command on your engine, save the output > into a file and attach it: > sudo journalctl -u ansible-runner-service > Dana > > >>> Thanks for answering, Dana. >>> >>> [root@ovmgr1 ansible-runner-service]# sudo journalctl -u >>> ansible-runner-service >>> -- Logs begin at Tue 2020-10-06 11:12:46 CEST, end at Thu 2020-10-08 >>> 17:02:25 CEST. -- >>> -- No entries -- >>> [root@ovmgr1 ansible-runner-service]# >>> >>> >>> [root@ovmgr1 ansible-runner-service]# cat >>> /etc/ansible-runner-service/config.yaml >>> >>> version: 1 >>> playbooks_root_dir: >>> '/usr/share/ovirt-engine/ansible-runner-service-project' >>> ssh_private_key: '/etc/pki/ovirt-engine/keys/engine_id_rsa' >>> port: 50001 >>> target_user: root >>> log_path: '/var/log/ovirt-engine' >>> [root@ovmgr1 ansible-runner-service]# >>> >>> I noticed that both on engine and on host the "ansible-runner" package >>> is not installed. Is it correct and only ansible-runner-service package to >>> be installed only on the engine? >>> Also, does the "service" in the name imply that I should have any >>> systemd or other kind of related service on engine? >>> Finally, I have to use a proxy for dnf/yum. >>> To be able to run "engine-setup" on engine I had to set http_proxy and >>> https_proxy eng variables inside the shell session, because it seems that >>> engine-setup was not able to leverage the global configuration. Could it be >>> something similar due to the host having to use a proxy too (that I already >>> setup in /etc/dnf/dnf.conf)? Just a guess. >>> >>> Gianluca >>> >> >> Also, the host already existed in 4.3. I upgraded the standalone engine >> from 4.3.10 to 4.4.2 following the guide. >> Now to update my hosts I put a host into maintenance, removed the host >> from the gui, reinstalled the server in CentOS 8.2 with same network >> parameters, and then add new host with the same name/hostname as before. >> Could it be a problem to reuse the host? >> >> Gianluca >> > > Any other thing to check to be able to provision a node in 4.4.2 using > plain CentOS 8.2 host? > Thanks, > Gianluca > ___ > 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/AJN3ENCAXNCTGWD4AXGCXQQEE6KOSXDN/ > -- 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/FSCB3N3KZLBV2RGWEOXAJZBMBK3A2RTY/
[ovirt-users] Re: problems installing standard Linux as nodes in 4.4
On Thu, Oct 8, 2020 at 5:13 PM Gianluca Cecchi wrote: > > > On Thu, Oct 8, 2020 at 5:08 PM Gianluca Cecchi > wrote: > >> On Thu, Oct 8, 2020 at 4:59 PM Dana Elfassy wrote: >> >>> And also please attach the content of the file found at: >>> /etc/ansible-runner-service/config.yaml >>> >>> On Thu, Oct 8, 2020 at 5:55 PM Dana Elfassy wrote: >>> Hi Gianluca, Please execute the following command on your engine, save the output into a file and attach it: sudo journalctl -u ansible-runner-service Dana >> Thanks for answering, Dana. >> >> [root@ovmgr1 ansible-runner-service]# sudo journalctl -u >> ansible-runner-service >> -- Logs begin at Tue 2020-10-06 11:12:46 CEST, end at Thu 2020-10-08 >> 17:02:25 CEST. -- >> -- No entries -- >> [root@ovmgr1 ansible-runner-service]# >> >> >> [root@ovmgr1 ansible-runner-service]# cat >> /etc/ansible-runner-service/config.yaml >> >> version: 1 >> playbooks_root_dir: >> '/usr/share/ovirt-engine/ansible-runner-service-project' >> ssh_private_key: '/etc/pki/ovirt-engine/keys/engine_id_rsa' >> port: 50001 >> target_user: root >> log_path: '/var/log/ovirt-engine' >> [root@ovmgr1 ansible-runner-service]# >> >> I noticed that both on engine and on host the "ansible-runner" package is >> not installed. Is it correct and only ansible-runner-service package to be >> installed only on the engine? >> Also, does the "service" in the name imply that I should have any systemd >> or other kind of related service on engine? >> Finally, I have to use a proxy for dnf/yum. >> To be able to run "engine-setup" on engine I had to set http_proxy and >> https_proxy eng variables inside the shell session, because it seems that >> engine-setup was not able to leverage the global configuration. Could it be >> something similar due to the host having to use a proxy too (that I already >> setup in /etc/dnf/dnf.conf)? Just a guess. >> >> Gianluca >> > > Also, the host already existed in 4.3. I upgraded the standalone engine > from 4.3.10 to 4.4.2 following the guide. > Now to update my hosts I put a host into maintenance, removed the host > from the gui, reinstalled the server in CentOS 8.2 with same network > parameters, and then add new host with the same name/hostname as before. > Could it be a problem to reuse the host? > > Gianluca > Any other thing to check to be able to provision a node in 4.4.2 using plain CentOS 8.2 host? Thanks, Gianluca ___ 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/AJN3ENCAXNCTGWD4AXGCXQQEE6KOSXDN/
[ovirt-users] Re: How to make oVirt + GlusterFS bulletproof
Hmm, I'm not sure. I just created glusterfs volumes on LVM volumes, changed ownership to vdsm.kvm and applied virt group. Then I added it to oVirt as storage for VMs ___ 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/DJEOW53SSPB4REFTJMZBVYQIDDXORLIT/
[ovirt-users] Re: How to make oVirt + GlusterFS bulletproof
Hi Strahil, I remember during after creating the volume I applied the virt group to it. Volume info: Volume Name: data Type: Replicate Volume ID: 05842cd6-7f16-4329-9ffd-64a0b4366fbe Status: Started Snapshot Count: 0 Number of Bricks: 1 x 3 = 3 Transport-type: tcp Bricks: Brick1: host1storage:/gluster_bricks/data/data Brick2: host2storage:/gluster_bricks/data/data Brick3: host3storage:/gluster_bricks/data/data Options Reconfigured: performance.client-io-threads: on nfs.disable: on transport.address-family: inet storage.owner-gid: 36 storage.owner-uid: 36 performance.quick-read: off performance.read-ahead: off performance.io-cache: off performance.low-prio-threads: 32 network.remote-dio: enable cluster.eager-lock: enable cluster.quorum-type: auto cluster.server-quorum-type: server cluster.data-self-heal-algorithm: full cluster.locking-scheme: granular cluster.shd-max-threads: 8 cluster.shd-wait-qlength: 1 features.shard: on user.cifs: off cluster.choose-local: off client.event-threads: 4 server.event-threads: 4 I do not have full logs but I have some saved. /var/log/messages: - Sep 14 08:36:20 host1 vdsm[4301]: ERROR Unhandled exception in timeout=30.0, duration=0.01 at 0x7f1244099210>#012Traceback (most recent call last):#012 File "/usr/lib/python2.7/site-packages/vdsm/executor.py", line 315, in _execute_task#012task()#012 File "/usr/lib/python2.7/site-packages/vdsm/executor.py", line 391, in __call__#012 self._callable()#012 File "/usr/lib/python2.7/site-packages/vdsm/virt/periodic.py", line 315, in __call__#012self._execute()#012 File "/usr/lib/python2.7/site-packages/vdsm/virt/periodic.py", line 357, in _execute#012self._vm.updateDriveVolume(drive)#012 File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 4189, in updateDriveVolume#012vmDrive.volumeID)#012 File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 6101, in _getVolumeSize#012(domainID, volumeID))#012StorageUnavailableError: Unable to get volume size for doma in 88f5972f-58bd-469f-bc77-5bf3b1802291 volume cdf313d7-bed3-4fae-a803-1297cdf8c82f Sep 14 08:37:20 host1 vdsm[4301]: ERROR Unhandled exception in timeout=30.0, duration=0.00 at 0x7f1244078490>#012Traceback (most recent call last):#012 File "/usr/lib/python2.7/site-packages/vdsm/executor.py", line 315, in _execute_task#012task()#012 File "/usr/lib/python2.7/site-packages/vdsm/executor.py", line 391, in __call__#012 self._callable()#012 File "/usr/lib/python2.7/site-packages/vdsm/virt/periodic.py", line 315, in __call__#012self._execute()#012 File "/usr/lib/python2.7/site-packages/vdsm/virt/periodic.py", line 357, in _execute#012self._vm.updateDriveVolume(drive)#012 File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 4189, in updateDriveVolume#012vmDrive.volumeID)#012 File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 6101, in _getVolumeSize#012(domainID, volumeID))#012StorageUnavailableError: Unable to get volume size for doma in 88f5972f-58bd-469f-bc77-5bf3b1802291 volume cdf313d7-bed3-4fae-a803-1297cdf8c82f Sep 14 08:38:20 host1 vdsm[4301]: ERROR Unhandled exception in timeout=30.0, duration=0.00 at 0x7f12045aaa90>#012Traceback (most recent call last):#012 File "/usr/lib/python2.7/site-packages/vdsm/executor.py", line 315, in _execute_task#012task()#012 File "/usr/lib/python2.7/site-packages/vdsm/executor.py", line 391, in __call__#012 self._callable()#012 File "/usr/lib/python2.7/site-packages/vdsm/virt/periodic.py", line 315, in __call__#012self._execute()#012 File "/usr/lib/python2.7/site-packages/vdsm/virt/periodic.py", line 357, in _execute#012self._vm.updateDriveVolume(drive)#012 File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 4189, in updateDriveVolume#012vmDrive.volumeID)#012 File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 6101, in _getVolumeSize#012(domainID, volumeID))#012StorageUnavailableError: Unable to get volume size for doma in 88f5972f-58bd-469f-bc77-5bf3b1802291 volume cdf313d7-bed3-4fae-a803-1297cdf8c82f Sep 14 08:39:20 host1 vdsm[4301]: ERROR Unhandled exception in timeout=30.0, duration=0.01 at 0x7f1287f189d0>#012Traceback (most recent call last):#012 File "/usr/lib/python2.7/site-packages/vdsm/executor.py", line 315, in _execute_task#012task()#012 File "/usr/lib/python2.7/site-packages/vdsm/executor.py", line 391, in __call__#012 self._callable()#012 File "/usr/lib/python2.7/site-packages/vdsm/virt/periodic.py", line 315, in __call__#012self._execute()#012 File "/usr/lib/python2.7/site-packages/vdsm/virt/periodic.py", line 357, in _execute#012self._vm.updateDriveVolume(drive)#012 File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 4189, in updateDriveVolume#012vmDrive.volumeID)#012 File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 6101, in
[ovirt-users] VM with illegal snapshots
Hi, due to a bug in our Ovirt integrated backup system now we have some VMs with snapshots in illegal state. It seems that there's an inconsistency between the db and the real status of images on disk. Let me show an example: engine=# select image_guid,parentid,imagestatus,vm_snapshot_id,volume_type,volume_format,active from images where image_group_id='e34f77cb-54d5-40d0-b539-e0a5fd512d2d'; image_guid | parentid | imagestatus |vm_snapshot_id| volume_type | volume_format | active --+--+-+--+-+---+ a107b6c4-842e-4b40-9215-c965431a0c0f | ---- | 4 | d19d6ca3-1989-4c67-8ee7-c0c43b3e6d74 | 2 | 4 | f a4c86a68-9123-454c-b417-1b15038a4bf2 | a107b6c4-842e-4b40-9215-c965431a0c0f | 1 | e7a405ee-8fd4-4733-ae9c-5252bf07c9d3 | 2 | 4 | f f6a61f2e-26bd-4b63-97c6-d66913ce48c5 | a4c86a68-9123-454c-b417-1b15038a4bf2 | 1 | 9d0958b9-4995-4e11-a027-a32d4bac52e4 | 2 | 4 | t (3 rows) [root@host02 ~]# lvs -o+lv_tags |grep e34f77cb-54d5-40d0-b539-e0a5fd512d2d a107b6c4-842e-4b40-9215-c965431a0c0f 459011cf-ebb6-46ff-831d-8ccfafd82c8a -wi--- 149.50g IU_e34f77cb-54d5-40d0-b539-e0a5fd512d2d,MD_68,PU_---- f6a61f2e-26bd-4b63-97c6-d66913ce48c5 459011cf-ebb6-46ff-831d-8ccfafd82c8a -wi--- 10.00g IU_e34f77cb-54d5-40d0-b539-e0a5fd512d2d,MD_348,PU_a107b6c4-842e-4b40-9215-c965431a0c0f so image guid a4c86a68-9123-454c-b417-1b15038a4bf2 is not present on disk, i think that the image was correctly merged but not removed from the database. Any suggestion on how to fix the database to reflect the real situation on disk?? TIA -- gb PGP Key: http://pgp.mit.edu/ Primary key fingerprint: C510 0765 943E EBED A4F2 69D3 16CC DC90 B9CB 0F34 ___ Users mailing list -- users@ovirt.org 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/OF4NTAC6BPGRP4YJZRWBXQCNBWLERL72/
[ovirt-users] Re: Disconnected -- Server has closed the connection
Running “# engine-setup” [ ERROR ] Failed to execute stage 'Closing up': Failed to start service 'ovirt-imageio' [ INFO ] Stage: Clean up Log file is located at /var/log/ovirt-engine/setup/ovirt-engine-setup-20201009105350-7q7pbo.log [ INFO ] Generating answer file '/var/lib/ovirt-engine/setup/answers/20201009105549-setup.conf' [ INFO ] Stage: Pre-termination [ INFO ] Stage: Termination [ ERROR ] Execution of setup failed Result in failure with the following error. 2020-10-09 10:46:05,604+0200 DEBUG otopi.context context.dumpEnvironment:779 ENVIRONMENT DUMP - END 2020-10-09 10:46:05,608+0200 DEBUG otopi.context context._executeMethod:127 Stage pre-terminate METHOD otopi.plugins.otopi.dialog.cli.Plugin._pre_terminate 2020-10-09 10:46:05,608+0200 DEBUG otopi.context context._executeMethod:136 otopi.plugins.otopi.dialog.cli.Plugin._pre_terminate condition False 2020-10-09 10:46:05,610+0200 INFO otopi.context context.runSequence:616 Stage: Termination 2020-10-09 10:46:05,610+0200 DEBUG otopi.context context.runSequence:620 STAGE terminate 2020-10-09 10:46:05,612+0200 DEBUG otopi.context context._executeMethod:127 Stage terminate METHOD otopi.plugins.ovirt_engine_common.base.core.misc.Plugin._terminate 2020-10-09 10:46:05,612+0200 ERROR otopi.plugins.ovirt_engine_common.base.core.misc misc._terminate:153 Execution of setup failed 2020-10-09 10:46:05,616+0200 DEBUG otopi.context context._executeMethod:127 Stage terminate METHOD otopi.plugins.otopi.dialog.human.Plugin._terminate 2020-10-09 10:46:05,627+0200 DEBUG otopi.context context._executeMethod:127 Stage terminate METHOD otopi.plugins.otopi.dialog.machine.Plugin._terminate 2020-10-09 10:46:05,627+0200 DEBUG otopi.context context._executeMethod:136 otopi.plugins.otopi.dialog.machine.Plugin._terminate condition False 2020-10-09 10:46:05,630+0200 DEBUG otopi.context context._executeMethod:127 Stage terminate METHOD otopi.plugins.otopi.core.log.Plugin._terminate Yours Sincerely, Henni From: Parth Dhanjal Sent: Friday, 09 October 2020 13:34 To: i...@worldhostess.com Cc: users Subject: Re: [ovirt-users] Disconnected -- Server has closed the connection Hey! Can you check the cockpit service from host systemctl status cockpit In case it is not started systemctl start cockpit This issue could be because of a firewall exception. You can try this - firewall-cmd --permanent --add-port=9090/tcp firewall-cmd --permanent --add-port=9090/udp systemctl restart firewalld If the problem still persists, you should check for systemctl status cups-browsed In case it is not started, try starting the service On Thu, Oct 8, 2020 at 8:56 PM mailto:i...@worldhostess.com> > wrote: A first part of the fresh install is without any problems and the second part of the fresh install the storage part “Disconnected - Server has closed the connection.” Thereafter the OVirt is unstable and disconnect continuously. “Unexpected error - Cockpit had an unexpected internal error.” “You can try restarting Cockpit by pressing refresh in your browser. The javascript console contains details about this error (Ctrl-Shift-J in most browsers).” Ctrl-Shift-J in most browsers --- RESULTS DevTools failed to load SourceMap: Could not load content for https://XYZ.co.za:9090/cockpit/$1aa0545898ca0350c292c35fee90966b96bf77ad1ca082ec115b4b7401aa8829/base1/jquery.min.js.map: HTTP error: status code 404, net::ERR_HTTP_RESPONSE_CODE_FAILURE DevTools failed to load SourceMap: Could not load content for https://XYZ.co.za:9090/cockpit/$1aa0545898ca0350c292c35fee90966b96bf77ad1ca082ec115b4b7401aa8829/base1/cockpit.min.js.map: HTTP error: status code 404, net::ERR_HTTP_RESPONSE_CODE_FAILURE DevTools failed to load SourceMap: Could not load content for https://XYZ.co.za:9090/cockpit/$1aa0545898ca0350c292c35fee90966b96bf77ad1ca082ec115b4b7401aa8829/shell/index.min.js.map: HTTP error: status code 404, net::ERR_HTTP_RESPONSE_CODE_FAILURE DevTools failed to load SourceMap: Could not load content for https://XYZ.co.za:9090/cockpit/$1aa0545898ca0350c292c35fee90966b96bf77ad1ca082ec115b4b7401aa8829/base1/jquery.min.js.map: HTTP error: status code 404, net::ERR_HTTP_RESPONSE_CODE_FAILURE DevTools failed to load SourceMap: Could not load content for https://XYZ.co.za:9090/cockpit/$1aa0545898ca0350c292c35fee90966b96bf77ad1ca082ec115b4b7401aa8829/base1/cockpit.min.js.map: HTTP error: status code 404, net::ERR_HTTP_RESPONSE_CODE_FAILURE DevTools failed to load SourceMap: Could not load content for https://XYZ.co.za:9090/cockpit/$1aa0545898ca0350c292c35fee90966b96bf77ad1ca082ec115b4b7401aa8829/base1/patternfly.min.css.map: HTTP error: status code 404, net::ERR_HTTP_RESPONSE_CODE_FAILURE index.js:15 Refused to apply inline style because it violates the following Content Security Policy directive: "default-src 'self' https://XYZ.co.za:9090;. Either the 'unsafe-inline' keyword, a hash
