- Users - oVirt List Archives

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

Info about soft fencing mechanism
by Gianluca Cecchi 13 Jun '19

13 Jun '19

Hello, I would like to know in better detail how soft fencing works in 4.3. In particular, with "soft fencing" we "only" mean vdsmd restart attempt, correct? Who is responsible for issuing the command? Manager or host itself? Because in case of Manager, if the host has already lost connection, how could the manager be able to do it? Thanks in advance for clarifications and eventually documentation pointers Gianluca

1 0

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

13 Jun '19

On Jun 6, 2019 12:52, souvaliotimaria(a)mail.com wrote: > > Hello, > > I came upon a problem the previous month that I figured it would be good to discuss here. I'm sorry I didn't post here earlier but time slipped me. > > I have set up a glustered, hyperconverged oVirt environment for experimental use as a means to see its behaviour and get used to its management and performance before setting it up as a production environment for use in our organization. The environment is up and running since 2018 October. The three nodes are HP ProLiant DL380 G7 and have the following characteristics: > > Mem: 22GB > CPU: 2x Hexa Core - Intel Xeon Hexa Core E56xx > HDD: 5x 300GB > Network: BCM5709C with dual-port Gigabit > OS: Linux RedHat 7.5.1804(Core 3.10.0-862.3.2.el7.x86_64 x86_64) - Ovirt Node 4.2.3.1 > > As I was working on the environment, the engine stopped working. > Not long before the time the HE stopped, I was in the web interface managing my VMs, when the browser froze and the HE was also not responding to ICMP requests. > > The first thing I did was to connect via ssh to all nodes and run the command > #hosted-engine --vm-status > which showed that the HE was down in nodes 1 and 2 and up on the 3rd node. > > After executing > #virsh -r list > the VM list that was shown contained two of the VMs I had previously created and were up; the HE was nowhere. > > I tried to restart the HE with the > #hosted-engine --vm-start > but it didn't work. > > I then put all nodes in maintenance mode with the command > #hosted-engine --set-maintenance --mode=global > (I guess I should have done that earlier) and re-run > #hosted-engine --vm-start > that had the same result as it previously did. > > After checking the mails the system sent to the root user, I saw there were several mails on the 3rd node (where the HE had been), informing of the HE's state. The messages were changing between EngineDown-EngineStart, EngineStart-EngineStarting, EngineStarting-EngineMaybeAway, EngineMaybeAway-EngineUnexpectedlyDown, EngineUnexpectedlyDown-EngineDown, EngineDown-EngineStart and so forth. > > I continued by searching the following logs in all nodes : > /var/log/libvirt/qemu/HostedEngine.log > /var/log/libvirt/qemu/win10.log > /var/log/libvirt/qemu/DNStest.log > /var/log/vdsm/vdsm.log > /var/log/ovirt-hosted-engine-ha/agent.log > > After that I spotted and error that had started appearing almost a month ago in node #2: > ERROR Internal server error Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/yajsonrpc/__init__.py", line 606, in _handle_request res = method(**params) File "/usr/lib/python2.7/site-packages/vdsm/rpc/Bridge.py", line 197, in _dynamicMethod result = fn(*methodArgs) File "/usr/lib/python2.7/site-packages/vdsm/gluster/apiwrapper.py", line 85, in logicalVolumeList return self._gluster.logicalVolumeList() File "/usr/lib/python2.7/site-packages/vdsm/gluster/api.py", line 90, in wrapper rv = func(*args, **kwargs) File "/usr/lib/python2.7/site-packages/vdsm/gluster/api.py", line 808, in logicalVolumeList status = self.svdsmProxy.glusterLogicalVolumeList() File "/usr/lib/python2.7/site-packages/vdsm/common/supervdsm.py", line 55, in __call__ return callMethod() File "/usr/lib/python2.7/site-packages/vdsm/common/supervdsm.py", line 52, in <lambda> getattr(self._supervdsmProxy._svdsm, self._funcName)(*args, AttributeError: 'AutoProxy[instance]' object has no attribute 'glusterLogicalVolumeList' > > > The outputs of the following commands were also checked as a way to see if there was a mandatory process missing/killed, a memory problem or even disk space shortage that led to the sudden death of a process > #ps -A > #top > #free -h > #df -hT > > Finally, after some time delving in the logs, the output of the > #journalctl --dmesg > showed the following message > "Out of memory: Kill process 5422 (qemu-kvm) score 514 or sacrifice child. > Killed process 5422 (qemu-kvm) total-vm:17526548kB, anon-rss:9310396kB, > file-rss:2336kB, shmem-rss:12kB" > which after that the ovirtmgmt started not responding. If you run out of memory, you should take that serious.Droping the cache seems like a workaround and not a fix. Check if KSM is enabled - this will merge your VM's memory pages for an exchange for CPU cycles - still better than getting a VM killed. Also, you can protect the HostedEngine from OOM killer. > I tried to restart the vhostd by executing > #/etc/rc.d/init.d/vhostmd start > but it didn't work. > > Finally, I decided to run the HE restart command on the other nodes as well (I'd figured that since the HE was last running on the node #3, that's where I should try to restart it). So, I run > #hosted-engine --vm-start > and the output was > "Command VM.getStats with args {'vmID':'...<το ID της HE>....'} failed: > (code=1,message=Virtual machine does not exist: {'vmID':'...<το ID της > HE>....'})" > And then I run the command again and the output was > "VM exists and its status is Powering Up." > > After that I executed > #virsh -r list > and the output was the following: > Id Name State > ---------------------------------------------------- > 2 HostedEngine running > > After the HE's restart two mails came that stated: ReinitializeFSMEngineStarting and EngineStarting-EngineUp > > After that and after checking that we had access to the web interface again, we executed > hosted-engine --set-maintenance --mode=none > to get out of the maintenance mode. > > The thing is, I still am not 1000% sure what the problem was that led to the shutdown of the hosted engine and I think that maybe some of the steps I took were not needed. I believe it was because the process qemu-kvm was killed after there was not enough memory for it but is this the real cause? I wasn't doing anything unusual before the shutdown to believe it was because of the new VM that was still in shutdown mode or anything of the sort. Also, I believe it may be because of memory shortage because I hadn't executed the > #sync ; echo 3 > /proc/sys/vm/drop_caches > command for a couple of weeks. > > What are your thoughts on this? Could you point me to where to search for more information on the topic or tell me what is the right process to follow when something like this happens? Check the sar (there is a graphical util called 'ksar' and check cpu , memory, swap, context switches , I/O and network usage). Crreate simple systemd service to monitor your nodes, or even better put a real monitoring software so you can proactively take any actions. > Also, I have set up a few VMs but only three are Up and they have no users yet, even so the buffers fill almost to the brim when the usage is almost non-existant. If you have an environment that has some users or you use the VMs as virtual servers of some sort, what is the consumption of the memory? What's the optimal size for the memory? What is your tuned profile ? Any customizations there ? Best Regards, Strahil Nikolov > Thank you all very much. > _______________________________________________ > 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/PKRB26GSDQ5JV…

