- Users - oVirt List Archives

Re: Unstable VM network connectivity after upgrade 4.2.8 to 4.3.7
by Strahil 12 Jan '20

12 Jan '20

This seems quite odd. What happens when you set custom compatibility mode to 4.2 ? I think it was in Edit -> system -> Advanced options -> Custom compatibility mode -> 4.2 Best Regards, Strahil NikolovOn Jan 12, 2020 13:24, Latchezar Filtchev <Latcho(a)aubg.bg> wrote: > > Hi Strahil, > > > > Unfortunately virtio drives cannot be used. Guest OS is CentOS 5.2, kernel 2.6.18-92.1.17.el5.centos.plusPAE > > > > The network connectivity of the VM is very short (please see below). Till I connect the VM (via spice) network connectivity is already gone. > > tcpdump –I eth0 –v > > tcpdump: listening on eth0, link-type EN10MB ( Ethernet ), capture 96 bytes > > > > 0 packets captured > > 0 packets received by filer > > 0 packets dropped by kernel > > > > From 172.17.17.7 icmp_seq=60 Destination Host Unreachable > > From 172.17.17.7 icmp_seq=61 Destination Host Unreachable > > From 172.17.17.7 icmp_seq=62 Destination Host Unreachable > > From 172.17.17.7 icmp_seq=63 Destination Host Unreachable > > From 172.17.17.7 icmp_seq=64 Destination Host Unreachable > > From 172.17.17.7 icmp_seq=65 Destination Host Unreachable > > 64 bytes from 172.17.16.16: icmp_seq=66 ttl=64 time=2.19 ms > > 64 bytes from 172.17.16.16: icmp_seq=67 ttl=64 time=0.567 ms > > 64 bytes from 172.17.16.16: icmp_seq=68 ttl=64 time=0.339 ms > > 64 bytes from 172.17.16.16: icmp_seq=69 ttl=64 time=0.337 ms > > 64 bytes from 172.17.16.16: icmp_seq=70 ttl=64 time=0.288 ms > > 64 bytes from 172.17.16.16: icmp_seq=71 ttl=64 time=0.305 ms > > 64 bytes from 172.17.16.16: icmp_seq=72 ttl=64 time=0.293 ms > > 64 bytes from 172.17.16.16: icmp_seq=73 ttl=64 time=0.346 ms > > 64 bytes from 172.17.16.16: icmp_seq=74 ttl=64 time=0.359 ms > > 64 bytes from 172.17.16.16: icmp_seq=75 ttl=64 time=0.479 ms > > 64 bytes from 172.17.16.16: icmp_seq=76 ttl=64 time=0.391 ms > > 64 bytes from 172.17.16.16: icmp_seq=77 ttl=64 time=0.302 ms > > 64 bytes from 172.17.16.16: icmp_seq=78 ttl=64 time=0.327 ms > > 64 bytes from 172.17.16.16: icmp_seq=79 ttl=64 time=0.321 ms > > From 172.17.17.7 icmp_seq=125 Destination Host Unreachable > > From 172.17.17.7 icmp_seq=126 Destination Host Unreachable > > From 172.17.17.7 icmp_seq=127 Destination Host Unreachable > > From 172.17.17.7 icmp_seq=128 Destination Host Unreachable > > > > Thank you! > > Best, > > Latcho > > > > > > From: Strahil Nikolov <hunter86_bg(a)yahoo.com> > Sent: Sunday, January 12, 2020 12:52 PM > To: users <users(a)ovirt.org>; Latchezar Filtchev <Latcho(a)aubg.bg> > Subject: Re: [ovirt-users] Re: Unstable VM network connectivity after upgrade 4.2.8 to 4.3.7 > > > > Hi Lacho, > > > > Can you run the virtio drivers ? > > > > They are the most tested in KVM . > > > > Also, can you run a tcpdump (with e1000) and check what is going on when the network disapperead? > > > > Best Regards, > > Strahil Nikolov > > > > В неделя, 12 януари 2020 г., 09:22:52 ч. Гринуич+2, Latchezar Filtchev <latcho(a)aubg.bg> написа: > > > > > > Dear Strahi, > > > > I tried rtl8139. The behavior is the same. > > > > Best, > > Latcho > > > > > > From: Strahil <hunter86_bg(a)yahoo.com> > Sent: Sunday, January 12, 2020 1:19 AM > To: Latchezar Filtchev <Latcho(a)aubg.bg>; users <users(a)ovirt.org> > Subject: Re: [ovirt-users] Unstable VM network connectivity after upgrade 4.2.8 to 4.3.7 > > > > Hi Latcho, > > Most probably it's a bug. > Have you tried virtio and/or rtl-based NIC ? > > As far as I know, CentOS 5 supports Virtio after Kernel >= 2.6.25 . > > Best Regards, > Strahil Nikolov > > On Jan 11, 2020 19:54, Latchezar Filtchev <Latcho(a)aubg.bg> wrote: >> >> Hello Everyone, >> >> >> >> I am aware my guest OS is out of support but I experienced the following: >> >> >> >> oVirt – 4.2.8 (self-hosted engine) >> >> VM – CentOS 5.2; two VNIC’s ( driver used e1000) connected to different VLAN’s; - no issues with network connectivity >> >> >> >> After upgrade to oVirt 4.3.7 >> >> >> >> The same VM starts normally. Network is available for several seconds (10 – 20 pings) and then it disappears. The machine works but no ping to/from VM. When I am returning the same machine (via export domain) to oVirt 4.2.8 environment – it works as expected. >> >> >> >> Can someone advise on this? Any help will be greatly appreciated. >> >> >> >> Thank you. >> >> Best, >> >> Latcho >> >> >> >> >> >> > > _______________________________________________ > 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/DAPMFAA3XZOUJ…

