- Users - oVirt List Archives

Re: ovirt 4.3.7 geo-replication not working
by Strahil 12 Dec '19

12 Dec '19

Hi Adrian, Have you checked the passwordless rsync between master and slave volume nodes ? Best Regards, Strahil NikolovOn Dec 11, 2019 22:36, adrianquintero(a)gmail.com wrote: > > Hi, > I am trying to setup geo-replication between 2 sites, but I keep getting: > [root@host1 ~]# gluster vol geo-rep geo-master slave1.mydomain2.com::geo-slave status > > MASTER NODE MASTER VOL MASTER BRICK SLAVE USER SLAVE SLAVE NODE STATUS CRAWL STATUS LAST_SYNCED > -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > host1.mydomain1.com geo-master /gluster_bricks/geo-master/geo-master root slave1.mydomain2.com::geo-slave N/A Faulty N/A N/A > host2.mydomain2.com geo-master /gluster_bricks/geo-master/geo-master root slave1.mydomain2.com::geo-slave N/A Faulty N/A N/A > vmm11.virt.iad3p geo-master /gluster_bricks/geo-master/geo-master root slave1.mydomain2.com::geo-slave N/A Faulty N/A N/A > > > oVirt GUI has an icon in the volume that says "volume data is being geo-replicated" but we know that is not the case > From the logs i can see: > [2019-12-11 19:57:48.441557] I [fuse-bridge.c:6810:fini] 0-fuse: Unmounting '/tmp/gsyncd-aux-mount-5WaCmt'. > [2019-12-11 19:57:48.441578] I [fuse-bridge.c:6815:fini] 0-fuse: Closing fuse connection to '/tmp/gsyncd-aux-mount-5WaCmt' > > and > [2019-12-11 19:45:14.785758] I [monitor(monitor):278:monitor] Monitor: worker died in startup phase brick=/gluster_bricks/geo-master/geo-master > > thoughts? > > thanks, > > Adrian > _______________________________________________ > Users mailing list -- users(a)ovirt.org > To unsubscribe send an email to users-leave(a)ovirt.org > Privacy Statement: https://www.ovirt.org/site/privacy-policy/ > oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ > List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/TPTAODQ3Q4ZDK…

5 5

Mixing compute and storage without (initial) HCI
by thomas＠hoberg.net 12 Dec '19

12 Dec '19

Some documentation, especially on older RHEV versions seems to indicate that Gluster storage roles and compute server roles in an oVirt cluster or actually exclusive. Yet HCI is all about doing both, which is slightly confusing when you try to overcome HCI issues simply by running the management engine in a "side car", in my case simply a KVM VM running on a host that's not part of the HCI (attempted) cluster. So the HCI wizard failed to deploy the management VM, but left me with a working Gluster. I then went ahead and used a fresh CentOS 7.7 VM to install the hosted engine the the script variant without an appliance. That went ... not too bad initially, it even found the Gluster bricks eventually, installed the three hosts, looked almost ready to go, but something must be wrong with the "ovirtmgmt" network. It looks alright in the network configuration, where it has all roles, but when I try to create a VM, I cannot select it as the standard network for the VM. Any new network I might try to define, won't work either. So apart from these detail problems: Is the prohibition against mising both roles, gluster and (compute) cluster still in place? Because there are also documentation remnants which seem to indicate that a management engine for an existing cluster can actually be converted into a VM managed by the hosted engine e.g. as part of a recovery, repeating later what the HCI setup attempts to automate.

2 1

Gluster mount still fails on Engine deployment - any suggestions...
by rob.downer＠orbitalsystems.co.uk 12 Dec '19

12 Dec '19