2 1

Re: 4.3 live migration creates wrong image permissions.
by Strahil 13 Jun '19

13 Jun '19

Hi Alex, Did you migrate from gluster v3 to v5 ? If yes, then it could be the issue with v5.3 where permissions go wrong. If so, pick ovirt 4.3.4 as it uses a newer (fixed ) version of gluster -> v5.6 Best Regards, Strahil NikolovOn Jun 13, 2019 09:46, Alex McWhirter <alex(a)triadic.us> wrote: > > after upgrading from 4.2 to 4.3, after a vm live migrates it's disk > images are become owned by root:root. Live migration succeeds and the vm > stays up, but after shutting down the VM from this point, starting it up > again will cause it to fail. At this point i have to go in and change > the permissions back to vdsm:kvm on the images, and the VM will boot > again. > _______________________________________________ > 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/TSWRTC2E7XZSG…

2 1

High Performance VM: trouble using vNUMA and hugepages
by Matthias Leopold 13 Jun '19

13 Jun '19

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

1 0

[ANN] oVirt 4.3.5 First Release Candidate is now available
by Sandro Bonazzola 13 Jun '19

13 Jun '19

The oVirt Project is pleased to announce the availability of the oVirt 4.3.5 First Release Candidate, as of June 13th, 2019. This update is a release candidate of the fifth 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.6 or later * CentOS Linux (or similar) 7.6 or later This release supports Hypervisor Hosts on x86_64 and ppc64le architectures for: * Red Hat Enterprise Linux 7.6 or later * CentOS Linux (or similar) 7.6 or later * oVirt Node 4.3 (available for x86_64 only) See the release notes [1] for installation / upgrade instructions and a list of new features and bugs fixed. Notes: - oVirt Appliance is already available - oVirt Node is already available[2] Additional Resources: * Read more about the oVirt 4.3.5 release highlights: http://www.ovirt.org/release/4.3.5/ * 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.5/ [2] http://resources.ovirt.org/pub/ovirt-4.3-pre/iso/ -- Sandro Bonazzola MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://www.redhat.com/>

1 0

Re: Memory ballon question
by Strahil 13 Jun '19

13 Jun '19

Hi Darrell, Yes , all VMs (both openSUSE and RedHat/CentOS 7) have the ovirt-guest-agent up and running. Best Regards, Strahil NikolovOn Jun 12, 2019 22:07, 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… > >

2 1

Re: Ovirt hiperconverged setup error
by Strahil 13 Jun '19

13 Jun '19