2 1

Re: Unstable VM network connectivity after upgrade 4.2.8 to 4.3.7
by Strahil 12 Jan '20

12 Jan '20

Hi Latcho, Most probably it's a bug. Have you tried virtio and/or rtl-based NIC ? As far as I know, CentOS 5 supports Virtio after Kernel >= 2.6.25 . Best Regards, Strahil NikolovOn Jan 11, 2020 19:54, Latchezar Filtchev <Latcho(a)aubg.bg> wrote: > > Hello Everyone, > > > > I am aware my guest OS is out of support but I experienced the following: > > > > oVirt – 4.2.8 (self-hosted engine) > > VM – CentOS 5.2; two VNIC’s ( driver used e1000) connected to different VLAN’s; - no issues with network connectivity > > > > After upgrade to oVirt 4.3.7 > > > > The same VM starts normally. Network is available for several seconds (10 – 20 pings) and then it disappears. The machine works but no ping to/from VM. When I am returning the same machine (via export domain) to oVirt 4.2.8 environment – it works as expected. > > > > Can someone advise on this? Any help will be greatly appreciated. > > > > Thank you. > > Best, > > Latcho > > > > > >

3 3

Upload ISO to data domain - checksum mismatch on the brick
by Strahil Nikolov 12 Jan '20

12 Jan '20

Hello Community, I'm currently migrating all my ISOs from the ISO domain to the DATA domain but it seems that the checksum (on brick level) mismatches.The problem is that I have managed to upload several ISOs (one of them 4.9GB) without issues. Restarting the ovirt-imageio-proxy.service and later the HostedEngine VM doesn't help. The logs from the imageio proxy indicate no issues. I thought that the gluster could be the problem ,but this is not the case - I tested via copying (using ovirt1) between the 2 mountpoints and the sha512sum matches. Trying to upload via ovirt2 also doesn't help. Any ideas are appreciated. PS: I'm running latest oVirt. Best Regards,Strahil Nikolov

1 0

HCI Disaster Recovery
by Christian Reiss 12 Jan '20

12 Jan '20

Hey folks, - theoretical question, no live data in jeopardy - Let's say a 3-way HCI cluster is up and running, with engine running, all is well. The setup was done via gui, including gluster. Now I would kill a host, poweroff & disk wipe. Simulating a full node failure. The remaining nodes should keep running on (3 copy sync, no arbiter), vms keep running or will be restarted. I would reinstall using the ovirt node installer on the "failed" node. This would net me with a completely empty, no-gluster setup. What is the oVirt way to recover from this point onward? Thanks for your continued support! <3 -Christian. -- with kind regards, mit freundlichen Gruessen, Christian Reiss

