- Users - oVirt List Archives

Re: Memory ballon question
by Strahil 14 Jun '19

14 Jun '19

Hi Martin, Thanks for clarifying that. Best Regards, Strahil NikolovOn Jun 14, 2019 13:02, Martin Sivak <msivak(a)redhat.com> wrote: > > Hi, > > > 2019-06-13 07:11:40,973 - mom.Controllers.Balloon - INFO - Ballooning guest:node1 from 695648 to 660865 > > 2019-06-13 07:12:51,437 - mom.GuestMonitor.Thread - INFO - GuestMonitor-node1 ending > > > > Can someone clarify what exactly does this (from xxxx to yyyy) mean ? > > It is the ballooning operation log: > > - From - how much memory was left in the VM before the action > - To - how much after (could be both lower and higher) > > I do not remember the units, but I think it was in KiB. > > Martin > > > On Thu, Jun 13, 2019 at 9:26 PM Strahil Nikolov <hunter86_bg(a)yahoo.com> wrote: > > > > Hi Martin,Darrell, > > > > thanks for your feedback. > > > > I have checked the /var/log/vdsm/mom.log and it seems that MOM was actually working: > > > > 2019-06-13 07:08:47,690 - mom.GuestMonitor.Thread - INFO - GuestMonitor-node1 starting > > 2019-06-13 07:09:39,490 - mom.Controllers.Balloon - INFO - Ballooning guest:node1 from 1048576 to 996147 > > 2019-06-13 07:09:54,658 - mom.Controllers.Balloon - INFO - Ballooning guest:node1 from 996148 to 946340 > > 2019-06-13 07:10:09,853 - mom.Controllers.Balloon - INFO - Ballooning guest:node1 from 946340 to 899023 > > 2019-06-13 07:10:25,053 - mom.Controllers.Balloon - INFO - Ballooning guest:node1 from 899024 to 854072 > > 2019-06-13 07:10:40,233 - mom.Controllers.Balloon - INFO - Ballooning guest:node1 from 854072 to 811368 > > 2019-06-13 07:10:55,428 - mom.Controllers.Balloon - INFO - Ballooning guest:node1 from 811368 to 770799 > > 2019-06-13 07:11:10,621 - mom.Controllers.Balloon - INFO - Ballooning guest:node1 from 770800 to 732260 > > 2019-06-13 07:11:25,827 - mom.Controllers.Balloon - INFO - Ballooning guest:node1 from 732260 to 695647 > > 2019-06-13 07:11:40,973 - mom.Controllers.Balloon - INFO - Ballooning guest:node1 from 695648 to 660865 > > 2019-06-13 07:12:51,437 - mom.GuestMonitor.Thread - INFO - GuestMonitor-node1 ending > > > > Can someone clarify what exactly does this (from xxxx to yyyy) mean ? > > > > Best Regards, > > Strahil Nikolov > > > > В четвъртък, 13 юни 2019 г., 17:27:01 ч. Гринуич+3, Martin Sivak <msivak(a)redhat.com> написа: > > > > > > Hi, > > > > iirc the guest agent is not needed anymore as we get almost the same > > stats from the balloon driver directly. > > > > Ballooning has to be enabled on cluster level though. So that is one > > thing to check. If that is fine then I guess a more detailed > > description is needed. > > > > oVirt generally starts ballooning when the memory load gets over 80% > > of available memory. > > > > The host agent that handles ballooning is called mom and the logs are > > located in /var/log/vdsm/mom* iirc. It might be a good idea to check > > whether the virtual machines were declared ready (meaning all data > > sources we collect provided data). > > > > -- > > Martin Sivak > > used to be maintainer of mom > > > > On Thu, Jun 13, 2019 at 12:26 AM Darrell Budic <budic(a)onholyground.com> wrote: > > > > > > Do you have the overt-guest-agent running on your VMs? It’s required for ballooning to control allocations on the guest side. > > > > > > On Jun 12, 2019, at 11:32 AM, Strahil <hunter86_bg(a)yahoo.com> wrote: > > > > > > Hello All, > > > > > > as a KVM user I know how usefull is the memory balloon and how you can both increase - and also decrease memory live (both Linux & Windows). > > > I have noticed that I cannot decrease the memory in oVirt. > > > > > > Does anyone got a clue why the situation is like that ? > > > > > > I was expecting that the guaranteed memory is the minimum to which the balloon driver will not go bellow, but when I put my host under pressure - the host just started to swap instead of reducing some of the VM memory (and my VMs had plenty of free space). > > > > > > It will be great if oVirt can decrease the memory (if the VM has unallocated memory) when the host is under pressure and the VM cannot be relocated. > > > > > > Best Regards, > > > Strahil Nikolov > > > > > > _______________________________________________ > > > 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/LUWCN2MLNTDJU… > > > > > > > > > _______________________________________________ > > > 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/22XYJD7XAYZLV… > > > > _______________________________________________ > > Users mailing list -- users(a)ovirt.org > > To unsubscribe send an email to users-l