Simone has provided you a workaround, so check his e-mail. The ansible is actually running: dig ov-node2 +short As dig is quarrying your DNS server, you need to bypass this check if you use /etc/host entries. Best Regards, Strahil NikolovOn Jun 12, 2019 21:57, PS Kazi <faruk.apsara(a)gmail.com> wrote: > > Hi, > How to check my DNS settings is ok or not for ovirt? > > On Wed, 12 Jun 2019, 6:55 pm Strahil Nikolov, <hunter86_bg(a)yahoo.com> wrote: >> >> Command run is "dig' which tries to resolve the hostname of each server. >> Do you have a DNS resolver properly configured ? >> >> Best Regards, >> Strahil Nikolov >> >> В сряда, 12 юни 2019 г., 3:59:14 ч. Гринуич-4, PS Kazi <faruk.apsara(a)gmail.com> написа: >> >> >> 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 >> _______________________________________________ >> 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/BXMOTKHGI5TNP…

1 0

Re: Replace bad Host from a 9 Node hyperconverged setup 4.3.3
by Strahil 12 Jun '19

12 Jun '19

Hi Adrian, You have several options: A) If you have space on another gluster volume (or volumes) or on NFS-based storage, you can migrate all VMs live . Once you do it, the simple way will be to stop and remove the storage domain (from UI) and gluster volume that correspond to the problematic brick. Once gone, you can remove the entry in oVirt for the old host and add the newly built one.Then you can recreate your volume and migrate the data back. B) If you don't have space you have to use a more riskier approach (usually it shouldn't be risky, but I had bad experience in gluster v3): - New server has same IP and hostname: Use command line and run the 'gluster volume reset-brick VOLNAME HOSTNAME:BRICKPATH HOSTNAME:BRICKPATH commit' Replace VOLNAME with your volume name. A more practical example would be: 'gluster volume reset-brick data ovirt3:/gluster_bricks/data/brick ovirt3:/gluster_ ricks/data/brick commit' If it refuses, then you have to cleanup '/gluster_bricks/data' (which should be empty). Also check if the new peer has been probed via 'gluster peer status'.Check the firewall is allowing gluster communication (you can compare it to the firewalls on another gluster host). The automatic healing will kick in 10 minutes (if it succeeds) and will stress the other 2 replicas, so pick your time properly. Note: I'm not recommending you to use the 'force' option in the previous command ... for now :) - The new server has a different IP/hostname: Instead of 'reset-brick' you can use 'replace-brick': It should be like this: gluster volume replace-brick data old-server:/path/to/brick new-server:/new/path/to/brick commit force In both cases check the status via: gluster volume info VOLNAME If your cluster is in production , I really recommend you the first option as it is less risky and the chance for unplanned downtime will be minimal. The 'reset-brick' in your previous e-mail shows that one of the servers is not connected. Check peer status on all servers, if they are less than they should check for network and/or firewall issues. On the new node check if glusterd is enabled and running. In order to debug - you should provide more info like 'gluster volume info' and the peer status from each node. Best Regards, Strahil Nikolov On Jun 10, 2019 20:10, Adrian Quintero <adrianquintero(a)gmail.com> wrote: > > Can you let me know how to fix the gluster and missing brick?, > I tried removing it by going to "storage > Volumes > vmstore > bricks > selected the brick > However it is showing as an unknown status (which is expected because the server was completely wiped) so if I try to "remove", "replace brick" or "reset brick" it wont work > If i do remove brick: Incorrect bricks selected for removal in Distributed Replicate volume. Either all the selected bricks should be from the same sub volume or one brick each for every sub volume! > If I try "replace brick" I cant because I dont have another server with extra bricks/disks > And if I try "reset brick": Error while executing action Start Gluster Volume Reset Brick: Volume reset brick commit force failed: rc=-1 out=() err=['Host myhost1_mydomain_com not connected'] > > Are you suggesting to try and fix the gluster using command line? > > Note that I cant "peer detach" the sever , so if I force the removal of the bricks would I need to force downgrade to replica 2 instead of 3? what would happen to oVirt as it only supports replica 3? > > thanks again. > > On Mon, Jun 10, 2019 at 12:52 PM Strahil <hunter86_bg(a)yahoo.com> wrote: >> >> Hi Adrian, >> Did you fix the issue with the gluster and the missing brick? >> If yes, try to set the 'old' host in maintenance an

3 4

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

12 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!

1 0

RFE: HostedEngine to use boom by default
by Strahil Nikolov 12 Jun '19

12 Jun '19

Hello All, I have seen a lot of cases where the HostedEngine gets corrupted/broken and beyond repair. I think that BOOM is a good option for our HostedEngine appliances due to the fact that it supports booting from LVM snapshots and thus being able to easily recover after upgrades or other outstanding situations. Sadly, BOOM has 1 drawback - that everything should be under a single snapshot - thus no separation of /var /log or /audit. Do you think that changing the appliance layout is worth it ? Note: I might have an unsupported layout that could cause my confusion.Is your layout a single root LV ? Best Regards,Strahil Nikolov

2 2

4K Sector Hard drive Support - oVirt 4.3.4
by nico.kruger＠darkmatter.ae 12 Jun '19

12 Jun '19