2 2

Unstable VM network connectivity after upgrade 4.2.8 to 4.3.7
by Latchezar Filtchev 11 Jan '20

11 Jan '20

Hello Everyone, I am aware my guest OS is out of support but I experienced the following: oVirt - 4.2.8 (self-hosted engine) VM - CentOS 5.2; two VNIC's ( driver used e1000) connected to different VLAN's; - no issues with network connectivity After upgrade to oVirt 4.3.7 The same VM starts normally. Network is available for several seconds (10 - 20 pings) and then it disappears. The machine works but no ping to/from VM. When I am returning the same machine (via export domain) to oVirt 4.2.8 environment - it works as expected. Can someone advise on this? Any help will be greatly appreciated. Thank you. Best, Latcho

1 0

Hosted-engine.metadata header is corrupted
by du_hongyu＠yeah.net 11 Jan '20

11 Jan '20

Hi my Hosted-engine.metadata header is corrupted. I should how to fix it? thanks Regards Hongyu Du

1 0

Re: HCI Disaster Recovery
by Strahil 10 Jan '20

10 Jan '20

It's actually not so easy. The fastest way to recover is just restore from backup. Otherwise the flow should be: 1. Install the new node (new hostname will be easier). 2. Use gluster's replace-brick to change the dead brick with new one. 3. Once ovirt 's integration with gluster detects the change, you will be able to forcefully remove the dead node. 4. Add the newly installed node to the relevant cluster (with or without hosted-engine deployment) 5. Test to move a low-priority VM to the new host. 6. Power up a test VM on the new host to test the functionality. 7. You can make the new node SPM and test snapahots and new vm creation. As you can see , in order to remove a missing node - it should not be part of the Gluster Cluster. Best Regards, Strahil NikolovOn Jan 10, 2020 20:10, Christian Reiss wrote: > > Hey, > > is there really no ovirt native way to restore a single host and bring > it back into the cluster? > > -Chris. > > On 07.01.2020 09:54, Christian Reiss wrote: > > Hey folks, > > > > - theoretical question, no live data in jeopardy - > > > > Let's say a 3-way HCI cluster is up and running, with engine running, > > all is well. The setup was done via gui, including gluster. > > > > Now I would kill a host, poweroff & disk wipe. Simulating a full node > > failure. > > > > The remaining nodes should keep running on (3 copy sync, no arbiter), > > vms keep running or will be restarted. I would reinstall using the ovirt > > node installer on the "failed" node. > > > > This would net me with a completely empty, no-gluster setup. What is the > > oVirt way to recover from this point onward? > > > > Thanks for your continued support! <3 > > -Christian. > > > > -- > Christian Reiss - email(a)christian-reiss.de /"\ ASCII Ribbon > christian(a)reiss.nrw \ / Campaign > X against HTML > XMPP chris(a)alpha-labs.net / \ in eMails > WEB christian-reiss.de, reiss.nrw > > GPG Retrieval http://gpg.christian-reiss.de > GPG ID ABCD43C5, 0x44E29126ABCD43C5 > GPG fingerprint = 9549 F537 2596 86BA 733C A4ED 44E2 9126 ABCD 43C5 > > "It's better to reign in hell than to serve in heaven.", > John Milton, Paradise lost. > _______________________________________________ > 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/GQECSH72L4SMO…

1 0

Hyperconverged setup - storage architecture - scaling
by Leo David 10 Jan '20

10 Jan '20

