On Thu, Aug 27, 2020 at 8:40 PM Vinícius Ferrão via Users <[email protected]> wrote:
> Hi Michal, > > On 27 Aug 2020, at 05:08, Michal Skrivanek <[email protected]> > wrote: > > > > On 26 Aug 2020, at 20:50, Vinícius Ferrão via Users <[email protected]> > 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 <[email protected]> > 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 <[email protected]> > 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 <[email protected]> wrote: > > > > On Mon, Aug 24, 2020 at 1:30 AM Vinícius Ferrão via Users <[email protected]> > 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 -- [email protected] >> To unsubscribe send an email to [email protected] >> 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/[email protected]/message/RV6FHRGKGPPZHVR36WKUHBFDMCQHEJHP/ > > > _______________________________________________ > Users mailing list -- [email protected] > To unsubscribe send an email to [email protected] > 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/[email protected]/message/3DFMIR7764V6P4U3DIMDKP6I2RNNNA3T/ > > > > _______________________________________________ > Users mailing list -- [email protected] > To unsubscribe send an email to [email protected] > 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/[email protected]/message/MLSRBXRNNBPHFVGYHVPTDHDMUSUN7YZS/ > > > _______________________________________________ > Users mailing list -- [email protected] > To unsubscribe send an email to [email protected] > 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/[email protected]/message/YMNMYMBMWTC7UGHOZBEGRIUSDZ3QAPPU/ >
_______________________________________________ Users mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected]/message/ULBED2LS2NA4FOPC2NAR7UA2GJR4DHPK/