Hi Guys, Does anyone have any idea if/when 4K Sector drives will be supported? My understanding is that this was one of the features for 4.3.4 Thanks Nico Kruger

2 1

vNUMA question
by Matthias Leopold 12 Jun '19

12 Jun '19

Hi, when I want to use vNUMA for VMs is it necessary that the number of VM virtual sockets corresponds to the number of vNUMA nodes? concrete example: hypervisor host has 2 physical cpus VM has 2 vNUMA nodes and uses CPU pinning which distributes the VCPUs equally over both physical CPUs is it necessary for the VM to have 2 virtual sockets or is it ok for virtual socket count to be powers of 2 (eg. 16)? thanks matthias

2 1

Re: Can't bring upgraded to 4.3 host back to cluster
by Shani Leviim 12 Jun '19

12 Jun '19

Np :) On Tuesday, June 11, 2019, Artem Tambovskiy <artem.tambovskiy(a)gmail.com> wrote: > Actually, this one wasn't stupid. The host was running version 4.3.3 and > was upgraded to 4.3.4 after yum update. > And this solved the issue ... thanks a lot! > > Looing at the bugtracker (https://bugzilla.redhat.com/ > buglist.cgi?classification=oVirt&f1=flagtypes.name&o1= > substring&query_format=advanced&target_milestone=ovirt-4.3.4&v1=blocker) > I don't see a suitable bug for this. perhaps vdsmd reconfiguration + yum > upgrade + host reboot did the trick. > > Thank you very much for spending a time on this! > Regards, > Artem > > On Tue, Jun 11, 2019 at 5:19 PM Shani Leviim <sleviim(a)redhat.com> wrote: > >> A stupid one: did you try to yum update? >> >> >> >> *Regards,* >> >> *Shani Leviim* >> >> >> On Tue, Jun 11, 2019 at 5:11 PM Artem Tambovskiy < >> artem.tambovskiy(a)gmail.com> wrote: >> >>> >>> Just tried this: >>> >>> [root@ovirt1 vdsm]# vdsm-tool configure --force >>> >>> Checking configuration status... >>> >>> abrt is already configured for vdsm >>> Managed volume database is already configured >>> lvm is configured for vdsm >>> libvirt is already configured for vdsm >>> SUCCESS: ssl configured to true. No conflicts >>> Current revision of multipath.conf detected, preserving >>> >>> Running configure... >>> Reconfiguration of abrt is done. >>> Reconfiguration of passwd is done. >>> Reconfiguration of libvirt is done. >>> >>> Done configuring modules to VDSM. >>> >>> And tried to restart vdsmd - it failed again. >>> >>> [root@ovirt1 vdsm]# journalctl -xe >>> Jun 11 17:07:58 ovirt1.telia.ru systemd[1]: ovirt-ha-broker.service >>> failed. >>> Jun 11 17:07:58 ovirt1.telia.ru systemd[1]: ovirt-ha-broker.service >>> holdoff time over, scheduling restart. >>> Jun 11 17:07:58 ovirt1.telia.ru systemd[1]: Cannot add dependency job >>> for unit lvm2-lvmetad.socket, ignoring: Unit is masked. >>> Jun 11 17:07:58 ovirt1.telia.ru systemd[1]: Stopped oVirt Hosted Engine >>> High Availability Communications Broker. >>> -- Subject: Unit ovirt-ha-broker.service has finished shutting down >>> -- Defined-By: systemd >>> -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel >>> -- >>> -- Unit ovirt-ha-broker.service has finished shutting down. >>> Jun 11 17:07:58 ovirt1.telia.ru systemd[1]: Started oVirt Hosted Engine >>> High Availability Communications Broker. >>> -- Subject: Unit ovirt-ha-broker.service has finished start-up >>> -- Defined-By: systemd >>> -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel >>> -- >>> -- Unit ovirt-ha-broker.service has finished starting up. >>> -- >>> -- The start-up result is done. >>> Jun 11 17:07:59 ovirt1.telia.ru systemd[1]: mom-vdsm.service holdoff >>> time over, scheduling restart. >>> Jun 11 17:07:59 ovirt1.telia.ru systemd[1]: Cannot add dependency job >>> for unit lvm2-lvmetad.socket, ignoring: Unit is masked. >>> Jun 11 17:07:59 ovirt1.telia.ru systemd[1]: Stopped MOM instance >>> configured for VDSM purposes. >>> -- Subject: Unit mom-vdsm.service has finished shutting down >>> -- Defined-By: systemd >>> -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel >>> -- >>> -- Unit mom-vdsm.service has finished shutting down. >>> Jun 11 17:07:59 ovirt1.telia.ru systemd[1]: start request repeated too >>> quickly for supervdsmd.service >>> Jun 11 17:07:59 ovirt1.telia.ru systemd[1]: Failed to start Auxiliary >>> vdsm service for running helper functions as root. >>> -- Subject: Unit supervdsmd.service has failed >>> -- Defined-By: systemd >>> -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel >>> -- >>> -- Unit supervdsmd.service has failed. >>> -- >>> -- The result is failed. >>> Jun 11 17:07:59 ovirt1.telia.ru systemd[1]: Dependency failed for >>> Virtual Desktop Server Manager. >>> -- Subject: Unit vdsmd.service has failed >>> -- Defined-By: systemd >>> -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel >>> -- >>> -- Unit vdsmd.service has failed. >>> -- >>> -- The result is dependency. >>> Jun 11 17:07:59 ovirt1.telia.ru systemd[1]: Dependency failed for MOM >>> instance configured for VDSM purposes. >>> -- Subject: Unit mom-vdsm.service has failed >>> -- Defined-By: systemd >>> -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel >>> -- >>> -- Unit mom-vdsm.service has failed. >>> -- >>> -- The result is dependency. >>> Jun 11 17:07:59 ovirt1.telia.ru systemd[1]: Job mom-vdsm.service/start >>> failed with result 'dependency'. >>> Jun 11 17:07:59 ovirt1.telia.ru systemd[1]: Job vdsmd.service/start >>> failed with result 'dependency'. >>> Jun 11 17:07:59 ovirt1.telia.ru systemd[1]: supervdsmd.service failed. >>> >>> I also tried to enable DEBUG level but failed. >>> >>> [root@ovirt1 vdsm]# vdsm-client Host setLogLevel level=DEBUG >>> vdsm-client: Connection to localhost:54321 with use_tls=True, timeout=60 >>> failed: [Errno 111] Connection refused >>> >>> >>> Regards, >>> Artem >>> >>> >>> >>> On Tue, Jun 11, 2019 at 4:45 PM Shani Leviim <sleviim(a)redhat.com> wrote: >>> >>>> Until will get a response from Dan (maybe it's related to a network >>>> issue), I would suggest to re-configure the vdsm: >>>> vdsm-tool configure --force >>>> >>>> some further steps are available here: https://www.ovirt.org/develop/ >>>> developer-guide/vdsm/installing-vdsm-from-rpm.html# >>>> installing--configuring-vdsm >>>> >>>> Let me know if it helped. >>>> >>>> Also, can you please attach a VDSM log with DEBUG level? >>>> To do so: >>>> vdsm-client Host setLogLevel level=DEBUG >>>> >>>> >>>> *Regards,* >>>> >>>> *Shani Leviim* >>>> >>>> >>>> On Tue, Jun 11, 2019 at 3:04 PM Artem Tambovskiy < >>>> artem.tambovskiy(a)gmail.com> wrote: >>>> >>>>> Hi Shani, >>>>> >>>>> yes, you are right - I can do ssh form aby to any hosts in the >>>>> cluster. vdsm.log attached. >>>>> I have tried to restart vdsm manually and even done a host restart >>>>> several times with no success. >>>>> Host activation fails all the time ... >>>>> >>>>> Thank you in advance for your help! >>>>> Regard, >>>>> Artem >>>>> >>>>> On Tue, Jun 11, 2019 at 10:51 AM Shani Leviim <sleviim(a)redhat.com> >>>>> wrote: >>>>> >>>>>> Hi Artem, >>>>>> According to oVirt documentation [1], hosts on the same cluster >>>>>> should be reachable from one to each other. >>>>>> >>>>>> Can you please share your vdsm log? >>>>>> I suppose you do manage to ssh that inactive host (correct me if I'm >>>>>> wrong). >>>>>> While getting the vdsm log, maybe try to restart the network and >>>>>> vdsmd services on the host. >>>>>> >>>>>> Another thing you can try on the UI is putting the host on >>>>>> maintenance and then activate it. >>>>>> >>>>>> [1] https://www.ovirt.org/documentation/admin-guide/ >>>>>> chap-Clusters.html#introduction-to-clusters >>>>>> >>>>>> >>>>>> *Regards,* >>>>>> >>>>>> *Shani Leviim* >>>>>> >>>>>> >>>>>> On Mon, Jun 10, 2019 at 4:42 PM Artem Tambovskiy < >>>>>> artem.tambovskiy(a)gmail.com> wrote: >>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> May I ask you for and advise? >>>>>>> I'm running a small oVirt cluster and couple of months ago I decided >>>>>>> to do an upgrade from oVirt 4.2.8 to 4.3 and having an issues since that >>>>>>> time. I can only guess what I did wrong - probably one of the problems that >>>>>>> I haven't switched the cluster from iptables to firewalld. But this is just >>>>>>> my guess. >>>>>>> >>>>>>> The problem is that I have upgraded the engine and one host, and >>>>>>> then I done an upgrade of second host I can't bring it to active state. >>>>>>> Looks like VDSM can't detect the network and fails to start. I even tried >>>>>>> to reinstall the hosts from UI (I have seen that the packages being >>>>>>> installed) but again, VDSM doesn't startup at the end and reinstallation >>>>>>> fails. >>>>>>> >>>>>>> Looking at hosts process list I see script *wait_for_ipv4s* >>>>>>> hanging forever. >>>>>>> >>>>>>> vdsm 8603 1 6 16:26 ? 00:00:00 /usr/bin/python >>>>>>> /usr/share/ovirt-hosted-engine-ha/ovirt-ha-agent >>>>>>> >>>>>>> *root 8630 1 0 16:26 ? 00:00:00 /bin/sh >>>>>>> /usr/libexec/vdsm/vdsmd_init_common.sh --pre-startroot 8645 8630 6 >>>>>>> 16:26 ? 00:00:00 /usr/bin/python2 /usr/libexec/vdsm/wait_for_ipv4s* >>>>>>> root 8688 1 30 16:27 ? 00:00:00 /usr/bin/python2 >>>>>>> /usr/share/vdsm/supervdsmd --sockfile /var/run/vdsm/svdsm.sock >>>>>>> vdsm 8715 1 0 16:27 ? 00:00:00 /usr/bin/python >>>>>>> /usr/share/ovirt-hosted-engine-ha/ovirt-ha-broker >>>>>>> >>>>>>> The all hosts in cluster are reachable from each other ... That >>>>>>> could be the issue? >>>>>>> >>>>>>> Thank you in advance! >>>>>>> -- >>>>>>> Regards, >>>>>>> Artem >>>>>>> _______________________________________________ >>>>>>> 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(a)ovirt.org/message/TQX3LN2TEM4DECKKUMMRCWXTRM6BGI >>>>>>> AB/ >>>>>>> >>>>>> >>>>> >>>>> -- >>>>> Regards, >>>>> Artem >>>>> >>>> >>> >>> -- >>> Regards, >>> Artem >>> >> > > -- > Regards, > Artem > -- *Regards,* *Shani Leviim*