1 0

Memory ballon question
by Strahil 14 Jun '19

14 Jun '19

Hello All, as a KVM user I know how usefull is the memory balloon and how you can both increase - and also decrease memory live (both Linux & Windows). I have noticed that I cannot decrease the memory in oVirt. Does anyone got a clue why the situation is like that ? I was expecting that the guaranteed memory is the minimum to which the balloon driver will not go bellow, but when I put my host under pressure - the host just started to swap instead of reducing some of the VM memory (and my VMs had plenty of free space). It will be great if oVirt can decrease the memory (if the VM has unallocated memory) when the host is under pressure and the VM cannot be relocated. Best Regards, Strahil Nikolov

4 4

Re: High Performance VM: trouble using vNUMA and hugepages
by Andrej Krejcir 14 Jun '19

14 Jun '19

Hi, this is probably a bug. Can you open a new ticket in Bugzilla? https://bugzilla.redhat.com/enter_bug.cgi?product=ovirt-engine As a workaround, if you are sure that the VM's NUMA configuration is compatible with the host's NUMA configuration, you could create a custom cluster scheduling policy and disable the "NUMA" filter. In Administration -> Configure -> Scheduling Policies. Regards, Andrej On Thu, 13 Jun 2019 at 12:49, Matthias Leopold < matthias.leopold(a)meduniwien.ac.at> wrote: > Hi, > > I'm having trouble using vNUMA and hugepages at the same time: > > - hypervisor host hast 2 CPU and 768G RAM > - hypervisor host is configured to allocate 512 1G hugepages > - VM configuration > * 2 virtual sockets, vCPUs are evenly pinned to 2 physical CPUs > * 512G RAM > * 2 vNUMA nodes that are pinned to the 2 host NUMA nodes > * custom property "hugepages=1048576" > - VM is the only VM on hypervisor host > > when I want to start the VM I'm getting the error message > "The host foo did not satisfy internal filter NUMA because cannot > accommodate memory of VM's pinned virtual NUMA nodes within host's > physical NUMA nodes" > VM start only works when VM memory is shrunk so that it fits in (host > memory - allocated huge pages) > > I don't understand why this happens. Can someone explain to me how this > is supposed to work? > > oVirt engine is 4.3.3 > oVirt host is 4.3.4 > > thanks > matthias

2 2

Ovirt engine setup Err'or
by PS Kazi 14 Jun '19

14 Jun '19

I am getting following error while ovirt engine setup. I am using ovirt node 4.3.4 please help ___________________________________ [ ERROR ] fatal: [localhost]: FAILED! => {"attempts": 90, "changed": true, "cmd": "virsh -r net-dhcp-leases default | grep -i 00:16:3e:5f:0e:ea | awk '{ print $5 }' | cut -f1 -d'/'", "delta": "0:00:00.086952", "end": "2019-06-14 12:05:37.249240", "rc": 0, "start": "2019-06-14 12:05:37.162288", "stderr": "", "stderr_lines": [], "stdout": "", "stdout_lines": []} [ INFO ] TASK [ovirt.hosted_engine_setup : include_tasks] [ INFO ] ok: [localhost] [ INFO ] TASK [ovirt.hosted_engine_setup : Remove local vm dir] [ INFO ] changed: [localhost] [ INFO ] TASK [ovirt.hosted_engine_setup : Remove temporary entry in /etc/hosts for the local VM] [ INFO ] ok: [localhost] [ INFO ] TASK [ovirt.hosted_engine_setup : Notify the user about a failure] [ ERROR ] fatal: [localhost]: FAILED! => {"changed": false, "msg": "The system may not be provisioned according to the playbook results: please check the logs for the issue, fix accordingly or re-deploy from scratch.\n"}

1 0

Ovirt hiperconverged setup error
by PS Kazi 14 Jun '19

14 Jun '19

