On Thu, Aug 27, 2020 at 8:40 PM Vinícius Ferrão via Users <users@ovirt.org>
wrote:

> Hi Michal,
>
> On 27 Aug 2020, at 05:08, Michal Skrivanek <michal.skriva...@redhat.com>
> wrote:
>
>
>
> On 26 Aug 2020, at 20:50, Vinícius Ferrão via Users <users@ovirt.org>
> wrote:
>
> Okay here we go Arik.
>
> With your insight I’ve done the following:
>
> # rpm -Va
>
> This showed what’s zeroed on the machine, since it was a lot of things,
> I’ve just gone crazy and done:
>
>
> you should still have host deploy logs on the engine machine. it’s weird
> it succeeded, unless it somehow happened afterwards?
>
>
> It only succeeded my yum reinstall rampage.
>
> yum list installed | cut -f 1 -d " " > file
> yum -y reinstall `cat file | xargs`
>
> Reinstalled everything.
>
> Everything worked as expected and I finally added the machine back to the
> cluster. It’s operational.
>
>
> eh, I wouldn’t trust it much. did you run redeploy at least?
>
>
> I’ve done reinstall on the web interface of the engine. I can reinstall
> the host, there’s nothing running on it… gonna try a third format.
>
>
>
> Now I’ve another issue, I have 3 VM’s that are ppc64le, when trying to
> import them, the Hosted Engine identifies them as x86_64:
>
> <PastedGraphic-2.png>
>
> So…
>
> This appears to be a bug. Any ideia on how to force it back to ppc64? I
> can’t manually force the import on the Hosted Engine since there’s no
> buttons to do this…
>
>
> how exactly did you import them? could be a bug indeed.
> we don’t support changing it as it doesn’t make sense, the guest can’t be
> converted
>
>
> Yeah. I done the normal procedure, added the storage domain to the engine
> and clicked on “Import VM”. Immediately it was detected as x86_64.
>
> Since I wasn’t able to upgrade my environment from 4.3.10 to 4.4.1 due to
> random errors when redeploying the engine with the backup from 4.3.10, I
> just reinstalled it, reconfigured everything and them imported the storage
> domains.
>
> I don’t know where the information about architecture is stored in the
> storage domain, I tried to search for some metadata files inside the domain
> but nothing come up. Is there a way to force this change? It must be a way.
>
> I even tried to import the machine as x86_64. So I can delete the VM and
> just reattach the disks in a new only, effectively not losing the data, but…
>
>
> Yeah, so something is broken. The check during the import appears to be
> OK, but the interface does not me allow to import it to the ppc64le
> machine, since it’s read as x86_64.
>

Could you please provide the output of the following query from the
database:
select * from unregistered_ovf_of_entities where entity_name='
energy.versatushpc.com.br';


