May 2021 - Users - oVirt List Archives

Moving interfaces for switch maintenance
by David White 12 May '21

12 May '21

So I have two switches. All 3 of my HCI oVirt servers are connected to both switches. 1 switch serves the ovirtmgmt network (internal, gluster communication and everything else on that subnet) The other switch serves the "main" front-end network (Private). It turns out that my datacenter plugged the switches into the wrong power supplies, and now needs to move them. My switches have single PSUs, so when we move them, the network will go down. Obviously, I'm just going to move 1 switch at a time. What I'm wondering, though, is there's an "easy" way to force all the traffic for both networks out one of the single interfaces, so that I don't experience any more downtime during this switch maintenance. Should I assign another temporary IP address on each of the interfaces for each server that is in the same subnet as the switch we're going to take down? Sent with ProtonMail Secure Email.

1 0

Issue upgrading from 4.3 (Centos 7) to 4.4 (Centos 8)
by ling＠aliko.com 12 May '21

12 May '21

Hello, I have been trying to upgrade my self-hosted engine from 4.3 to 4.4 but running into issue while performing hosted-engine deploy. Old hypervisor hosts are all running Centos 8 and old ovirt-engine is also running Centos 7. I created a brand new baremental node running Centos 8, Kernel 4.18.0-240.15.1.el8_3.x86_64 and the following engine versions: ovirt-hosted-engine-setup-2.4.9-1.el8.noarch ovirt-hosted-engine-ha-2.4.6-1.el8.noarch ovirt-engine-appliance-4.4-20210323171213.1.el8.x86_64 python3-ovirt-engine-sdk4-4.4.10-1.el8.x86_64 I have many VLANs in my environment. But on this host, I only have these network devices set up (eth0 is the main network, eth1 for storage): # nmcli con NAME UUID TYPE DEVICE ovirtmgmt 02f64861-d992-4e56-8cec-da1906bac09f bridge ovirtmgmt System eth1 bd9e565f-bdc3-4e43-bbd3-5875b9d7fed7 ethernet eth1 virbr0 78e6875d-70f6-4c89-89dd-180dbb9250b1 bridge virbr0 eth0 743b0e26-aae7-44b8-9215-3754a537e90b ethernet eth0 vnet0 bcfead6d-c5b6-4428-9f89-41589735be02 tun vnet0 When I run hosted-engine --deploy --restore-from-file=backup_050321.bck, it hangs after showing: [ INFO ] TASK [ovirt.ovirt.engine_setup : Copy yum configuration file] [ INFO ] changed: [localhost -> ovirt.safari.apple.com] [ INFO ] TASK [ovirt.ovirt.engine_setup : Set 'best' to false] [ INFO ] changed: [localhost -> ovirt.safari.apple.com] [ INFO ] TASK [ovirt.ovirt.engine_setup : Update all packages] virsh shows the VM is in paused state: # virsh list Id Name State ---------------------------------- 1 HostedEngineLocal paused I was able to ssh onto the VM until that point. Do I need to set up all the network connection for all the VLANs before running the deploy script? And how about engine storage domain? I have a new NFS mount ready but it did not ask me about which storage domain to use. Will it ask in later stage? Thanks.

4 12

Something broke & took down multiple VMs for ~20 minutes
by David White 12 May '21

12 May '21

