[ovirt-users] Re: ovirt 4.4.1.1 hci and problems with ansible 2.9.10 and/or missing python2

2020-07-17 Thread Gianluca Cecchi
On Fri, Jul 17, 2020 at 8:20 PM Edward Berger  wrote:

> cockpit hosted-engine deploy fails after defining VM name with static
> address with similar python2 error.
>
>
Yes I already reported both here and in the bugzilla, but to fix that it
would be necessary to trick with the engine VM (aka the appliance disk)
itself, so I think it is better to fix the whole root cause when found.

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


[ovirt-users] Re: ovirt 4.4.1.1 hci and problems with ansible 2.9.10 and/or missing python2

2020-07-17 Thread Edward Berger
cockpit hosted-engine deploy fails after defining VM name with static
address with similar python2 error.
[image: engine-deploy-fail.JPG]

On Fri, Jul 17, 2020 at 6:44 AM Gobinda Das  wrote:

> Hi Gianluca,
>  Thanks for opening the bug.
> Adding @Prajith Kesava Prasad  to look into it.
>
>
> On Fri, Jul 17, 2020 at 4:02 PM Gianluca Cecchi 
> wrote:
>
>> On Fri, Jul 17, 2020 at 12:13 PM Martin Perina 
>> wrote:
>>
>>> I've reverified that install new host, check for upgrades, upgrade host
>>> and enroll certificates work fine even with ansible 2.9.10 on standalone
>>> engine installation. So there is some issue inside HCI installer, which
>>> doesn't handle python interpreter correctly.
>>>
>>> Gianluca, could you please create a bug for that?
>>>
>>>
>> Opened here:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1858234
>>
>> I have attached the whole content of /var/log/ovirt-hosted-engine-setup/
>> tree of the host.
>> Let me know if anything else to attach and feel free to change subject
>> and/or component
>>
>> Gianluca
>>
>
>
> --
>
>
> Thanks,
> Gobinda
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@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/ZFMOSNKCRE4PRBU6VUQGTSO4SAVGD5IT/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@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/VBROMV6JPXDMGCSHWVWTGDBJYG72NPDL/


[ovirt-users] Re: VM Snapshot inconsistent

2020-07-17 Thread Nir Soffer
On Thu, Jul 16, 2020 at 11:33 AM Arsène Gschwind
 wrote:

> It looks like the Pivot completed successfully, see attached vdsm.log.
> Is there a way to recover that VM?
> Or would it be better to recover the VM from Backup?

This what we see in the log:

1. Merge request recevied

2020-07-13 11:18:30,282+0200 INFO  (jsonrpc/7) [api.virt] START
merge(drive={u'imageID': u'd7bd480d-2c51-4141-a386-113abf75219e',
u'volumeID': u'6197b30d-0732-4cc7-aef0-12f9f6e9565b', u'domainID':
u'33777993-a3a5-4aad-a24c-dfe5e473faca', u'poolID':
u'0002-0002-0002-0002-0289'},
baseVolUUID=u'8e412b5a-85ec-4c53-a5b8-dfb4d6d987b8',
topVolUUID=u'6197b30d-0732-4cc7-aef0-12f9f6e9565b', bandwidth=u'0',
jobUUID=u'720410c3-f1a0-4b25-bf26-cf40aa6b1f97')
from=:::10.34.38.31,39226,
flow_id=4a8b9527-06a3-4be6-9bb9-88630febc227,
vmId=b5534254-660f-44b1-bc83-d616c98ba0ba (api:48)

To track this job, we can use the jobUUID: 720410c3-f1a0-4b25-bf26-cf40aa6b1f97
and the top volume UUID: 6197b30d-0732-4cc7-aef0-12f9f6e9565b

2. Starting the merge

2020-07-13 11:18:30,690+0200 INFO  (jsonrpc/7) [virt.vm]
(vmId='b5534254-660f-44b1-bc83-d616c98ba0ba') Starting merge with
jobUUID=u'720410c3-f1a0-4b25-bf26-cf40aa6b1f97', original
chain=8e412b5a-85ec-4c53-a5b8-dfb4d6d987b8 <
6197b30d-0732-4cc7-aef0-12f9f6e9565b (top), disk='sda', base='sda[1]',
top=None, bandwidth=0, flags=12 (vm:5945)

We see the original chain:
8e412b5a-85ec-4c53-a5b8-dfb4d6d987b8 <
6197b30d-0732-4cc7-aef0-12f9f6e9565b (top)

3. The merge was completed, ready for pivot

2020-07-13 11:19:00,992+0200 INFO  (libvirt/events) [virt.vm]
(vmId='b5534254-660f-44b1-bc83-d616c98ba0ba') Block job ACTIVE_COMMIT
for drive 
/rhev/data-center/mnt/blockSD/33777993-a3a5-4aad-a24c-dfe5e473faca/images/d7bd480d-2c51-4141-a386-113abf75219e/6197b30d-0732-4cc7-aef0-12f9f6e9565b
is ready (vm:5847)

At this point parent volume contains all the data in top volume and we can pivot
to the parent volume.

4. Vdsm detect that the merge is ready, and start the clean thread
that will complete the merge

2020-07-13 11:19:06,166+0200 INFO  (periodic/1) [virt.vm]
(vmId='b5534254-660f-44b1-bc83-d616c98ba0ba') Starting cleanup thread
for job: 720410c3-f1a0-4b25-bf26-cf40aa6b1f97 (vm:5809)

5. Requesting pivot to parent volume:

2020-07-13 11:19:06,717+0200 INFO  (merge/720410c3) [virt.vm]
(vmId='b5534254-660f-44b1-bc83-d616c98ba0ba') Requesting pivot to
complete active layer commit (job
720410c3-f1a0-4b25-bf26-cf40aa6b1f97) (vm:6205)

6. Pivot was successful

2020-07-13 11:19:06,734+0200 INFO  (libvirt/events) [virt.vm]
(vmId='b5534254-660f-44b1-bc83-d616c98ba0ba') Block job ACTIVE_COMMIT
for drive 
/rhev/data-center/mnt/blockSD/33777993-a3a5-4aad-a24c-dfe5e473faca/images/d7bd480d-2c51-4141-a386-113abf75219e/6197b30d-0732-4cc7-aef0-12f9f6e9565b
has completed (vm:5838)

7. Vdsm wait until libvirt updates the xml:

2020-07-13 11:19:06,756+0200 INFO  (merge/720410c3) [virt.vm]
(vmId='b5534254-660f-44b1-bc83-d616c98ba0ba') Pivot completed (job
720410c3-f1a0-4b25-bf26-cf40aa6b1f97) (vm:6219)

8. Syncronizing vdsm metadata

2020-07-13 11:19:06,776+0200 INFO  (merge/720410c3) [vdsm.api] START
imageSyncVolumeChain(sdUUID='33777993-a3a5-4aad-a24c-dfe5e473faca',
imgUUID='d7bd480d-2c51-4141-a386-113abf75219e',
volUUID='6197b30d-0732-4cc7-aef0-12f9f6e9565b',
newChain=['8e412b5a-85ec-4c53-a5b8-dfb4d6d987b8']) from=internal,
task_id=b8f605bd-8549-4983-8fc5-f2ebbe6c4666 (api:48)

We can see the new chain:
['8e412b5a-85ec-4c53-a5b8-dfb4d6d987b8']

2020-07-13 11:19:07,005+0200 INFO  (merge/720410c3) [storage.Image]
Current chain=8e412b5a-85ec-4c53-a5b8-dfb4d6d987b8 <
6197b30d-0732-4cc7-aef0-12f9f6e9565b (top)  (image:1221)

The old chain:
8e412b5a-85ec-4c53-a5b8-dfb4d6d987b8 <
6197b30d-0732-4cc7-aef0-12f9f6e9565b (top)

2020-07-13 11:19:07,006+0200 INFO  (merge/720410c3) [storage.Image]
Unlinking subchain: ['6197b30d-0732-4cc7-aef0-12f9f6e9565b']
(image:1231)
2020-07-13 11:19:07,017+0200 INFO  (merge/720410c3) [storage.Image]
Leaf volume 6197b30d-0732-4cc7-aef0-12f9f6e9565b is being removed from
the chain. Marking it ILLEGAL to prevent data corruption (image:1239)

This matches what we see on storage.

9. Merge job is untracked

2020-07-13 11:19:21,134+0200 INFO  (periodic/1) [virt.vm]
(vmId='b5534254-660f-44b1-bc83-d616c98ba0ba') Cleanup thread

successfully completed, untracking job
720410c3-f1a0-4b25-bf26-cf40aa6b1f97
(base=8e412b5a-85ec-4c53-a5b8-dfb4d6d987b8,
top=6197b30d-0732-4cc7-aef0-12f9f6e9565b) (vm:5752)

This was a successful merge on vdsm side.

We don't see any more requests for the top volume in this log. The next step to
complete the merge it to delete the volume 6197b30d-0732-4cc7-aef0-12f9f6e9565b
but this can be done only on the SPM.

To understand why this did not happen, we need engine log showing this
interaction,
and logs from the SPM host from the same time.

Please file a bug about this and attach these logs (and the vdsm log
you sent here).
Fixing this vm is important but preventing this bug for 

[ovirt-users] Re: oVirt Node 4.4.1.1 Cockpit Hyperconverged Gluster deploy fails insufficient free space no matter how small the volume is set

2020-07-17 Thread Gianluca Cecchi
They should be in the log files I attached to the bugzilla, if you download
the tar,gz file

Gianluca

On Fri, Jul 17, 2020 at 4:45 PM Strahil Nikolov 
wrote:

> Can you provide the target's facts in the bug report ?
>
> Best Regards,
> Strahil Nikolov
>
> На 17 юли 2020 г. 14:48:39 GMT+03:00, Gianluca Cecchi <
> gianluca.cec...@gmail.com> написа:
> >On Fri, Jul 17, 2020 at 1:34 PM Dominique Deschênes <
> >dominique.desche...@gcgenicom.com> wrote:
> >
> >> Hi,
> >>
> >> I use ovirt ISO file ovirt-node-ng-installer-4.4.1-2020070811.el8.iso
> >> (July 8).
> >>
> >> I just saw that there is a new version of July 13 (4.4.1-2020071311).
> >I will try it.
> >>
> >>
> >>
> >No. See my thread I referred and I'm using the July 13 version.
> >Follow the bugzilla I have opened:
> >https://bugzilla.redhat.com/show_bug.cgi?id=1858234
> >
> >Gianluca
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@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/UXSSLGAAHN3DNACZLI4ELREPCI7NO75O/


[ovirt-users] Re: VM Snapshot inconsistent

2020-07-17 Thread Nir Soffer
On Thu, Jul 16, 2020 at 11:33 AM Arsène Gschwind
 wrote:
