- Users - oVirt List Archives

problem with multipath.conf
by g.vasilopoulos＠uoc.gr 05 Sep '18

05 Sep '18

after upgrading to 4.20.39-1.el7 sas multipath stopped being detected I did a diff to the two files Is the current behaviour the correct one or the previous one ? I think sas multipath should also be detected no ? [root@g1-car0136 etc]# diff multipath.conf multipath.conf.201809031555 1c1 < # VDSM REVISION 1.6 --- > # VDSM REVISION 1.5 101,109d100 < } < < # Whitelist FCP and iSCSI devices. < blacklist { < protocol ".*" < } < < blacklist_exceptions { < protocol "(scsi:fcp|scsi:iscsi)"

3 4

ERROR: Malformed metadata for host 3
by info＠linuxfabrik.ch 05 Sep '18

05 Sep '18

Hi, we have a Hyperconverged oVirt Cluster with three machines. All three are running GlusterFS (Replica 3), and on two of them we are running the VMs (because they have better hardware). Now we wanted to add a new oVirt host. Due to some network related errors, adding this host was unsuccessful, so we removed it from GUI and also via "hosted-engine --clean-metadata --host-id=3 --force-clean" (as it was still listed using "hosted-engine --vm-status" after removal from the GUI). Inside the GUI and with "hosted-engine --vm-status", everything looks fine now, the third oVirt host is gone, and there are no problems at all. But in the /var/log/ovirt-hosted-engine-ha/agent.log, we now get every 15 minutes a "MainThread::ERROR::2018-09-05 10:20:17,190::hosted_engine::793::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(process_remote_metadata) Malformed metadata for host 3: received 0 of 512 expected bytes", on both of the remaining oVirt hosts. Can someone explain what is wrong? oVirt 4.2.2.6-1.el7.centos Thank you Markus

1 0

qemu-kvm memory leak in 4.2.5
by Hesham Ahmed 05 Sep '18

05 Sep '18

Starting oVirt 4.2.4 (also in 4.2.5 and maybe in 4.2.3) I am facing some sort of memory leak. The memory usage on the hosts keep increasing till it reaches somewhere around 97%. Putting the host in maintenance and back resolves it. The memory usage by the qemu-kvm processes is way above the defined VM memory for instance below is the memory usage of a VM: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 12271 qemu 20 0 35.4g 30.9g 8144 S 13.3 49.3 9433:15 qemu-kvm The VM memory settings are: Defined Memory: 8192 MB Physical Memory Guaranteed: 5461 MB This is for a 3 node hyperconverged cluster running on latest oVirt Node 4.2.5.

3 2

Local storage formatting
by Matt Simonsen 04 Sep '18

04 Sep '18

Hello, I'm running oVirt with several data centers, some with NFS storage and some with local storage. I had problems in the past with a large pool and local storage. The problem was nodectl showed the pool being too full (I think >80%), but it was only the images that made the pool "full" -- and this storage was carefully setup such that there was no chance it would actually fill. The LVs for oVirt itself were all under 20%, yet nodectl still reported the pool was too full. My solution so far has been to use our RAID card tools, so that sda is the oVirt node install, and sdb is for images. There are probably other good reasons for me to handle it this way, for example being able to use different RAID levels, but I'm hoping someone can confirm my partitioning below doesn't have some risk I'm now yet aware of. I setup a new volume group for images, as below: [root@node4-g8-h4 multipath]# pvs PV VG Fmt Attr PSize PFree /dev/mapper/3600508b1001c7e172160824d7b204c3b2 onn_node4-g8-h4 lvm2 a-- <119.00g <22.85g /dev/sdb1 data lvm2 a-- 1.13t <361.30g [root@node4-g8-h4 multipath]# vgs VG #PV #LV #SN Attr VSize VFree data 1 1 0 wz--n- 1.13t <361.30g onn_node4-g8-h4 1 13 0 wz--n- <119.00g <22.85g [root@node4-g8-h4 multipath]# lvs LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert images_main data -wi-ao---- 800.00g home onn_node4-g8-h4 Vwi-aotz-- 1.00g pool00 4.79 ovirt-node-ng-4.2.5.1-0.20180816.0 onn_node4-g8-h4 Vwi---tz-k 64.10g pool00 root ovirt-node-ng-4.2.5.1-0.20180816.0+1 onn_node4-g8-h4 Vwi---tz-- 64.10g pool00 ovirt-node-ng-4.2.5.1-0.20180816.0 ovirt-node-ng-4.2.6-0.20180903.0 onn_node4-g8-h4 Vri---tz-k 64.10g pool00 ovirt-node-ng-4.2.6-0.20180903.0+1 onn_node4-g8-h4 Vwi-aotz-- 64.10g pool00 ovirt-node-ng-4.2.6-0.20180903.0 4.83 pool00 onn_node4-g8-h4 twi-aotz-- 91.10g 8.94 0.49 root onn_node4-g8-h4 Vwi---tz-- 64.10g pool00 swap onn_node4-g8-h4 -wi-ao---- 4.00g tmp onn_node4-g8-h4 Vwi-aotz-- 1.00g pool00 4.87 var onn_node4-g8-h4 Vwi-aotz-- 15.00g pool00 3.31 var_crash onn_node4-g8-h4 Vwi-aotz-- 10.00g pool00 2.86 var_log onn_node4-g8-h4 Vwi-aotz-- 8.00g pool00 3.57 var_log_audit onn_node4-g8-h4 Vwi-aotz-- 2.00g pool00 4.89 The images_main is setup as "Block device for filesystems" with ext4. Is there any reason I should consider pool for thinly provisioned volumes? I don't need to over-allocate storage and it seems to me like a fixed partition is ideal. Please confirm or let me know if there's anything else I should consider. Thanks Matt