1 0

VM Disk Performance metrics?
by Wesley Stewart 11 Jun '19

11 Jun '19

Is there any way to get ovirt disk performance metrics into the web interface? It would be nice to see some type of IOPs data, so we can see which VMs are hitting our data stores the most. It seems you can run virt-top on a host to get some of these metrics, but it would be nice to get some sort of data in the gui. Thanks!

3 2

Can't bring upgraded to 4.3 host back to cluster
by Artem Tambovskiy 11 Jun '19

11 Jun '19

Hello, May I ask you for and advise? I'm running a small oVirt cluster and couple of months ago I decided to do an upgrade from oVirt 4.2.8 to 4.3 and having an issues since that time. I can only guess what I did wrong - probably one of the problems that I haven't switched the cluster from iptables to firewalld. But this is just my guess. The problem is that I have upgraded the engine and one host, and then I done an upgrade of second host I can't bring it to active state. Looks like VDSM can't detect the network and fails to start. I even tried to reinstall the hosts from UI (I have seen that the packages being installed) but again, VDSM doesn't startup at the end and reinstallation fails. Looking at hosts process list I see script *wait_for_ipv4s* hanging forever. vdsm 8603 1 6 16:26 ? 00:00:00 /usr/bin/python /usr/share/ovirt-hosted-engine-ha/ovirt-ha-agent *root 8630 1 0 16:26 ? 00:00:00 /bin/sh /usr/libexec/vdsm/vdsmd_init_common.sh --pre-startroot 8645 8630 6 16:26 ? 00:00:00 /usr/bin/python2 /usr/libexec/vdsm/wait_for_ipv4s* root 8688 1 30 16:27 ? 00:00:00 /usr/bin/python2 /usr/share/vdsm/supervdsmd --sockfile /var/run/vdsm/svdsm.sock vdsm 8715 1 0 16:27 ? 00:00:00 /usr/bin/python /usr/share/ovirt-hosted-engine-ha/ovirt-ha-broker The all hosts in cluster are reachable from each other ... That could be the issue? Thank you in advance! -- Regards, Artem