>
>
> Thanks,
> michal
>
>
> Ideias?
>
> On 26 Aug 2020, at 15:04, Vinícius Ferrão <fer...@versatushpc.com.br>
> wrote:
>
> What a strange thing is happening here:
>
> [root@power ~]# file /usr/bin/vdsm-client
> /usr/bin/vdsm-client: empty
> [root@power ~]# ls -l /usr/bin/vdsm-client
> -rwxr-xr-x. 1 root root 0 Jul  3 06:23 /usr/bin/vdsm-client
>
> A lot of files are just empty, I’ve tried reinstalling vdsm-client, it
> worked, but there’s other zeroed files:
>
> Transaction test succeeded.
> Running transaction
>   Preparing        :
>
>   1/1
>   Reinstalling     : vdsm-client-4.40.22-1.el8ev.noarch
>
>   1/2
>   Cleanup          : vdsm-client-4.40.22-1.el8ev.noarch
>
>   2/2
>   Running scriptlet: vdsm-client-4.40.22-1.el8ev.noarch
>
>   2/2
> /sbin/ldconfig: File /lib64/libkadm5clnt.so is empty, not checked.
> /sbin/ldconfig: File /lib64/libkadm5clnt_mit.so is empty, not checked.
> /sbin/ldconfig: File /lib64/libkadm5clnt_mit.so.11 is empty, not checked.
> /sbin/ldconfig: File /lib64/libkadm5clnt_mit.so.11.0 is empty, not checked.
> /sbin/ldconfig: File /lib64/libkadm5srv.so is empty, not checked.
> /sbin/ldconfig: File /lib64/libkadm5srv_mit.so is empty, not checked.
> /sbin/ldconfig: File /lib64/libkadm5srv_mit.so.11 is empty, not checked.
> /sbin/ldconfig: File /lib64/libkadm5srv_mit.so.11.0 is empty, not checked.
> /sbin/ldconfig: File /lib64/libsensors.so.4 is empty, not checked.
> /sbin/ldconfig: File /lib64/libsensors.so.4.4.0 is empty, not checked.
> /sbin/ldconfig: File /lib64/libvirt-admin.so.0 is empty, not checked.
> /sbin/ldconfig: File /lib64/libvirt-admin.so.0.6000.0 is empty, not
> checked.
> /sbin/ldconfig: File /lib64/libvirt-lxc.so.0 is empty, not checked.
> /sbin/ldconfig: File /lib64/libvirt-lxc.so.0.6000.0 is empty, not checked.
> /sbin/ldconfig: File /lib64/libvirt-qemu.so.0 is empty, not checked.
> /sbin/ldconfig: File /lib64/libvirt-qemu.so.0.6000.0 is empty, not checked.
> /sbin/ldconfig: File /lib64/libvirt.so.0 is empty, not checked.
> /sbin/ldconfig: File /lib64/libvirt.so.0.6000.0 is empty, not checked.
> /sbin/ldconfig: File /lib64/libisns.so.0 is empty, not checked.
> /sbin/ldconfig: File /lib64/libiscsi.so.0 is empty, not checked.
> /sbin/ldconfig: File /lib64/libopeniscsiusr.so.0 is empty, not checked.
> /sbin/ldconfig: File /lib64/libopeniscsiusr.so.0.2.0 is empty, not checked.
>
> /sbin/ldconfig: File /lib64/libkadm5clnt.so is empty, not checked.
> /sbin/ldconfig: File /lib64/libkadm5clnt_mit.so is empty, not checked.
> /sbin/ldconfig: File /lib64/libkadm5clnt_mit.so.11 is empty, not checked.
> /sbin/ldconfig: File /lib64/libkadm5clnt_mit.so.11.0 is empty, not checked.
> /sbin/ldconfig: File /lib64/libkadm5srv.so is empty, not checked.
> /sbin/ldconfig: File /lib64/libkadm5srv_mit.so is empty, not checked.
> /sbin/ldconfig: File /lib64/libkadm5srv_mit.so.11 is empty, not checked.
> /sbin/ldconfig: File /lib64/libkadm5srv_mit.so.11.0 is empty, not checked.
> /sbin/ldconfig: File /lib64/libsensors.so.4 is empty, not checked.
> /sbin/ldconfig: File /lib64/libsensors.so.4.4.0 is empty, not checked.
> /sbin/ldconfig: File /lib64/libvirt-admin.so.0 is empty, not checked.
> /sbin/ldconfig: File /lib64/libvirt-admin.so.0.6000.0 is empty, not
> checked.
> /sbin/ldconfig: File /lib64/libvirt-lxc.so.0 is empty, not checked.
> /sbin/ldconfig: File /lib64/libvirt-lxc.so.0.6000.0 is empty, not checked.
> /sbin/ldconfig: File /lib64/libvirt-qemu.so.0 is empty, not checked.
> /sbin/ldconfig: File /lib64/libvirt-qemu.so.0.6000.0 is empty, not checked.
> /sbin/ldconfig: File /lib64/libvirt.so.0 is empty, not checked.
> /sbin/ldconfig: File /lib64/libvirt.so.0.6000.0 is empty, not checked.
> /sbin/ldconfig: File /lib64/libisns.so.0 is empty, not checked.
> /sbin/ldconfig: File /lib64/libiscsi.so.0 is empty, not checked.
> /sbin/ldconfig: File /lib64/libopeniscsiusr.so.0 is empty, not checked.
> /sbin/ldconfig: File /lib64/libopeniscsiusr.so.0.2.0 is empty, not checked.
>
>   Verifying        : vdsm-client-4.40.22-1.el8ev.noarch
>
>   1/2
>   Verifying        : vdsm-client-4.40.22-1.el8ev.noarch
>
>   2/2
> Installed products updated.
>
> Reinstalled:
>   vdsm-client-4.40.22-1.el8ev.noarch
>
>
>
> I’ve never seen something like this.
>
> I’ve already reinstalled the host from the ground and the same thing
> happens.
>
>
> On 26 Aug 2020, at 14:28, Vinícius Ferrão via Users <users@ovirt.org>
> wrote:
>
> Hello Arik,
> This is probably the issue. Output totally empty:
>
> [root@power ~]# vdsm-client Host getCapabilities
> [root@power ~]#
>
> Here are the packages installed on the machine: (grepped ovirt and vdsm on
> rpm -qa)
> ovirt-imageio-daemon-2.0.8-1.el8ev.ppc64le
> ovirt-imageio-client-2.0.8-1.el8ev.ppc64le
> ovirt-host-4.4.1-4.el8ev.ppc64le
> ovirt-vmconsole-host-1.0.8-1.el8ev.noarch
> ovirt-host-dependencies-4.4.1-4.el8ev.ppc64le
> ovirt-imageio-common-2.0.8-1.el8ev.ppc64le
> ovirt-vmconsole-1.0.8-1.el8ev.noarch
> vdsm-hook-vmfex-dev-4.40.22-1.el8ev.noarch
> vdsm-hook-fcoe-4.40.22-1.el8ev.noarch
> vdsm-hook-ethtool-options-4.40.22-1.el8ev.noarch
> vdsm-hook-openstacknet-4.40.22-1.el8ev.noarch
> vdsm-common-4.40.22-1.el8ev.noarch
> vdsm-python-4.40.22-1.el8ev.noarch
> vdsm-jsonrpc-4.40.22-1.el8ev.noarch
> vdsm-api-4.40.22-1.el8ev.noarch
> vdsm-yajsonrpc-4.40.22-1.el8ev.noarch
> vdsm-4.40.22-1.el8ev.ppc64le
> vdsm-network-4.40.22-1.el8ev.ppc64le
> vdsm-http-4.40.22-1.el8ev.noarch
> vdsm-client-4.40.22-1.el8ev.noarch
> vdsm-hook-vhostmd-4.40.22-1.el8ev.noarch
>
> Any ideias to try?
>
> Thanks.
>
> On 26 Aug 2020, at 05:09, Arik Hadas <aha...@redhat.com> wrote:
>
>
>
> On Mon, Aug 24, 2020 at 1:30 AM Vinícius Ferrão via Users <users@ovirt.org>
> wrote:
>
>> Hello, I was using oVirt 4.3.10 with IBM AC922 (POWER9 / ppc64le) without
>> any issues.
>>
>> Since I’ve moved to 4.4.1 I can’t add the AC922 machine to the engine
>> anymore, it complains with the following error:
>> The host CPU does not match the Cluster CPU type and is running in
>> degraded mode. It is missing the following CPU flags: model_POWER9, powernv.
>>
>> Any ideia of what’s may be happening? The engine runs on x86_64, and I
>> was using this way on 4.3.10.
>
>
>> Machine info:
>> timebase        : 512000000
>> platform        : PowerNV
>> model           : 8335-GTH
>> machine         : PowerNV 8335-GTH
>> firmware        : OPAL
>> MMU             : Radix
>>
>
> Can you please provide the output of 'vdsm-client Host getCapabilities' on
> that host?
>
>
>>
>> Thanks,
>>
>>
>> _______________________________________________
>> 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/RV6FHRGKGPPZHVR36WKUHBFDMCQHEJHP/
>
>
> _______________________________________________
> 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/3DFMIR7764V6P4U3DIMDKP6I2RNNNA3T/
>
>
>
> _______________________________________________
> 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/MLSRBXRNNBPHFVGYHVPTDHDMUSUN7YZS/
>
>
> _______________________________________________
> 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/YMNMYMBMWTC7UGHOZBEGRIUSDZ3QAPPU/
>
_______________________________________________
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/ULBED2LS2NA4FOPC2NAR7UA2GJR4DHPK/

Reply via email to