- Users - oVirt List Archives

Cluster compatibility version 4.5 on oVirt 4.4
by tferic＠swissonline.ch 12 Nov '20

12 Nov '20

Hi Today, I upgraded oVirt from 4.3 to 4.4.3. After the upgrade, I upgraded the compatibility from 4.3 to 4.4. I noticed that the cluster config is offering me another upgrade of the compatibility to version 4.5. Up until now, I was under the impression that the compatibility version must match the oVirt version. I am now reluctant to upgrade the compatibility to 4.5, while my oVirt version is still at 4.4 (there is no oVirt 4.5 at this time). Is it safe to upgrade the compatibility in any case, or are there certain circumstances, where we should refrain from upgrading it? I wasn't able to find anything in the documentation. Kind regards Toni Feric

4 3

Re: sshd_config AuthorizedKeysFile
by Yedidyah Bar David 12 Nov '20

12 Nov '20

On Thu, Nov 12, 2020 at 10:01 AM Angus Clarke <angus(a)charworth.com> wrote: > > Hello > > Sharing for anyone who needs it, this was carried out on OL7, they use ovirt 4.3 > > In short: both the hosted-engine deployment routine and the host add to cluster routine distribute public ssh keys to /root/.ssh/authorized_keys regardless of the AuthorizedKeysFile setting in /etc/ssh/sshd_config. Both routines fail if AuthorizedKeysfile is not default. > > > The hosted-engine setup assumes AuthorizedKeysFile to be default (~/.ssh/authorized_keys) and creates a public key there, instead of following the sshd_config directive. The setup fails on the back of this. > > Once I commented this out of sshd_config file (assumes default) and restarted sshd on the KVM host that was running the hosted-engine deployment, the hosted-engine setup completed successfully. > > > Similarly, I could not deploy a second KVM host to the compute cluster until I had altered this setting on that 2nd KVM host - presumably that process has some similar routine that unwittingly writes keys to ~/.ssh/authorized_keys. Thanks for the report. Would you like to open one or two bugs about this? I think it's just bug, though - from searching relevant source - in the code adding a host to the engine. This code is also used during hosted-engine deploy. We also have code there to add lines to this file on the appliance (engine vm image), but I do not believe users will work so hard as to update the image before deploy. So one bug is probably enough. To make sure, please include there all relevant details about how "they" (your customer?) configure their machines - e.g. is it only during their installation (image/PXE/etc.) or also routinely (puppet etc.) I admit I am not sure what the expected behavior should be, though: An admin can run sshd with a custom file. So should we also check that? Perhaps it's enough if we allow the admin to set a custom location also for oVirt, instead of trying to guess. And make sure that the failure error message is clear and unique enough so that people searching the net for it find your bug, so can find how to configure it :-) Best regards, -- Didi

1 0

sshd_config AuthorizedKeysFile
by Angus Clarke 12 Nov '20

12 Nov '20

Hello Sharing for anyone who needs it, this was carried out on OL7, they use ovirt 4.3 In short: both the hosted-engine deployment routine and the host add to cluster routine distribute public ssh keys to /root/.ssh/authorized_keys regardless of the AuthorizedKeysFile setting in /etc/ssh/sshd_config. Both routines fail if AuthorizedKeysfile is not default. The hosted-engine setup assumes AuthorizedKeysFile to be default (~/.ssh/authorized_keys) and creates a public key there, instead of following the sshd_config directive. The setup fails on the back of this. Once I commented this out of sshd_config file (assumes default) and restarted sshd on the KVM host that was running the hosted-engine deployment, the hosted-engine setup completed successfully. Similarly, I could not deploy a second KVM host to the compute cluster until I had altered this setting on that 2nd KVM host - presumably that process has some similar routine that unwittingly writes keys to ~/.ssh/authorized_keys. HTH Angus

1 0

Upgrade OVIRT from 3.6 to 4.3
by Miguel Angel Costas 12 Nov '20

12 Nov '20