3 5

Failed to activate Storage Domain --- ovirt 4.2
by aminur.rahman＠iongroup.com 11 Jun '19

11 Jun '19

Hi Has anyone experiencing the following issue with Storage Domain - Failed to activate Storage Domain cLUN-R940-DC2-dstore01 -- VDSM command ActivateStorageDomainVDS failed: Storage domain does not exist: (u'1b0ef853-fd71-45ea-8165-cc6047a267bc',) Currently, the storge Domain is Inactive and strangely, the VMs are running as normal. We can't manage or extend the volume size of this storage domain. The pvscan shows as: [root@uk1-ion-ovm-18 pvscan /dev/mapper/36000d310056978000000000000000014: Checksum error at offset 4397954425856 Couldn't read volume group metadata from /dev/mapper/36000d310056978000000000000000014. Metadata location on /dev/mapper/36000d310056978000000000000000014 at 4397954425856 has invalid summary for VG. Failed to read metadata summary from /dev/mapper/36000d310056978000000000000000014 Failed to scan VG from /dev/mapper/36000d310056978000000000000000014 I have tired the following steps: 1. Restarted ovirt-engine.service 2. tried to restore the metadata using vgcfgrestore but it failed with the following error: [root@uk1-ion-ovm-19 backup]# vgcfgrestore 36000d310056978000000000000000014 Volume group 36000d310056978000000000000000014 has active volume: . WARNING: Found 1 active volume(s) in volume group "36000d310056978000000000000000014". Restoring VG with active LVs, may cause mismatch with its metadata. Do you really want to proceed with restore of volume group "36000d310056978000000000000000014", while 1 volume(s) are active? [y/n]: y /dev/mapper/36000d310056978000000000000000014: Checksum error at offset 4397954425856 Couldn't read volume group metadata from /dev/mapper/36000d310056978000000000000000014. Metadata location on /dev/mapper/36000d310056978000000000000000014 at 4397954425856 has invalid summary for VG. Failed to read metadata summary from /dev/mapper/36000d310056978000000000000000014 Failed to scan VG from /dev/mapper/36000d310056978000000000000000014 /etc/lvm/backup/36000d310056978000000000000000014: stat failed: No such file or directory Couldn't read volume group metadata from file. Failed to read VG 36000d310056978000000000000000014 from /etc/lvm/backup/36000d310056978000000000000000014 Restore failed. Please let me know if anyone knows any possible resolution. -AMinur