Hi Engine deployment fails here... [ INFO ] TASK [ovirt.hosted_engine_setup : Add glusterfs storage domain] [ ERROR ] Error: Fault reason is "Operation Failed". Fault detail is "[Unexpected exception]". HTTP response code is 400. [ ERROR ] fatal: [localhost]: FAILED! => {"changed": false, "msg": "Fault reason is \"Operation Failed\". Fault detail is \"[Unexpected exception]\". HTTP response code is 400."} However Gluster looks good... I have reinstalled all nodes from scratch. root@ovirt3 ~]# gluster volume status Status of volume: data Gluster process TCP Port RDMA Port Online Pid ------------------------------------------------------------------------------ Brick gfs3.gluster.private:/gluster_bricks/ data/data 49152 0 Y 3756 Brick gfs2.gluster.private:/gluster_bricks/ data/data 49153 0 Y 3181 Brick gfs1.gluster.private:/gluster_bricks/ data/data 49152 0 Y 15548 Self-heal Daemon on localhost N/A N/A Y 17602 Self-heal Daemon on gfs1.gluster.private N/A N/A Y 15706 Self-heal Daemon on gfs2.gluster.private N/A N/A Y 3348 Task Status of Volume data ------------------------------------------------------------------------------ There are no active volume tasks Status of volume: engine Gluster process TCP Port RDMA Port Online Pid ------------------------------------------------------------------------------ Brick gfs3.gluster.private:/gluster_bricks/ engine/engine 49153 0 Y 3769 Brick gfs2.gluster.private:/gluster_bricks/ engine/engine 49154 0 Y 3194 Brick gfs1.gluster.private:/gluster_bricks/ engine/engine 49153 0 Y 15559 Self-heal Daemon on localhost N/A N/A Y 17602 Self-heal Daemon on gfs1.gluster.private N/A N/A Y 15706 Self-heal Daemon on gfs2.gluster.private N/A N/A Y 3348 Task Status of Volume engine ------------------------------------------------------------------------------ There are no active volume tasks Status of volume: vmstore Gluster process TCP Port RDMA Port Online Pid ------------------------------------------------------------------------------ Brick gfs3.gluster.private:/gluster_bricks/ vmstore/vmstore 49154 0 Y 3786 Brick gfs2.gluster.private:/gluster_bricks/ vmstore/vmstore 49152 0 Y 2901 Brick gfs1.gluster.private:/gluster_bricks/ vmstore/vmstore 49154 0 Y 15568 Self-heal Daemon on localhost N/A N/A Y 17602 Self-heal Daemon on gfs1.gluster.private N/A N/A Y 15706 Self-heal Daemon on gfs2.gluster.private N/A N/A Y 3348 Task Status of Volume vmstore ------------------------------------------------------------------------------ There are no active volume tasks

2 1

Re: OVN communications between hosts
by Strahil 12 Dec '19

12 Dec '19

Hi Pavel, Would you mind to share the list of ovn devices you have. Currently in UI, I don't have any network (except ovirtmgmt) and I see multiplee devices. My guess is that I should remove all but the br-int , but I would like not to kill my cluster communication :) Best Regards, Strahil NikolovOn Dec 11, 2019 10:25, Pavel Nakonechnyi <pavel(a)gremwell.com> wrote: > > Hi Strahil, > > On Tuesday, 10 December 2019 20:50:27 CET Strahil wrote: > > Hi Pavel, > > > > Can you explain how did you find the issue. > > > > I'm new in OVN and I experience the same symptoms . > > > > I'm not sure what will be the best approach to start cleanly with OVN. > > > > I am new to OVN / OpenVSwitch too. :) > > What helped me to begin with is capturing traffic on "ovirtmgmnt" interface using tcpdump and looking into it for packets related to data exchange between VMs over virtual network. I found communications over UDP:6081, which were fine by themselves. However, this helped to craft more targeted search requests which lead me to this discussion: https://lists.ovirt.org/archives/list/users@ovirt.org/thread/PVJJPK7MQOFLXJ… > > Some suggestions there were helpful to at least become slightly more familiar with how the things work. > > Anyway, lack of documentation on this matter (I know that there are high-level old docs) does not help to resolve such cases. > > >

2 1

Ovirt OVN help needed
by Strahil Nikolov 12 Dec '19