Hello Everyone, Reading through the document: "Red Hat Hyperconverged Infrastructure for Virtualization 1.5 Automating RHHI for Virtualization deployment" Regarding storage scaling, i see the following statements: *2.7. SCALINGRed Hat Hyperconverged Infrastructure for Virtualization is supported for one node, and for clusters of 3, 6, 9, and 12 nodes.The initial deployment is either 1 or 3 nodes.There are two supported methods of horizontally scaling Red Hat Hyperconverged Infrastructure for Virtualization:* *1 Add new hyperconverged nodes to the cluster, in sets of three, up to the maximum of 12 hyperconverged nodes.* *2 Create new Gluster volumes using new disks on existing hyperconverged nodes.You cannot create a volume that spans more than 3 nodes, or expand an existing volume so that it spans across more than 3 nodes at a time* *2.9.1. Prerequisites for geo-replicationBe aware of the following requirements and limitations when configuring geo-replication:One geo-replicated volume onlyRed Hat Hyperconverged Infrastructure for Virtualization (RHHI for Virtualization) supports only one geo-replicated volume. Red Hat recommends backing up the volume that stores the data of your virtual machines, as this is usually contains the most valuable data.* ------ Also in oVirtEngine UI, when I add a brick to an existing volume i get the following warning: *"Expanding gluster volume in a hyper-converged setup is not recommended as it could lead to degraded performance. To expand storage for cluster, it is advised to add additional gluster volumes." * Those things are raising a couple of questions that maybe for some for you guys are easy to answer, but for me it creates a bit of confusion... I am also referring to RedHat product documentation, because I treat oVirt as production-ready as RHHI is. *1*. Is there any reason for not going to distributed-replicated volumes ( ie: spread one volume across 6,9, or 12 nodes ) ? - ie: is recomanded that in a 9 nodes scenario I should have 3 separated volumes, but how should I deal with the folowing question *2.* If only one geo-replicated volume can be configured, how should I deal with 2nd and 3rd volume replication for disaster recovery *3.* If the limit of hosts per datacenter is 250, then (in theory ) the recomended way in reaching this treshold would be to create 20 separated oVirt logical clusters with 12 nodes per each ( and datacenter managed from one ha-engine ) ? *4.* In present, I have the folowing one 9 nodes cluster , all hosts contributing with 2 disks each to a single replica 3 distributed replicated volume. They where added to the volume in the following order: node1 - disk1 node2 - disk1 ...... node9 - disk1 node1 - disk2 node2 - disk2 ...... node9 - disk2 At the moment, the volume is arbitrated, but I intend to go for full distributed replica 3. Is this a bad setup ? Why ? It oviously brakes the redhat recommended rules... Is there anyone so kind to discuss on these things ? Thank you very much ! Leo -- Best regards, Leo David -- Best regards, Leo David

3 5

Re: Ovirt OVN help needed
by Strahil 10 Jan '20

10 Jan '20