ovirt Node version 4.3.3.1 I am trying to configure 3 node Gluster storage and oVirt hosted engine but gettng following error: TASK [gluster.features/roles/gluster_hci : Check if valid FQDN is provided] **** failed: [ov-node-2 -> localhost] (item=ov-node-2) => {"changed": true, "cmd": ["dig", "ov-node-2", "+short"], "delta": "0:00:00.041003", "end": "2019-06-12 12:52:34.158688", "failed_when_result": true, "item": "ov-node-2", "rc": 0, "start": "2019-06-12 12:52:34.117685", "stderr": "", "stderr_lines": [], "stdout": "", "stdout_lines": []} failed: [ov-node-2 -> localhost] (item=ov-node-3) => {"changed": true, "cmd": ["dig", "ov-node-3", "+short"], "delta": "0:00:00.038688", "end": "2019-06-12 12:52:34.459176", "failed_when_result": true, "item": "ov-node-3", "rc": 0, "start": "2019-06-12 12:52:34.420488", "stderr": "", "stderr_lines": [], "stdout": "", "stdout_lines": []} failed: [ov-node-2 -> localhost] (item=ov-node-1) => {"changed": true, "cmd": ["dig", "ov-node-1", "+short"], "delta": "0:00:00.047938", "end": "2019-06-12 12:52:34.768149", "failed_when_result": true, "item": "ov-node-1", "rc": 0, "start": "2019-06-12 12:52:34.720211", "stderr": "", "stderr_lines": [], "stdout": "", "stdout_lines": []} Please help

4 5

Re: The CPU type of the cluster is unknown. Its possible to change the cluster cpu or set a different one per VM.
by Strahil 14 Jun '19

14 Jun '19

In the docs, the proper order to update is: 1. update ovirt-setup packages on the engine yum update ovirt\*setup\* 2. update the engine engine-setup 3. update the OS on the engine yum update 4. reboot the engine if kernel/glibc/systemd got updated 5 upgrade hosts 1 by 1 Best Regards, Strahil NikolovOn Jun 13, 2019 16:27, sandeepkumar86k(a)gmail.com wrote: > > Thank you. > > I upgraded all three hosts one by one to oVirt-4.3 and then HE. After the upgrade, I was able to change the CPU Type. > _______________________________________________ > 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/NGUEEF4DVLBXL…

1 0

Re: Hosted Engine Abruptly Stopped Responding - Unexpected Shutdown
by Strahil 14 Jun '19

14 Jun '19

Hi Maria, I guess the memory usage is very specidic to the environment. My setup includes 2 VDOs, 8 gluster volumes , 2 clusters, 12 VMs and only 1 user - the built-in admin . In result my engine is using 4GB of RAM. How many users/storages/clusters/VMs do you have ? When you login on the engine, what is the process eating most of the RAM? My suspicion is the DB. If so, maybe someone else can advise if performing vacuum on DB during upgrade will be beneficial. Best Regards, Strahil NikolovOn Jun 13, 2019 15:55, souvaliotimaria(a)mail.com wrote: > > Hello and thank you very much for your reply. > > I'm terribly sorry for being so late to respond. > > I thought the same, that dropping the cache was more of a workaround and not a real solution but truthfully I was stuck and can't think of anything more than how much I need to upgrade the memory on the nodes. I try to find info about other ovirt virtualization set-ups and the amount of memory allocated so I can get an idea of what my set-up needs. The only thing that I found was that one admin had set ovirt up with 128GB and still needed more because of the growing needs of the system and its users and was about to upgrade its memory too. I'm just worried that ovirt is very memory consuming and no matter how much I will "feed" it, it will still ask for more. Also, I'm worried that there one, two or even more tweaks in the configurations that I still miss and they'd be able to solve the memory problem. > > Anyway, KSM is enabled. Sar shows that the committed memory when a Windows 10 VM is active too (alongside Hosted Engine of course, and two Linux VMs - 1 CentOS, 1 Debian) is around 89% in the specific host that it runs (together with the Debian VM) and has reached up to 98%. > > You are correct about the monitoring system too. I have set up a PRTG environment and there's Nagios running but they can't yet see ovirt. I will set them up correctly the next few days. > > I haven't made any changes to my tuned profile. it's the default from ovirt. Specifically, the active profile says it's set to virtual-host. > > Again I'm very sorry for taking me so long to reply and thank you very much for your response. > > Best Regards, > Maria Souvalioti > _______________________________________________ > 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/G4YELWF5L4AKU…