2 3

self-hosted engine lost password
by Rob Epping 04 Sep '18

04 Sep '18

Hello list, I'm trying to update our ovirt self-hosted engine to the latest version using the docs at https://www.ovirt.org/documentation/upgrade-guide/chap-Updates_between_ Minor_Releases/#updating-the-ovirt-self-hosted-engine-and-underlying- virtualization-hosts For this I need to logon to the engine VM, but none of the passwords we used seems to work. I can not seem to find information on how te reset passwords of the hosted engine, so I'm stuck. Am I doing something wrong or is access to the self-hosted engine required. When access is required, is there a way to reset the password? THNX && GRTNX, RobJE

2 2

Upgraded host, engine now won't boot
by Jim Kusznir 04 Sep '18

04 Sep '18

Hello: I saw that there were updates to my ovirt-4.2 3 node hyperconverged system, so I proceeded to apply them the usual way through the UI. At one point, the hosted engine was migrated to one of the upgraded hosts, and then went "unstable" on me. Now, the hosted engine appears to be crashed: It gets powered up, but it never boots up to the point where it responds to pings or allows logins. After a while, the hosted engine shows status (via console "hosted-engine --vm-status" command) "Powering Down". It stays there for a long time. I tried forcing a poweroff then powering it on, but again, it never gets up to where it will respond to pings. --vm-status shows bad health, but up. I tried running the hosted-engine --console command, but got: [root@ovirt1 ~]# hosted-engine --console The engine VM is running on this host Connected to domain HostedEngine Escape character is ^] error: internal error: cannot find character device <null> [root@ovirt1 ~]# I tried to run the hosted-engine --upgrade-appliance command, but it hangs at obtaining certificate (understandably, as the hosted-engine is not up). How do i recover from this? And what caused this? --Jim

2 10

ovirt4 api search storage domain
by David David 04 Sep '18

04 Sep '18

hi need to lookup storage name by vm disk id. how to do it in python or in java? thanks

2 1

Wrong network threshold limit warnings on 4.2.5
by Florian Schmid 04 Sep '18

04 Sep '18

Good morning, since we have upgraded to version 4.2.5, we get a lot of warnings about network interface exceeded defined threshold limits. For example: Aug 31, 2018, 7:54:05 AM Host xxx has network interface which exceeded the defined threshold [95%] (enp9s0.80: transmit rate[100%], receive rate [12%]) This is a 10 Gbit interface and on our monitoring software, which is getting network statistics every 10s, the bandwidth of TX was 150 Mbit maximum at this time, so far away from being 100%. Could it be, that the engine detected the wrong interface speed or there is a calculation error? In the engine for this host, I have 10000 Mbps for all interfaces. I have checked now all those warnings on our different hosts and they happen every time, we go over 100 Mbit and this is for sure quite often... Can I maybe disable these warnings, because we have it anyway in our monitoring software? If you need any logs, please ask. BR Florian Schmid

5 10

Bricks do not appear in oVirt Manager UI under Hosts unless manually created on nodes.
by payden.pringle+ovirtlist＠gmail.com 03 Sep '18

03 Sep '18

I have a CentOS 7.5 system running the oVirt-Engine package as the manager for three oVirt Nodes (version 4.2). Two of the nodes have a 200GB disk and one has a 2GB disk. I am attempting to create a Gluster Volume that replicates between the two 200GB disks with the 2GB as Arbiter. When I create the bricks by going to Hosts > host1 > Storage Devices > Create Brick (with the 200GB device selected), it succeeds, but no bricks appear under the Bricks tab for the Host. Doing the same for host2 and host3 results in the same problem. If I run the following command on a host `gluster volume create test-volume replica 3 arbiter 1 192.168.5.{50,60,40}:/gluster-bricks/200GBbrick/test`, it creates the volume correctly and the bricks then appear as they should. However, then these Bricks are labeled as "Down" and when I go to Storage > Volumes, I get this error: ``` Uncaught exception occurred. Please try reloading the page. Details: (TypeError) : Cannot read property 'a' of null Please have your administrator check the UI logs ``` The Volume is also shown as "Down". SELinux is enabled on my CentOS 7.5 system. I'm not really sure what the correct method is to create bricks then a Volume in Gluster through the oVirt Management UI, but I've followed the guides and this is where it has got me.

2 1

oVirt Node 4.2.3.1. to 4.2.5 upgrade trouble, log attached
by Matt Simonsen 03 Sep '18

03 Sep '18

Hello all, I've emailed about similar trouble with an oVirt Node upgrade using the ISO install. I've attached the /tmp/imgbased.log file in hopes it will help give a clue as to why the trouble. Since these use NFS storage I can rebuild, but would like to know, ideally, what caused the upgrade to break. Truthfully following the install, I don't think I have done *that* much to these systems, so I'm not sure what would have caused the problem. I have done several successful upgrades in the past and most of my standalone systems have been working great. I've been really happy with oVirt, so kudos to the team. Thanks for any help, Matt

5 13