12 Dec '19

Hi Community, can someone hint me how to get rid of some ports? I just want to 'reset' my ovn setup. Here is what I have so far: [root@ovirt1 openvswitch]# ovs-vsctl list interface _uuid : be89c214-10e4-4a97-a9eb-1b82bc433a24 admin_state : up bfd : {} bfd_status : {} cfm_fault : [] cfm_fault_status : [] cfm_flap_count : [] cfm_health : [] cfm_mpid : [] cfm_remote_mpids : [] cfm_remote_opstate : [] duplex : [] error : [] external_ids : {} ifindex : 35 ingress_policing_burst: 0 ingress_policing_rate: 0 lacp_current : [] link_resets : 0 link_speed : [] link_state : up lldp : {} mac : [] mac_in_use : "7a:7d:1d:a7:43:1d" mtu : [] mtu_request : [] name : "ovn-25cc77-0" ofport : 6 ofport_request : [] options : {csum="true", key=flow, remote_ip="192.168.1.64"} other_config : {} statistics : {rx_bytes=0, rx_packets=0, tx_bytes=0, tx_packets=0} status : {tunnel_egress_iface=ovirtmgmt, tunnel_egress_iface_carrier=up} type : geneve _uuid : ec6a6688-e5d6-4346-ac47-ece1b8379440 admin_state : down bfd : {} bfd_status : {} cfm_fault : [] cfm_fault_status : [] cfm_flap_count : [] cfm_health : [] cfm_mpid : [] cfm_remote_mpids : [] cfm_remote_opstate : [] duplex : [] error : [] external_ids : {} ifindex : 13 ingress_policing_burst: 0 ingress_policing_rate: 0 lacp_current : [] link_resets : 0 link_speed : [] link_state : down lldp : {} mac : [] mac_in_use : "66:36:dd:63:dc:48" mtu : 1500 mtu_request : [] name : br-int ofport : 65534 ofport_request : [] options : {} other_config : {} statistics : {collisions=0, rx_bytes=0, rx_crc_err=0, rx_dropped=0, rx_errors=0, rx_frame_err=0, rx_over_err=0, rx_packets=0, tx_bytes=0, tx_dropped=0, tx_errors=0, tx_packets=0} status : {driver_name=openvswitch} type : internal _uuid : 1e511b4d-f7c2-499f-bd8c-07236e7bb7af admin_state : up bfd : {} bfd_status : {} cfm_fault : [] cfm_fault_status : [] cfm_flap_count : [] cfm_health : [] cfm_mpid : [] cfm_remote_mpids : [] cfm_remote_opstate : [] duplex : [] error : [] external_ids : {} ifindex : 35 ingress_policing_burst: 0 ingress_policing_rate: 0 lacp_current : [] link_resets : 0 link_speed : [] link_state : up lldp : {} mac : [] mac_in_use : "1a:85:d1:d9:e2:a5" mtu : [] mtu_request : [] name : "ovn-566849-0" ofport : 5 ofport_request : [] options : {csum="true", key=flow, remote_ip="192.168.1.41"} other_config : {} statistics : {rx_bytes=0, rx_packets=0, tx_bytes=0, tx_packets=0} status : {tunnel_egress_iface=ovirtmgmt, tunnel_egress_iface_carrier=up} type : geneve When I try to remove a port - it never ends (just hanging): [root@ovirt1 openvswitch]# ovs-vsctl --dry-run del-port br-int ovn-25cc77-0 In journal I see only this:дек 12 04:13:57 ovirt1.localdomain ovs-vsctl[22030]: ovs|00001|vsctl|INFO|Called as ovs-vsctl --dry-run del-port br-int ovn-25cc77-0 The stranger part to me is the log output: [root@ovirt1 openvswitch]# grep ovn-25cc77-0 /var/log/openvswitch/*.log /var/log/openvswitch/ovs-vswitchd.log:2019-12-12T01:26:28.642Z|00032|bridge|INFO|bridge br-int: added interface ovn-25cc77-0 on port 14 /var/log/openvswitch/ovs-vswitchd.log:2019-12-12T01:45:15.646Z|00113|bridge|INFO|bridge br-int: deleted interface ovn-25cc77-0 on port 14 /var/log/openvswitch/ovs-vswitchd.log:2019-12-12T01:45:15.861Z|00116|bridge|INFO|bridge br-int: added interface ovn-25cc77-0 on port 2 /var/log/openvswitch/ovs-vswitchd.log:2019-12-12T01:50:36.678Z|00118|bridge|INFO|bridge br-int: deleted interface ovn-25cc77-0 on port 2 /var/log/openvswitch/ovs-vswitchd.log:2019-12-12T01:52:31.180Z|00121|bridge|INFO|bridge br-int: added interface ovn-25cc77-0 on port 3 /var/log/openvswitch/ovs-vswitchd.log:2019-12-12T01:55:09.734Z|00125|bridge|INFO|bridge br-int: deleted interface ovn-25cc77-0 on port 3 /var/log/openvswitch/ovs-vswitchd.log:2019-12-12T01:58:15.138Z|00127|bridge|INFO|bridge br-int: added interface ovn-25cc77-0 on port 6 I'm also attaching the verbose output of the dryrun. Thanks in advance. Best Regards,Strahil Nikolov

