[ovirt-users] Re: Newbie Questions

[Dominik Holler]

On Mon, Nov 18, 2019 at 10:32 PM Dirk Streubel 
wrote:

> Hi,
>
> thanks a lot for the quick answers. So, my Server Management will run on
> another machine, not a pi4 :)
>
> But i have still the problem with the integration with a host. Always the
> same error of the host side.
>
> Maybe my hardware is to old for ovirt, but i'am not sure.  I send an
> attachment with the log file of the host integration, maybe somebody can
> read an and tell me what my fault is.
>

The relevant error is:
'Cannot locate ovirt-host package, '

Should be there, if
https://resources.ovirt.org/pub/yum-repo/ovirt-release43.rpm is installed.
Is this step is missing in the doc you follow?


Regards
>
> Dirk
>
>
>
>
>
> Am 18.11.19 um 11:23 schrieb Yedidyah Bar David:
>
> On Mon, Nov 18, 2019 at 10:52 AM Pavol Brilla  wrote:
>
>> Hi,
>>
>> just to clarify 1 question - RPI4 = Cortex A72 CPU, ovirt engine is x86,
>> so no it is not possible
>>
>
> Indeed it's not supported. But actually, engine itself is java, and most
> of the other supplemental code involved is python. I guess most of the work
> to support it would be in packaging all the dependencies.
>
> If you intend to work on this, you should probably start either by adding
> Fedora support to rpi4 ([1] says it's not supported currently) or by
> porting the engine to some other distribution supported on it. There was
> interest some time ago on porting to Debian, but not sure about current
> status. oVirt project itself only ships for Fedora and CentOS.
>
> [1] https://fedoraproject.org/wiki/Architectures/ARM/Raspberry_Pi
>
>
>>
>> On Sun, Nov 17, 2019 at 11:20 AM Dirk Streubel 
>> wrote:
>>
>>> Hello,
>>>
>>> i'am a new user and i have a few questions, maybe somebody can Help.
>>>
>>> It is possible to install the Server Management on a Raspberry PI 4 with
>>> 4GB.  I find in the official Re Hat Document "Red Hat Virtualization
>>> Manager Hardware Requirements" that 4GB RAM is enough.
>>> And the PI has a 128 GB Flash Card. Would it work? Have somebody tested
>>> it?
>>>
>>> Another Question: Since yesterday i am trying to ad a host in my
>>> environment on ovirt Version 4.3.6. My Server Management runs under
>>> Fedora 31 under KVM/Virt-Manager without any problems.
>>> Adding a new Host doesn't work. I have tried to ad another VM with 8
>>> Cores and 32 GB RAM as a host. This is not working, maybe VMs in VMs
>>> under ovirt is not possible, i don't know.
>>> So i try  a physical Machine here as a Host. This and the other
>>> Installations fails with the Information: no route to Host. I found a
>>> bug and it says that the bug is closed.
>>> In the bug stand that maybe something wrong with the openvswitch. So i
>>> tried the following commands on the Server Management: ovn-nbctl show
>>> and ovn-sbctl show and the output was nothing.
>>> journalctl -xfe on the host that i want to migrate gave my the output:
>>>
>>> Nov 17 10:30:38 hypervisor1.linux.fritz.box sshd[12632]: Accepted
>>> keyboard-interactive/pam for root from 10.2.0.99 port 43260 ssh2
>>> Nov 17 10:30:38 hypervisor1.linux.fritz.box systemd-logind[960]: New
>>> session 5 of user root.
>>> -- Subject: A new session 5 has been created for user root
>>> -- Defined-By: systemd
>>> -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>>> -- Documentation:
>>> http://www.freedesktop.org/wiki/Software/systemd/multiseat
>>> --
>>> -- A new session with the ID 5 has been created for the user root.
>>> --
>>> -- The leading process of the session is 12632.
>>> Nov 17 10:30:38 hypervisor1.linux.fritz.box sshd[12632]:
>>> pam_unix(sshd:session): session opened for user root by (uid=0)
>>> Nov 17 10:30:38 hypervisor1.linux.fritz.box systemd[1]: Started Session
>>> 5 of user root.
>>> -- Subject: Unit session-5.scope has finished start-up
>>> -- Defined-By: systemd
>>> -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>>> --
>>> -- Unit session-5.scope has finished starting up.
>>> --
>>> -- The start-up result is done.
>>> Nov 17 10:30:39 hypervisor1.linux.fritz.box sshd[12632]:
>>> pam_unix(sshd:session): session closed for user root
>>> Nov 17 10:30:39 hypervisor1.linux.fritz.box systemd-logind[960]: Removed
>>> session 5.
>>> -- Subject: Session 5 has been terminated
>>> -- Defined-By: systemd
>>> -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>>> -- Documentation:
>>> http://www.freedesktop.org/wiki/Software/systemd/multiseat
>>> --
>>> -- A session with the ID 5 has been terminated.
>>> Nov 17 10:30:39 hypervisor1.linux.fritz.box sshd[12654]: Accepted
>>> keyboard-interactive/pam for root from 10.2.0.99 port 43264 ssh2
>>> Nov 17 10:30:39 hypervisor1.linux.fritz.box systemd-logind[960]: New
>>> session 6 of user root.
>>> -- Subject: A new session 6 has been created for user root
>>> -- Defined-By: systemd
>>> -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>>> -- Documentation:
>>> 

[ovirt-users] Re: Newbie Thin Client question

[Mathieu Simon]

Hi

Am Di., 19. Nov. 2019 um 21:32 Uhr schrieb Joseph Jackson
:
>
> Yes you can.  The ovirt VM portal gives you the ability to run a virtual 
> desktop.You can use any client that supports the console protocols like 
> VNC or spice.
While you can and SPICE does a reasonable job at being quite
well-suited, please be aware that it does reach its limits
when you do media intensive work.

There is a reason why my workplace has dropped virtual desktops as a
service (if you want to call it that) on oVirt.
It didn't scale very well in terms of latency and had issues with
media streaming like Youtube.

I could imagine that it could work reasonably well in an office
environment, but not in education for what I can tell.

Regards,
Mathieu
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@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/I7XN5NUWQRWMMIDUBUPH2RRQISHJHEYA/

[ovirt-users] Re: Newbie Thin Client question

[Joseph Jackson]

Yes you can.  The ovirt VM portal gives you the ability to run a virtual 
desktop.You can use any client that supports the console protocols like VNC 
or spice.



-Original Message-
From: cre...@gmail.com [mailto:cre...@gmail.com] 
Sent: Tuesday, November 19, 2019 9:32 AM
To: users@ovirt.org
Subject: [ovirt-users] Newbie Thin Client question

I am new to this whole technology and I can't find anything about thin clients. 
I was wondering if I can even use oVirt with a thin client, if anyone knows how 
help would be much appreciated. I am also wondering if there is a way to use a 
Raspberry Pi as a thin client.
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@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/UQ3XS7LWG3LPZRTDNSRHGPGTA4TYCXV3/
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@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/ETNMEKKQGTHWHRADDOHNYUJICGVNSG5V/

[ovirt-users] Re: terraform integration

[Nathanaël Blanchet]

Le 19/11/2019 à 13:43, Roy Golan a écrit :



On Tue, 19 Nov 2019 at 14:34, Nathanaël Blanchet > wrote:


Le 19/11/2019 à 08:55, Roy Golan a écrit :

oc get -o json clusterversion


This is the output of the previous failed deployment, I'll give a
try to a newer one when I'll have a minute to test

Without changing nothing with template,  I gave a new try and... nothing 
works anymore now, none of provided IPs can be pingued : dial tcp 
10.34.212.51:6443: connect: no route to host", so none of masters can be 
provisonned by bootstrap.


I tried with the latest rhcos and latest ovirt 4.3.7, it is the same. 
Obviously something changed since my first attempt 12 days ago... is 
your docker image for openshift-installer up to date?


Are you still able to your side to deploy a valid cluster ?


(do I need to use the terraform-workers tag instead of latest?)

docker pullquay.io/rgolangh/openshift-installer:terraform-workers  



[root@openshift-installer
openshift-origin-client-tools-v3.11.0-0cbc58b-linux-64bit]# ./oc
get -o json clusterversion
{
    "apiVersion": "v1",
    "items": [
    {
    "apiVersion": "config.openshift.io/v1
",
    "kind": "ClusterVersion",
    "metadata": {
    "creationTimestamp": "2019-11-07T12:23:06Z",
    "generation": 1,
    "name": "version",
    "namespace": "",
    "resourceVersion": "3770202",
    "selfLink":
"/apis/config.openshift.io/v1/clusterversions/version
",
    "uid": "77600bba-6e71-4b35-a60b-d8ee6e0f545c"
    },
    "spec": {
    "channel": "stable-4.3",
    "clusterID": "6f87b719-e563-4c0b-ab5a-1144172bc983",
    "upstream":
"https://api.openshift.com/api/upgrades_info/v1/graph;

    },
    "status": {
    "availableUpdates": null,
    "conditions": [
    {
    "lastTransitionTime": "2019-11-07T12:23:12Z",
    "status": "False",
    "type": "Available"
    },
    {script
    "lastTransitionTime": "2019-11-07T12:56:15Z",
    "message": "Cluster operator
image-registry is still updating",
    "reason": "ClusterOperatorNotAvailable",
    "status": "True",
    "type": "Failing"
    },
    {
    "lastTransitionTime": "2019-11-07T12:23:12Z",
    "message": "Unable to apply
4.3.0-0.okd-2019-10-29-180250: the cluster operator image-registry
has not yet successfully rolled out",
    "reason": "ClusterOperatorNotAvailable",
    "status": "True",
    "type": "Progressing"
    },
    {
    "lastTransitionTime": "2019-11-07T12:23:12Z",
    "message": "Unable to retrieve available
updates: currently installed version 4.3.0-0.okd-2019-10-29-180250
not found in the \"stable-4.3\" channel",
    "reason": "RemoteFailed",
    "status": "False",
    "type": "RetrievedUpdates"
    }
    ],
    "desired": {
    "force": false,
    "image":

"registry.svc.ci.openshift.org/origin/release@sha256:68286e07f7d68ebc8a067389aabf38dee9f9b810c5520d6ee4593c38eb48ddc9

",
    "version": "4.3.0-0.okd-2019-10-29-180250"


Indeed this version is not the latest and is missing the 
aforementioned fix for the registry.


    },
    "history": [
    {
    "completionTime": null,
    "image":

"registry.svc.ci.openshift.org/origin/release@sha256:68286e07f7d68ebc8a067389aabf38dee9f9b810c5520d6ee4593c38eb48ddc9

",
    "startedTime": "2019-11-07T12:23:12Z",
    "state": "Partial",
    "verified": false,
 

[ovirt-users] Newbie Thin Client question

[crege7]

I am new to this whole technology and I can't find anything about thin clients. 
I was wondering if I can even use oVirt with a thin client, if anyone knows how 
help would be much appreciated. I am also wondering if there is a way to use a 
Raspberry Pi as a thin client.
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@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/UQ3XS7LWG3LPZRTDNSRHGPGTA4TYCXV3/

[ovirt-users] Re: metrics

[suporte]

Hello, 

Still cannot find it. 

# echo $ANSIBLE_DEBUG 
1 

I just find this: 

2019-11-19 16:25:50,264 p=root u=6462 | ok: [localhost] 
2019-11-19 16:25:50,296 p=root u=6462 | TASK 
[/usr/share/ansible/roles/oVirt.metrics/roles/oVirt.origin-on-ovirt : Collect 
oVirt VM facts]  
2019-11-19 16:30:54,647 p=root u=6462 | fatal: [localhost]: FAILED! => 
{"attempts": 5, "censored": "the output has been hidden due to the fact that 
'no_log: true' was specified for this result", "changed": false} 
2019-11-19 16:30:54,679 p=root u=6462 | TASK 
[/usr/share/ansible/roles/oVirt.metrics/roles/oVirt.origin-on-ovirt : Logout 
from oVirt] * 
2019-11-19 16:30:55,074 p=root u=6462 | ok: [localhost] 
2019-11-19 16:30:55,107 p=root u=6462 | TASK 
[oVirt.metrics/roles/oVirt.metrics-store-installation : Delete 
engine_id_rsa.pub] 
 


Maybe I'm missing something? 


De: "Shirly Radco"  
Para: supo...@logicworks.pt 
Cc: "Jayme" , "users"  
Enviadas: Terça-feira, 19 De Novembro de 2019 14:01:20 
Assunto: Re: [ovirt-users] Re: metrics 

Hi, 

Did you try running the playbook with the ANSIBLE_DEBUG=1 ? It should show you 
the issue in the log that 
is located under /var/log/ovirt-engine/ansible/ . 
Best, 
Shirly 


On Mon, Nov 18, 2019 at 7:56 PM < supo...@logicworks.pt > wrote: 



Hello, 

I attached the log. Cannot figure it out where is the issue. 

Any idea? 

Thanks 

José 


De: "Shirly Radco" < sra...@redhat.com > 
Para: supo...@logicworks.pt 
Cc: "Jayme" < jay...@gmail.com >, "users" < users@ovirt.org > 
Enviadas: Segunda-feira, 18 De Novembro de 2019 10:24:28 
Assunto: Re: [ovirt-users] Re: metrics 


-- 





Shirly Radco 

BI Principal Software Engineer 

Red Hat 







On Fri, Nov 15, 2019 at 7:34 PM < supo...@logicworks.pt > wrote: 

BQ_BEGIN

Ok, found this https://github.com/oVirt/ovirt-ansible-image-template/pull/47 
and change 

retries: "{{ (disk_resize_timeout / 3) | int }}" 
delay: 3 

to 

retries: 60 
delay: 3 

in 
/usr/share/ansible/roles/ovirt.image-template/tasks/qcow2_image.yml 

but now I'm stuck in here: 

TASK [/usr/share/ansible/roles/oVirt.metrics/roles/oVirt.origin-on-ovirt : 
Collect oVirt VM facts] 
*
 
FAILED - RETRYING: Collect oVirt VM facts (5 retries left). 
FAILED - RETRYING: Collect oVirt VM facts (4 retries left). 
FAILED - RETRYING: Collect oVirt VM facts (3 retries left). 
FAILED - RETRYING: Collect oVirt VM facts (2 retries left). 
FAILED - RETRYING: Collect oVirt VM facts (1 retries left). 
fatal: [localhost]: FAILED! => {"attempts": 5, "censored": "the output has been 
hidden due to the fact that 'no_log: true' was specified for this result", 
"changed": false} 




There is probably something wrong with your engine credentials. 
You try setting ANSIBLE_DEBUG to true to debug this issue. 
ANSIBLE_DEBUG ignores np_log so please keep in mind that your password will be 
readable and you might want to delete the log once you finish. 


BQ_BEGIN



after the creation of metrics-store-installer VM 




De: supo...@logicworks.pt 
Para: "Jayme" < jay...@gmail.com > 
Cc: "users" < users@ovirt.org > 
Enviadas: Sexta-feira, 15 De Novembro de 2019 16:11:25 
Assunto: [ovirt-users] Re: metrics 

Well, I did a mistake when copying the metrics-store-config.yml 

But now I'm getting this error 
.. 
FAILED - RETRYING: Wait for resize (1 retries left) 
fatal: [localhost]: FAILED! => {"attempts": 40, "changed": false, "disk": 
{"actual_size": 942409728, "alias": "centos76", "backup": "none", 
"content_type": "data", 
"description": "", "disk_profile": {"href": 
"/ovirt-engine/api/diskprofiles/13b70c52-8265-4cd2-aac0-3497750bd03b", "id": 
"13b70c52-8265-4cd2-aac0-3497750bd03b"}, 
"format": "cow", "href": 
"/ovirt-engine/api/disks/2abbe5f5-7534-4d6e-bd91-9ce1c135de13", "id": 
"2abbe5f5-7534-4d6e-bd91-9ce1c135de13", "image_id": 
"ad50f9c0-1b07-43fb-bea2-9f38d6e22acd", "name": "centos76", "permissions": [], 
"propagate_errors": false, "provisioned_size": 8589934592, "qcow_version": 
"qcow2_v2", 
"quota": {"href": 
"/ovirt-engine/api/datacenters/e2c375e0-929e-11e9-969e-0013f7d1bb52/quotas/f3f4eefc-929e-11e9-b3a6-0013f7d1bb52",
 "id": 
"f3f4eefc-929e-11e9-b3a6-0013f7d1bb52"}, "shareable": false, "sparse": true, 
"statistics": [], "status": "ok", "storage_domains": 
[{"href": 
"/ovirt-engine/api/storagedomains/156168f1-3905-4514-b7c1-817e39718ba6", "id": 
"156168f1-3905-4514-b7c1-817e39718ba6"}], 
"storage_type": "image", "total_size": 942409728, "wipe_after_delete": false}, 
"id": "2abbe5f5-7534-4d6e-bd91-9ce1c135de13"} 


De: supo...@logicworks.pt 
Para: "Jayme" < jay...@gmail.com > 
Cc: "users" < users@ovirt.org > 
Enviadas: Sexta-feira, 15 De Novembro de 2019 10:29:06 
Assunto: [ovirt-users] Re: metrics 

Hello, 

Still 

[ovirt-users] Re: Ovirt 4.3.6 USB passthrough not working with iommu_intel=on iommu=pt

[Don Dupuis]

with that approach, still get same error.

Don

On Mon, Nov 18, 2019 at 10:49 PM Strahil Nikolov 
wrote:

> I would recommend you to "unpresent" that USB, then replug (if that's
> possible) the USB and then to refresh the hosts's Capabilities (management
> dropdown). Only then try to assign the USB.
>
> Best Regards,
> Strahil Nikolov
>
> В вторник, 19 ноември 2019 г., 05:30:00 ч. Гринуич+2, Don Dupuis <
> donds...@gmail.com> написа:
>
>
> I am trying to pass through a USB Dongle to a Windows virtual machine in
> ovirt 4.3.6. This will work if these options aren't used. Below is the
> output of lsusb with no iommu enable:
>
> Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
> Bus 001 Device 005: ID 1604:10c0 Tascam
> Bus 001 Device 004: ID 1604:10c0 Tascam
> Bus 001 Device 003: ID 1604:10c0 Tascam
> Bus 001 Device 002: ID 07f2:0001 Microcomputer Applications, Inc. KEYLOK II
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>
> The device I am passing through is Bus 001 Device 002.
>
> This is the error I get in vdsmd.log:
>
> Traceback (most recent call last):
>   File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 867, in
> _startUnderlyingVm
> self._run()
>   File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 2890, in
> _run
> self._domDependentInit()
>   File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 2466, in
> _domDependentInit
> self._vmDependentInit()
>   File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 2480, in
> _vmDependentInit
> self._getUnderlyingVmDevicesInfo()
>   File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 2448, in
> _getUnderlyingVmDevicesInfo
> vmdevices.common.update_device_info(self, self._devices)
>   File "/usr/lib/python2.7/site-packages/vdsm/virt/vmdevices/common.py",
> line 94, in update_device_info
> hostdevice.HostDevice.update_device_info(vm, devices[hwclass.HOSTDEV])
>   File
> "/usr/lib/python2.7/site-packages/vdsm/virt/vmdevices/hostdevice.py", line
> 426, in update_device_info
> vm, device_conf, device_xml)
>   File
> "/usr/lib/python2.7/site-packages/vdsm/virt/vmdevices/hostdevice.py", line
> 223, in update_from_xml
> if host_address == dev.hostAddress:
> AttributeError: 'MdevDevice' object has no attribute 'hostAddress'
> 2019-11-18 18:20:06,173-0600 INFO  (vm/9944089c) [virt.vm]
> (vmId='9944089c-2109-4352-a0c6-7d0d9e04bb3f') Changed state to Down:
> 'MdevDevice' object has no attribute 'hostAddress' (code=1) (vm:1690)
>
> I am using kernel 3.10.0-957.12.1.el7.x86_64
>
> vdsm is vdsm-4.30.33-1.el7.x86_64
> libvirt is libvirt-5.0.0-1.el7.x86_64
> qemu is qemu-img-ev-2.12.0-33.1.el7.x86_64
>
> Any help with this issue would be appreciated.
>
> Thanks
> Don
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@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/3JWP5GNYJWH7HDLBDRU3UGGHUENINW4I/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@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/PANWBLPOD5TG3O5TEYXSJKSHNNKS3SKU/

[ovirt-users] Re: metrics

[Shirly Radco]

Hi,

Did you try running the playbook with the ANSIBLE_DEBUG=1 ? It should show
you the issue in the log that
is located under /var/log/ovirt-engine/ansible/ .

Best,

Shirly



On Mon, Nov 18, 2019 at 7:56 PM  wrote:

> Hello,
>
> I attached the log. Cannot figure it out where is the issue.
>
> Any idea?
>
> Thanks
>
> José
>
> --
> *De: *"Shirly Radco" 
> *Para: *supo...@logicworks.pt
> *Cc: *"Jayme" , "users" 
> *Enviadas: *Segunda-feira, 18 De Novembro de 2019 10:24:28
> *Assunto: *Re: [ovirt-users] Re: metrics
>
>
> --
>
>
> Shirly Radco
>
> BI Principal Software Engineer
>
> Red Hat 
>
>
> 
>
>
> On Fri, Nov 15, 2019 at 7:34 PM  wrote:
>
>> Ok, found this
>> https://github.com/oVirt/ovirt-ansible-image-template/pull/47
>> and change
>>
>> retries: "{{ (disk_resize_timeout / 3) | int }}"
>> delay: 3
>>
>> to
>>
>> retries: 60
>> delay: 3
>>
>> in
>> /usr/share/ansible/roles/ovirt.image-template/tasks/qcow2_image.yml
>>
>> but now I'm stuck in here:
>>
>> TASK [/usr/share/ansible/roles/oVirt.metrics/roles/oVirt.origin-on-ovirt
>> : Collect oVirt VM facts]
>> *
>> FAILED - RETRYING: Collect oVirt VM facts (5 retries left).
>> FAILED - RETRYING: Collect oVirt VM facts (4 retries left).
>> FAILED - RETRYING: Collect oVirt VM facts (3 retries left).
>> FAILED - RETRYING: Collect oVirt VM facts (2 retries left).
>> FAILED - RETRYING: Collect oVirt VM facts (1 retries left).
>> fatal: [localhost]: FAILED! => {"attempts": 5, "censored": "the output
>> has been hidden due to the fact that 'no_log: true' was specified for this
>> result", "changed": false}
>>
>
> There is probably something wrong with your engine credentials.
> You try setting ANSIBLE_DEBUG to true to debug this issue.
> ANSIBLE_DEBUG ignores np_log so please keep in mind that your password
> will be readable and you might want to delete the log once you finish.
>
>
>>
>> after the creation of metrics-store-installer VM
>>
>>
>>
>> --
>> *De: *supo...@logicworks.pt
>> *Para: *"Jayme" 
>> *Cc: *"users" 
>> *Enviadas: *Sexta-feira, 15 De Novembro de 2019 16:11:25
>> *Assunto: *[ovirt-users] Re: metrics
>>
>> Well, I did a mistake when copying the metrics-store-config.yml
>>
>> But now I'm getting this error
>> ..
>> FAILED - RETRYING: Wait for resize (1 retries left)
>> fatal: [localhost]: FAILED! => {"attempts": 40, "changed": false, "disk":
>> {"actual_size": 942409728, "alias": "centos76", "backup": "none",
>> "content_type": "data",
>> "description": "", "disk_profile": {"href":
>> "/ovirt-engine/api/diskprofiles/13b70c52-8265-4cd2-aac0-3497750bd03b",
>> "id": "13b70c52-8265-4cd2-aac0-3497750bd03b"},
>> "format": "cow", "href":
>> "/ovirt-engine/api/disks/2abbe5f5-7534-4d6e-bd91-9ce1c135de13", "id":
>> "2abbe5f5-7534-4d6e-bd91-9ce1c135de13", "image_id":
>> "ad50f9c0-1b07-43fb-bea2-9f38d6e22acd", "name": "centos76",
>> "permissions": [], "propagate_errors": false, "provisioned_size":
>> 8589934592, "qcow_version": "qcow2_v2",
>> "quota": {"href":
>> "/ovirt-engine/api/datacenters/e2c375e0-929e-11e9-969e-0013f7d1bb52/quotas/f3f4eefc-929e-11e9-b3a6-0013f7d1bb52",
>> "id":
>> "f3f4eefc-929e-11e9-b3a6-0013f7d1bb52"}, "shareable": false, "sparse":
>> true, "statistics": [], "status": "ok", "storage_domains":
>> [{"href":
>> "/ovirt-engine/api/storagedomains/156168f1-3905-4514-b7c1-817e39718ba6",
>> "id": "156168f1-3905-4514-b7c1-817e39718ba6"}],
>> "storage_type": "image", "total_size": 942409728, "wipe_after_delete":
>> false}, "id": "2abbe5f5-7534-4d6e-bd91-9ce1c135de13"}
>>
>> --
>> *De: *supo...@logicworks.pt
>> *Para: *"Jayme" 
>> *Cc: *"users" 
>> *Enviadas: *Sexta-feira, 15 De Novembro de 2019 10:29:06
>> *Assunto: *[ovirt-users] Re: metrics
>>
>> Hello,
>>
>> Still nothing happens. I'm a little lost here.
>> I'm getting this message when running
>> ./configure_ovirt_machines_for_metrics.sh
>> --playbook=ovirt-metrics-store-installation.yml --
>> ask-vault-pass
>>
>> changed: [localhost -> localhost] => {
>> "msg": "oVirt Metrics store is not configured. This host will not be
>> configured to send metrics"
>> }
>>
>> I think this is the problem?
>> Any idea?
>>
>> Thanks a lot
>>
>> José
>>
>> --
>> *De: *"Jayme" 
>> *Para: *supo...@logicworks.pt
>> *Cc: *"users" 
>> *Enviadas: *Quinta-feira, 14 De Novembro de 2019 18:06:51
>> *Assunto: *Re: [ovirt-users] metrics
>>
>> this should do it:
>> https://cloud.centos.org/centos/7/images/CentOS-7-x86_64-GenericCloud.qcow2
>>
>> On Thu, Nov 14, 2019 at 1:38 PM  wrote:
>>
>>> Ok. I just commented it out and run
>>> # ./configure_ovirt_machines_for_metrics.sh
>>> --playbook=ovirt-metrics-store-installation.yml --ask-vault-pass
>>> PLAY RECAP
>>> **
>>> localhost : ok=5 

[ovirt-users] Re: Wrong CPU?

[Juhani Rautiainen]

Hi!

Had to get back to work to check which CPU we had. We have AMD Epyc
7281 and ovirt CPU Type is AMD EPYC IBPB SSBD. It seems that your CPU
is the next generation (Zen2) and I'm pretty sure that problem is with
Qemu version. As far as I can see from git there is not even Zen2
support in latest Qemu (checking by target/i386/cpu.c)? I mean they
added Hygon Dhyana (never even heard about this chinese AMD EPYC
clone) and in that discussion there was reference to Zen2
architecture. So biggest problem for oVirt seems to come from
upstream. I mean that Zen2 is quite good for virtualization and it's
going to sell a lot. Maybe AMD should help with that push?

-Juhani

On Fri, Nov 15, 2019 at 9:03 PM Christian Reiss
 wrote:
>
> Sorry,
>
> I meant EPYC, not Ryzen.
> How did you solve your EPYC issue?
>
> -Chris.
>
> On 15/11/2019 18:55, Juhani Rautiainen wrote:
> > Hi!
> >
> > It might be that the Qemu in oVirt doesn't recognize the Ryzen. That
> > was case with Epyc when I started using oVirt. It was reconized as a
> > Opteron G2 which caused lot's of problems when upgrading to 4.3.
> >
> > -Juhani
> >
> > On Fri, Nov 15, 2019 at 6:45 PM Christian Reiss
> >  wrote:
> >>
> >> Hey folks,
> >>
> >> running an AMD Ryzen CPU here:
> >>
> >> processor   : 0
> >> vendor_id   : AuthenticAMD
> >> cpu family  : 23
> >> model   : 49
> >> model name  : AMD EPYC 7282 16-Core Processor
> >>
> >> However, libvirt is detecting this as EPYC-IBPB without the ssbd flags?
> >>
> >>   
> >> x86_64
> >> EPYC-IBPB
> >> AMD
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >>   
> >>
> >>
> >> [root@node01 ~]# grep ssbd /var/cache/libvirt/qemu/capabilities/*.xml
> >>   
> >>   
> >>   
> >>   
> >>
> >> But the flag is there:
> >>
> >> [root@node01 ~]# grep ssbd /proc/cpuinfo | tail -n1
> >> flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca 
> >> cmov
> >> pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt
> >> pdpe1gb rdtscp lm constant_tsc art rep_good nopl xtopology nonstop_tsc
> >> extd_apicid aperfmperf eagerfpu pni pclmulqdq monitor ssse3 fma cx16
> >> sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy
> >> svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs
> >> skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_l2 cpb
> >> cat_l3 cdp_l3 hw_pstate sme retpoline_amd ssbd ibrs ibpb stibp vmmcall
> >> fsgsbase bmi1 avx2 smep bmi2 cqm rdt_a rdseed adx smap clflushopt clwb
> >> sha_ni xsaveopt xsavec xgetbv1 cqm_llc cqm_occup_llc cqm_mbm_total
> >> cqm_mbm_local clzero irperf xsaveerptr arat npt lbrv svm_lock nrip_save
> >> tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold
> >> avic v_vmsave_vmload vgif umip overflow_recov succor smca
> >>
> >> I tried adding "options kvm_amd avic=1" as well as "options kvm_amd
> >> avic=0" to /etc/modprobe.d/kvm.conf (always with reboots), adding
> >> mitigations=off to grub.. I can't think of any other solution.
> >>
> >> I just can't get the oVirt engine running with the ssbd flag. Seems cpu
> >> can do this, oVirt can do this, libvirt does not detect the cpu
> >> correctly or at least ignores it. But the hosted engine demands it.
> >>
> >> I am at a loss. Any help is oh-so-greatly appreciated.
> >>
> >> -Chris.
> >>
> >> --
> >>Christian Reiss - em...@christian-reiss.de /"\  ASCII Ribbon
> >>  supp...@alpha-labs.net   \ /Campaign
> >>X   against HTML
> >>WEB alpha-labs.net / \   in eMails
> >>
> >>GPG Retrieval https://gpg.christian-reiss.de
> >>GPG ID ABCD43C5, 0x44E29126ABCD43C5
> >>GPG fingerprint = 9549 F537 2596 86BA 733C  A4ED 44E2 9126 ABCD 43C5
> >>
> >>"It's better to reign in hell than to serve in heaven.",
> >> John Milton, Paradise lost.
> >> ___
> >> Users mailing list -- users@ovirt.org
> >> To unsubscribe send an email to users-le...@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/PPXT55FJZESYOAOPR7HY5LOHTYELWDN6/
> >
> >
> >
>
> --
>   Christian Reiss - em...@christian-reiss.de /"\  ASCII Ribbon
> supp...@alpha-labs.net   \ /Campaign
>   X   against HTML
>   WEB 

[ovirt-users] Re: Unable to attach ISO domain to Datacenter

[ivan]

Follow the content of file /var/log/ovirt-engine/engine.log when I'm trying to 
attach ISO Domain to Datacenter:

2019-11-18 13:32:16,146-03 INFO  
[org.ovirt.engine.core.bll.storage.domain.AttachStorageDomainToPoolCommand] 
(default task-26) [f798-4334-40ca-ba43-e97e4be396db] Lock Acquired to 
object 
'EngineLock:{exclusiveLocks='[e6b34c42-0ca6-41f4-be3e-3c9b2af1747b=STORAGE]', 
sharedLocks=''}'
2019-11-18 13:32:16,241-03 INFO  
[org.ovirt.engine.core.bll.storage.domain.AttachStorageDomainToPoolCommand] 
(EE-ManagedThreadFactory-engine-Thread-178210) 
[f798-4334-40ca-ba43-e97e4be396db] Running command: 
AttachStorageDomainToPoolCommand internal: false. Entities affected :  ID: 
e6b34c42-0ca6-41f4-be3e-3c9b2af1747b Type: StorageAction group 
MANIPULATE_STORAGE_DOMAIN with role type ADMIN,  ID: 
dd2a11c0-f450-11e9-8e3b-0050568ac2b9 Type: StoragePoolAction group 
MANIPULATE_STORAGE_DOMAIN with role type ADMIN
2019-11-18 13:32:16,261-03 INFO  
[org.ovirt.engine.core.bll.storage.connection.ConnectStorageToVdsCommand] 
(EE-ManagedThreadFactory-engine-Thread-178211) [20e44128] Running command: 
ConnectStorageToVdsCommand internal: true. Entities affected :  ID: 
aaa0----123456789aaa Type: SystemAction group 
CREATE_STORAGE_DOMAIN with role type ADMIN
2019-11-18 13:32:16,261-03 INFO  
[org.ovirt.engine.core.bll.storage.connection.ConnectStorageToVdsCommand] 
(EE-ManagedThreadFactory-engine-Thread-178212) [a7f5e93] Running command: 
ConnectStorageToVdsCommand internal: true. Entities affected :  ID: 
aaa0----123456789aaa Type: SystemAction group 
CREATE_STORAGE_DOMAIN with role type ADMIN
2019-11-18 13:32:16,266-03 INFO  
[org.ovirt.engine.core.vdsbroker.vdsbroker.ConnectStorageServerVDSCommand] 
(EE-ManagedThreadFactory-engine-Thread-178212) [a7f5e93] START, 
ConnectStorageServerVDSCommand(HostName = ZeLele, 
StorageServerConnectionManagementVDSParameters:{hostId='86198321-38ff-4596-8c24-2f9442928009',
 storagePoolId='----', storageType='NFS', 
connectionList='[StorageServerConnections:{id='ff0b050c-1b20-41fb-8373-32d9991a327e',
 connection='nholau:/storage/iso', iqn='null', vfsType='null', 
mountOptions='null', nfsVersion='AUTO', nfsRetrans='null', nfsTimeo='null', 
iface='null', netIfaceName='null'}]', sendNetworkEventOnFailure='true'}), log 
id: 2c81e6d5
2019-11-18 13:32:16,266-03 INFO  
[org.ovirt.engine.core.vdsbroker.vdsbroker.ConnectStorageServerVDSCommand] 
(EE-ManagedThreadFactory-engine-Thread-178211) [20e44128] START, 
ConnectStorageServerVDSCommand(HostName = Rosinha, 
StorageServerConnectionManagementVDSParameters:{hostId='a838a3d5-8f52-44cd-a293-e530692814a3',
 storagePoolId='----', storageType='NFS', 
connectionList='[StorageServerConnections:{id='ff0b050c-1b20-41fb-8373-32d9991a327e',
 connection='nholau:/storage/iso', iqn='null', vfsType='null', 
mountOptions='null', nfsVersion='AUTO', nfsRetrans='null', nfsTimeo='null', 
iface='null', netIfaceName='null'}]', sendNetworkEventOnFailure='true'}), log 
id: 482f56e6
2019-11-18 13:32:16,385-03 INFO  
[org.ovirt.engine.core.vdsbroker.vdsbroker.ConnectStorageServerVDSCommand] 
(EE-ManagedThreadFactory-engine-Thread-178211) [20e44128] FINISH, 
ConnectStorageServerVDSCommand, return: 
{ff0b050c-1b20-41fb-8373-32d9991a327e=0}, log id: 482f56e6
2019-11-18 13:32:16,385-03 INFO  
[org.ovirt.engine.core.vdsbroker.vdsbroker.ConnectStorageServerVDSCommand] 
(EE-ManagedThreadFactory-engine-Thread-178212) [a7f5e93] FINISH, 
ConnectStorageServerVDSCommand, return: 
{ff0b050c-1b20-41fb-8373-32d9991a327e=0}, log id: 2c81e6d5
2019-11-18 13:32:16,387-03 INFO  
[org.ovirt.engine.core.vdsbroker.irsbroker.AttachStorageDomainVDSCommand] 
(EE-ManagedThreadFactory-engine-Thread-178210) 
[f798-4334-40ca-ba43-e97e4be396db] START, AttachStorageDomainVDSCommand( 
AttachStorageDomainVDSCommandParameters:{storagePoolId='dd2a11c0-f450-11e9-8e3b-0050568ac2b9',
 ignoreFailoverLimit='false', 
storageDomainId='e6b34c42-0ca6-41f4-be3e-3c9b2af1747b'}), log id: 2263565b
2019-11-18 13:32:16,801-03 ERROR 
[org.ovirt.engine.core.vdsbroker.irsbroker.AttachStorageDomainVDSCommand] 
(EE-ManagedThreadFactory-engine-Thread-178210) 
[f798-4334-40ca-ba43-e97e4be396db] Failed in 'AttachStorageDomainVDS' method
2019-11-18 13:32:16,838-03 ERROR 
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] 
(EE-ManagedThreadFactory-engine-Thread-178210) 
[f798-4334-40ca-ba43-e97e4be396db] EVENT_ID: 
IRS_BROKER_COMMAND_FAILURE(10,803), VDSM command AttachStorageDomainVDS failed: 
Cannot obtain lock: u"id=e6b34c42-0ca6-41f4-be3e-3c9b2af1747b, rc=1, out=[], 
err=['setsid: failed to execute /usr/bin/ionice: Permission denied']"
2019-11-18 13:32:16,838-03 ERROR 
[org.ovirt.engine.core.vdsbroker.irsbroker.AttachStorageDomainVDSCommand] 
(EE-ManagedThreadFactory-engine-Thread-178210) 
[f798-4334-40ca-ba43-e97e4be396db] Command 'AttachStorageDomainVDSCommand( 

[ovirt-users] Re: Unable to attach ISO domain to Datacenter

[ivan]

When trying to attach ISO Domain to Datacenter, the following lines are 
populated on file /var/log/ovirt-engine/engine.log:

2019-11-17 15:02:44,269-03 INFO  
[org.ovirt.engine.core.bll.storage.domain.AttachStorageDomainToPoolCommand] 
(default task-15) [f3795b36-ac1b-4115-9cfd-69e1b13783c9] Lock Acquired to 
object 
'EngineLock:{exclusiveLocks='[e6b34c42-0ca6-41f4-be3e-3c9b2af1747b=STORAGE]', 
sharedLocks=''}'
2019-11-17 15:02:44,301-03 INFO  
[org.ovirt.engine.core.bll.storage.domain.AttachStorageDomainToPoolCommand] 
(EE-ManagedThreadFactory-engine-Thread-138287) 
[f3795b36-ac1b-4115-9cfd-69e1b13783c9] Running command: 
AttachStorageDomainToPoolCommand internal: false. Entities affected :  ID: 
e6b34c42-0ca6-41f4-be3e-3c9b2af1747b Type: StorageAction group 
MANIPULATE_STORAGE_DOMAIN with role type ADMIN,  ID: 
dd2a11c0-f450-11e9-8e3b-0050568ac2b9 Type: StoragePoolAction group 
MANIPULATE_STORAGE_DOMAIN with role type ADMIN
2019-11-17 15:02:44,315-03 INFO  
[org.ovirt.engine.core.bll.storage.connection.ConnectStorageToVdsCommand] 
(EE-ManagedThreadFactory-engine-Thread-138289) [2c0665e4] Running command: 
ConnectStorageToVdsCommand internal: true. Entities affected :  ID: 
aaa0----123456789aaa Type: SystemAction group 
CREATE_STORAGE_DOMAIN with role type ADMIN
2019-11-17 15:02:44,315-03 INFO  
[org.ovirt.engine.core.bll.storage.connection.ConnectStorageToVdsCommand] 
(EE-ManagedThreadFactory-engine-Thread-138291) [40c539bc] Running command: 
ConnectStorageToVdsCommand internal: true. Entities affected :  ID: 
aaa0----123456789aaa Type: SystemAction group 
CREATE_STORAGE_DOMAIN with role type ADMIN
2019-11-17 15:02:44,318-03 INFO  
[org.ovirt.engine.core.bll.storage.connection.ConnectStorageToVdsCommand] 
(EE-ManagedThreadFactory-engine-Thread-138290) [7b359087] Running command: 
ConnectStorageToVdsCommand internal: true. Entities affected :  ID: 
aaa0----123456789aaa Type: SystemAction group 
CREATE_STORAGE_DOMAIN with role type ADMIN
2019-11-17 15:02:44,319-03 INFO  
[org.ovirt.engine.core.bll.storage.connection.ConnectStorageToVdsCommand] 
(EE-ManagedThreadFactory-engine-Thread-138288) [505dd498] Running command: 
ConnectStorageToVdsCommand internal: true. Entities affected :  ID: 
aaa0----123456789aaa Type: SystemAction group 
CREATE_STORAGE_DOMAIN with role type ADMIN
2019-11-17 15:02:44,321-03 INFO  
[org.ovirt.engine.core.vdsbroker.vdsbroker.ConnectStorageServerVDSCommand] 
(EE-ManagedThreadFactory-engine-Thread-138291) [40c539bc] START, 
ConnectStorageServerVDSCommand(HostName = ZeLele, 
StorageServerConnectionManagementVDSParameters:{hostId='86198321-38ff-4596-8c24-2f9442928009',
 storagePoolId='----', storageType='NFS', 
connectionList='[StorageServerConnections:{id='ff0b050c-1b20-41fb-8373-32d9991a327e',
 connection='nholau:/storage/iso', iqn='null', vfsType='null', 
mountOptions='null', nfsVersion='AUTO', nfsRetrans='null', nfsTimeo='null', 
iface='null', netIfaceName='null'}]', sendNetworkEventOnFailure='true'}), log 
id: 742a0d4d
2019-11-17 15:02:44,338-03 INFO  
[org.ovirt.engine.core.vdsbroker.vdsbroker.ConnectStorageServerVDSCommand] 
(EE-ManagedThreadFactory-engine-Thread-138289) [2c0665e4] START, 
ConnectStorageServerVDSCommand(HostName = ChicoBento, 
StorageServerConnectionManagementVDSParameters:{hostId='c5018534-42b6-497a-8107-91493193d088',
 storagePoolId='----', storageType='NFS', 
connectionList='[StorageServerConnections:{id='ff0b050c-1b20-41fb-8373-32d9991a327e',
 connection='nholau:/storage/iso', iqn='null', vfsType='null', 
mountOptions='null', nfsVersion='AUTO', nfsRetrans='null', nfsTimeo='null', 
iface='null', netIfaceName='null'}]', sendNetworkEventOnFailure='true'}), log 
id: 65f576b9
2019-11-17 15:02:44,339-03 INFO  
[org.ovirt.engine.core.vdsbroker.vdsbroker.ConnectStorageServerVDSCommand] 
(EE-ManagedThreadFactory-engine-Thread-138290) [7b359087] START, 
ConnectStorageServerVDSCommand(HostName = NhoLau, 
StorageServerConnectionManagementVDSParameters:{hostId='0fc23e51-3e84-46df-9fd6-e97d83d32040',
 storagePoolId='----', storageType='NFS', 
connectionList='[StorageServerConnections:{id='ff0b050c-1b20-41fb-8373-32d9991a327e',
 connection='nholau:/storage/iso', iqn='null', vfsType='null', 
mountOptions='null', nfsVersion='AUTO', nfsRetrans='null', nfsTimeo='null', 
iface='null', netIfaceName='null'}]', sendNetworkEventOnFailure='true'}), log 
id: 6ed52cef
2019-11-17 15:02:44,344-03 INFO  
[org.ovirt.engine.core.vdsbroker.vdsbroker.ConnectStorageServerVDSCommand] 
(EE-ManagedThreadFactory-engine-Thread-138288) [505dd498] START, 
ConnectStorageServerVDSCommand(HostName = Rosinha, 
StorageServerConnectionManagementVDSParameters:{hostId='a838a3d5-8f52-44cd-a293-e530692814a3',
 storagePoolId='----', storageType='NFS', 

[ovirt-users] Re: terraform integration

[Roy Golan]

On Tue, 19 Nov 2019 at 14:34, Nathanaël Blanchet  wrote:

> Le 19/11/2019 à 08:55, Roy Golan a écrit :
>
> oc get -o json clusterversion
>
> This is the output of the previous failed deployment, I'll give a try to a
> newer one when I'll have a minute to test
>
> (do I need to use the terraform-workers tag instead of latest?)
>
> docker pull quay.io/rgolangh/openshift-installer:terraform-workers
>
>
> [root@openshift-installer
> openshift-origin-client-tools-v3.11.0-0cbc58b-linux-64bit]# ./oc get -o
> json clusterversion
> {
> "apiVersion": "v1",
> "items": [
> {
> "apiVersion": "config.openshift.io/v1",
> "kind": "ClusterVersion",
> "metadata": {
> "creationTimestamp": "2019-11-07T12:23:06Z",
> "generation": 1,
> "name": "version",
> "namespace": "",
> "resourceVersion": "3770202",
> "selfLink": "/apis/
> config.openshift.io/v1/clusterversions/version",
> "uid": "77600bba-6e71-4b35-a60b-d8ee6e0f545c"
> },
> "spec": {
> "channel": "stable-4.3",
> "clusterID": "6f87b719-e563-4c0b-ab5a-1144172bc983",
> "upstream":
> "https://api.openshift.com/api/upgrades_info/v1/graph;
> 
> },
> "status": {
> "availableUpdates": null,
> "conditions": [
> {
> "lastTransitionTime": "2019-11-07T12:23:12Z",
> "status": "False",
> "type": "Available"
> },
> {script
> "lastTransitionTime": "2019-11-07T12:56:15Z",
> "message": "Cluster operator image-registry is
> still updating",
> "reason": "ClusterOperatorNotAvailable",
> "status": "True",
> "type": "Failing"
> },
> {
> "lastTransitionTime": "2019-11-07T12:23:12Z",
> "message": "Unable to apply
> 4.3.0-0.okd-2019-10-29-180250: the cluster operator image-registry has not
> yet successfully rolled out",
> "reason": "ClusterOperatorNotAvailable",
> "status": "True",
> "type": "Progressing"
> },
> {
> "lastTransitionTime": "2019-11-07T12:23:12Z",
> "message": "Unable to retrieve available updates:
> currently installed version 4.3.0-0.okd-2019-10-29-180250 not found in the
> \"stable-4.3\" channel",
> "reason": "RemoteFailed",
> "status": "False",
> "type": "RetrievedUpdates"
> }
> ],
> "desired": {
> "force": false,
> "image": "
> registry.svc.ci.openshift.org/origin/release@sha256:68286e07f7d68ebc8a067389aabf38dee9f9b810c5520d6ee4593c38eb48ddc9
> ",
> "version": "4.3.0-0.okd-2019-10-29-180250"
>

Indeed this version is not the latest and is missing the aforementioned fix
for the registry.

},
> "history": [
> {
> "completionTime": null,
> "image": "
> registry.svc.ci.openshift.org/origin/release@sha256:68286e07f7d68ebc8a067389aabf38dee9f9b810c5520d6ee4593c38eb48ddc9
> ",
> "startedTime": "2019-11-07T12:23:12Z",
> "state": "Partial",
> "verified": false,
> "version": "4.3.0-0.okd-2019-10-29-180250"
> }
> ],
> "observedGeneration": 1,
> "versionHash": "-3onP9QpPTg="
> }
> }
> ],
> "kind": "List",
> "metadata": {
> "resourceVersion": "",
> "selfLink": ""
> }
>
> }
>
>
> Can you answer to these few questions please?
>
>- The latest stable OKD version is 4.2.4. Is it possible to chose the
>version of okd when deploying (seems to use 4.3) or does the installer
>always download the latest OKD?
>
>

>
>- Can we use FCOS instead of RHCOS?
>
>

>- About the pull secret, do we absolutely need a redhat login to get
>this file to deploy an upstream OKD cluster and not downstream openshift?
>
>
> To answer the 3 of those, this specific build is not really OKD, and will
use 4.3 and Red Hat artifact and must use RHCOs, hence the pull secret
thing.
I frankly don't know when OKD 4.3 is going to be released, I guess it will
be on top FCOS.
I'll update the list once we have the oVirt installer for OKD ready for
testing (on FCOS)



-- 
> Nathanaël 

[ovirt-users] Re: terraform integration

[Nathanaël Blanchet]

Le 19/11/2019 à 08:55, Roy Golan a écrit :

oc get -o json clusterversion


This is the output of the previous failed deployment, I'll give a try to 
a newer one when I'll have a minute to test


(do I need to use the terraform-workers tag instead of latest?)

docker pull quay.io/rgolangh/openshift-installer:terraform-workers


[root@openshift-installer 
openshift-origin-client-tools-v3.11.0-0cbc58b-linux-64bit]# ./oc get -o 
json clusterversion

{
    "apiVersion": "v1",
    "items": [
    {
    "apiVersion": "config.openshift.io/v1",
    "kind": "ClusterVersion",
    "metadata": {
    "creationTimestamp": "2019-11-07T12:23:06Z",
    "generation": 1,
    "name": "version",
    "namespace": "",
    "resourceVersion": "3770202",
    "selfLink": 
"/apis/config.openshift.io/v1/clusterversions/version",

    "uid": "77600bba-6e71-4b35-a60b-d8ee6e0f545c"
    },
    "spec": {
    "channel": "stable-4.3",
    "clusterID": "6f87b719-e563-4c0b-ab5a-1144172bc983",
    "upstream": 
"https://api.openshift.com/api/upgrades_info/v1/graph;

    },
    "status": {
    "availableUpdates": null,
    "conditions": [
    {
    "lastTransitionTime": "2019-11-07T12:23:12Z",
    "status": "False",
    "type": "Available"
    },
    {
    "lastTransitionTime": "2019-11-07T12:56:15Z",
    "message": "Cluster operator image-registry is 
still updating",

    "reason": "ClusterOperatorNotAvailable",
    "status": "True",
    "type": "Failing"
    },
    {
    "lastTransitionTime": "2019-11-07T12:23:12Z",
    "message": "Unable to apply 
4.3.0-0.okd-2019-10-29-180250: the cluster operator image-registry has 
not yet successfully rolled out",

    "reason": "ClusterOperatorNotAvailable",
    "status": "True",
    "type": "Progressing"
    },
    {
    "lastTransitionTime": "2019-11-07T12:23:12Z",
    "message": "Unable to retrieve available 
updates: currently installed version 4.3.0-0.okd-2019-10-29-180250 not 
found in the \"stable-4.3\" channel",

    "reason": "RemoteFailed",
    "status": "False",
    "type": "RetrievedUpdates"
    }
    ],
    "desired": {
    "force": false,
    "image": 
"registry.svc.ci.openshift.org/origin/release@sha256:68286e07f7d68ebc8a067389aabf38dee9f9b810c5520d6ee4593c38eb48ddc9",

    "version": "4.3.0-0.okd-2019-10-29-180250"
    },
    "history": [
    {
    "completionTime": null,
    "image": 
"registry.svc.ci.openshift.org/origin/release@sha256:68286e07f7d68ebc8a067389aabf38dee9f9b810c5520d6ee4593c38eb48ddc9",

    "startedTime": "2019-11-07T12:23:12Z",
    "state": "Partial",
    "verified": false,
    "version": "4.3.0-0.okd-2019-10-29-180250"
    }
    ],
    "observedGeneration": 1,
    "versionHash": "-3onP9QpPTg="
    }
    }
    ],
    "kind": "List",
    "metadata": {
    "resourceVersion": "",
    "selfLink": ""
    }

}


Can you answer to these few questions please?

 * The latest stable OKD version is 4.2.4. Is it possible to chose the
   version of okd when deploying (seems to use 4.3) or does the
   installer always download the latest OKD?
 * Can we use FCOS instead of RHCOS?
 * About the pull secret, do we absolutely need a redhat login to get
   this file to deploy an upstream OKD cluster and not downstream
   openshift?


--
Nathanaël Blanchet

Supervision réseau
Pôle Infrastrutures Informatiques
227 avenue Professeur-Jean-Louis-Viala
34193 MONTPELLIER CEDEX 5   
Tél. 33 (0)4 67 54 84 55
Fax  33 (0)4 67 54 84 14
blanc...@abes.fr

___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@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/GN6N42RLIAW6T5KQVBILE5FWMMV4IDGJ/

[ovirt-users] Re: Gluster & Hyper Converged setup

[rob . downer]

Hi,

I believe I need to create a Storage Block which I was unaware of as I thought 
one would be able to use part of the free space on the disks automatically 
provisioned by the node installer, I believe this requires a reinstall and 
creation of a new volume or reduce the current size of the volume used and 
create a new volume on the live system. Additionally on another note how do I 
remove my email address from showing on posts this is not great to have it 
showing.

that file you wanted is below...
[root@ovirt1 ~]# cat 
/etc/ansible/roles/gluster.infra/roles/backend_setup/tasks/vg_create.yml
---
# We have to set the dataalignment for physical volumes, and physicalextentsize
# for volume groups. For JBODs we use a constant alignment value of 256K
# however, for RAID we calculate it by multiplying the RAID stripe unit size
# with the number of data disks. Hence in case of RAID stripe_unit_size and data
# disks are mandatory parameters.

- name: Check if valid disktype is provided
  fail:
msg: "Unknown disktype. Allowed disktypes: JBOD, RAID6, RAID10, RAID5."
  when: gluster_infra_disktype not in [ 'JBOD', 'RAID6', 'RAID10', 'RAID5' ]


# Set data alignment for JBODs, by default it is 256K. This set_fact is not
# needed if we can always assume 256K for JBOD, however we provide this extra
# variable to override it.
- name: Set PV data alignment for JBOD
  set_fact:
pv_dataalign: "{{ gluster_infra_dalign | default('256K') }}"
  when: gluster_infra_disktype == 'JBOD'

# Set data alignment for RAID
# We need KiB: ensure to keep the trailing `K' in the pv_dataalign calculation.
- name: Set PV data alignment for RAID
  set_fact:
pv_dataalign: >
{{ gluster_infra_diskcount|int *
   gluster_infra_stripe_unit_size|int }}K
  when: >
  gluster_infra_disktype == 'RAID6' or
  gluster_infra_disktype == 'RAID10' or
  gluster_infra_disktype == 'RAID5'

- name: Set VG physical extent size for RAID
  set_fact:
vg_pesize: >
 {{ gluster_infra_diskcount|int *
gluster_infra_stripe_unit_size|int }}K
  when: >
 gluster_infra_disktype == 'RAID6' or
 gluster_infra_disktype == 'RAID10' or
 gluster_infra_disktype == 'RAID5'

# Tasks to create a volume group
# The devices in `pvs' can be a regular device or a VDO device
- name: Create volume groups
  lvg:
state: present
vg: "{{ item.vgname }}"
pvs: "{{ item.pvname }}"
pv_options: "--dataalignment {{ pv_dataalign }}"
# pesize is 4m by default for JBODs
pesize: "{{ vg_pesize | default(4) }}"
  with_items: "{{ gluster_infra_volume_groups }}"
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@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/T6YPHITYF3TRE2FLKILBOADSFNZ5HMOS/

[ovirt-users] Re: Wrong CPU?

[Christian Reiss]

Hey Michal,

thanks for replying.
First off and in answer to most of your questions: No clue. Wasn't me.

On 19/11/2019 09:32, Michal Skrivanek wrote:


I’m curious why do you need virt-ssbd for hosted engine? What for?


I don't. Deploying the oVirt hosted engine on the hyperconverged cluster 
enables the flag in the ovirt engine by default. I _wish_ it would not 
be there/ do that.


yes, AFAIK Zen2 is not yet supported in upstream. Once it is we’ll pick 
it up afterwards.
But it doesn’t mean you can’t use it for running stuff in EPYC or lower 
CPU family feature set.


But without an oVirt hosted engine, that won't install due to CPU flags, 
how can I change CPU flags? :)


in 4.3 we still use flags instead of libvirt feature detection (which 
we’re fixing in 4.4, but so far it’s playing to your advantage:)
So seeing “ssbd" below in cpuinfo should be enough to detect the oVirt 
type with SSBD. Where exatly you see that not working?


Doing: Installing fresh 3-Server cluster from oVirt Node installer. 
Doing HCI oVirt engine without any modifications.


Expected result: oVirt engine running.

Actual result: Nothing is starting due to cpu flags, ssbd is among those 
errors.


So this is what I would define as "not seeing working". Also not seeing 
my advantage here: Not working is not working, really ;)



I could happily live a great live if the cluster would _somehow_ just 
work. It just does not. If there would be an option to disable/enable 
ssbd (whatever just works) and oVirt engine can be installed and a VM 
would run I would be so happy.



Cheers,
Chris.

--
 Christian Reiss - em...@christian-reiss.de /"\  ASCII Ribbon
   supp...@alpha-labs.net   \ /Campaign
 X   against HTML
 WEB alpha-labs.net / \   in eMails

 GPG Retrieval https://gpg.christian-reiss.de
 GPG ID ABCD43C5, 0x44E29126ABCD43C5
 GPG fingerprint = 9549 F537 2596 86BA 733C  A4ED 44E2 9126 ABCD 43C5

 "It's better to reign in hell than to serve in heaven.",
  John Milton, Paradise lost.
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@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/AYH2WCD6HC2PCTEDSXRD7NPQG7IIN7U3/

[ovirt-users] Re: Wrong CPU?

[Michal Skrivanek]

> On 18 Nov 2019, at 09:29, Christian Reiss  wrote:
> 
> Ugh,
> 
> first off thanks for all your effort and information. Much obliged.
> But this also means that I am looking at a lng time before I can go to 
> production with this cluster. Now I am sad.
> 
> Would it be an option to run the engine on dedicated hardware and control the 
> cluster from there? Or is that thing in total not usable?

I’m curious why do you need virt-ssbd for hosted engine? What for? 

> 
> -Chris.
> 
> On 18/11/2019 07:25, Juhani Rautiainen wrote:
>> Hi!
>> Had to get back to work to check which CPU we had. We have AMD Epyc
>> 7281 and ovirt CPU Type is AMD EPYC IBPB SSBD. It seems that your CPU
>> is the next generation (Zen2) and I'm pretty sure that problem is with
>> Qemu version. As far as I can see from git there is not even Zen2

yes, AFAIK Zen2 is not yet supported in upstream. Once it is we’ll pick it up 
afterwards.
But it doesn’t mean you can’t use it for running stuff in EPYC or lower CPU 
family feature set.


>> support in latest Qemu (checking by target/i386/cpu.c)? I mean they
>> added Hygon Dhyana (never even heard about this chinese AMD EPYC
>> clone) and in that discussion there was reference to Zen2
>> architecture. So biggest problem for oVirt seems to come from
>> upstream. I mean that Zen2 is quite good for virtualization and it's
>> going to sell a lot. Maybe AMD should help with that push?
>> -Juhani
>> On Fri, Nov 15, 2019 at 9:03 PM Christian Reiss
>> mailto:em...@christian-reiss.de>> wrote:
>>> 
>>> Sorry,
>>> 
>>> I meant EPYC, not Ryzen.
>>> How did you solve your EPYC issue?
>>> 
>>> -Chris.
>>> 
>>> On 15/11/2019 18:55, Juhani Rautiainen wrote:
 Hi!
 
 It might be that the Qemu in oVirt doesn't recognize the Ryzen. That
 was case with Epyc when I started using oVirt. It was reconized as a
 Opteron G2 which caused lot's of problems when upgrading to 4.3.
 
 -Juhani
 
 On Fri, Nov 15, 2019 at 6:45 PM Christian Reiss
  wrote:
> 
> Hey folks,
> 
> running an AMD Ryzen CPU here:
> 
> processor   : 0
> vendor_id   : AuthenticAMD
> cpu family  : 23
> model   : 49
> model name  : AMD EPYC 7282 16-Core Processor
> 
> However, libvirt is detecting this as EPYC-IBPB without the ssbd flags?
> 
>   
> x86_64
> EPYC-IBPB
> AMD
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>   

in 4.3 we still use flags instead of libvirt feature detection (which we’re 
fixing in 4.4, but so far it’s playing to your advantage:) 
So seeing “ssbd" below in cpuinfo should be enough to detect the oVirt type 
with SSBD. Where exatly you see that not working?
 
Thanks,
michal

> 
> 
> [root@node01 ~]# grep ssbd /var/cache/libvirt/qemu/capabilities/*.xml
>   
>   
>   
>   
> 
> But the flag is there:
> 
> [root@node01 ~]# grep ssbd /proc/cpuinfo | tail -n1
> flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge 
> mca cmov
> pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt
> pdpe1gb rdtscp lm constant_tsc art rep_good nopl xtopology nonstop_tsc
> extd_apicid aperfmperf eagerfpu pni pclmulqdq monitor ssse3 fma cx16
> sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy
> svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs
> skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_l2 cpb
> cat_l3 cdp_l3 hw_pstate sme retpoline_amd ssbd ibrs ibpb stibp vmmcall
> fsgsbase bmi1 avx2 smep bmi2 cqm rdt_a rdseed adx smap clflushopt clwb
> sha_ni xsaveopt xsavec xgetbv1 cqm_llc cqm_occup_llc cqm_mbm_total
> cqm_mbm_local clzero irperf xsaveerptr arat npt lbrv svm_lock nrip_save
> tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold
> avic v_vmsave_vmload vgif umip overflow_recov succor smca
> 
> I tried adding "options kvm_amd avic=1" as well as "options kvm_amd
> avic=0" to /etc/modprobe.d/kvm.conf (always with reboots), adding
> mitigations=off to grub.. I can't think of any other solution.
> 
> I just can't get the oVirt engine running with the ssbd flag. Seems cpu
> can do this, oVirt can do this, libvirt does not detect the cpu
> correctly or at least ignores it. But the hosted engine demands it.
> 
> I am at a loss. Any help is oh-so-greatly appreciated.
> 
> -Chris.
> 
> --
>Christian Reiss - em...@christian-reiss.de /"\  ASCII Ribbon
>