5 6

[ANN] oVirt 4.3.4 is now generally available
by Sandro Bonazzola 11 Jun '19

11 Jun '19

The oVirt Project is pleased to announce the general availability of oVirt 4.3.4 as of June 11th, 2019. This update is the fourth in a series of stabilization updates to the 4.3 series. This release is available now on x86_64 architecture for: * Red Hat Enterprise Linux 7.6 or later * CentOS Linux (or similar) 7.6 or later This release supports Hypervisor Hosts on x86_64 and ppc64le architectures for: * Red Hat Enterprise Linux 7.6 or later * CentOS Linux (or similar) 7.6 or later * oVirt Node 4.3 (available for x86_64 only) Due to Fedora 28 being now at end of life this release is missing experimental tech preview for x86_64 and s390x architectures for Fedora 28. We are working on Fedora 29 and 30 support and we may re-introduce experimental support for Fedora in next release. See the release notes [1] for installation / upgrade instructions and a list of new features and bugs fixed. Notes: - oVirt Appliance is already available - oVirt Node is already available[2] - oVirt Windows Guest Tools is already available[2] oVirt Guest Tools ISO has been updated including new virtio-win-prewhql drivers collection version 171, providing updated qxl-wddm-dod driver version 0.19 (see https://gitlab.freedesktop.org/spice/win32/qxl-wddm-dod/blob/master/Changel… for more information). oVirt Node and Appliance have been updated including: - oVirt 4.3.4: http://www.ovirt.org/release/4.3.4/ - Latest CentOS updates including: - CEBA-2019:1015 CentOS 7 glibc BugFix Update <https://lists.centos.org/pipermail/centos-announce/2019-May/023302.html> - CESA-2019:0809 Important CentOS 7 ovmf Security Update <https://lists.centos.org/pipermail/centos-announce/2019-April/023280.html> - CEBA-2019:0814 CentOS 7 lvm2 BugFix Update <https://lists.centos.org/pipermail/centos-announce/2019-April/023294.html> - CEBA-2019:0808 CentOS 7 iproute BugFix Update <https://lists.centos.org/pipermail/centos-announce/2019-April/023288.html> - CESA-2019:1168 Important CentOS 7 kernel Security Update <https://lists.centos.org/pipermail/centos-announce/2019-May/023314.html> - CEBA-2019:0807 CentOS 7 gcc BugFix Update <https://lists.centos.org/pipermail/centos-announce/2019-April/023286.html> - CEBA-2019:0820 CentOS 7 systemd BugFix Update <https://lists.centos.org/pipermail/centos-announce/2019-April/023281.html> - CEBA-2019:0816 CentOS 7 sssd BugFix Update <https://lists.centos.org/pipermail/centos-announce/2019-April/023283.html> - CESA-2019:1264 Important CentOS 7 libvirt Security Update <https://lists.centos.org/pipermail/centos-announce/2019-May/023319.html> - CEEA-2019:1210 CentOS 7 microcode_ctl Enhancement Update <https://lists.centos.org/pipermail/centos-announce/2019-May/023311.html> - CESA-2019:1022 Important CentOS 7 python-jinja2 Security Update <https://lists.centos.org/pipermail/centos-announce/2019-May/023303.html> - CEEA-2019:0045 CentOS 7 rsync Enhancement Update <https://lists.centos.org/pipermail/centos-announce/2019-April/023284.html> - CEBA-2019:0826 CentOS 7 scap-security-guide BugFix Update <https://lists.centos.org/pipermail/centos-announce/2019-April/023291.html> - CEBA-2019:0819 CentOS 7 sos BugFix Update <https://lists.centos.org/pipermail/centos-announce/2019-April/023292.html> - latest CentOS Virt and Storage SIG updates: - CESA-2019:1179 CentOS Virt SIG - Errata and Security Advisory 2019:1179 Important Upstream details at : https://access.redhat.com/errata/RHSA-2019:1179 - ansible-2.8.1: https://github.com/ansible/ansible/blob/stable-2.8/changelogs/CHANGELOG-v2.… - glusterfs-5.6: https://docs.gluster.org/en/latest/release-notes/5.6/ - cockpit 193: https://cockpit-project.org/blog/cockpit-193.html Additional Resources: * Read more about the oVirt 4.3.4 release highlights: http://www.ovirt.org/release/4.3.4/ * 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.4/ [2] http://resources.ovirt.org/pub/ovirt-4.3/iso/ -- Sandro Bonazzola MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://www.redhat.com/>

1 0

Replace bad Host from a 9 Node hyperconverged setup 4.3.3
by adrianquintero＠gmail.com 10 Jun '19

10 Jun '19

Anybody have had to replace a failed host from a 3, 6, or 9 node hyperconverged setup with gluster storage? One of my hosts is completely dead, I need to do a fresh install using ovirt node iso, can anybody point me to the proper steps? thanks,

6 15

Re: run ovirt without firewalld
by Strahil 10 Jun '19

10 Jun '19

Then ... You have no choice , but to enable firewalld via a cron job or systemd service. I think Sahina and/or Sandro can hint you how to proceed . Best Regards, Strahil Nikolov On Jun 10, 2019 20:02, Chris Boon <cpjboon(a)gmail.com> wrote: > > yeah i noticed the same, HostedEngine doesn't want to migrate or start due to disabled firewalld. > But some organizations have a company policy not to run firewalls on servers, only edge firewalls. > So automation tools disable firewalld :( > > best regards, > Chris > _______________________________________________ > 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/JQOROLNXKSQHT…

1 0

Re: Replace bad Host from a 9 Node hyperconverged setup 4.3.3
by Strahil 10 Jun '19

10 Jun '19

Hi Adrian, Did you fix the issue with the gluster and the missing brick? If yes, try to set the 'old' host in maintenance and then forcefully remove it from oVirt. If it succeeds (and it should), then you can add the server back and then check what happens. Best Regards, Strahil NikolovOn Jun 10, 2019 18:12, Adrian Quintero <adrianquintero(a)gmail.com> wrote: > > Ok I have tried reinstalling the server from scratch with a different name and IP address and when trying to add it to cluster I get the following error: > > Event details > ID: 505 > Time: Jun 10, 2019, 10:00:00 AM > Message: Host myshost2.virt.iad3p installation failed. Host myhost2.mydomain.com reports unique id which already registered for myhost1.mydomain.com > > I am at a loss here, I don't have a brand new server to do this and in need to re-use what I have. > > > From the oVirt engine log (/var/log/ovirt-engine/engine.log): > 2019-06-10 10:57:59,950-04 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (EE-ManagedThreadFactory-engine-Thread-37744) [9b88055] EVENT_ID: VDS_INSTALL_FAILED(505), Host myhost2.mydomain.com installation failed. Host myhost2.mydomain.com reports unique id which already registered for myhost1.mydomain.com > > So in the /var/log/ovirt-engine/host-deploy/ovirt-host-deploy-20190610105759-myhost2.mydomain.com-9b88055.log of the ovirt engine I see that the host deploy is running the following command to identify the system, if this is the case then it will never work :( because it identifies each host using the system uuid. > > dmidecode -s system-uuid > b64d566e-055d-44d4-83a2-d3b83f25412e > > > Any suggestions? > > Thanks > > On Sat, Jun 8, 2019 at 11:23 AM Adrian Quintero <adrianquintero(a)gmail.com> wrote: >> >> Leo, >> I did try putting it under maintenance and checking to ignore gluster and it did not work. >> Error while executing action: >> -Cannot remove host. Server having gluster volume. >> >> Note: the server was already reinstalled so gluster will never see the volumes or bricks for this server. >> >> I will rename the server to myhost2.mydomain.com and try to replace the bricks hopefully that might work, however it would be good to know that you can re-install from scratch an existing cluster server and put it back to the cluster. >> >> Still doing research hopefully we can find a way. >> >> thanks again >> >> Adrian >> >> >> >> >> On Fri, Jun 7, 2019 at 2:39 AM Leo David <leoalex(a)gmail.com> wrote: >>> >>> You will need to remove the storage role from that server first ( not being part of gluster cluster ). >>> I cannot test this right now on production, but maybe putting host although its already died under "mantainance" while checking to ignore guster warning will let you remove it. >>> Maybe I am wrong about the procedure, can anybody input an advice helping with this situation ? >>> Cheers, >>> >>> Leo >>> >>> >>> >>> >>> On Thu, Jun 6, 2019 at 9:45 PM Adrian Quintero <adrianquintero(a)gmail.com> wrote: >>>> >>>> I tried removing the bad host but running into the following issue , any idea?

2 1