1 0

oVirt engine/engine-setup with other port than default HTTPS 443 possible?
by Dirk Rydvan 13 Jun '19

13 Jun '19

Hello, in a home lab with only one puplic IPv4-Adress is the Port 443 a very precious one. The installation of oVirt 4.3 on a single node/host with bare metal installed CentOS works well. (oVirt Cockpit and local installed engine added after installation of Centos 7.6). But it is more difficult to change the port from 443 to maybe 4443 the save the port 443. The change in: - /etc/httpd/conf/conf.d/ssl.conf - /var/lib/ovirt-engine/jboss_runtime/config/ovirt-engine.xml and - disable selinux - add 4443 to public with firewall-cmd It does not work... now I see is more difficult than I think before... A port redirection at the edge route from <public-IPv4>:4443 to <private-IPv4>:443 does also not work, because the links points all to the standard https adress without a port number. Is there a way to change the default port 443 of oVirt engine to a other port? Many Thanks in advance!

2 2

Re: 4.3.4 caching disk error during hyperconverged deployment
by Strahil 13 Jun '19

13 Jun '19

Better raise a bug in bugilla.redhat.com and mention the working 4.3.3 Best Regards, Strahil NikolovOn Jun 13, 2019 04:30, adrianquintero(a)gmail.com wrote: > > While trying to do a hyperconverged setup and trying to use "configure LV Cache" /dev/sdf the deployment fails. If I dont use the LV cache SSD Disk the setup succeds, thought you mighg want to know, for now I retested with 4.3.3 and all worked fine, so reverting to 4.3.3 unless you know of a workaround? > > Error: > TASK [gluster.infra/roles/backend_setup : Extend volume group] ***************** > failed: [vmm11.mydomain.com] (item={u'vgname': u'gluster_vg_sdb', u'cachethinpoolname': u'gluster_thinpool_gluster_vg_sdb', u'cachelvname': u'cachelv_gluster_thinpool_gluster_vg_sdb', u'cachedisk': u'/dev/sdf', u'cachemetalvname': u'cache_gluster_thinpool_gluster_vg_sdb', u'cachemode': u'writethrough', u'cachemetalvsize': u'0.1G', u'cachelvsize': u'0.9G'}) => {"ansible_loop_var": "item", "changed": false, "err": " Physical volume \"/dev/sdb\" still in use\n", "item": {"cachedisk": "/dev/sdf", "cachelvname": "cachelv_gluster_thinpool_gluster_vg_sdb", "cachelvsize": "0.9G", "cachemetalvname": "cache_gluster_thinpool_gluster_vg_sdb", "cachemetalvsize": "0.1G", "cachemode": "writethrough", "cachethinpoolname": "gluster_thinpool_gluster_vg_sdb", "vgname": "gluster_vg_sdb"}, "msg": "Unable to reduce gluster_vg_sdb by /dev/sdb.", "rc": 5} > > failed: [vmm12.mydomain.com] (item={u'vgname': u'gluster_vg_sdb', u'cachethinpoolname': u'gluster_thinpool_gluster_vg_sdb', u'cachelvname': u'cachelv_gluster_thinpool_gluster_vg_sdb', u'cachedisk': u'/dev/sdf', u'cachemetalvname': u'cache_gluster_thinpool_gluster_vg_sdb', u'cachemode': u'writethrough', u'cachemetalvsize': u'0.1G', u'cachelvsize': u'0.9G'}) => {"ansible_loop_var": "item", "changed": false, "err": " Physical volume \"/dev/sdb\" still in use\n", "item": {"cachedisk": "/dev/sdf", "cachelvname": "cachelv_gluster_thinpool_gluster_vg_sdb", "cachelvsize": "0.9G", "cachemetalvname": "cache_gluster_thinpool_gluster_vg_sdb", "cachemetalvsize": "0.1G", "cachemode": "writethrough", "cachethinpoolname": "gluster_thinpool_gluster_vg_sdb", "vgname": "gluster_vg_sdb"}, "msg": "Unable to reduce gluster_vg_sdb by /dev/sdb.", "rc": 5} > > failed: [vmm10.mydomain.com] (item={u'vgname': u'gluster_vg_sdb', u'cachethinpoolname': u'gluster_thinpool_gluster_vg_sdb', u'cachelvname': u'cachelv_gluster_thinpool_gluster_vg_sdb', u'cachedisk': u'/dev/sdf', u'cachemetalvname': u'cache_gluster_thinpool_gluster_vg_sdb', u'cachemode': u'writethrough', u'cachemetalvsize': u'30G', u'cachelvsize': u'270G'}) => {"ansible_loop_var": "item", "changed": false, "err": " Physical volume \"/dev/sdb\" still in use\n", "item": {"cachedisk": "/dev/sdf", "cachelvname": "cachelv_gluster_thinpool_gluster_vg_sdb", "cachelvsize": "270G", "cachemetalvname": "cache_gluster_thinpool_gluster_vg_sdb", "cachemetalvsize": "30G", "cachemode": "writethrough", "cachethinpoolname": "gluster_thinpool_gluster_vg_sdb", "vgname": "gluster_vg_sdb"}, "msg": "Unable to reduce gluster_vg_sdb by /dev/sdb.", "rc": 5} > > PLAY RECAP ********************************************************************* > vmm10.mydomain.com : ok=13 changed=4 unreachable=0 failed=1 skipped=10 rescued=0 ignored=0 > vmm11.mydomain.com : ok=13 changed=4 unreachable=0 failed=1 skipped=10 rescued=0 ignored=0 > vmm12.mydomain.com : ok=13 changed=4 unreachable=0 failed=1 skipped=10 rescued=0 ignored=0 > > > > --------------------------------------------------------------------------------------------------------------------- > #cat /etc/ansible/hc_wizard_inventory.yml > --------------------------------------------------------------------------------------------------------------------- > hc_nodes: > hosts: > vmm10.mydomain.com: > gluster_infra_volume_gro