As the subject suggestions, something in oVirt HCI broke. I have no idea what, and it recovered on its own after about 20 minutes or so. I believe that the issue was limited to a single host (although I don't know that for sure), as we had two VMs go completely unresponsive, but a 3rd VM remained operational. For a while during the outage, I was able to log into the oVirt admin web portal, and I noticed at least 1-2 of my hosts (I have 3 hosts) showed the problematic VMs as being problematic inside of oVirt. Reviewing the oVirt Events, I see that this basically started right when the ETL Service Started. There were no events before that point since yesterday, but right when the ETL Service started, it seems like all hell broke loose. oVirt detected "No faulty multipaths" on any of the hosts, but then very quickly started indicating that hosts, vms, and storage targets were unavailable. See my screenshot below. Around 30 - 35 minutes later, it appears that the Hosted Engine terminated due to a storage issue, and auto recovered on a different host. There's a 2nd screenshot beneath the first. Everything came back up shortly before 9am, and has been stable since. In fact, the Volume replication issues that I saw in my environment after I performed maintenance on 1 of my hosts on Friday are no longer present. It appears that the Hosted Engine sees the storage as being perfectly healthy. How do I even begin to figure out what happened, and try to prevent it from happening again? [Screenshot from 2021-04-26 16-36-47.png] [Screenshot from 2021-04-26 16-44-08.png] Sent with ProtonMail Secure Email.

2 7

pool list vm assign user
by Dominique D 11 May '21

11 May '21

Is there a way to know how to see who the vm of a pool assigned to? I am able on the portal to see those who are "logged-in user" but the others VM I don't know to whom they are assigned.

2 3

[ANN] Async oVirt Node release for oVirt 4.4.6
by Sandro Bonazzola 11 May '21

11 May '21

On May 10th 2021 the oVirt project released an async update of oVirt Node (4.4.6.1) Changes: - Updated Advanced Virtualization packages - Updated ovn2.11 and openvswitch2.11 - Updated ansible 2.9.21 ( https://github.com/ansible/ansible/blob/stable-2.9/changelogs/CHANGELOG-v2.… ) - Update libssh (fixes CVE-2020-16135) Full diff list: --- ovirt-node-ng-image-4.4.6.manifest-rpm 2021-05-04 17:02:01.839123874 +0200 +++ ovirt-node-ng-image-4.4.6.1.manifest-rpm 2021-05-11 08:39:44.714649170 +0200 @@ -24 +24 @@ -ansible-2.9.20-2.el8.noarch +ansible-2.9.21-2.el8.noarch @@ -89 +89 @@ -corosynclib-3.1.0-4.el8.0.1.x86_64 +corosynclib-3.1.0-5.el8.x86_64 @@ -100 +100 @@ -cups-libs-2.2.6-38.el8.x86_64 +cups-libs-2.2.6-39.el8.x86_64 @@ -130,5 +130,5 @@ -dracut-049-135.git20210121.el8.x86_64 -dracut-config-generic-049-135.git20210121.el8.x86_64 -dracut-live-049-135.git20210121.el8.x86_64 -dracut-network-049-135.git20210121.el8.x86_64 -dracut-squash-049-135.git20210121.el8.x86_64 +dracut-049-136.git20210426.el8.x86_64 +dracut-config-generic-049-136.git20210426.el8.x86_64 +dracut-live-049-136.git20210426.el8.x86_64 +dracut-network-049-136.git20210426.el8.x86_64 +dracut-squash-049-136.git20210426.el8.x86_64 @@ -148,36 +148,36 @@ -fence-agents-all-4.2.1-67.el8.x86_64 -fence-agents-amt-ws-4.2.1-67.el8.noarch -fence-agents-apc-4.2.1-67.el8.noarch -fence-agents-apc-snmp-4.2.1-67.el8.noarch -fence-agents-bladecenter-4.2.1-67.el8.noarch -fence-agents-brocade-4.2.1-67.el8.noarch -fence-agents-cisco-mds-4.2.1-67.el8.noarch -fence-agents-cisco-ucs-4.2.1-67.el8.noarch -fence-agents-common-4.2.1-67.el8.noarch -fence-agents-compute-4.2.1-67.el8.noarch -fence-agents-drac5-4.2.1-67.el8.noarch -fence-agents-eaton-snmp-4.2.1-67.el8.noarch -fence-agents-emerson-4.2.1-67.el8.noarch -fence-agents-eps-4.2.1-67.el8.noarch -fence-agents-heuristics-ping-4.2.1-67.el8.noarch -fence-agents-hpblade-4.2.1-67.el8.noarch -fence-agents-ibmblade-4.2.1-67.el8.noarch -fence-agents-ifmib-4.2.1-67.el8.noarch -fence-agents-ilo-moonshot-4.2.1-67.el8.noarch -fence-agents-ilo-mp-4.2.1-67.el8.noarch -fence-agents-ilo-ssh-4.2.1-67.el8.noarch -fence-agents-ilo2-4.2.1-67.el8.noarch -fence-agents-intelmodular-4.2.1-67.el8.noarch -fence-agents-ipdu-4.2.1-67.el8.noarch -fence-agents-ipmilan-4.2.1-67.el8.noarch -fence-agents-kdump-4.2.1-67.el8.x86_64 -fence-agents-mpath-4.2.1-67.el8.noarch -fence-agents-redfish-4.2.1-67.el8.x86_64 -fence-agents-rhevm-4.2.1-67.el8.noarch -fence-agents-rsa-4.2.1-67.el8.noarch -fence-agents-rsb-4.2.1-67.el8.noarch -fence-agents-sbd-4.2.1-67.el8.noarch -fence-agents-scsi-4.2.1-67.el8.noarch -fence-agents-vmware-rest-4.2.1-67.el8.noarch -fence-agents-vmware-soap-4.2.1-67.el8.noarch -fence-agents-wti-4.2.1-67.el8.noarch +fence-agents-all-4.2.1-68.el8.x86_64 +fence-agents-amt-ws-4.2.1-68.el8.noarch +fence-agents-apc-4.2.1-68.el8.noarch +fence-agents-apc-snmp-4.2.1-68.el8.noarch +fence-agents-bladecenter-4.2.1-68.el8.noarch +fence-agents-brocade-4.2.1-68.el8.noarch +fence-agents-cisco-mds-4.2.1-68.el8.noarch +fence-agents-cisco-ucs-4.2.1-68.el8.noarch +fence-agents-common-4.2.1-68.el8.noarch +fence-agents-compute-4.2.1-68.el8.noarch +fence-agents-drac5-4.2.1-68.el8.noarch +fence-agents-eaton-snmp-4.2.1-68.el8.noarch +fence-agents-emerson-4.2.1-68.el8.noarch +fence-agents-eps-4.2.1-68.el8.noarch +fence-agents-heuristics-ping-4.2.1-68.el8.noarch +fence-agents-hpblade-4.2.1-68.el8.noarch +fence-agents-ibmblade-4.2.1-68.el8.noarch +fence-agents-ifmib-4.2.1-68.el8.noarch +fence-agents-ilo-moonshot-4.2.1-68.el8.noarch +fence-agents-ilo-mp-4.2.1-68.el8.noarch +fence-agents-ilo-ssh-4.2.1-68.el8.noarch +fence-agents-ilo2-4.2.1-68.el8.noarch +fence-agents-intelmodular-4.2.1-68.el8.noarch +fence-agents-ipdu-4.2.1-68.el8.noarch +fence-agents-ipmilan-4.2.1-68.el8.noarch +fence-agents-kdump-4.2.1-68.el8.x86_64 +fence-agents-mpath-4.2.1-68.el8.noarch +fence-agents-redfish-4.2.1-68.el8.x86_64 +fence-agents-rhevm-4.2.1-68.el8.noarch +fence-agents-rsa-4.2.1-68.el8.noarch +fence-agents-rsb-4.2.1-68.el8.noarch +fence-agents-sbd-4.2.1-68.el8.noarch +fence-agents-scsi-4.2.1-68.el8.noarch +fence-agents-vmware-rest-4.2.1-68.el8.noarch +fence-agents-vmware-soap-4.2.1-68.el8.noarch +fence-agents-wti-4.2.1-68.el8.noarch @@ -187 +187 @@ -filesystem-3.8-4.el8.x86_64 +filesystem-3.8-3.el8.x86_64 @@ -193 +193 @@ -freetype-2.9.1-5.el8.x86_64 +freetype-2.9.1-4.el8_3.1.x86_64 @@ -199 +199 @@ -fwupd-1.5.5-3.el8.x86_64 +fwupd-1.5.9-1.el8.x86_64 @@ -210 +210 @@ -glib2-2.56.4-10.el8.x86_64 +glib2-2.56.4-11.el8.x86_64 @@ -269,2 +269,2 @@ -iproute-5.9.0-4.el8.x86_64 -iproute-tc-5.9.0-4.el8.x86_64 +iproute-5.12.0-0.el8.x86_64 +iproute-tc-5.12.0-0.el8.x86_64 @@ -317,2 +317,2 @@ -krb5-libs-1.18.2-9.el8.x86_64 -krb5-workstation-1.18.2-9.el8.x86_64 +krb5-libs-1.18.2-10.el8.x86_64 +krb5-workstation-1.18.2-10.el8.x86_64 @@ -381 +381 @@ -libgcc-8.4.1-1.el8.x86_64 +libgcc-8.4.1-2.1.el8.x86_64 @@ -393 +393 @@ -libgomp-8.4.1-1.el8.x86_64 +libgomp-8.4.1-2.1.el8.x86_64 @@ -409 +409 @@ -libkadm5-1.18.2-9.el8.x86_64 +libkadm5-1.18.2-10.el8.x86_64 @@ -469,2 +469,2 @@ -libssh-0.9.4-2.el8.x86_64 -libssh-config-0.9.4-2.el8.noarch +libssh-0.9.4-3.el8.x86_64 +libssh-config-0.9.4-3.el8.noarch @@ -476 +476 @@ -libstdc++-8.4.1-1.el8.x86_64 +libstdc++-8.4.1-2.1.el8.x86_64 @@ -498,26 +498,26 @@ -libvirt-7.0.0-9.el8s.x86_64 -libvirt-admin-7.0.0-9.el8s.x86_64 -libvirt-bash-completion-7.0.0-9.el8s.x86_64 -libvirt-client-7.0.0-9.el8s.x86_64 -libvirt-daemon-7.0.0-9.el8s.x86_64 -libvirt-daemon-config-network-7.0.0-9.el8s.x86_64 -libvirt-daemon-config-nwfilter-7.0.0-9.el8s.x86_64 -libvirt-daemon-driver-interface-7.0.0-9.el8s.x86_64 -libvirt-daemon-driver-network-7.0.0-9.el8s.x86_64 -libvirt-daemon-driver-nodedev-7.0.0-9.el8s.x86_64 -libvirt-daemon-driver-nwfilter-7.0.0-9.el8s.x86_64 -libvirt-daemon-driver-qemu-7.0.0-9.el8s.x86_64 -libvirt-daemon-driver-secret-7.0.0-9.el8s.x86_64 -libvirt-daemon-driver-storage-7.0.0-9.el8s.x86_64 -libvirt-daemon-driver-storage-core-7.0.0-9.el8s.x86_64 -libvirt-daemon-driver-storage-disk-7.0.0-9.el8s.x86_64 -libvirt-daemon-driver-storage-gluster-7.0.0-9.el8s.x86_64 -libvirt-daemon-driver-storage-iscsi-7.0.0-9.el8s.x86_64 -libvirt-daemon-driver-storage-iscsi-direct-7.0.0-9.el8s.x86_64 -libvirt-daemon-driver-storage-logical-7.0.0-9.el8s.x86_64 -libvirt-daemon-driver-storage-mpath-7.0.0-9.el8s.x86_64 -libvirt-daemon-driver-storage-rbd-7.0.0-9.el8s.x86_64 -libvirt-daemon-driver-storage-scsi-7.0.0-9.el8s.x86_64 -libvirt-daemon-kvm-7.0.0-9.el8s.x86_64 -libvirt-libs-7.0.0-9.el8s.x86_64 -libvirt-lock-sanlock-7.0.0-9.el8s.x86_64 +libvirt-7.0.0-14.el8s.x86_64 +libvirt-admin-7.0.0-14.el8s.x86_64 +libvirt-bash-completion-7.0.0-14.el8s.x86_64 +libvirt-client-7.0.0-14.el8s.x86_64 +libvirt-daemon-7.0.0-14.el8s.x86_64 +libvirt-daemon-config-network-7.0.0-14.el8s.x86_64 +libvirt-daemon-config-nwfilter-7.0.0-14.el8s.x86_64 +libvirt-daemon-driver-interface-7.0.0-14.el8s.x86_64 +libvirt-daemon-driver-network-7.0.0-14.el8s.x86_64 +libvirt-daemon-driver-nodedev-7.0.0-14.el8s.x86_64 +libvirt-daemon-driver-nwfilter-7.0.0-14.el8s.x86_64 +libvirt-daemon-driver-qemu-7.0.0-14.el8s.x86_64 +libvirt-daemon-driver-secret-7.0.0-14.el8s.x86_64 +libvirt-daemon-driver-storage-7.0.0-14.el8s.x86_64 +libvirt-daemon-driver-storage-core-7.0.0-14.el8s.x86_64 +libvirt-daemon-driver-storage-disk-7.0.0-14.el8s.x86_64 +libvirt-daemon-driver-storage-gluster-7.0.0-14.el8s.x86_64 +libvirt-daemon-driver-storage-iscsi-7.0.0-14.el8s.x86_64 +libvirt-daemon-driver-storage-iscsi-direct-7.0.0-14.el8s.x86_64 +libvirt-daemon-driver-storage-logical-7.0.0-14.el8s.x86_64 +libvirt-daemon-driver-storage-mpath-7.0.0-14.el8s.x86_64 +libvirt-daemon-driver-storage-rbd-7.0.0-14.el8s.x86_64 +libvirt-daemon-driver-storage-scsi-7.0.0-14.el8s.x86_64 +libvirt-daemon-kvm-7.0.0-14.el8s.x86_64 +libvirt-libs-7.0.0-14.el8s.x86_64 +libvirt-lock-sanlock-7.0.0-14.el8s.x86_64 @@ -533 +533,2 @@ -libxcrypt-4.1.1-5.el8.x86_64 +libxcrypt-4.1.1-6.el8.x86_64 +libxkbcommon-0.9.1-1.el8.x86_64 @@ -618,2 +619,2 @@ -openscap-1.3.4-5.el8.x86_64 -openscap-scanner-1.3.4-5.el8.x86_64 +openscap-1.3.5-2.el8.x86_64 +openscap-scanner-1.3.5-2.el8.x86_64 @@ -626 +627 @@ -openvswitch2.11-2.11.0-50.el8.x86_64 +openvswitch2.11-2.11.3-87.el8s.x86_64 @@ -642 +643 @@ -ovirt-node-ng-image-update-placeholder-4.4.6-1.el8.noarch +ovirt-node-ng-image-update-placeholder-4.4.6.1-1.el8.noarch @@ -650,2 +651,2 @@ -ovirt-release-host-node-4.4.6-1.el8.noarch -ovirt-release44-4.4.6-1.el8.noarch +ovirt-release-host-node-4.4.6.1-1.el8.noarch +ovirt-release44-4.4.6.1-1.el8.noarch @@ -654,2 +655,2 @@ -ovn2.11-2.11.1-39.el8.x86_64 -ovn2.11-host-2.11.1-39.el8.x86_64 +ovn2.11-2.11.1-57.el8s.x86_64 +ovn2.11-host-2.11.1-57.el8s.x86_64 @@ -788 +789 @@ -python3-openvswitch2.11-2.11.0-50.el8.x86_64 +python3-openvswitch2.11-2.11.3-87.el8s.x86_64 @@ -828 +829 @@ -python3-subscription-manager-rhsm-1.28.13-2.el8.x86_64 +python3-subscription-manager-rhsm-1.28.16-1.el8.x86_64 @@ -830 +831 @@ -python3-syspurpose-1.28.13-2.el8.x86_64 +python3-syspurpose-1.28.16-1.el8.x86_64 @@ -836,12 +837,14 @@ -qemu-guest-agent-5.2.0-11.el8s.x86_64 -qemu-img-5.2.0-11.el8s.x86_64 -qemu-kvm-5.2.0-11.el8s.x86_64 -qemu-kvm-block-curl-5.2.0-11.el8s.x86_64 -qemu-kvm-block-gluster-5.2.0-11.el8s.x86_64 -qemu-kvm-block-iscsi-5.2.0-11.el8s.x86_64 -qemu-kvm-block-rbd-5.2.0-11.el8s.x86_64 -qemu-kvm-block-ssh-5.2.0-11.el8s.x86_64 -qemu-kvm-common-5.2.0-11.el8s.x86_64 -qemu-kvm-core-5.2.0-11.el8s.x86_64 -quota-4.04-13.el8.x86_64 -quota-nls-4.04-13.el8.noarch +qemu-guest-agent-5.2.0-16.el8s.x86_64 +qemu-img-5.2.0-16.el8s.x86_64 +qemu-kvm-5.2.0-16.el8s.x86_64 +qemu-kvm-block-curl-5.2.0-16.el8s.x86_64 +qemu-kvm-block-gluster-5.2.0-16.el8s.x86_64 +qemu-kvm-block-iscsi-5.2.0-16.el8s.x86_64 +qemu-kvm-block-rbd-5.2.0-16.el8s.x86_64 +qemu-kvm-block-ssh-5.2.0-16.el8s.x86_64 +qemu-kvm-common-5.2.0-16.el8s.x86_64 +qemu-kvm-core-5.2.0-16.el8s.x86_64 +qemu-kvm-ui-opengl-5.2.0-16.el8s.x86_64 +qemu-kvm-ui-spice-5.2.0-16.el8s.x86_64 +quota-4.04-14.el8.x86_64 +quota-nls-4.04-14.el8.noarch @@ -889 +892 @@ -sos-4.0-11.el8.noarch +sos-4.1-1.el8.noarch @@ -903 +906 @@ -subscription-manager-rhsm-certificates-1.28.13-2.el8.x86_64 +subscription-manager-rhsm-certificates-1.28.16-1.el8.x86_64 @@ -960,0 +964 @@ +xkeyboard-config-2.28-1.el8.noarch @@ -963,0 +968,2 @@ +xmlsec1-1.2.25-4.el8.x86_64 +xmlsec1-openssl-1.2.25-4.el8.x86_64 -- Sandro Bonazzola MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://www.redhat.com/> *Red Hat respects your work life balance. Therefore there is no need to answer this email out of your office hours.*

1 0

Re: Changing the ovirtmgmt IP address
by Matthew.Stier＠fujitsu.com 10 May '21

10 May '21

Found the answer: Update /var/lib/vdsm/persistence/netconf/nets/ovritmgmt and reboot. From: Matthew.Stier(a)fujitsu.com <Matthew.Stier(a)fujitsu.com> Sent: Monday, May 10, 2021 3:18 PM To: users(a)ovirt.org Subject: [ovirt-users] Changing the ovirtmgmt IP address Version: 4.3.10 I'm attempting to change the IP address, netmask and gateway of the ovirtmgmt NIC of a host, but everytime I reboot the host, the old address/netmask/gateway re-assert themselves. Where do I need to make the changes, so they will be permanent? I've modified /etc/sysconfig/network-scripts/ifcfg-ovirtmgmt and route-ovirtmgmt, but they don't stick through a reboot.

1 0

Changing the ovirtmgmt IP address
by Matthew.Stier＠fujitsu.com 10 May '21

10 May '21

Version: 4.3.10 I'm attempting to change the IP address, netmask and gateway of the ovirtmgmt NIC of a host, but everytime I reboot the host, the old address/netmask/gateway re-assert themselves. Where do I need to make the changes, so they will be permanent? I've modified /etc/sysconfig/network-scripts/ifcfg-ovirtmgmt and route-ovirtmgmt, but they don't stick through a reboot.

1 0

Re: Unable to provide network acces to second cluster in DC
by Miguel Garcia 10 May '21

10 May '21

Indeed, the network is assigned to the cluster however is not listed at all.

1 0

Changing 1 node Gluster Distributed to replica
by Ernest Clyde Chua 10 May '21

10 May '21

Good day, currently we have a 1 node host that also runs a gluster in 1 node distributed mode and we recently decided to upgrade to a 3 node host which also runs gluster and set a replica count of 3. can someone help me how can i safely change the volume type to replicated

2 5

Sharding decision for oVirt
by levin＠mydream.com.hk 10 May '21

10 May '21

Description of problem: Intermittent VM pause and Qcow image corruption after add new bricks. I'm suffered an issue on image corruption on oVirt 4.3 caused by default gluster ovirt profile, and intermittent VM pause. the problem is similar to #2246 #2254 in glusterfs issue and VM pause issue report in ovirt user group. The gluster vol did not have pending heal object, vol appear in good shape, xfs is healthy, no hardware issue. Sadly few VM have mystery corruption after new bricks added. Afterwards, I try to simulate the problem with or without "cluster.lookup-optimize off" few time, but the problem is not 100% reproducible with lookup-optimize on, I got 1 of 3 attempt that able to reproduce it. It really depend on the workloads and cache status at that moment and the number of object after rebalance as well. Also I tried to disable all sharding features, it ran very solid, write performance increase by far, no corruption, no VM pause when the gluster under stress. So, here is a decision question on shard or not shard. IMO, even recommendation document saying it break large file into smaller chunk that allow healing to complete faster, a larger file can spread over multiple bricks. But there are uncovered issue compared to full large file in this case, I'd like to further deep dive into the reason why recommend shard as default for oVirt? Especially from the reliability and performance perspective, sharding seems losing this end for ovirt/kvm workloads. Is it more appropriate to just tell ovirt user to ensure underlying single bricks shall be large enough to hold the largest chunk instead? Besides, anything i'm overlooked for the shard setting? I'm really doubt to enable sharding on the volume after disaster.

4 12