2 1

ovirt 4.3.7 geo-replication not working
by adrianquintero＠gmail.com 11 Dec '19

11 Dec '19

Hi, I am trying to setup geo-replication between 2 sites, but I keep getting: [root@host1 ~]# gluster vol geo-rep geo-master slave1.mydomain2.com::geo-slave status MASTER NODE MASTER VOL MASTER BRICK SLAVE USER SLAVE SLAVE NODE STATUS CRAWL STATUS LAST_SYNCED -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- host1.mydomain1.com geo-master /gluster_bricks/geo-master/geo-master root slave1.mydomain2.com::geo-slave N/A Faulty N/A N/A host2.mydomain2.com geo-master /gluster_bricks/geo-master/geo-master root slave1.mydomain2.com::geo-slave N/A Faulty N/A N/A vmm11.virt.iad3p geo-master /gluster_bricks/geo-master/geo-master root slave1.mydomain2.com::geo-slave N/A Faulty N/A N/A oVirt GUI has an icon in the volume that says "volume data is being geo-replicated" but we know that is not the case From the logs i can see: [2019-12-11 19:57:48.441557] I [fuse-bridge.c:6810:fini] 0-fuse: Unmounting '/tmp/gsyncd-aux-mount-5WaCmt'. [2019-12-11 19:57:48.441578] I [fuse-bridge.c:6815:fini] 0-fuse: Closing fuse connection to '/tmp/gsyncd-aux-mount-5WaCmt' and [2019-12-11 19:45:14.785758] I [monitor(monitor):278:monitor] Monitor: worker died in startup phase brick=/gluster_bricks/geo-master/geo-master thoughts? thanks, Adrian

1 0

Re: 3node HCI fails when HostedEngineLocal is trying to add additional Gluster members
by Strahil 11 Dec '19

11 Dec '19