Hi Dominik, Thanks for your reply. On ovirt1 I got the following: [root@ovirt1 openvswitch]# less ovn-controller.log-20191216.gz 2019-12-15T01:49:02.988Z|00032|vlog|INFO|opened log file /var/log/openvswitch/ovn-controller.log 2019-12-16T01:18:02.114Z|00033|vlog|INFO|closing log file ovn-controller.log-20191216.gz (END) Same is on the other node: [root@ovirt2 openvswitch]# less ovn-controller.log-20191216.gz 2019-12-15T01:26:03.477Z|00028|vlog|INFO|opened log file /var/log/openvswitch/ovn-controller.log 2019-12-16T01:30:01.718Z|00029|vlog|INFO|closing log file ovn-controller.log-20191216.gz (END) The strange thing is that the geneve tunnels are there: [root@ovirt1 ~]# ovs-vsctl show c0e938f1-b5b5-4d5a-9cda-29dae2986f29 Bridge br-int fail_mode: secure Port "ovn-25cc77-0" Interface "ovn-25cc77-0" type: geneve options: {csum="true", key=flow, remote_ip="192.168.1.64"} Port "ovn-566849-0" Interface "ovn-566849-0" type: geneve options: {csum="true", key=flow, remote_ip="192.168.1.41"} Port br-int Interface br-int type: internal Port "vnet2" Interface "vnet2" ovs_version: "2.11.0" [root@ovirt1 ~]# ovs-vsctl list ports ovs-vsctl: unknown table "ports" [root@ovirt1 ~]# ovs-vsctl list port _uuid : fbf40569-925e-4430-a7c5-c78d58979bbc bond_active_slave : [] bond_downdelay : 0 bond_fake_iface : false bond_mode : [] bond_updelay : 0 cvlans : [] external_ids : {} fake_bridge : false interfaces : [3207c0cb-3000-40f2-a850-83548f76f090]lacp : [] mac : [] name : "vnet2" other_config : {} protected : false qos : [] rstp_statistics : {} rstp_status : {} statistics : {} status : {} tag : [] trunks : [] vlan_mode : [] _uuid : 8947f82d-a089-429b-8843-71371314cb52 bond_active_slave : [] bond_downdelay : 0 bond_fake_iface : false bond_mode : [] bond_updelay : 0 cvlans : [] external_ids : {} fake_bridge : false interfaces : [ec6a6688-e5d6-4346-ac47-ece1b8379440]lacp : [] mac : [] name : br-int other_config : {} protected : false qos : [] rstp_statistics : {} rstp_status : {} statistics : {} status : {} tag : [] trunks : [] vlan_mode : [] _uuid : 72d612be-853e-43e9-8f5c-ce66cef0bebe bond_active_slave : [] bond_downdelay : 0 bond_fake_iface : false bond_mode : [] bond_updelay : 0 cvlans : [] external_ids : {ovn-chassis-id="5668499c-7dd0-41ee-bc5d-2e6ee9cd61c3(a)192.168.1.41"} fake_bridge : false interfaces : [a31574fe-515b-420b-859d-7f2ac729638f]lacp : [] mac : [] name : "ovn-566849-0" other_config : {} protected : false qos : [] rstp_statistics : {} rstp_status : {} statistics : {} status : {} tag : [] trunks : [] vlan_mode : [] _uuid : 2043a15f-ec39-4cc3-b875-7be00423dd7a bond_active_slave : [] bond_downdelay : 0 bond_fake_iface : false bond_mode : [] bond_updelay : 0 cvlans : [] external_ids : {ovn-chassis-id="25cc77b3-046f-45c5-af0c-ffb2f77d73f1(a)192.168.1.64"} fake_bridge : false interfaces : [f9a9e3ff-070e-4044-b601-7f7394dc295f]lacp : [] mac : [] name : "ovn-25cc77-0" other_config : {} protected : false qos : [] rstp_statistics : {} rstp_status : {} statistics : {} status : {} tag : [] trunks : [] vlan_mode : [] [root@ovirt1 ~]# [root@ovirt2 ~]# ovs-vsctl show 3dbab138-6b90-44c5-af05-b8a944c9bf20 Bridge br-int fail_mode: secure Port "ovn-baa019-0" Interface "ovn-baa019-0" type: geneve options: {csum="true", key=flow, remote_ip="192.168.1.90"} Port br-int Interface br-int type: internal Port "vnet5" Interface "vnet5" Port "ovn-566849-0" Interface "ovn-566849-0" type: geneve options: {csum="true", key=flow, remote_ip="192.168.1.41"} ovs_version: "2.11.0" [root@ovirt2 ~]# ovs-vsctl list port _uuid : 151e1188-f07a-4750-a620-392a08e7e7fe bond_active_slave : [] bond_downdelay : 0 bond_fake_iface : false bond_mode : [] bond_updelay : 0 cvlans : [] external_ids : {ovn-chassis-id="baa0199e-d1a4-484c-af13-a41bcad19dbc(a)192.168.1.90"} fake_bridge : false interfaces : [4d4bc12a-609a-4917-b839-d4f652acdc33]lacp : [] mac : [] name : "ovn-baa019-0" other_config : {} protected : false qos : [] rstp_statistics : {} rstp_status : {} statistics : {} status : {} tag : [] trunks : [] vlan_mode : [] _uuid : 3a862f96-b3ec-46a9-bcf6-f385e5def410 bond_active_slave : [] bond_downdelay : 0 bond_fake_iface : false bond_mode : [] bond_updelay : 0 cvlans : [] external_ids : {} fake_bridge : false interfaces : [777f2819-ca27-4890-8d2f-11349ca0d398]lacp : [] mac : [] name : br-int other_config : {} protected : false qos : [] rstp_statistics : {} rstp_status : {} statistics : {} status : {} tag : [] trunks : [] vlan_mode : [] _uuid : a65109fa-f8b4-4670-8ae8-a2bd0bf6aba3 bond_active_slave : [] bond_downdelay : 0 bond_fake_iface : false bond_mode : [] bond_updelay : 0 cvlans : [] external_ids : {ovn-chassis-id="5668499c-7dd0-41ee-bc5d-2e6ee9cd61c3(a)192.168.1.41"} fake_bridge : false interfaces : [ed442077-f897-4e0b-97a1-a8051e9c3d56]lacp : [] mac : [] name : "ovn-566849-0" other_config : {} protected : false qos : [] rstp_statistics : {} rstp_status : {} statistics : {} status : {} tag : [] trunks : [] vlan_mode : [] _uuid : a1622e6f-fcd0-4a8a-b259-ca4d0ccf1cd2 bond_active_slave : [] bond_downdelay : 0 bond_fake_iface : false bond_mode : [] bond_updelay : 0 cvlans : [] external_ids : {} fake_bridge : false interfaces : [ca368654-54f3-49d0-a71c-8894426df6bf]lacp : [] mac : [] name : "vnet5" other_config : {} protected : false qos : [] rstp_statistics : {} rstp_status : {} statistics : {} status : {} tag : [] trunks : [] vlan_mode : [] [root@ovirt2 ~]# Best Regards, Strahil Nikolov On Dec 16, 2019 23:28, Dominik Holler <dholler(a)redhat.com> wrote: > > > > On Sat, Dec 14, 2019 at 11:36 AM Strahil Nikolov <hunter86_bg(a)yahoo.com> wrote: >> >> Hi Dominik, >> >> yes I was looking for those settings. >> >> I have added again the external provider , but I guess the mess is even bigger as I made some stupid decisions (like removing 2 port groups :) without knowing what I'm doing) . >> Sadly I can't remove all packages on the engine and hosts and reinstall them from scratch. >> >> Pip fails to install the openstacksdk (centOS7 is not great for such tasks) on the engine and my lack of knowledge in OVN makes it even more difficult. >> >> So the symptoms are that 2 machines can communicate with each other only if they are on the same host ,while on separate - no communications is happening. >> > > This indicates that the tunnels between the hosts are not created. > Can you please check the /var/log/openvswitch/ovn-controller.log on both hosts for errors and warnings, or share parts of the files here? > If this does not point us to a problem, ovn has to be reconfigured. If possible, most easy way to do this would be to ensure that > ovirt-provider-ovn is the default network provider of the cluster of the hosts, put one host after another in maintance mode and reinstall. > > >> >> How I created the network via UI: >> >> 1. Networks - new >> 2. Fill in the name >> 3. Create on external provider >> 4. Network Port security -> disabled (even undefined does not work) >> 5.Connect to physical network -> ovirtmgmt >> >> >> I would be happy to learn more about OVN and thus I would like to make it work. >> >> Here is some info from the engine: >> >> [root@engine ~]# ovn-nbctl show >> switch 1288ed26-471c-4bc2-8a7d-4531f306f44c (ovirt-pxelan-2a88b2e0-d04b-4196-ad50-074501e4ed08) >> port c1eba112-5eed-4c04-b25c-d3dcfb934546 >> addresses: ["56:6f:5a:65:00:06"] >> port 8b52ab60-f474-4d51-b258-cb2e0a53c34a >> type: localnet >> addresses: ["unknown"] >> port b2753040-881b-487a-92a1-9721da749be4 >> addresses: ["56:6f:5a:65:00:09"] >> [root@engine ~]# ovn-sbctl show >> Chassis "5668499c-7dd0-41ee-bc5d-2e6ee9cd61c3" >> hostname: "ovirt3.localdomain" >> Encap geneve >> ip: "192.168.1.41" >> options: {csum="true"} >> Chassis "baa0199e-d1a4-484c-af13-a41bcad19dbc" >> hostname: "ovirt1.localdomain" >> Encap geneve >> ip: "192.168.1.90" >> options: {csum="true"} >> Chassis "25cc77b3-046f-45c5-af0c-ffb2f77d73f1" >> hostname: "ovirt2.localdomain" >> Encap geneve >> ip: "192.168.1.64" >> options: {csum="true"} >> Port_Binding "b2753040-881b-487a-92a1-9721da749be4" >> Port_Binding &quo

4 8

is there any feature of load balancing for engine??
by yam yam 10 Jan '20

10 Jan '20

Hello, given massive oVirt environment, I think single engine looks too small to deal with all workloads. so, I want to make active-active engine cluster for distributing workloads. is it possible for an oVirt environment to be made up of multiple engines & DBs for load balancing?

3 4