>
> On Wed, 2020-07-15 at 22:54 +0300, Nir Soffer wrote:
>
> On Wed, Jul 15, 2020 at 7:54 PM Arsène Gschwind
>
> <
>
> arsene.gschw...@unibas.ch
>
> > wrote:
>
>
> On Wed, 2020-07-15 at 17:46 +0300, Nir Soffer wrote:
>
>
> What we see in the data you sent:
>
>
>
> Qemu chain:
>
>
>
> $ qemu-img info --backing-chain
>
>
> /dev/33777993-a3a5-4aad-a24c-dfe5e473faca/6197b30d-0732-4cc7-aef0-12f9f6e9565b
>
>
> image: 
> /dev/33777993-a3a5-4aad-a24c-dfe5e473faca/6197b30d-0732-4cc7-aef0-12f9f6e9565b
>
>
> file format: qcow2
>
>
> virtual size: 150G (161061273600 bytes)
>
>
> disk size: 0
>
>
> cluster_size: 65536
>
>
> backing file: 8e412b5a-85ec-4c53-a5b8-dfb4d6d987b8 (actual path:
>
>
> /dev/33777993-a3a5-4aad-a24c-dfe5e473faca/8e412b5a-85ec-4c53-a5b8-dfb4d6d987b8)
>
>
> backing file format: qcow2
>
>
> Format specific information:
>
>
> compat: 1.1
>
>
> lazy refcounts: false
>
>
> refcount bits: 16
>
>
> corrupt: false
>
>
>
> image: 
> /dev/33777993-a3a5-4aad-a24c-dfe5e473faca/8e412b5a-85ec-4c53-a5b8-dfb4d6d987b8
>
>
> file format: qcow2
>
>
> virtual size: 150G (161061273600 bytes)
>
>
> disk size: 0
>
>
> cluster_size: 65536
>
>
> Format specific information:
>
>
> compat: 1.1
>
>
> lazy refcounts: false
>
>
> refcount bits: 16
>
>
> corrupt: false
>
>
>
> Vdsm chain:
>
>
>
> $ cat 6197b30d-0732-4cc7-aef0-12f9f6e9565b.meta
>
>
> CAP=161061273600
>
>
> CTIME=1594060718
>
>
> DESCRIPTION=
>
>
> DISKTYPE=DATA
>
>
> DOMAIN=33777993-a3a5-4aad-a24c-dfe5e473faca
>
>
> FORMAT=COW
>
>
> GEN=0
>
>
> IMAGE=d7bd480d-2c51-4141-a386-113abf75219e
>
>
> LEGALITY=ILLEGAL
>
>
>
> ^^
>
>
> This is the issue, the top volume is illegal.
>
>
>
> PUUID=8e412b5a-85ec-4c53-a5b8-dfb4d6d987b8
>
>
> TYPE=SPARSE
>
>
> VOLTYPE=LEAF
>
>
>
> $ cat 8e412b5a-85ec-4c53-a5b8-dfb4d6d987b8.meta
>
>
> CAP=161061273600
>
>
> CTIME=1587646763
>
>
> DESCRIPTION={"DiskAlias":"cpslpd01_Disk1","DiskDescription":"SAP SLCM
>
>
> H11 HDB D13"}
>
>
> DISKTYPE=DATA
>
>
> DOMAIN=33777993-a3a5-4aad-a24c-dfe5e473faca
>
>
> FORMAT=COW
>
>
> GEN=0
>
>
> IMAGE=d7bd480d-2c51-4141-a386-113abf75219e
>
>
> LEGALITY=LEGAL
>
>
> PUUID=----
>
>
> TYPE=SPARSE
>
>
> VOLTYPE=INTERNAL
>
>
>
> We set volume to ILLEGAL when we merge the top volume into the parent volume,
>
>
> and both volumes contain the same data.
>
>
>
> After we mark the volume as ILLEGAL, we pivot to the parent volume
>
>
> (8e412b5a-85ec-4c53-a5b8-dfb4d6d987b8).
>
>
>
> If the pivot was successful, the parent volume may have new data, and starting
>
>
> the vm using the top volume may corrupt the vm filesystem. The ILLEGAL state
>
>
> prevent this.
>
>
>
> If the pivot was not successful, the vm must be started using the top
>
>
> volume, but it
>
>
> will always fail if the volume is ILLEGAL.
>
>
>
> If the volume is ILLEGAL, trying to merge again when the VM is not running 
> will
>
>
> always fail, since vdsm does not if the pivot succeeded or not, and cannot 
> merge
>
>
> the volume in a safe way.
>
>
>
> Do you have the vdsm from all merge attempts on this disk?
>
>
> This is an extract of the vdsm logs, i may provide the complete log if it 
> would help.
>
>
> Yes, this is only the start of the merge. We see the success message
>
> but this only means the merge
>
> job was started.
>
>
> Please share the complete log, and if needed the next log. The
>
> important messages we look for are:
>
>
> Requesting pivot to complete active layer commit ...
>
>
> Follow by:
>
>
> Pivot completed ...
>
>
> If pivot failed, we expect to see this message:
>
>
> Pivot failed: ...
>
>
> After these messages we may find very important logs that explain why
>
> your disk was left
>
> in an inconsistent state.
>
> It looks like the Pivot completed successfully, see attached vdsm.log.

That's good, I'm looking in your log.

> Is there a way to recover that VM?

If the pivot was successful, qemu started to use the parent volume instead
of the top volume. In thi case you can delete the top volume, and fix the
metadata of the parent volume.

Then you need to remove the top volume from engine db, and fix the metadata
of the parent volume in engine db.

Let me veirfy first that the pivot was successful, and then I'll add
instructions
how to fix engine and volume metadata.

> Or would it be better to recover the VM from Backup?

If the backup is recent enough, it will be easier. But fixing the VM is will
prevent any data loss since the last backup.

It is not clear from the previous mails (or maybe I missed it) - is the VM
running now or stopped?

If the vm is running, checking the vm xml will show very clearly that it is not
using the top volume. You can do:

virsh -r dumpxml vm-name-or-id

> Thanks a lot
> Arsene
>
>
> Since this looks like a bug and may be useful to others, I think it is
>
> time to file a vdsm bug,
>
> and attach the logs to the bug.
>
>
> 2020-07-13 

[ovirt-users] Re: oVirt Node 4.4.1.1 Cockpit Hyperconverged Gluster deploy fails insufficient free space no matter how small the volume is set

2020-07-17 Thread Strahil Nikolov via Users
Can you provide the target's facts in the bug report ?

Best Regards,
Strahil Nikolov

На 17 юли 2020 г. 14:48:39 GMT+03:00, Gianluca Cecchi 
 написа:
>On Fri, Jul 17, 2020 at 1:34 PM Dominique Deschênes <
>dominique.desche...@gcgenicom.com> wrote:
>
>> Hi,
>>
>> I use ovirt ISO file ovirt-node-ng-installer-4.4.1-2020070811.el8.iso
>> (July 8).
>>
>> I just saw that there is a new version of July 13 (4.4.1-2020071311).
>I will try it.
>>
>>
>>
>No. See my thread I referred and I'm using the July 13 version.
>Follow the bugzilla I have opened:
>https://bugzilla.redhat.com/show_bug.cgi?id=1858234
>
>Gianluca
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@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/5I3CZMMWN2HD5SC4PVZQ5TKZQHDH3BPR/


[ovirt-users] Info on transporting a gluster storage domain

2020-07-17 Thread Gianluca Cecchi
Hello,
I have env1 and env2, both in 4.3 and both configured as single host HCI
environments.

On both I have the predefined hosted_storage, data and vmstore gluster
storage domains.
On env1 I have hosted_storage and data on a disk, and vmstore on a whole
different disk. I also have a "big2" gluster storage domain created in
another disk in a second time.

I want  to scratch env1 but preserve and then import vmstore and big2
storage domains in env2

This "big2" is configured as a PV on the whole 4Tb disk on env1.

- nvme1n1 4Tb  gluster_vg_4t2   serial: BTLF72840DVK4P0DGN
eui.010001005cd2e45c02de4d51 dm-3 NVME,INTEL SSDPEDKX040T7

size=3.6T features='1 queue_if_no_path' hwhandler='0' wp=rw
`-+- policy='service-time 0' prio=0 status=active
  `- 1:0:1:0 nvme1n1 259:3 active undef running

[root@ovirt ~]# pvs /dev/mapper/eui.010001005cd2e45c02de4d51
  PV   VG Fmt  Attr
PSize  PFree
  /dev/mapper/eui.010001005cd2e45c02de4d51 gluster_vg_4t2 lvm2 a--
 <3.64t0
[root@ovirt ~]#

[root@ovirt ~]# lvs gluster_vg_4t2
  LV  VG Attr   LSize  PoolOrigin Data%
 Meta%  Move Log Cpy%Sync Convert
  gluster_lv_big2 gluster_vg_4t2 Vwi-aot--- <4.35t my_pool1.36

  my_pool gluster_vg_4t2 twi-aot--- <3.61t1.64
0.18
[root@ovirt ~]#

In similar way the vmstore storage domain has:

- nvme2n1 1Tb gluster_vg_nvme1n1   serial: PHLF8125037R1P0GGN
eui.010001005cd2e4e359284f51 dm-1 NVME,INTEL SSDPE2KX010T7

size=932G features='1 queue_if_no_path' hwhandler='0' wp=rw
`-+- policy='service-time 0' prio=0 status=active
  `- 2:0:1:0 nvme2n1 259:2 active undef running

[root@ovirt ~]# pvs /dev/mapper/eui.010001005cd2e4e359284f51
  PV   VG Fmt
 Attr PSize   PFree
  /dev/mapper/eui.010001005cd2e4e359284f51 gluster_vg_nvme1n1 lvm2
a--  931.51g0
[root@ovirt ~]#

[root@ovirt ~]# lvs gluster_vg_nvme1n1
  LV  VG Attr   LSize
PoolOrigin Data%  Meta%  Move Log Cpy%Sync
Convert
  gluster_lv_vmstore  gluster_vg_nvme1n1 Vwi-aot--- 930.00g
gluster_thinpool_gluster_vg_nvme1n163.99

  gluster_thinpool_gluster_vg_nvme1n1 gluster_vg_nvme1n1 twi-aot--- 921.51g
   64.58  1.80

[root@ovirt ~]#

I presume the correct way is:

- env1
delete and detach vmstore and big2 (without formatting/zeroing)

- env2
attach the two disks to the system

and then?
What should I do at gluster commands level to "import" the already setup
gluster bricks/volumes and then at oVirt side to import the corresponding
storage domain?
BTW: can I import the previous storage domain named "vmstore" giving anothe
r name such as vmstore2, not to create conflict with already existing
"vmstore" storage domain or the name is hard coded when importing and
creating possible conflict?

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


[ovirt-users] Re: VDSM HOST ISSUE - Message timeout which can be caused by communication issues

2020-07-17 Thread Strahil Nikolov via Users
Definitely it's not a resolve issue.

Have you made changes to sshd_config on sia-svr-ct02 ?
Is root login opened ?


Best Regards,
Strahil Nikolov

На 17 юли 2020 г. 13:58:09 GMT+03:00, lu.alfo...@almaviva.it написа:
>This is the output from the engine:
>
>[root@dacs-ovirt ~]# host sia-svr-ct02
>sia-svr-ct02.afis has address 10.234.50.134
>
>[root@dacs-ovirt ~]# nslookup sia-svr-ct02
>Server: 10.249.20.21
>Address:10.249.20.21#53
>
>Name:   sia-svr-ct02.afis
>Address: 10.234.50.134
>___
>Users mailing list -- users@ovirt.org
>To unsubscribe send an email to users-le...@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/5AUR2KK63HHJHJD44IRX2XO2UVOUI6XJ/
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@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/ANFCVK3OUB2QWPCNRHOGIP2TUC6ZY2YC/


[ovirt-users] Re: oVirt Node 4.4.1.1 Cockpit Hyperconverged Gluster deploy fails insufficient free space no matter how small the volume is set

2020-07-17 Thread Gianluca Cecchi
On Fri, Jul 17, 2020 at 1:34 PM Dominique Deschênes <
dominique.desche...@gcgenicom.com> wrote:

> Hi,
>
> I use ovirt ISO file ovirt-node-ng-installer-4.4.1-2020070811.el8.iso
> (July 8).
>
> I just saw that there is a new version of July 13 (4.4.1-2020071311). I will 
> try it.
>
>
>
No. See my thread I referred and I'm using the July 13 version.
Follow the bugzilla I have opened:
https://bugzilla.redhat.com/show_bug.cgi?id=1858234

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


[ovirt-users] Re: oVirt Node 4.4.1.1 Cockpit Hyperconverged Gluster deploy fails insufficient free space no matter how small the volume is set

2020-07-17 Thread Dominique Deschênes

Hi,

I use ovirt ISO file ovirt-node-ng-installer-4.4.1-2020070811.el8.iso (July 8).
I just saw that there is a new version of July 13 (4.4.1-2020071311). I will 
try it.


Dominique Deschênes
Ingénieur chargé de projets, Responsable TI
816, boulevard Guimond, Longueuil J4G 1T5
 450 670-8383 x105  450 670-2259


          

- Message reçu -
De: Strahil Nikolov (hunter86...@yahoo.com)
Date: 17/07/20 04:03
À: Dominique Deschênes (dominique.desche...@gcgenicom.com), clam2...@gmail.com, 
users@ovirt.org
Objet: Re: [ovirt-users] Re: oVirt Node 4.4.1.1 Cockpit Hyperconverged Gluster 
deploy fails insufficient free space no matter how small the volume is set

What version of CentOS 8 are you using -> Stream or regular, version ?

Best Regards,
Strahil Nikolov

На 16 юли 2020 г. 21:07:57 GMT+03:00, "Dominique Deschênes" 
 написа:
>
>
>HI,
>Thank you for your answers
>
>I tried to replace the "package" with "dnf".  the installation of the
>gluster seems to work well but I had the similar message during the
>deployment of the Hosted engine.
>
>Here is the error
>
>[ ERROR ] fatal: [localhost]: FAILED! => {"attempts": 10, "changed":
>false, "msg": "The Python 2 yum module is needed for this module. If
>you require Python 3 support use the `dnf` Ansible module instead."}
>
>
>
>
>
>Dominique Deschênes
>Ingénieur chargé de projets, Responsable TI
>816, boulevard Guimond, Longueuil J4G 1T5
> 450 670-8383 x105  450 670-2259
>
>
>        
>
>- Message reçu -
>De: clam2...@gmail.com
>Date: 16/07/20 13:40
>À: users@ovirt.org
>Objet: [ovirt-users] Re: oVirt Node 4.4.1.1 Cockpit Hyperconverged
>Gluster deploy fails insufficient free space no matter how small the
>volume is set
>
>Dear Strahil, Dominique and Edward:
>
>I reimaged the three hosts with
>ovirt-node-ng-installer-4.4.1-2020071311.el8.iso just to be sure
>everything was stock (I had upgraded from v4.4) and attempted a
>redeploy with all suggested changes EXCEPT replacing "package" with
>"dnf" --> same failure.  I then made Strahil's recommended replacement
>of "package" with "dnf" and the Gluster deployment succeeded through
>that section of main.yml only to fail a little later at:
>
>- name: Install python-yaml package for Debian systems
> package:
>   name: python-yaml
>   state: present
> when: ansible_distribution == "Debian" or ansible_distribution ==
>"Ubuntu"
>
>I found this notable given that I had not replaced "package" with "dnf"
>in the prior section:
>
>- name: Change to Install lvm tools for debian systems.
> package:
>   name: thin-provisioning-tools
>   state: present
> when: ansible_distribution == "Debian" or ansible_distribution ==
>"Ubuntu"
>
>and deployment had not failed here.  Anyhow, I deleted the two Debian
>statements as I am deploying from Node (CentOS based), cleaned up,
>cleaned up my drives ('dmsetup remove eui.xxx...' and 'wipefs --all
>--force /dev/nvme0n1 /dev/nvmeXn1 ...')  and redeployed again.  This
>time Gluster deployment seemed to execute main.yml OK only to fail in a
>new file, vdo_create.yml:
>
>TASK [gluster.infra/roles/backend_setup : Install VDO dependencies]
>
>task path:
>/etc/ansible/roles/gluster.infra/roles/backend_setup/tasks/vdo_create.yml:26
>fatal: [fmov1n1.sn.dtcorp.com]: FAILED! => {"changed": false, "msg":
>"The Python 2 yum module is needed for this module. If you require
>Python 3 support use the `dnf` Ansible module instead."}
>fatal: [fmov1n3.sn.dtcorp.com]: FAILED! => {"changed": false, "msg":
>"The Python 2 yum module is needed for this module. If you require
>Python 3 support use the `dnf` Ansible module instead."}
>fatal: [fmov1n2.sn.dtcorp.com]: FAILED! => {"changed": false, "msg":
>"The Python 2 yum module is needed for this module. If you require
>Python 3 support use the `dnf` Ansible module instead."}
>
>Expecting that this might continue, I have been looking into the
>documentation of how "package" works and if I can find a root cause for
>this rather than reviewing n *.yml files and replacing "package" with
>"dnf" in all of them.  Thank you VERY much to Strahil for helping me!
>
>If Strahil or anyone else has any additional troubleshooting tips,
>suggestions, insight or solutions I am all ears.  I will continue to
>update as I progress.
>
>Respectfully,
>Charles
>___
>Users mailing list -- users@ovirt.org
>To unsubscribe send an email to users-le...@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/3JTZX2OF4JTGRECMZLZXZQT5IWR4PFSG/


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

[ovirt-users] Re: VDSM HOST ISSUE - Message timeout which can be caused by communication issues

2020-07-17 Thread lu . alfonsi
This is the output from the engine:

[root@dacs-ovirt ~]# host sia-svr-ct02
sia-svr-ct02.afis has address 10.234.50.134

[root@dacs-ovirt ~]# nslookup sia-svr-ct02
Server: 10.249.20.21
Address:10.249.20.21#53

Name:   sia-svr-ct02.afis
Address: 10.234.50.134
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@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/5AUR2KK63HHJHJD44IRX2XO2UVOUI6XJ/


[ovirt-users] Re: ovirt 4.4.1.1 hci and problems with ansible 2.9.10 and/or missing python2

2020-07-17 Thread Gobinda Das
Hi Gianluca,
 Thanks for opening the bug.
Adding @Prajith Kesava Prasad  to look into it.


On Fri, Jul 17, 2020 at 4:02 PM Gianluca Cecchi 
wrote:

> On Fri, Jul 17, 2020 at 12:13 PM Martin Perina  wrote:
>
>> I've reverified that install new host, check for upgrades, upgrade host
>> and enroll certificates work fine even with ansible 2.9.10 on standalone
>> engine installation. So there is some issue inside HCI installer, which
>> doesn't handle python interpreter correctly.
>>
>> Gianluca, could you please create a bug for that?
>>
>>
> Opened here:
> https://bugzilla.redhat.com/show_bug.cgi?id=1858234
>
> I have attached the whole content of /var/log/ovirt-hosted-engine-setup/
> tree of the host.
> Let me know if anything else to attach and feel free to change subject
> and/or component
>
> Gianluca
>


-- 


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


[ovirt-users] Re: ovirt 4.4.1.1 hci and problems with ansible 2.9.10 and/or missing python2

2020-07-17 Thread Gianluca Cecchi
On Fri, Jul 17, 2020 at 12:13 PM Martin Perina  wrote:

> I've reverified that install new host, check for upgrades, upgrade host
> and enroll certificates work fine even with ansible 2.9.10 on standalone
> engine installation. So there is some issue inside HCI installer, which
> doesn't handle python interpreter correctly.
>
> Gianluca, could you please create a bug for that?
>
>
Opened here:
https://bugzilla.redhat.com/show_bug.cgi?id=1858234

I have attached the whole content of /var/log/ovirt-hosted-engine-setup/
tree of the host.
Let me know if anything else to attach and feel free to change subject
and/or component

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


[ovirt-users] Re: ovirt 4.4.1.1 hci and problems with ansible 2.9.10 and/or missing python2

2020-07-17 Thread Martin Perina
I've reverified that install new host, check for upgrades, upgrade host and
enroll certificates work fine even with ansible 2.9.10 on standalone engine
installation. So there is some issue inside HCI installer, which doesn't
handle python interpreter correctly.

Gianluca, could you please create a bug for that?

Thanks,
Martin


On Fri, Jul 17, 2020 at 11:36 AM Gianluca Cecchi 
wrote:

>
>
> On Fri, Jul 17, 2020 at 11:25 AM Gianluca Cecchi <
> gianluca.cec...@gmail.com> wrote:
>
>> On Fri, Jul 17, 2020 at 11:04 AM Gianluca Cecchi <
>> gianluca.cec...@gmail.com> wrote:
>>
>>> On Fri, Jul 17, 2020 at 10:58 AM Gianluca Cecchi <
>>> gianluca.cec...@gmail.com> wrote:
>>>
 On Fri, Jul 17, 2020 at 10:54 AM Martin Perina 
 wrote:

> Hi Gianluca,
>
> that's very strange error, because I'm 100% sure we are using yum
> module with Python3 in several other roles including adding host to engine
> or upgrading host and so far I haven't heard any issue with ansible 2.9.10
> and yum module.
>
> Gobinda, wouldn't enforcing python interpreter version help there?
>
>
> https://github.com/oVirt/ovirt-engine/blob/master/packaging/ansible-runner-service-project/project/roles/ovirt-host-deploy-facts/tasks/main.yml#L28
>
> Regards,
> Martin
>
>
 I have a very clean install from 4.1.1.1 node ng iso anf I'm the third
 to notice that with this release.
 The engine deployment is going on. Not finished yet, but to have ti go
 I had to modify, with the same strategy ("use: dnf" with package module and
 use "package" instead of "yum" and also specifying "use: dnf") in these
 files under /usr/share/ansible/roles:

 ovirt.engine-setup/tasks/engine_setup.yml
 ovirt.engine-setup/tasks/install_packages.yml
 ovirt.hosted_engine_setup/tasks/install_packages.yml

 ovirt.hosted_engine_setup/tasks/create_target_vm/03_hosted_engine_final_tasks.yml
 ovirt.hosted_engine_setup/tasks/install_appliance.yml

 Gianluca

>>>
>>> The installation from the iso was with all default values.
>>> The only "non standard" thing, if we want it to call this way is that
>>> before running the wizard, on the host I pre-installed the appliance
>>> package, to shorten the deploy phase hereafter.
>>> And to do it I executed, because of habit:
>>> yum install ovirt-engine-appliance
>>>
>>> instead of "dnf install...", but I think this doesn't influence ansible
>>> autodetect when using "package" module or the error about python2 when
>>> using "yum" module...
>>>
>>> Gianluca
>>>
>>
>> The engine deployment failed in the phase where it tries to add the host
>> and waits for the host to be up and if I go into the logs in
>>
>> /var/log/ovirt-hosted-engine-setup/engine-logs-2020-07-17T08:30:48Z/ovirt-engine/host-deploy/
>>
>> the file
>> ovirt-host-deploy-ansible-20200717104103-novirt2.example.net-3a710f0c.log
>> contains
>>
>> 020-07-17 10:41:17 CEST - fatal: [novirt2.example.net]: FAILED! =>
>> {"changed": false, "module_stderr": "/bin/sh: /usr/bin
>> /python2: No such file or directory\n", "module_stdout": "", "msg": "The
>> module failed to execute correctly, you probably
>> need to set the interpreter.\nSee stdout/stderr for the exact error",
>> "rc": 127}
>> 2020-07-17 10:41:17 CEST - {
>>   "status" : "OK",
>>   "msg" : "",
>>   "data" : {
>> "uuid" : "00f4c6a8-8423-4a2a-bfd5-f38c34f56ecf",
>> "counter" : 53,
>> "stdout" : "fatal: [novirt2.example.net]: FAILED! => {\"changed\":
>> false, \"module_stderr\": \"/bin/sh: /usr/bin/pytho
>> n2: No such file or directory\\n\", \"module_stdout\": \"\", \"msg\":
>> \"The module failed to execute correctly, you probab
>> ly need to set the interpreter.\\nSee stdout/stderr for the exact
>> error\", \"rc\": 127}",
>>
>> So I think I have to find and solve why it searches python2
>> I compared on an existing 4.4.0 environment I have (hci single node
>> installed from 4.4.0 node ng iso) and no python2 apparently there, only
>> ansible that is at  ansible-2.9.9-1.el8.noarch instead of
>> ansible-2.9.10-1.el8.noarch of 4.4.1.1
>>
>> Possibly any wrong default about python?
>>
>> Alternatives seems the same between 4.4.0 and 4.4.1.1
>>
>> 4.4.0
>> [g.cecchi@ovirt01 ~]$ alternatives --list
>> cifs-idmap-plugin auto   /usr/lib64/cifs-utils/cifs_idmap_sss.so
>> ifup   auto   /etc/sysconfig/network-scripts/ifup
>> ld auto   /usr/bin/ld.bfd
>> libnssckbi.so.x86_64   auto   /usr/lib64/pkcs11/p11-kit-trust.so
>> libwbclient.so.0.15-64 auto
>> /usr/lib64/samba/wbclient/libwbclient.so.0.15
>> mkisofs   auto   /usr/bin/genisoimage
>> mta   auto   /usr/sbin/sendmail.postfix
>> nmap   auto   /usr/bin/ncat
>> python auto   /usr/libexec/no-python
>> python3   auto   /usr/bin/python3.6
>> [g.cecchi@ovirt01 ~]$
>>
>> 4.4.1.1
>> [root@novirt2 host-deploy]# alternatives --list
>> 

[ovirt-users] Re: ovirt 4.4.1.1 hci and problems with ansible 2.9.10 and/or missing python2

2020-07-17 Thread Strahil Nikolov via Users
Hm...
but then setting that variable to python3 should work,  but based on the list 
reports - it doesn't work.

Best Regards,
Strahil Nikolov

На 17 юли 2020 г. 12:35:52 GMT+03:00, Gianluca Cecchi 
 написа:
>On Fri, Jul 17, 2020 at 11:25 AM Gianluca Cecchi
>
>wrote:
>
>> On Fri, Jul 17, 2020 at 11:04 AM Gianluca Cecchi <
>> gianluca.cec...@gmail.com> wrote:
>>
>>> On Fri, Jul 17, 2020 at 10:58 AM Gianluca Cecchi <
>>> gianluca.cec...@gmail.com> wrote:
>>>
 On Fri, Jul 17, 2020 at 10:54 AM Martin Perina 
 wrote:

> Hi Gianluca,
>
> that's very strange error, because I'm 100% sure we are using yum
> module with Python3 in several other roles including adding host
>to engine
> or upgrading host and so far I haven't heard any issue with
>ansible 2.9.10
> and yum module.
>
> Gobinda, wouldn't enforcing python interpreter version help there?
>
>
>
>https://github.com/oVirt/ovirt-engine/blob/master/packaging/ansible-runner-service-project/project/roles/ovirt-host-deploy-facts/tasks/main.yml#L28
>
> Regards,
> Martin
>
>
 I have a very clean install from 4.1.1.1 node ng iso anf I'm the
>third
 to notice that with this release.
 The engine deployment is going on. Not finished yet, but to have ti
>go I
 had to modify, with the same strategy ("use: dnf" with package
>module and
 use "package" instead of "yum" and also specifying "use: dnf") in
>these
 files under /usr/share/ansible/roles:

 ovirt.engine-setup/tasks/engine_setup.yml
 ovirt.engine-setup/tasks/install_packages.yml
 ovirt.hosted_engine_setup/tasks/install_packages.yml


>ovirt.hosted_engine_setup/tasks/create_target_vm/03_hosted_engine_final_tasks.yml
 ovirt.hosted_engine_setup/tasks/install_appliance.yml

 Gianluca

>>>
>>> The installation from the iso was with all default values.
>>> The only "non standard" thing, if we want it to call this way is
>that
>>> before running the wizard, on the host I pre-installed the appliance
>>> package, to shorten the deploy phase hereafter.
>>> And to do it I executed, because of habit:
>>> yum install ovirt-engine-appliance
>>>
>>> instead of "dnf install...", but I think this doesn't influence
>ansible
>>> autodetect when using "package" module or the error about python2
>when
>>> using "yum" module...
>>>
>>> Gianluca
>>>
>>
>> The engine deployment failed in the phase where it tries to add the
>host
>> and waits for the host to be up and if I go into the logs in
>>
>>
>/var/log/ovirt-hosted-engine-setup/engine-logs-2020-07-17T08:30:48Z/ovirt-engine/host-deploy/
>>
>> the file
>>
>ovirt-host-deploy-ansible-20200717104103-novirt2.example.net-3a710f0c.log
>> contains
>>
>> 020-07-17 10:41:17 CEST - fatal: [novirt2.example.net]: FAILED! =>
>> {"changed": false, "module_stderr": "/bin/sh: /usr/bin
>> /python2: No such file or directory\n", "module_stdout": "", "msg":
>"The
>> module failed to execute correctly, you probably
>> need to set the interpreter.\nSee stdout/stderr for the exact error",
>> "rc": 127}
>> 2020-07-17 10:41:17 CEST - {
>>   "status" : "OK",
>>   "msg" : "",
>>   "data" : {
>> "uuid" : "00f4c6a8-8423-4a2a-bfd5-f38c34f56ecf",
>> "counter" : 53,
>> "stdout" : "fatal: [novirt2.example.net]: FAILED! =>
>{\"changed\":
>> false, \"module_stderr\": \"/bin/sh: /usr/bin/pytho
>> n2: No such file or directory\\n\", \"module_stdout\": \"\", \"msg\":
>> \"The module failed to execute correctly, you probab
>> ly need to set the interpreter.\\nSee stdout/stderr for the exact
>error\",
>> \"rc\": 127}",
>>
>> So I think I have to find and solve why it searches python2
>> I compared on an existing 4.4.0 environment I have (hci single node
>> installed from 4.4.0 node ng iso) and no python2 apparently there,
>only
>> ansible that is at  ansible-2.9.9-1.el8.noarch instead of
>> ansible-2.9.10-1.el8.noarch of 4.4.1.1
>>
>> Possibly any wrong default about python?
>>
>> Alternatives seems the same between 4.4.0 and 4.4.1.1
>>
>> 4.4.0
>> [g.cecchi@ovirt01 ~]$ alternatives --list
>> cifs-idmap-plugin auto   /usr/lib64/cifs-utils/cifs_idmap_sss.so
>> ifup   auto   /etc/sysconfig/network-scripts/ifup
>> ld auto   /usr/bin/ld.bfd
>> libnssckbi.so.x86_64   auto   /usr/lib64/pkcs11/p11-kit-trust.so
>> libwbclient.so.0.15-64 auto  
>/usr/lib64/samba/wbclient/libwbclient.so.0.15
>> mkisofs   auto   /usr/bin/genisoimage
>> mta   auto   /usr/sbin/sendmail.postfix
>> nmap   auto   /usr/bin/ncat
>> python auto   /usr/libexec/no-python
>> python3   auto   /usr/bin/python3.6
>> [g.cecchi@ovirt01 ~]$
>>
>> 4.4.1.1
>> [root@novirt2 host-deploy]# alternatives --list
>> cifs-idmap-plugin auto   /usr/lib64/cifs-utils/cifs_idmap_sss.so
>> ifup   auto   /etc/sysconfig/network-scripts/ifup
>> ld auto   /usr/bin/ld.bfd
>> 

[ovirt-users] Re: VDSM HOST ISSUE - Message timeout which can be caused by communication issues

2020-07-17 Thread Strahil Nikolov via Users
What is the output of:
host sia-svr-ct02
nslookup sia-svr-ct02

Best Regards,
Strahil Nikolov

На 17 юли 2020 г. 10:46:08 GMT+03:00, lu.alfo...@almaviva.it написа:
>2020-07-15 11:41:58,968+02 ERROR
>[org.ovirt.engine.core.vdsbroker.monitoring.HostMonitoring]
>(EE-ManagedThreadFactory-engineScheduled-Thread-79) [] Unable to
>RefreshCapabilities: VDSNetworkException: VDSGenericException:
>VDSNetworkException: Message timeout which can be caused by
>communication issues
>2020-07-15 11:41:59,350+02 WARN 
>[org.ovirt.vdsm.jsonrpc.client.utils.retry.Retryable] (SSL Stomp
>Reactor) [] Retry failed
>2020-07-15 11:41:59,350+02 ERROR
>[org.ovirt.vdsm.jsonrpc.client.reactors.ReactorClient]
>(EE-ManagedThreadFactory-engineScheduled-Thread-59) [] Exception during
>connection
>2020-07-15 11:41:59,351+02 ERROR
>[org.ovirt.engine.core.vdsbroker.monitoring.HostMonitoring]
>(EE-ManagedThreadFactory-engineScheduled-Thread-59) [] Unable to
>RefreshCapabilities: ConnectException: Connection timeout
>2020-07-15 11:41:59,354+02 ERROR
>[org.ovirt.engine.core.vdsbroker.vdsbroker.GetCapabilitiesAsyncVDSCommand]
>(EE-ManagedThreadFactory-engineScheduled-Thread-59) [] Command
>'GetCapabilitiesAsyncVDSCommand(HostName = sia-svr-ct02,
>VdsIdAndVdsVDSCommandParametersBase:{hostId='9e65ad71-f633-4be3-aa74-a7fc51b285e6',
>vds='Host[sia-svr-ct02,9e65ad71-f633-4be3-aa74-a7fc51b285e6]'})'
>execution failed: java.rmi.ConnectException: Connection timeout
>2020-07-15 11:42:00,465+02 ERROR
>[org.ovirt.engine.core.vdsbroker.vdsbroker.SpmStatusVDSCommand]
>(EE-ManagedThreadFactory-engineScheduled-Thread-62) [] Command
>'SpmStatusVDSCommand(HostName = sia-svr-ct01,
>SpmStatusVDSCommandParameters:{hostId='2a97ece4-c83e-4107-ac0d-915757c17f16',
>storagePoolId='cdeb9ed3-60ab-441e-8026-de62e6aa8022'})' execution
>failed: VDSGenericException: VDSNetworkException: Message timeout which
>can be caused by communication issues
>2020-07-15 11:42:00,484+02 INFO 
>[org.ovirt.vdsm.jsonrpc.client.reactors.ReactorClient] (SSL Stomp
>Reactor) [] Connecting to sia-svr-ct01.afis/10.234.50.133
>2020-07-15 11:42:02,370+02 INFO 
>[org.ovirt.vdsm.jsonrpc.client.reactors.ReactorClient] (SSL Stomp
>Reactor) [] Connecting to sia-svr-ct02.afis/10.234.50.134
>2020-07-15 11:42:02,745+02 INFO 
>[org.ovirt.engine.core.vdsbroker.monitoring.VmAnalyzer]
>(EE-ManagedThreadFactory-engineScheduled-Thread-64) [] VM
>'faf4149e-4e31-40a1-a4ce-f08f03b282c9' is migrating to VDS
>'b8e7c982-f816-4eb0-9634-762cd6956fac'(sia-svr-rc02) ignoring it in the
>refresh until migration is done
>2020-07-15 11:42:17,771+02 INFO 
>[org.ovirt.engine.core.vdsbroker.monitoring.VmAnalyzer]
>(EE-ManagedThreadFactory-engineScheduled-Thread-80) [] VM
>'faf4149e-4e31-40a1-a4ce-f08f03b282c9' is migrating to VDS
>'b8e7c982-f816-4eb0-9634-762cd6956fac'(sia-svr-rc02) ignoring it in the
>refresh until migration is done
>2020-07-15 11:42:20,485+02 WARN 
>[org.ovirt.vdsm.jsonrpc.client.utils.retry.Retryable] (SSL Stomp
>Reactor) [] Retry failed
>2020-07-15 11:42:20,486+02 ERROR
>[org.ovirt.vdsm.jsonrpc.client.reactors.ReactorClient]
>(EE-ManagedThreadFactory-engineScheduled-Thread-62) [] Exception during
>connection
>2020-07-15 11:42:20,487+02 ERROR
>[org.ovirt.engine.core.vdsbroker.irsbroker.IrsBrokerCommand]
>(EE-ManagedThreadFactory-engineScheduled-Thread-62) []
>IrsBroker::Failed::GetStoragePoolInfoVDS
>2020-07-15 11:42:20,487+02 ERROR
>[org.ovirt.engine.core.vdsbroker.irsbroker.GetStoragePoolInfoVDSCommand]
>(EE-ManagedThreadFactory-engineScheduled-Thread-62) [] Command
>'GetStoragePoolInfoVDSCommand(
>GetStoragePoolInfoVDSCommandParameters:{storagePoolId='cdeb9ed3-60ab-441e-8026-de62e6aa8022',
>ignoreFailoverLimit='true'})' execution failed: IRSProtocolException:
>2020-07-15 11:42:20,497+02 ERROR
>[org.ovirt.engine.core.vdsbroker.monitoring.HostMonitoring]
>(EE-ManagedThreadFactory-engineScheduled-Thread-81) [] Unable to
>RefreshCapabilities: VDSNetworkException: VDSGenericException:
>VDSNetworkException: Connection issue Connection timeout
>2020-07-15 11:42:22,370+02 WARN 
>[org.ovirt.vdsm.jsonrpc.client.utils.retry.Retryable] (SSL Stomp
>Reactor) [] Retry failed
>2020-07-15 11:42:22,370+02 ERROR
>[org.ovirt.vdsm.jsonrpc.client.reactors.ReactorClient]
>(EE-ManagedThreadFactory-engineScheduled-Thread-37) [] Exception during
>connection
>2020-07-15 11:42:22,371+02 ERROR
>[org.ovirt.engine.core.vdsbroker.monitoring.HostMonitoring]
>(EE-ManagedThreadFactory-engineScheduled-Thread-37) [] Unable to
>RefreshCapabilities: ConnectException: Connection timeout
>2020-07-15 11:42:22,373+02 ERROR
>[org.ovirt.engine.core.vdsbroker.vdsbroker.GetCapabilitiesAsyncVDSCommand]
>(EE-ManagedThreadFactory-engineScheduled-Thread-37) [] Command
>'GetCapabilitiesAsyncVDSCommand(HostName = sia-svr-ct02,
>VdsIdAndVdsVDSCommandParametersBase:{hostId='9e65ad71-f633-4be3-aa74-a7fc51b285e6',
>vds='Host[sia-svr-ct02,9e65ad71-f633-4be3-aa74-a7fc51b285e6]'})'
>execution failed: java.rmi.ConnectException: Connection timeout
>2020-07-15 

[ovirt-users] Re: ovirt 4.4.1.1 hci and problems with ansible 2.9.10 and/or missing python2

2020-07-17 Thread Gianluca Cecchi
On Fri, Jul 17, 2020 at 11:25 AM Gianluca Cecchi 
wrote:

> On Fri, Jul 17, 2020 at 11:04 AM Gianluca Cecchi <
> gianluca.cec...@gmail.com> wrote:
>
>> On Fri, Jul 17, 2020 at 10:58 AM Gianluca Cecchi <
>> gianluca.cec...@gmail.com> wrote:
>>
>>> On Fri, Jul 17, 2020 at 10:54 AM Martin Perina 
>>> wrote:
>>>
 Hi Gianluca,

 that's very strange error, because I'm 100% sure we are using yum
 module with Python3 in several other roles including adding host to engine
 or upgrading host and so far I haven't heard any issue with ansible 2.9.10
 and yum module.

 Gobinda, wouldn't enforcing python interpreter version help there?


 https://github.com/oVirt/ovirt-engine/blob/master/packaging/ansible-runner-service-project/project/roles/ovirt-host-deploy-facts/tasks/main.yml#L28

 Regards,
 Martin


>>> I have a very clean install from 4.1.1.1 node ng iso anf I'm the third
>>> to notice that with this release.
>>> The engine deployment is going on. Not finished yet, but to have ti go I
>>> had to modify, with the same strategy ("use: dnf" with package module and
>>> use "package" instead of "yum" and also specifying "use: dnf") in these
>>> files under /usr/share/ansible/roles:
>>>
>>> ovirt.engine-setup/tasks/engine_setup.yml
>>> ovirt.engine-setup/tasks/install_packages.yml
>>> ovirt.hosted_engine_setup/tasks/install_packages.yml
>>>
>>> ovirt.hosted_engine_setup/tasks/create_target_vm/03_hosted_engine_final_tasks.yml
>>> ovirt.hosted_engine_setup/tasks/install_appliance.yml
>>>
>>> Gianluca
>>>
>>
>> The installation from the iso was with all default values.
>> The only "non standard" thing, if we want it to call this way is that
>> before running the wizard, on the host I pre-installed the appliance
>> package, to shorten the deploy phase hereafter.
>> And to do it I executed, because of habit:
>> yum install ovirt-engine-appliance
>>
>> instead of "dnf install...", but I think this doesn't influence ansible
>> autodetect when using "package" module or the error about python2 when
>> using "yum" module...
>>
>> Gianluca
>>
>
> The engine deployment failed in the phase where it tries to add the host
> and waits for the host to be up and if I go into the logs in
>
> /var/log/ovirt-hosted-engine-setup/engine-logs-2020-07-17T08:30:48Z/ovirt-engine/host-deploy/
>
> the file
> ovirt-host-deploy-ansible-20200717104103-novirt2.example.net-3a710f0c.log
> contains
>
> 020-07-17 10:41:17 CEST - fatal: [novirt2.example.net]: FAILED! =>
> {"changed": false, "module_stderr": "/bin/sh: /usr/bin
> /python2: No such file or directory\n", "module_stdout": "", "msg": "The
> module failed to execute correctly, you probably
> need to set the interpreter.\nSee stdout/stderr for the exact error",
> "rc": 127}
> 2020-07-17 10:41:17 CEST - {
>   "status" : "OK",
>   "msg" : "",
>   "data" : {
> "uuid" : "00f4c6a8-8423-4a2a-bfd5-f38c34f56ecf",
> "counter" : 53,
> "stdout" : "fatal: [novirt2.example.net]: FAILED! => {\"changed\":
> false, \"module_stderr\": \"/bin/sh: /usr/bin/pytho
> n2: No such file or directory\\n\", \"module_stdout\": \"\", \"msg\":
> \"The module failed to execute correctly, you probab
> ly need to set the interpreter.\\nSee stdout/stderr for the exact error\",
> \"rc\": 127}",
>
> So I think I have to find and solve why it searches python2
> I compared on an existing 4.4.0 environment I have (hci single node
> installed from 4.4.0 node ng iso) and no python2 apparently there, only
> ansible that is at  ansible-2.9.9-1.el8.noarch instead of
> ansible-2.9.10-1.el8.noarch of 4.4.1.1
>
> Possibly any wrong default about python?
>
> Alternatives seems the same between 4.4.0 and 4.4.1.1
>
> 4.4.0
> [g.cecchi@ovirt01 ~]$ alternatives --list
> cifs-idmap-plugin auto   /usr/lib64/cifs-utils/cifs_idmap_sss.so
> ifup   auto   /etc/sysconfig/network-scripts/ifup
> ld auto   /usr/bin/ld.bfd
> libnssckbi.so.x86_64   auto   /usr/lib64/pkcs11/p11-kit-trust.so
> libwbclient.so.0.15-64 auto   /usr/lib64/samba/wbclient/libwbclient.so.0.15
> mkisofs   auto   /usr/bin/genisoimage
> mta   auto   /usr/sbin/sendmail.postfix
> nmap   auto   /usr/bin/ncat
> python auto   /usr/libexec/no-python
> python3   auto   /usr/bin/python3.6
> [g.cecchi@ovirt01 ~]$
>
> 4.4.1.1
> [root@novirt2 host-deploy]# alternatives --list
> cifs-idmap-plugin auto   /usr/lib64/cifs-utils/cifs_idmap_sss.so
> ifup   auto   /etc/sysconfig/network-scripts/ifup
> ld auto   /usr/bin/ld.bfd
> libnssckbi.so.x86_64   auto   /usr/lib64/pkcs11/p11-kit-trust.so
> libwbclient.so.0.15-64 auto   /usr/lib64/samba/wbclient/libwbclient.so.0.15
> mkisofs   auto   /usr/bin/genisoimage
> mta   auto   /usr/sbin/sendmail.postfix
> nmap   auto   /usr/bin/ncat
> python auto   /usr/libexec/no-python
> 

[ovirt-users] Re: ovirt 4.4.1.1 hci and problems with ansible 2.9.10 and/or missing python2

2020-07-17 Thread Gianluca Cecchi
On Fri, Jul 17, 2020 at 11:04 AM Gianluca Cecchi 
wrote:

> On Fri, Jul 17, 2020 at 10:58 AM Gianluca Cecchi <
> gianluca.cec...@gmail.com> wrote:
>
>> On Fri, Jul 17, 2020 at 10:54 AM Martin Perina 
>> wrote:
>>
>>> Hi Gianluca,
>>>
>>> that's very strange error, because I'm 100% sure we are using yum module
>>> with Python3 in several other roles including adding host to engine or
>>> upgrading host and so far I haven't heard any issue with ansible 2.9.10 and
>>> yum module.
>>>
>>> Gobinda, wouldn't enforcing python interpreter version help there?
>>>
>>>
>>> https://github.com/oVirt/ovirt-engine/blob/master/packaging/ansible-runner-service-project/project/roles/ovirt-host-deploy-facts/tasks/main.yml#L28
>>>
>>> Regards,
>>> Martin
>>>
>>>
>> I have a very clean install from 4.1.1.1 node ng iso anf I'm the third to
>> notice that with this release.
>> The engine deployment is going on. Not finished yet, but to have ti go I
>> had to modify, with the same strategy ("use: dnf" with package module and
>> use "package" instead of "yum" and also specifying "use: dnf") in these
>> files under /usr/share/ansible/roles:
>>
>> ovirt.engine-setup/tasks/engine_setup.yml
>> ovirt.engine-setup/tasks/install_packages.yml
>> ovirt.hosted_engine_setup/tasks/install_packages.yml
>>
>> ovirt.hosted_engine_setup/tasks/create_target_vm/03_hosted_engine_final_tasks.yml
>> ovirt.hosted_engine_setup/tasks/install_appliance.yml
>>
>> Gianluca
>>
>
> The installation from the iso was with all default values.
> The only "non standard" thing, if we want it to call this way is that
> before running the wizard, on the host I pre-installed the appliance
> package, to shorten the deploy phase hereafter.
> And to do it I executed, because of habit:
> yum install ovirt-engine-appliance
>
> instead of "dnf install...", but I think this doesn't influence ansible
> autodetect when using "package" module or the error about python2 when
> using "yum" module...
>
> Gianluca
>

The engine deployment failed in the phase where it tries to add the host
and waits for the host to be up and if I go into the logs in
/var/log/ovirt-hosted-engine-setup/engine-logs-2020-07-17T08:30:48Z/ovirt-engine/host-deploy/

the file
ovirt-host-deploy-ansible-20200717104103-novirt2.example.net-3a710f0c.log
contains

020-07-17 10:41:17 CEST - fatal: [novirt2.example.net]: FAILED! =>
{"changed": false, "module_stderr": "/bin/sh: /usr/bin
/python2: No such file or directory\n", "module_stdout": "", "msg": "The
module failed to execute correctly, you probably
need to set the interpreter.\nSee stdout/stderr for the exact error", "rc":
127}
2020-07-17 10:41:17 CEST - {
  "status" : "OK",
  "msg" : "",
  "data" : {
"uuid" : "00f4c6a8-8423-4a2a-bfd5-f38c34f56ecf",
"counter" : 53,
"stdout" : "fatal: [novirt2.example.net]: FAILED! => {\"changed\":
false, \"module_stderr\": \"/bin/sh: /usr/bin/pytho
n2: No such file or directory\\n\", \"module_stdout\": \"\", \"msg\": \"The
module failed to execute correctly, you probab
ly need to set the interpreter.\\nSee stdout/stderr for the exact error\",
\"rc\": 127}",

So I think I have to find and solve why it searches python2
I compared on an existing 4.4.0 environment I have (hci single node
installed from 4.4.0 node ng iso) and no python2 apparently there, only
ansible that is at  ansible-2.9.9-1.el8.noarch instead of
ansible-2.9.10-1.el8.noarch of 4.4.1.1

Possibly any wrong default about python?

Alternatives seems the same between 4.4.0 and 4.4.1.1

4.4.0
[g.cecchi@ovirt01 ~]$ alternatives --list
cifs-idmap-plugin auto   /usr/lib64/cifs-utils/cifs_idmap_sss.so
ifup   auto   /etc/sysconfig/network-scripts/ifup
ld auto   /usr/bin/ld.bfd
libnssckbi.so.x86_64   auto   /usr/lib64/pkcs11/p11-kit-trust.so
libwbclient.so.0.15-64 auto   /usr/lib64/samba/wbclient/libwbclient.so.0.15
mkisofs   auto   /usr/bin/genisoimage
mta   auto   /usr/sbin/sendmail.postfix
nmap   auto   /usr/bin/ncat
python auto   /usr/libexec/no-python
python3   auto   /usr/bin/python3.6
[g.cecchi@ovirt01 ~]$

4.4.1.1
[root@novirt2 host-deploy]# alternatives --list
cifs-idmap-plugin auto   /usr/lib64/cifs-utils/cifs_idmap_sss.so
ifup   auto   /etc/sysconfig/network-scripts/ifup
ld auto   /usr/bin/ld.bfd
libnssckbi.so.x86_64   auto   /usr/lib64/pkcs11/p11-kit-trust.so
libwbclient.so.0.15-64 auto   /usr/lib64/samba/wbclient/libwbclient.so.0.15
mkisofs   auto   /usr/bin/genisoimage
mta   auto   /usr/sbin/sendmail.postfix
nmap   auto   /usr/bin/ncat
python auto   /usr/libexec/no-python
python3   auto   /usr/bin/python3.6
[root@novirt2 host-deploy]#

Not sure where to search if not somehow a bug of ansible 2.9.10
Can I try to clean install a 4.4.1.1 host and downgrade ansible before
deploy, eg running

rpm -Uvh --oldpackage 

[ovirt-users] Re: ovirt 4.4.1.1 hci and problems with ansible 2.9.10 and/or missing python2

2020-07-17 Thread Gianluca Cecchi
On Fri, Jul 17, 2020 at 10:58 AM Gianluca Cecchi 
wrote:

> On Fri, Jul 17, 2020 at 10:54 AM Martin Perina  wrote:
>
>> Hi Gianluca,
>>
>> that's very strange error, because I'm 100% sure we are using yum module
>> with Python3 in several other roles including adding host to engine or
>> upgrading host and so far I haven't heard any issue with ansible 2.9.10 and
>> yum module.
>>
>> Gobinda, wouldn't enforcing python interpreter version help there?
>>
>>
>> https://github.com/oVirt/ovirt-engine/blob/master/packaging/ansible-runner-service-project/project/roles/ovirt-host-deploy-facts/tasks/main.yml#L28
>>
>> Regards,
>> Martin
>>
>>
> I have a very clean install from 4.1.1.1 node ng iso anf I'm the third to
> notice that with this release.
> The engine deployment is going on. Not finished yet, but to have ti go I
> had to modify, with the same strategy ("use: dnf" with package module and
> use "package" instead of "yum" and also specifying "use: dnf") in these
> files under /usr/share/ansible/roles:
>
> ovirt.engine-setup/tasks/engine_setup.yml
> ovirt.engine-setup/tasks/install_packages.yml
> ovirt.hosted_engine_setup/tasks/install_packages.yml
>
> ovirt.hosted_engine_setup/tasks/create_target_vm/03_hosted_engine_final_tasks.yml
> ovirt.hosted_engine_setup/tasks/install_appliance.yml
>
> Gianluca
>

The installation from the iso was with all default values.
The only "non standard" thing, if we want it to call this way is that
before running the wizard, on the host I pre-installed the appliance
package, to shorten the deploy phase hereafter.
And to do it I executed, because of habit:
yum install ovirt-engine-appliance

instead of "dnf install...", but I think this doesn't influence ansible
autodetect when using "package" module or the error about python2 when
using "yum" module...

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


[ovirt-users] Re: ovirt 4.4.1.1 hci and problems with ansible 2.9.10 and/or missing python2

2020-07-17 Thread Gianluca Cecchi
On Fri, Jul 17, 2020 at 10:54 AM Martin Perina  wrote:

> Hi Gianluca,
>
> that's very strange error, because I'm 100% sure we are using yum module
> with Python3 in several other roles including adding host to engine or
> upgrading host and so far I haven't heard any issue with ansible 2.9.10 and
> yum module.
>
> Gobinda, wouldn't enforcing python interpreter version help there?
>
>
> https://github.com/oVirt/ovirt-engine/blob/master/packaging/ansible-runner-service-project/project/roles/ovirt-host-deploy-facts/tasks/main.yml#L28
>
> Regards,
> Martin
>
>
I have a very clean install from 4.1.1.1 node ng iso anf I'm the third to
notice that with this release.
The engine deployment is going on. Not finished yet, but to have ti go I
had to modify, with the same strategy ("use: dnf" with package module and
use "package" instead of "yum" and also specifying "use: dnf") in these
files under /usr/share/ansible/roles:

ovirt.engine-setup/tasks/engine_setup.yml
ovirt.engine-setup/tasks/install_packages.yml
ovirt.hosted_engine_setup/tasks/install_packages.yml
ovirt.hosted_engine_setup/tasks/create_target_vm/03_hosted_engine_final_tasks.yml
ovirt.hosted_engine_setup/tasks/install_appliance.yml

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


[ovirt-users] Re: ovirt 4.4.1.1 hci and problems with ansible 2.9.10 and/or missing python2

2020-07-17 Thread Martin Perina
Hi Gianluca,

that's very strange error, because I'm 100% sure we are using yum module
with Python3 in several other roles including adding host to engine or
upgrading host and so far I haven't heard any issue with ansible 2.9.10 and
yum module.

Gobinda, wouldn't enforcing python interpreter version help there?

https://github.com/oVirt/ovirt-engine/blob/master/packaging/ansible-runner-service-project/project/roles/ovirt-host-deploy-facts/tasks/main.yml#L28

Regards,
Martin


On Fri, Jul 17, 2020 at 10:22 AM Gianluca Cecchi 
wrote:

> Same problem for the next stage
>
> [ INFO ] TASK [ovirt.hosted_engine_setup : Install oVirt Hosted Engine
> packages]
> [ ERROR ] fatal: [localhost]: FAILED! => {"attempts": 10, "changed":
> false, "msg": "The Python 2 yum module is needed for this module. If you
> require Python 3 support use the `dnf` Ansible module instead."}
>
> I think this is a major problem for new installations.
> How can I get back python2 to see if it works without having to go through
> all yaml files?
>
> Gianluca
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@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/QJ54NVDAGWXXPCT7AHEJIQYQR5IZ5IZU/
>


-- 
Martin Perina
Manager, Software Engineering
Red Hat Czech s.r.o.
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@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/EY6SIF3FFRQ6PVMRNH3TJJUZAXABCKCD/


[ovirt-users] Re: ovirt 4.4.1.1 hci and problems with ansible 2.9.10 and/or missing python2

2020-07-17 Thread Gianluca Cecchi
Same problem for the next stage

[ INFO ] TASK [ovirt.hosted_engine_setup : Install oVirt Hosted Engine
packages]
[ ERROR ] fatal: [localhost]: FAILED! => {"attempts": 10, "changed": false,
"msg": "The Python 2 yum module is needed for this module. If you require
Python 3 support use the `dnf` Ansible module instead."}

I think this is a major problem for new installations.
How can I get back python2 to see if it works without having to go through
all yaml files?

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


[ovirt-users] Re: oVirt Node 4.4.1.1 Cockpit Hyperconverged Gluster deploy fails insufficient free space no matter how small the volume is set

2020-07-17 Thread Gianluca Cecchi
On Fri, Jul 17, 2020 at 10:09 AM Strahil Nikolov via Users 
wrote:

> What version of CentOS 8 are you using -> Stream or regular, version ?
>
> Best Regards,
> Strahil Nikolov


Strahil, see the other thread I have just opened.
It happens also to me with latest oVirt node iso for 4.4.1.1 dated 13/07
In my opinion there is a major problem with all yaml files using yum and
package modules:
- yum because it expects python2 that is missing
- package because it doesn't autodetect dnf and tries yum and fails for the
same reason above

A possible workaround for not modifying all yaml files is to install
python2; I don't know if a channel could be enabled to have python2 back

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


[ovirt-users] Re: oVirt Node 4.4.1.1 Cockpit Hyperconverged Gluster deploy fails insufficient free space no matter how small the volume is set

2020-07-17 Thread Strahil Nikolov via Users
What version of CentOS 8 are you using -> Stream or regular, version ?

Best Regards,
Strahil Nikolov

На 16 юли 2020 г. 21:07:57 GMT+03:00, "Dominique Deschênes" 
 написа:
>
>
>HI, 
>Thank you for your answers
>
>I tried to replace the "package" with "dnf".  the installation of the
>gluster seems to work well but I had the similar message during the
>deployment of the Hosted engine.
>
>Here is the error
>
>[ ERROR ] fatal: [localhost]: FAILED! => {"attempts": 10, "changed":
>false, "msg": "The Python 2 yum module is needed for this module. If
>you require Python 3 support use the `dnf` Ansible module instead."} 
>
>
>
>
>
>Dominique Deschênes
>Ingénieur chargé de projets, Responsable TI
>816, boulevard Guimond, Longueuil J4G 1T5
> 450 670-8383 x105  450 670-2259
>
>
>          
>
>- Message reçu -
>De: clam2...@gmail.com
>Date: 16/07/20 13:40
>À: users@ovirt.org
>Objet: [ovirt-users] Re: oVirt Node 4.4.1.1 Cockpit Hyperconverged
>Gluster deploy fails insufficient free space no matter how small the
>volume is set
>
>Dear Strahil, Dominique and Edward:
>
>I reimaged the three hosts with
>ovirt-node-ng-installer-4.4.1-2020071311.el8.iso just to be sure
>everything was stock (I had upgraded from v4.4) and attempted a
>redeploy with all suggested changes EXCEPT replacing "package" with
>"dnf" --> same failure.  I then made Strahil's recommended replacement
>of "package" with "dnf" and the Gluster deployment succeeded through
>that section of main.yml only to fail a little later at:
>
>- name: Install python-yaml package for Debian systems
> package:
>   name: python-yaml
>   state: present
> when: ansible_distribution == "Debian" or ansible_distribution ==
>"Ubuntu"
>
>I found this notable given that I had not replaced "package" with "dnf"
>in the prior section:
>
>- name: Change to Install lvm tools for debian systems.
> package:
>   name: thin-provisioning-tools
>   state: present
> when: ansible_distribution == "Debian" or ansible_distribution ==
>"Ubuntu"
>
>and deployment had not failed here.  Anyhow, I deleted the two Debian
>statements as I am deploying from Node (CentOS based), cleaned up,
>cleaned up my drives ('dmsetup remove eui.xxx...' and 'wipefs --all
>--force /dev/nvme0n1 /dev/nvmeXn1 ...')  and redeployed again.  This
>time Gluster deployment seemed to execute main.yml OK only to fail in a
>new file, vdo_create.yml:
>
>TASK [gluster.infra/roles/backend_setup : Install VDO dependencies]
>
>task path:
>/etc/ansible/roles/gluster.infra/roles/backend_setup/tasks/vdo_create.yml:26
>fatal: [fmov1n1.sn.dtcorp.com]: FAILED! => {"changed": false, "msg":
>"The Python 2 yum module is needed for this module. If you require
>Python 3 support use the `dnf` Ansible module instead."}
>fatal: [fmov1n3.sn.dtcorp.com]: FAILED! => {"changed": false, "msg":
>"The Python 2 yum module is needed for this module. If you require
>Python 3 support use the `dnf` Ansible module instead."}
>fatal: [fmov1n2.sn.dtcorp.com]: FAILED! => {"changed": false, "msg":
>"The Python 2 yum module is needed for this module. If you require
>Python 3 support use the `dnf` Ansible module instead."}
>
>Expecting that this might continue, I have been looking into the
>documentation of how "package" works and if I can find a root cause for
>this rather than reviewing n *.yml files and replacing "package" with
>"dnf" in all of them.  Thank you VERY much to Strahil for helping me!
>
>If Strahil or anyone else has any additional troubleshooting tips,
>suggestions, insight or solutions I am all ears.  I will continue to
>update as I progress.
>
>Respectfully,
>Charles
>___
>Users mailing list -- users@ovirt.org
>To unsubscribe send an email to users-le...@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/3JTZX2OF4JTGRECMZLZXZQT5IWR4PFSG/
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@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/KABMZ6EJIEQJMIYCG6MUPTCKHIZOHI65/


[ovirt-users] ovirt 4.4.1.1 hci and problems with ansible 2.9.10 and/or missing python2

2020-07-17 Thread Gianluca Cecchi
Hello,
today I wanted to test a single host hci install using
ovirt-node-ng-installer-4.4.1-2020071311.el8.iso
On this same environment 4.4.0 gui wizard worked ok, apart a final problem
with cpu flags and final engine boot up, so I wanted to verify if all is ok
now, because that problem should have been fixed

But I incurred in the same problems recently discussed here:

https://lists.ovirt.org/archives/list/users@ovirt.org/message/3AARZD4VBNNHWNWRCVD2QNWQZJYY5AL5/

The first part failed because of

TASK [gluster.infra/roles/backend_setup : Change to Install lvm tools for
RHEL systems.] ***
fatal: [novirt2st.storage.local]: FAILED! => {"changed": false, "msg": "The
Python 2 yum module is needed for this module. If you require Python 3
support use the `dnf` Ansible module instead."}

To have the first stage work (now I have to continue with the "Continue to
Hosted Engine Deployment" step) I have to modify:

- /etc/ansible/roles/gluster.infra/roles/backend_setup/tasks/main.yml
force to use dnf as package manager. For some reason not automatically
detected by the "package" ansible module
from
- name: Change to Install lvm tools for RHEL systems.
  package:
name: device-mapper-persistent-data
state: present
  when: ansible_os_family == 'RedHat'

to
- name: Change to Install lvm tools for RHEL systems.
  package:
name: device-mapper-persistent-data
state: present
use: dnf
  when: ansible_os_family == 'RedHat'

- /etc/ansible/roles/gluster.infra/roles/backend_setup/tasks/vdo_create.yml
change from yum to package and specify to use dnf

from:
- name: Install VDO dependencies
  #maybe use package module?
  yum:
   name: "{{ packages }}"
  register: vdo_deps
...

to:
- name: Install VDO dependencies
  #maybe use package module?
  package:
   name: "{{ packages }}"
   use: dnf
  register: vdo_deps
...

So in my opinion a bug has to be opened if not already done.

The root cause being or for any reason ansible 2.9.10 that recently updated
2.9.9 or having removed python2 modules from the distribution, that before
was for some reason silently used with yum, while not using the expected
dnf module with package

I'm going to test if in the next phase any further modification has to be
done.
Gianluca
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@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/ROTLHVLIXQENVPSB4QBUX3QBKDFPQ5KJ/


[ovirt-users] Re: VDSM HOST ISSUE - Message timeout which can be caused by communication issues

2020-07-17 Thread lu . alfonsi
2020-07-15 11:41:58,968+02 ERROR 
[org.ovirt.engine.core.vdsbroker.monitoring.HostMonitoring] 
(EE-ManagedThreadFactory-engineScheduled-Thread-79) [] Unable to 
RefreshCapabilities: VDSNetworkException: VDSGenericException: 
VDSNetworkException: Message timeout which can be caused by communication issues
2020-07-15 11:41:59,350+02 WARN  
[org.ovirt.vdsm.jsonrpc.client.utils.retry.Retryable] (SSL Stomp Reactor) [] 
Retry failed
2020-07-15 11:41:59,350+02 ERROR 
[org.ovirt.vdsm.jsonrpc.client.reactors.ReactorClient] 
(EE-ManagedThreadFactory-engineScheduled-Thread-59) [] Exception during 
connection
2020-07-15 11:41:59,351+02 ERROR 
[org.ovirt.engine.core.vdsbroker.monitoring.HostMonitoring] 
(EE-ManagedThreadFactory-engineScheduled-Thread-59) [] Unable to 
RefreshCapabilities: ConnectException: Connection timeout
2020-07-15 11:41:59,354+02 ERROR 
[org.ovirt.engine.core.vdsbroker.vdsbroker.GetCapabilitiesAsyncVDSCommand] 
(EE-ManagedThreadFactory-engineScheduled-Thread-59) [] Command 
'GetCapabilitiesAsyncVDSCommand(HostName = sia-svr-ct02, 
VdsIdAndVdsVDSCommandParametersBase:{hostId='9e65ad71-f633-4be3-aa74-a7fc51b285e6',
 vds='Host[sia-svr-ct02,9e65ad71-f633-4be3-aa74-a7fc51b285e6]'})' execution 
failed: java.rmi.ConnectException: Connection timeout
2020-07-15 11:42:00,465+02 ERROR 
[org.ovirt.engine.core.vdsbroker.vdsbroker.SpmStatusVDSCommand] 
(EE-ManagedThreadFactory-engineScheduled-Thread-62) [] Command 
'SpmStatusVDSCommand(HostName = sia-svr-ct01, 
SpmStatusVDSCommandParameters:{hostId='2a97ece4-c83e-4107-ac0d-915757c17f16', 
storagePoolId='cdeb9ed3-60ab-441e-8026-de62e6aa8022'})' execution failed: 
VDSGenericException: VDSNetworkException: Message timeout which can be caused 
by communication issues
2020-07-15 11:42:00,484+02 INFO  
[org.ovirt.vdsm.jsonrpc.client.reactors.ReactorClient] (SSL Stomp Reactor) [] 
Connecting to sia-svr-ct01.afis/10.234.50.133
2020-07-15 11:42:02,370+02 INFO  
[org.ovirt.vdsm.jsonrpc.client.reactors.ReactorClient] (SSL Stomp Reactor) [] 
Connecting to sia-svr-ct02.afis/10.234.50.134
2020-07-15 11:42:02,745+02 INFO  
[org.ovirt.engine.core.vdsbroker.monitoring.VmAnalyzer] 
(EE-ManagedThreadFactory-engineScheduled-Thread-64) [] VM 
'faf4149e-4e31-40a1-a4ce-f08f03b282c9' is migrating to VDS 
'b8e7c982-f816-4eb0-9634-762cd6956fac'(sia-svr-rc02) ignoring it in the refresh 
until migration is done
2020-07-15 11:42:17,771+02 INFO  
[org.ovirt.engine.core.vdsbroker.monitoring.VmAnalyzer] 
(EE-ManagedThreadFactory-engineScheduled-Thread-80) [] VM 
'faf4149e-4e31-40a1-a4ce-f08f03b282c9' is migrating to VDS 
'b8e7c982-f816-4eb0-9634-762cd6956fac'(sia-svr-rc02) ignoring it in the refresh 
until migration is done
2020-07-15 11:42:20,485+02 WARN  
[org.ovirt.vdsm.jsonrpc.client.utils.retry.Retryable] (SSL Stomp Reactor) [] 
Retry failed
2020-07-15 11:42:20,486+02 ERROR 
[org.ovirt.vdsm.jsonrpc.client.reactors.ReactorClient] 
(EE-ManagedThreadFactory-engineScheduled-Thread-62) [] Exception during 
connection
2020-07-15 11:42:20,487+02 ERROR 
[org.ovirt.engine.core.vdsbroker.irsbroker.IrsBrokerCommand] 
(EE-ManagedThreadFactory-engineScheduled-Thread-62) [] 
IrsBroker::Failed::GetStoragePoolInfoVDS
2020-07-15 11:42:20,487+02 ERROR 
[org.ovirt.engine.core.vdsbroker.irsbroker.GetStoragePoolInfoVDSCommand] 
(EE-ManagedThreadFactory-engineScheduled-Thread-62) [] Command 
'GetStoragePoolInfoVDSCommand( 
GetStoragePoolInfoVDSCommandParameters:{storagePoolId='cdeb9ed3-60ab-441e-8026-de62e6aa8022',
 ignoreFailoverLimit='true'})' execution failed: IRSProtocolException:
2020-07-15 11:42:20,497+02 ERROR 
[org.ovirt.engine.core.vdsbroker.monitoring.HostMonitoring] 
(EE-ManagedThreadFactory-engineScheduled-Thread-81) [] Unable to 
RefreshCapabilities: VDSNetworkException: VDSGenericException: 
VDSNetworkException: Connection issue Connection timeout
2020-07-15 11:42:22,370+02 WARN  
[org.ovirt.vdsm.jsonrpc.client.utils.retry.Retryable] (SSL Stomp Reactor) [] 
Retry failed
2020-07-15 11:42:22,370+02 ERROR 
[org.ovirt.vdsm.jsonrpc.client.reactors.ReactorClient] 
(EE-ManagedThreadFactory-engineScheduled-Thread-37) [] Exception during 
connection
2020-07-15 11:42:22,371+02 ERROR 
[org.ovirt.engine.core.vdsbroker.monitoring.HostMonitoring] 
(EE-ManagedThreadFactory-engineScheduled-Thread-37) [] Unable to 
RefreshCapabilities: ConnectException: Connection timeout
2020-07-15 11:42:22,373+02 ERROR 
[org.ovirt.engine.core.vdsbroker.vdsbroker.GetCapabilitiesAsyncVDSCommand] 
(EE-ManagedThreadFactory-engineScheduled-Thread-37) [] Command 
'GetCapabilitiesAsyncVDSCommand(HostName = sia-svr-ct02, 
VdsIdAndVdsVDSCommandParametersBase:{hostId='9e65ad71-f633-4be3-aa74-a7fc51b285e6',
 vds='Host[sia-svr-ct02,9e65ad71-f633-4be3-aa74-a7fc51b285e6]'})' execution 
failed: java.rmi.ConnectException: Connection timeout
2020-07-15 11:42:25,384+02 INFO  
[org.ovirt.vdsm.jsonrpc.client.reactors.ReactorClient] (SSL Stomp Reactor) [] 
Connecting to sia-svr-ct02.afis/10.234.50.134
2020-07-15 11:42:32,805+02 INFO  

[ovirt-users] Re: qemu-guest-agent on Ubuntu doesn't report FQDN

2020-07-17 Thread Sandro Bonazzola
Il giorno gio 16 lug 2020 alle ore 15:55 Florian Schmid via Users <
users@ovirt.org> ha scritto:

> Hi,
>
> I have a problem with Ubuntu 20.04 VM reporting the correct FQDN to the
> engine.
> Starting with this release, the ovirt-guest-agent is not available anymore.
>
> Therefore, I have installed qemu-geust-agent with package defaults.
>
> Now in the Engine, I only see the hostname under FQDN tab, instead the
> real full name with domain.
>
> I'm running an oVirt environment on 4.3.8.
>
> The VM is resolveable, forward and reverse DNS entries are working.
> hostname -f shows the correct FQDN.
>
> Even adding IP and FQDN to /etc/hosts file doesn't change anything.
>
> qemu-guest-agent version: 4.2-3ubuntu6.3
>
> I manage this VM via ansible 2.9 and ansible is able to get the FQDN of
> the VM without any issues...
>
> What can I do here to debug my issue?
> Does the engine cache the wrong result? Even after stopping and starting
> the VM again, engine is only showing the hostname instead of the FQDN.
>
>
+Tomas Golembiovsky  can you help here?




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


-- 

Sandro Bonazzola

MANAGER, SOFTWARE ENGINEERING, EMEA R RHV

Red Hat EMEA 

sbona...@redhat.com


*Red Hat respects your work life balance. Therefore there is no need to
answer this email out of your office hours.
*
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@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/CFOULE62AQOYYX2ODM3RVYGBGJVOH4Z2/


[ovirt-users] Re: Strange SD problem

2020-07-17 Thread Arsène Gschwind
Hi,

I have some running VM on it, this isn't easy...
If I remove that LUN from the SD, what will happen to the disk defined in that 
SD? will they get lost?


On Thu, 2020-07-16 at 17:58 +0300, Ahmad Khiet wrote:
Hi,
if its the same LUN, then why not remove and import back?


On Thu, Jul 16, 2020 at 3:21 PM Arsène Gschwind 
mailto:arsene.gschw...@unibas.ch>> wrote:
Hi,

We did compare engine backups and found some differences in the LUNs

"public"."luns"  (restored db from 2020.04.09)


physical_volume_id  lun_idvolume_group_id   
serial lun_mapping  
vendor_id   product_id   device_sizediscard_max_size

wEx3tY-OELy-gOtD-CFDp-az4D-EyYO-1SAAqd  repl_HanaDB_osd_01
a1q5Jr-Bd7h-wEVJ-9b0C-Ggnr-M1JI-kyXeDVSHUAWEI_XSG1_2102350RMG10HC210053 
 6HUAWEI  XSG1 4096   268435456

DPUtaW-Q5zp-aZos-HriP-5Z0v-hiWO-w7rmwG  repl_HanaLogs_osd_01  
4TCXZ7-R1l1-xkdU-u0vx-S3n4-JWcE-qksPd1SHUAWEI_XSG1_2102350RMG10HC200035 
 7HUAWEI  XSG1 2048   268435456


"public"."luns"  (current db)



physical_volume_id  lun_idvolume_group_id   
serial lun_mapping  
vendor_id   product_id   device_sizediscard_max_size

wEx3tY-OELy-gOtD-CFDp-az4D-EyYO-1SAAqd  repl_HanaDB_osd_01
a1q5Jr-Bd7h-wEVJ-9b0C-Ggnr-M1JI-kyXeDVSHUAWEI_XSG1_2102350RMG10HC210053 
 6HUAWEI  XSG1 4096   268435456

repl_HanaLogs_osd_01
SHUAWEI_XSG1_2102350RMG10HC210054  7
HUAWEI  XSG1 2548   268435456

We observed that the physical_volume_id and volume_group_id is missing from the 
corrupt SD.
We also observed that the serial has changed on the corrupted SD/LUN.
Is the serial calculated or read somewhere?
Would it be possible to inject the missing values in the engine DB to recover 
to a consistent state?

Thanks for any help.
Arsene


On Wed, 2020-07-15 at 13:24 +0300, Ahmad Khiet wrote:
Hi Arsène,

can you please send which version are you referring to?

as shown in the log: Storage domains with IDs 
[6b82f31b-fa2a-406b-832d-64d9666e1bcc] could not be synchronized. To 
synchronize them, please move them to maintenance and then activate.
can you put them in maintenance and then activate them back so it will be 
synced?
I guess that it is out of sync, that's why the "Add" button appears to already 
added LUNs



On Tue, Jul 14, 2020 at 4:58 PM Arsène Gschwind 
mailto:arsene.gschw...@unibas.ch>> wrote:
Hi Ahmad,

I did the following:

1. Storage -> Storage Domains
2 Click the existing Storage Domain and click "Manage Domain"
and then I see next to the LUN which is already part of the SD the "Add" button

I do not want to click add since it may destroy the existing SD or the content 
of the LUNs.
In the Engine Log I see the following:


020-07-14 09:57:45,131+02 WARN  
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] 
(EE-ManagedThreadFactory-engine-Thread-20) [277145f2] EVENT_ID: 
STORAGE_DOMAINS_COULD_NOT_BE_SYNCED(1,046), Storage domains with IDs 
[6b82f31b-fa2a-406b-832d-64d9666e1bcc] could not be synchronized. To 
synchronize them, please move them to maintenance and then activate.

Thanks a lot

On Tue, 2020-07-14 at 16:07 +0300, Ahmad Khiet wrote:
Hi Arsène Gschwind,

it's really strange that you see "Add" on a LUN that already has been added to 
the database.
to verify the steps you did make at first,
1- Storage -> Storage Domains
2- New Domain - [ select iSCSI ]
3- click on "+" on the iscsi target, then you see the "Add" button is available
4- after clicking add and ok, then this error will be shown in the logs
is that right?

can you also attach vdsm log?




On Tue, Jul 14, 2020 at 1:15 PM Arsène Gschwind 
mailto:arsene.gschw...@unibas.ch>> wrote:
Hello all,

I've checked all my multipath configuration and everything seems korrekt.
Is there a way to correct this, may be in the DB?

I really need some help, thanks a lot.
Arsène

On Tue, 2020-07-14 at 00:29 +, Arsène Gschwind wrote:
HI,

I'm having a strange behavior with a SD. When trying to manage the SD I see 
they "Add" button for the LUN which should already be the one use for that SD.
In the Logs I see the following:

2020-07-13 17:48:07,292+02 ERROR 
[org.ovirt.engine.core.dal.dbbroker.BatchProcedureExecutionConnectionCallback] 
(EE-ManagedThreadFactory-engine-Thread-95) [51091853] Can't execute batch: 
Batch entry 0 select * from public.insertluns(CAST ('repl_HanaLogs_osd_01' AS 
varchar),CAST ('DPUtaW-Q5zp-aZos-HriP-5Z0v-hiWO-w7rmwG' AS varchar),CAST 
('4TCXZ7-R1l1-xkdU-u0vx-S3n4-JWcE-qksPd1' AS varchar),CAST