Hi Guys! I need to upgrade from 3.6 to 4.3 and I have a doubt. Do I need to restard VMs for each upgrade (DC Compatibilty 1° 4.0 - 2° 4.1 - 3° 4.2 and 4° 4.3) or can modify the compatibilty from 3.6 to 4.2 and restart the vms in this only step. Best regards

2 1

Adding iscsi issue 4.3
by thilburn＠generalpacific.com 11 Nov '20

11 Nov '20

When connecting an iscsi connection from an array I get the following popup "A database error occurred. Please contact your system administrator." I have checked everything and the only device connected right now is the single host in the datacenter. If I check the box " Approve operation" and click Ok it will error out with "A database error occurred. Please contact your system administrator." This is a new volume and no other machine is connected to this LUN or array. Below is from the vdsm log 2020-11-11 10:42:26,087-0800 INFO (jsonrpc/0) [vdsm.api] START getDeviceList(storageType=3, guids=[u'32021001378a6ddad'], checkStatus=True, options={}) from=::ffff:XXXXXX,46208, flow_id=d09dbfd6-2256-48ad-8597-b6c581def1fd, task_id=67c17255-3ffb-4e8b-b6d3-a4e40836d12c (api:48) 2020-11-11 10:42:26,650-0800 INFO (jsonrpc/0) [storage.LVM] Overriding read_only mode current=True override=False (lvm:398) 2020-11-11 10:42:26,822-0800 INFO (jsonrpc/0) [vdsm.api] FINISH getDeviceList return={'devList': [{'status': 'used', 'vendorID': 'ETIUSA', 'capacity': '3999688294400', 'fwrev': '10E', 'discard_zeroes_data': 0, 'vgUUID': '', 'pvsize': '', 'pathlist': [{'connection': u'10.87.172.100', 'iqn': u'XXXXXX.XXXXXX.XXXXXX:storage3', 'portal': '0', 'port': '3260', 'initiatorname': u'default'}], 'logicalblocksize': '512', 'discard_max_bytes': 0, 'pathstatus': [{'type': 'iSCSI', 'physdev': 'sdc', 'capacity': '3999688294400', 'state': 'active', 'lun': '0'}], 'devtype': 'iSCSI', 'physicalblocksize': '512', 'pvUUID': '', 'serial': 'SETIUSA_UltraStorRS8IP4_2021001378A6DDAD', 'GUID': '32021001378a6ddad', 'productID': 'UltraStorRS8IP4'}]} from=::ffff:XXXXX,46208, flow_id=d09dbfd6-2256-48ad-8597-b6c581def1fd, task_id=67c17255-3ffb-4e8b-b6d3-a4e40836d12c (api:54) 2020-11-11 10:42:26,823-0800 INFO (jsonrpc/0) [jsonrpc.JsonRpcServer] RPC call Host.getDeviceList succeeded in 0.74 seconds (__init__:312) 2020-11-11 10:42:27,158-0800 INFO (jsonrpc/2) [api.host] START getAllVmStats() from=::1,48480 (api:48) 2020-11-11 10:42:27,159-0800 INFO (jsonrpc/2) [api.host] FINISH getAllVmStats return={'status': {'message': 'Done', 'code': 0}, 'statsList': (suppressed)} from=::1,48480 (api:54) 2020-11-11 10:42:27,159-0800 INFO (jsonrpc/2) [jsonrpc.JsonRpcServer] RPC call Host.getAllVmStats succeeded in 0.00 seconds (__init__:312) 2020-11-11 10:42:27,393-0800 INFO (jsonrpc/1) [api.host] START getAllVmStats() from=::ffff:XXXXX,46208 (api:48) 2020-11-11 10:42:27,394-0800 INFO (jsonrpc/1) [api.host] FINISH getAllVmStats return={'status': {'message': 'Done', 'code': 0}, 'statsList': (suppressed)} from=::ffff:XXXXX,46208 (api:54) 2020-11-11 10:42:27,394-0800 INFO (jsonrpc/1) [jsonrpc.JsonRpcServer] RPC call Host.getAllVmStats succeeded in 0.00 seconds (__init__:312) 2020-11-11 10:43:12,323-0800 INFO (jsonrpc/6) [vdsm.api] START createVG(vgname=u'35e95355-75db-4640-bf99-e576b9ce39aa', devlist=[u'32021001378a6ddad'], force=True, options=None) from=::ffff:XXXXX,46208, flow_id=2c973734, task_id=91f2ab5b-017a-4c88-aa45-ece3bd920ce0 (api:48) 2020-11-11 10:43:12,348-0800 INFO (jsonrpc/6) [storage.LVM] Overriding read_only mode current=True override=False (lvm:398) 2020-11-11 10:43:12,409-0800 INFO (jsonrpc/4) [api.host] START getAllVmStats() from=::ffff:XXXXXX,46208 (api:48) 2020-11-11 10:43:12,410-0800 INFO (jsonrpc/4) [api.host] FINISH getAllVmStats return={'status': {'message': 'Done', 'code': 0}, 'statsList': (suppressed)} from=::ffff:XXXXXXX,46208 (api:54) 2020-11-11 10:43:12,410-0800 INFO (jsonrpc/4) [jsonrpc.JsonRpcServer] RPC call Host.getAllVmStats succeeded in 0.00 seconds (__init__:312) 2020-11-11 10:43:12,520-0800 ERROR (jsonrpc/6) [storage.LVM] pvcreate failed with rc=5 (lvm:988) 2020-11-11 10:43:12,520-0800 ERROR (jsonrpc/6) [storage.LVM] [], [' Device /dev/mapper/32021001378a6ddad excluded by a filter.'] (lvm:989) 2020-11-11 10:43:12,520-0800 INFO (jsonrpc/6) [vdsm.api] FINISH createVG error=Failed to initialize physical device: ("[u'/dev/mapper/32021001378a6ddad']",) from=::ffff:XXXXXX,46208, flow_id=2c973734, task_id=91f2ab5b-017a-4c88-aa45-ece3bd920ce0 (api:52) 2020-11-11 10:43:12,520-0800 ERROR (jsonrpc/6) [storage.TaskManager.Task] (Task='91f2ab5b-017a-4c88-aa45-ece3bd920ce0') Unexpected error (task:875) Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/vdsm/storage/task.py", line 882, in _run return fn(*args, **kargs) File "<string>", line 2, in createVG File "/usr/lib/python2.7/site-packages/vdsm/common/api.py", line 50, in method ret = func(*args, **kwargs) File "/usr/lib/python2.7/site-packages/vdsm/storage/hsm.py", line 2146, in createVG force=force) File "/usr/lib/python2.7/site-packages/vdsm/storage/lvm.py", line 1256, in createVG _initpvs(pvs, metadataSize, force) File "/usr/lib/python2.7/site-packages/vdsm/storage/lvm.py", line 990, in _initpvs raise se.PhysDevInitializationError(str(devices)) PhysDevInitializationError: Failed to initialize physical device: ("[u'/dev/mapper/32021001378a6ddad']",) 2020-11-11 10:43:12,520-0800 INFO (jsonrpc/6) [storage.TaskManager.Task] (Task='91f2ab5b-017a-4c88-aa45-ece3bd920ce0') aborting: Task is aborted: 'Failed to initialize physical device: ("[u\'/dev/mapper/32021001378a6ddad\']",)' - code 601 (task:1181) 2020-11-11 10:43:12,521-0800 ERROR (jsonrpc/6) [storage.Dispatcher] FINISH createVG error=Failed to initialize physical device: ("[u'/dev/mapper/32021001378a6ddad']",) (dispatcher:83) 2020-11-11 10:43:12,521-0800 INFO (jsonrpc/6) [jsonrpc.JsonRpcServer] RPC call LVMVolumeGroup.create failed (error 601) in 0.20 seconds (__init__:312)

1 1

Dependencies failure when upgrading from version 4.4.2 to 4.4.3
by jorgevisentini＠gmail.com 11 Nov '20

11 Nov '20

When I update the Engine and Host, many dependencies are missing, as shown by the host error log: Error: Problem 1: package ovirt-hosted-engine-setup-2.4.6-1.el8.noarch requires ovirt-ansible-engine-setup >= 1.1.9, but none of the providers can be installed - package ovirt-ansible-collection-1.2.1-1.el8.noarch obsoletes ovirt-ansible-engine-setup provided by ovirt-ansible-engine-setup-1.2.4-1.el8.noarch - cannot install the best update candidate for package ovirt-hosted-engine-setup-2.4.6-1.el8.noarch - cannot install the best update candidate for package ovirt-ansible-engine-setup-1.2.4-1.el8.noarch Problem 2: package ovirt-host-4.4.1-4.el8.x86_64 requires ovirt-hosted-engine-setup, but none of the providers can be installed - package ovirt-hosted-engine-setup-2.4.6-1.el8.noarch requires ovirt-ansible-hosted-engine-setup >= 1.0.34, but none of the providers can be installed - package ovirt-ansible-collection-1.2.1-1.el8.noarch obsoletes ovirt-ansible-hosted-engine-setup provided by ovirt-ansible-hosted-engine-setup-1.1.8-1.el8.noarch - cannot install the best update candidate for package ovirt-host-4.4.1-4.el8.x86_64 - cannot install the best update candidate for package ovirt-ansible-hosted-engine-setup-1.1.8-1.el8.noarch - package ovirt-ansible-hosted-engine-setup-1.1.4-1.el8.noarch is filtered out by exclude filtering - package ovirt-ansible-hosted-engine-setup-1.1.5-1.el8.noarch is filtered out by exclude filtering - package ovirt-ansible-hosted-engine-setup-1.1.6-1.el8.noarch is filtered out by exclude filtering - package ovirt-ansible-hosted-engine-setup-1.1.7-1.el8.noarch is filtered out by exclude filtering - package ovirt-hosted-engine-setup-2.4.4-1.el8.noarch is filtered out by exclude filtering - package ovirt-hosted-engine-setup-2.4.5-1.el8.noarch is filtered out by exclude filtering - package ovirt-hosted-engine-setup-2.4.7-1.el8.noarch is filtered out by exclude filtering - package ovirt-hosted-engine-setup-2.4.8-1.el8.noarch is filtered out by exclude filtering (try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)

3 3

Single Node HCI upgrade procedure from CentOS7/oVirt 4.3 to CentOS8/oVirt 4.4?
by thomas＠hoberg.net 11 Nov '20

11 Nov '20

I can hear you saying: "You did understand that single node HCI is just a toy, right?" For me the primary use of a single node HCI is adding some disaster resilience in small server edge type scenarios, where a three node HCI provides the fault tolerance: 3+1 with a bit of distance, warm or even cold stand-by, potentially manual switch and reduced workload in case disaster strikes. Of course, another 3nHCI would be better, but who gets that type of budget, right? What I am trying say: If you want oVirt to gain market share, try to give HCI more love. And while you're at it, try to make expanding from 1nHCI to 3nHCI (and higher counts) a standard operational procedure to allow expanding a disaster stand-by into a production setup, while the original 3nHCI is being rebuilt. For me low-budget HCI is where oVirt has its biggest competitive advantage against vSan and Nutanix, so please don't treat the HCI/gluster variant like an unwanted child any more. In the mean-time OVA imports (from 4.3.10 exports) on my 4.4.2 1nHCI fail again, which I'll report separately.

2 1

Upgrade Problem oVirt engine 4.4.1.8-1.el8 -> 4.4.3
by Andrei Verovski 11 Nov '20

11 Nov '20

Hi ! I’m trying to upgrade oVirt engine 4.4.1.8-1.el8 to the latest 4.4.3, running as KVM appliance (not hosted engine). This sequence of commands yum install https://resources.ovirt.org/pub/yum-repo/ovirt-release44.rpm engine-upgrade-check yum update ovirt\*setup\* Results in a long list of dependency errors, short excerpt below. Looks like something (e.g. repo) is missing. How to fix this? Thanks in advance. ————— LOG ---------- Problem 1: problem with installed package ovirt-engine-ui-extensions-1.2.2-1.el8.noarch - package ovirt-engine-ui-extensions-1.2.2-1.el8.noarch requires ovirt-ansible-cluster-upgrade >= 1.1.12, but none of the providers can be installed Problem 2: package ovirt-engine-4.4.1.8-1.el8.noarch requires ovirt-engine-ui-extensions >= 1.0.4, but none of the providers can be installed - package ovirt-engine-ui-extensions-1.2.2-1.el8.noarch requires ovirt-ansible-cluster-upgrade >= 1.1.12, but none of the providers can be installed - package ovirt-engine-4.4.1.8-1.el8.noarch requires ovirt-ansible-roles >= 1.2.0, but none of the providers can be installed - package ovirt-ansible-collection-1.2.1-1.el8.noarch obsoletes ovirt-ansible-cluster-upgrade provided by ovirt-ansible-cluster-upgrade-1.2.3-1.el8.noarch

3 3

Cluster with Hosted Engine update BIOS Setting Ovirt 4.4.3
by scrik787＠gmail.com 11 Nov '20

11 Nov '20

I changed the type in the cluster and now my hosted-engine machine won't start!. There are no backups. How can I manually change the parameters of the machine from under the roof so that it starts and I can restore ovirt to work Error in logs: XML error: The device at PCI address 0000:00:02.0 cannot be plugged into the PCI controller with index='0'. It requires a controller that accepts a pcie-root-port VDSM.log https://pastebin.com/vsAKy9rX

2 1

Host NonResponsive after migration to oVirt 4.4
by tferic＠swissonline.ch 11 Nov '20

11 Nov '20

Hi I am looking for help after my oVirt upgrade failed. I have upgraded from ovirt 4.3 to 4.4 following the instructions here: https://www.ovirt.org/documentation/upgrade_guide/#Upgrading_from_4-3 <https://www.ovirt.org/documentation/upgrade_guide/#Upgrading_from_4-3> It's a single-host (standalone engine) test environment. I wiped CentOS 7 and reinstalled a fresh CentOS 8. I installed the oVirt 4.4 repo and all the necessary software packets. I used `engine-backup --mode=restore --file=/tmp/ovirt-engine-pre-upgrade.backup --provision-all-databases` from a backup file I created before I started the upgrade. After the restore, I ran `engine-setup`. I did not get any errors during any of these steps on the console. So the upgrade could be considered successful from that perspective. After the upgrade, I login to the ovirt admin portal, and I try to "Activate" my host (was set to "Maintenance" mode before upgrade). The Activation fails with error "NonResponsive" in the GUI. Under the "bell" icon, I find the Event "Host nuc1.feric.ch is non responsive.” In /var/log/ovirt-engine/engine.log, I find the following error: ``` 2020-11-09 23:12:21,080+01 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.GetCapabilitiesAsyncVDSCommand] (EE-ManagedScheduledExecutorService-engineScheduledThreadPool-Thread-47) [] Command 'GetCapabilitiesAsyncVDSCommand(HostName = nuc1.feric.ch, VdsIdAndVdsVDSCommandParametersBase:{hostId='d7c30cc0-ac59-4cf3-a1e7-b9fae9db83fb', vds=‘Host[nuc1.feric.h,d7c30cc0-ac59-4cf3-a1e7-b9fae9db83fb]'})' execution failed: java.net.ConnectException: Connection refused ``` `systemctl status ovirt-engine` shows that the engine is running. I am able to reboot the host from the oVirt GUI directly. Does anyone have an idea how to proceed? Many thanks Toni

3 7