Most probably the vdsm or supervdsm's PreExec task is doing it (they got multiple, so you can run manually till you find it out). Just try the following: systemctl stop vdsmd supervdsmd systemctl start supervdsmd Check for certs systemctl start vdsmd Keep in mind that that the chain of events (at least for me is): 1. VG activation 2. VDO activation 3. Gluster brick is mounted (I use systemd service due to deps between vdo, gluster brick and glusterd) 4. Glusterd and libvirt are started 5. Sanlock is started 6. Supervdsm 7. Vdsm If this is a host that will host HostedEngine VM: 8. Ovirt-ha-broker 9. Ovirt-ha-agent After cleanup, did you reboot? Best Regards, Strahil NikolovOn Dec 4, 2019 17:14, thomas(a)hoberg.net wrote: > > After spending another couple of hours trying to track down the problem, I have found that the "lost connection" seems due to KVM shutting down, because it cannot find the certificates for the Spice and VNC connections in /etc/pki/vdsm/*, where 'ovirt-hosted-engine-cleanup' deleted them. > > So now I wonder: Who is supposed to (re-)generated them afterwards? > > Assuming that it was a much earlier step I proceeded to completely undo the deployment, get rid of the Gluster setup etc. and start from the very beginning, only to find that that didn't change a thing: It still missed those certificates.... > > ...while something or someone *did* generated them when I tried a distinct and new set of nodes for counter-testing.. > > That setup failed with an Ansible error (reported separately), but I have now grown afraid of using 'ovirt-hosted-engine-cleanup' when I don't know how to get the ciphers/keys for /etc/pki/vsdm/{spice|vnc} regenerated... > > Can anyone shed some light into this darkness? > _______________________________________________ > Users mailing list -- users(a)ovirt.org > To unsubscribe send an email to users-leave(a)ovirt.org > Privacy Statement: https://www.ovirt.org/site/privacy-policy/ > oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ > List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/Z7AFFFU6KMDPS…

2 1

CPU Type compatibility matrix
by Gianluca Cecchi 11 Dec '19

11 Dec '19

Hello, In my case I currently have a cluster with hosts with cpu Intel E5-2680 v4 (each socket with 14 cores) and their Cluster is set as "Intel Broadwell Family" and I would like to add in the same oVirt Cluster two more hosts with Intel E5-2640 v4 cpus (each socket 10 cores) that should be the same CPU Family Type. Is it true? Is there a sort of matrix where one could compare and match? Thanks in advance, Gianluca

4 3

Gluster set up fails - Nearly there I think...
by rob.downer＠orbitalsystems.co.uk 11 Dec '19

11 Dec '19

Gluster fails with vdo: ERROR - Device /dev/sdb excluded by a filter.\n", however I have run [root@ovirt1 ~]# vdo create --name=vdo1 --device=/dev/sdb --force Creating VDO vdo1 Starting VDO vdo1 Starting compression on VDO vdo1 VDO instance 1 volume is ready at /dev/mapper/vdo1 [root@ovirt1 ~]# there are no filters in lvm.conf I have run wipefs -a /dev/sdb —force on all hosts before start

5 9

[ovirt-announce] [ANN] oVirt 4.3.8 Second Release Candidate is now available for testing
by Lev Veyde 11 Dec '19

11 Dec '19

The oVirt Project is pleased to announce the availability of the oVirt 4.3.8 Second Release Candidate for testing, as of December 11th, 2019. This update is a release candidate of the eighth in a series of stabilization updates to the 4.3 series. This is pre-release software. This pre-release should not to be used in production. This release is available now on x86_64 architecture for: * Red Hat Enterprise Linux 7.7 or later (but <8) * CentOS Linux (or similar) 7.7 or later (but <8) This release supports Hypervisor Hosts on x86_64 and ppc64le architectures for: * Red Hat Enterprise Linux 7.7 or later (but <8) * CentOS Linux (or similar) 7.7 or later (but <8) * oVirt Node 4.3 (available for x86_64 only) has been built consuming CentOS 7.7 Release See the release notes [1] for known issues, new features and bugs fixed. Notes: - oVirt Appliance is already available - oVirt Node is already available Additional Resources: * Read more about the oVirt 4.3.8 release highlights: http://www.ovirt.org/release/4.3.8/ * Get more oVirt Project updates on Twitter: https://twitter.com/ovirt * Check out the latest project news on the oVirt blog: http://www.ovirt.org/blog/ [1] http://www.ovirt.org/release/4.3.8/ [2] http://resources.ovirt.org/pub/ovirt-4.3-pre/iso/ -- Lev Veyde Senior Software Engineer, RHCE | RHCVA | MCITP Red Hat Israel <https://www.redhat.com> lev(a)redhat.com | lveyde(a)redhat.com <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>

1 0