- Users - oVirt List Archives

Re: Cluster compatibility version 4.5 on oVirt 4.4
by Christopher Law 12 Nov '20

12 Nov '20

I should have pointed out that in my case the hosted engine failed to install. After the Local VM came up the host was marked as non-operational because the cluster (which I had given a custom name via ansible input) was set to compatibility 4.5 and was not changeable. No idea why the cluster was created at 4.5 if that is not supposed to be available yet or marked for some sort of future release. This caused the host to be non-operational with a warning that the “host” needed upgrading, so perhaps it’s a slightly different issue to that faced below. If you have faced this issue though I would appreciated some advice on how to resolve it. I noticed the default cluster was marked as 4.4. My plan is therefore to re-install the hosted engine and use the “Default” datacentre and cluster names and changes these later. From: Christopher Law <chris(a)chrislaw.me> Sent: 12 November 2020 09:21 To: Ritesh Chikatwar <rchikatw(a)redhat.com>; shadow emy <shadow.emy1(a)gmail.com> Cc: users <users(a)ovirt.org> Subject: [ovirt-users] Re: Cluster compatibility version 4.5 on oVirt 4.4 I’ve also faced this issue, which is surprising since I used an ovirt node download for 4.4. How did you resolve it? How can you upgrade to CentOS 8.3 or downgrade the cluster? Thanks, Chris. From: Ritesh Chikatwar <rchikatw(a)redhat.com<mailto:rchikatw@redhat.com>> Sent: 12 November 2020 05:10 To: shadow emy <shadow.emy1(a)gmail.com<mailto:shadow.emy1@gmail.com>> Cc: users <users(a)ovirt.org<mailto:users@ovirt.org>> Subject: [ovirt-users] Re: Cluster compatibility version 4.5 on oVirt 4.4 Hello, To upgrade to cluster 4.5 you need a 8.3 host. I guess still CentOS 8.3 is not available. I am not sure on CentOS 8.3 availability. If it's available please make sure your host is upgraded to 8.3 . On Thu, Nov 12, 2020, 5:38 AM shadow emy <shadow.emy1(a)gmail.com<mailto:shadow.emy1@gmail.com>> wrote: Just to confirm i face similar problem. Yes i saw that warning too : "Upgrade Cluster Compatibility Level" to upgrade the Cluster to version 4.5. Though when i try to do that there are a lot of errors. In GUI : Error while executing action: Cannot change Cluster Compatibility Version to higher version when there are active Hosts with lower version. -Please move Host host1, host2, host3 with lower version to maintenance first. In engine.log : WARN [org.ovirt.engine.core.bll.UpdateClusterCommand] (default task-163) [2c681b74-8666-4f2f-b2e0-6b20e98f417e] Validation of action 'UpdateCluster' failed for user admin@internal-authz. Reasons: VAR__TYPE__CLUSTER,VAR__ACTION__UPDATE,$host host1, host2, host3,CLUSTER_CANNOT_UPDATE_COMPATIBILITY_VERSION_WITH_LOWER_HOSTS I did not find any documentation for 4.5 cluster compatibility, so i like as well to understand why is that option present there. It will be used when ovirt 4.5.x will be released ? _______________________________________________ Users mailing list -- users(a)ovirt.org<mailto:users@ovirt.org> To unsubscribe send an email to users-leave(a)ovirt.org<mailto:users-leave@ovirt.org> Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/3UGQ6HPT2HTEG…

1 0

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 11 Nov '20

11 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