2 1

The CPU type of the cluster is unknown. Its possible to change the cluster cpu or set a different one per VM.
by sandeepkumar86k＠gmail.com 13 Jun '19

13 Jun '19

Hi, I am having trouble in fixing the CPU type of my oVirt cluster. I have AMD EPYC 7551P 32-Core Processor hosts(x3) in a gluster cluster. The HE and cluster by default had the: AMD Opteron 23xx (Gen 3 Class Opteron). I tried changing it with this method(https://lists.ovirt.org/archives/list/users@ovirt.org/thread/XYY2WAG…, it didn't work as I can't move the Host to another cluster it complains (Error while executing action: *******: Cannot edit Host. Server having Gluster volume.) Then I tried updating the cpu_name manually in DB by following: https://www.mail-archive.com/users@ovirt.org/msg33177.html After the Update, the web UI shows it changed to AMD EPYC but if I click on Edit cluster it shows the "Intel Conroe Family" and again doesn't allow to modify. I am now stuck with unusable oVirt setup, my existing VMs won't start and throw: Error while executing action: ******: The CPU type of the cluster is unknown. Its possible to change the cluster cpu or set a different one per VM.) Please help or suggest to fix this issue. HE: cat /proc/cpuinfo |grep "model name" model name : AMD Opteron 23xx (Gen 3 Class Opteron) model name : AMD Opteron 23xx (Gen 3 Class Opteron) model name : AMD Opteron 23xx (Gen 3 Class Opteron) model name : AMD Opteron 23xx (Gen 3 Class Opteron) rpm -qa |grep -i ovirt ovirt-ansible-image-template-1.1.9-1.el7.noarch ovirt-engine-dwh-setup-4.2.4.3-1.el7.noarch ovirt-engine-backend-4.2.8.2-1.el7.noarch ovirt-engine-extension-aaa-ldap-1.3.8-1.el7.noarch ovirt-engine-extension-aaa-jdbc-1.1.7-1.el7.centos.noarch ovirt-engine-wildfly-overlay-14.0.1-3.el7.noarch ovirt-ansible-hosted-engine-setup-1.0.2-1.el7.noarch ovirt-host-deploy-java-1.7.4-1.el7.noarch ovirt-engine-setup-plugin-websocket-proxy-4.2.8.2-1.el7.noarch ovirt-engine-setup-plugin-vmconsole-proxy-helper-4.2.8.2-1.el7.noarch ovirt-ansible-engine-setup-1.1.6-1.el7.noarch ovirt-ansible-cluster-upgrade-1.1.10-1.el7.noarch ovirt-ansible-roles-1.1.6-1.el7.noarch ovirt-release42-4.2.8-1.el7.noarch ovirt-engine-setup-plugin-ovirt-engine-common-4.2.8.2-1.el7.noarch ovirt-engine-tools-backup-4.2.8.2-1.el7.noarch ovirt-provider-ovn-1.2.18-1.el7.noarch ovirt-imageio-common-1.4.6-1.el7.x86_64 ovirt-js-dependencies-1.2.0-3.1.el7.centos.noarch ovirt-cockpit-sso-0.0.4-1.el7.noarch ovirt-engine-restapi-4.2.8.2-1.el7.noarch ovirt-engine-vmconsole-proxy-helper-4.2.8.2-1.el7.noarch ovirt-engine-api-explorer-0.0.2-1.el7.centos.noarch ovirt-engine-lib-4.2.8.2-1.el7.noarch ovirt-engine-setup-base-4.2.8.2-1.el7.noarch ovirt-engine-metrics-1.1.8.1-1.el7.noarch ovirt-ansible-repositories-1.1.3-1.el7.noarch ovirt-ansible-disaster-recovery-1.1.4-1.el7.noarch ovirt-ansible-infra-1.1.10-1.el7.noarch ovirt-ansible-shutdown-env-1.0.0-1.el7.noarch ovirt-engine-dwh-4.2.4.3-1.el7.noarch ovirt-iso-uploader-4.2.0-1.el7.centos.noarch ovirt-engine-webadmin-portal-4.2.8.2-1.el7.noarch ovirt-engine-dbscripts-4.2.8.2-1.el7.noarch ovirt-engine-setup-plugin-ovirt-engine-4.2.8.2-1.el7.noarch ovirt-engine-extension-aaa-ldap-setup-1.3.8-1.el7.noarch ovirt-engine-extensions-api-impl-4.2.8.2-1.el7.noarch ovirt-host-deploy-1.7.4-1.el7.noarch ovirt-vmconsole-1.0.6-2.el7.noarch python-ovirt-engine-sdk4-4.2.9-2.el7.x86_64 ovirt-engine-wildfly-14.0.1-3.el7.x86_64 ovirt-guest-agent-common-1.0.16-1.el7.noarch ovirt-ansible-v2v-conversion-host-1.9.0-1.el7.noarch ovirt-ansible-manageiq-1.1.13-1.el7.noarch ovirt-setup-lib-1.1.5-1.el7.noarch ovirt-engine-websocket-proxy-4.2.8.2-1.el7.noarch ovirt-engine-dashboard-1.2.4-1.el7.noarch ovirt-engine-setup-4.2.8.2-1.el7.noarch ovirt-engine-sdk-python-3.6.9.1-1.el7.noarch ovirt-vmconsole-proxy-1.0.6-2.el7.noarch ovirt-web-ui-1.4.5-1.el7.noarch ovirt-ansible-vm-infra-1.1.12-1.el7.noarch ovirt-imageio-proxy-setup-1.4.6-1.el7.noarch ovirt-imageio-proxy-1.4.6-1.el7.noarch ovirt-engine-tools-4.2.8.2-1.el7.noarch ovirt-engine-4.2.8.2-1.el7.noarch ovirt-engine-cli-3.6.9.2-1.el7.centos.noarch 3xHosts: cat /proc/cpuinfo |grep "model name" model name : AMD EPYC 7551P 32-Core Processor model name : AMD EPYC 7551P 32-Core Processor model name : AMD EPYC 7551P 32-Core Processor rpm -qa |grep -i ovirt ovirt-release42-4.2.8-1.el7.noarch cockpit-ovirt-dashboard-0.11.38-1.el7.noarch ovirt-vmconsole-1.0.6-2.el7.noarch python-ovirt-engine-sdk4-4.2.9-2.el7.x86_64 cockpit-machines-ovirt-193-2.el7.noarch ovirt-imageio-daemon-1.4.6-1.el7.noarch ovirt-hosted-engine-setup-2.2.33-1.el7.noarch ovirt-engine-appliance-4.2-20190121.1.el7.noarch ovirt-vmconsole-host-1.0.6-2.el7.noarch ovirt-engine-sdk-python-3.6.9.1-1.el7.noarch ovirt-setup-lib-1.1.5-1.el7.noarch ovirt-host-deploy-1.7.4-1.el7.noarch ovirt-host-dependencies-4.2.3-1.el7.x86_64 ovirt-hosted-engine-ha-2.2.19-1.el7.noarch ovirt-provider-ovn-driver-1.2.18-1.el7.noarch ovirt-imageio-common-1.4.6-1.el7.x86_64 ovirt-host-4.2.3-1.el7.x86_64 Thanks,

2 2