[ovirt-users] Re: POWER9 (ppc64le) Support on oVirt 4.4.1

2020-08-27 Thread Arik Hadas 
On Thu, Aug 27, 2020 at 10:23 PM Arik Hadas  wrote:

>
>
> On Thu, Aug 27, 2020 at 10:13 PM Vinícius Ferrão <
> fer...@versatushpc.com.br> wrote:
>
>>
>>
>> On 27 Aug 2020, at 16:03, Arik Hadas  wrote:
>>
>>
>>
>> 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 
>>> wrote:
>>>
>>>
>>>
>>> On 26 Aug 2020, at 20:50, Vinícius Ferrão via Users 
>>> 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:
>>>
>>> 
>>>
>>> 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';
>>
>>
>> Sure, there you go:
>>
>>  46ad1d80-2649-48f5-92e6-e5489d11d30c | energy.versatushpc.com.br | VM
>>|1 | |
>> d19456e4-0051-456e-b33c-57348a78c2e0 |
>>  http://schemas.dmtf.org/ovf/envelope/1/; xmlns:rasd="
>> http://schemas.dmtf.org/wbem/wscim/1/cim
>> -schema/2/CIM_ResourceAllocationSettingData" xmlns:vssd="
>> http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_VirtualSystemSettingData;
>> xmlns:xsi="http://ww
>> w.w3.org/2001/XMLSchema-instance"
>> ovf:version="4.1.0.0">> ovf:href="775b24a9-6a32-431a-831f-4ac9b3b31152/b1d9832e-076f-48f3-a300-0b5cdf0949af
>> " ovf:id="b1d9832e-076f-48f3-a300-0b5cdf0949af" ovf:size="512"
>> ovf:description="Active VM" ovf:disk_storage_type="IMAGE"
>> ovf:cinder_volume_type="">> eferences>List of networks> ovf:name="legacyservers">> xsi:type="ovf:DiskSection_Type">
>> List of Virtual Disks> ovf:diskId="b1d9832e-076f-48f3-a300-0b5cdf0949af" ovf:size="40"
>> ovf:actual_size="1" ovf:vm_snapshot_id="6de58683-c586
>> -4e97-b0e8-ee7ee3baf754" ovf:parentRef=""
>> ovf:fileRef="775b24a9-6a32-431a-831f-4ac9b3b31152/b1d9832e-076f-48f3-a300-0b5cdf0949af"
>> ovf:format="http://www.vmwa
>> re.com/specifications/vmdk.html#sparse" ovf:volume-format="RAW"
>> ovf:volume-type="Sparse" ovf:disk-interface="VirtIO_SCSI"
>> ovf:read-only="false" ovf:shareable
>> ="false" ovf:boot="true" ovf:pass-discard="false"
>> ovf:disk-alias="energy.versatushpc.com.br_Disk1" ovf:disk-description=""
>> ovf:wipe-after-delete="false">> sk>> xsi:type="ovf:VirtualSystem_Type">energy.versatushpc.com.brHolds
>> Kosen backend and frontend prod
>>  services (nginx +
>> docker)2020/08/19
>> 20:11:332020/08/20 18:37:41>
>> eProtected>falseguest_agentfalse1>
>> >Etc/GMT984.3>
>> mType>1AUTO_RESUME2730falsefalse>
>> nAndPause>false16ea16f22-45d7-11ea-bd83-00163e518b7c0>
>> igrationSupport>falsetruetrue>
>> ceCopyPasteEnabled>trueLOCK_SCREEN>
>> CustomEmulatedMachine>0>
>>

[ovirt-users] Re: POWER9 (ppc64le) Support on oVirt 4.4.1

2020-08-27 Thread Arik Hadas 
On Thu, Aug 27, 2020 at 10:13 PM Vinícius Ferrão 
wrote:

>
>
> On 27 Aug 2020, at 16:03, Arik Hadas  wrote:
>
>
>
> On Thu, Aug 27, 2020 at 8:40 PM Vinícius Ferrão via Users 
> wrote:
>
>> Hi Michal,
>>
>> On 27 Aug 2020, at 05:08, Michal Skrivanek 
>> wrote:
>>
>>
>>
>> On 26 Aug 2020, at 20:50, Vinícius Ferrão via Users 
>> 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:
>>
>> 
>>
>> 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';
>
>
> Sure, there you go:
>
>  46ad1d80-2649-48f5-92e6-e5489d11d30c | energy.versatushpc.com.br | VM
>|1 | |
> d19456e4-0051-456e-b33c-57348a78c2e0 |
>  http://schemas.dmtf.org/ovf/envelope/1/; xmlns:rasd="
> http://schemas.dmtf.org/wbem/wscim/1/cim
> -schema/2/CIM_ResourceAllocationSettingData" xmlns:vssd="
> http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_VirtualSystemSettingData;
> xmlns:xsi="http://ww
> w.w3.org/2001/XMLSchema-instance" ovf:version="4.1.0.0"> ovf:href="775b24a9-6a32-431a-831f-4ac9b3b31152/b1d9832e-076f-48f3-a300-0b5cdf0949af
> " ovf:id="b1d9832e-076f-48f3-a300-0b5cdf0949af" ovf:size="512"
> ovf:description="Active VM" ovf:disk_storage_type="IMAGE"
> ovf:cinder_volume_type=""> eferences>List of networks ovf:name="legacyservers"> xsi:type="ovf:DiskSection_Type">
> List of Virtual Disks ovf:diskId="b1d9832e-076f-48f3-a300-0b5cdf0949af" ovf:size="40"
> ovf:actual_size="1" ovf:vm_snapshot_id="6de58683-c586
> -4e97-b0e8-ee7ee3baf754" ovf:parentRef=""
> ovf:fileRef="775b24a9-6a32-431a-831f-4ac9b3b31152/b1d9832e-076f-48f3-a300-0b5cdf0949af"
> ovf:format="http://www.vmwa
> re.com/specifications/vmdk.html#sparse" ovf:volume-format="RAW"
> ovf:volume-type="Sparse" ovf:disk-interface="VirtIO_SCSI"
> ovf:read-only="false" ovf:shareable
> ="false" ovf:boot="true" ovf:pass-discard="false"
> ovf:disk-alias="energy.versatushpc.com.br_Disk1" ovf:disk-description=""
> ovf:wipe-after-delete="false"> sk>
> energy.versatushpc.com.brHolds Kosen backend and
> frontend prod
>  services (nginx +
> docker)2020/08/19
> 20:11:332020/08/20 18:37:41
> eProtected>falseguest_agentfalse1
> >Etc/GMT984.3
> mType>1AUTO_RESUME2730falsefalse
> nAndPause>false16ea16f22-45d7-11ea-bd83-00163e518b7c0
> igrationSupport>falsetruetrue
> ceCopyPasteEnabled>trueLOCK_SCREEN
> CustomEmulatedMachine>0
> roperties>16384truefalseBlastoise
> ame>----Blanktrue0
> id>32644894-755e-4588-b967-8fb9dc3277952false000
>
> 0----Blankfalse stVersion>2020/08/20 17:52:35 ovf:id="46ad1d80-2649-48f5-92e6-e5489d11d30c" ovf:required="false"
>

[ovirt-users] Re: POWER9 (ppc64le) Support on oVirt 4.4.1

2020-08-27 Thread Vinícius Ferrão via Users 


On 27 Aug 2020, at 16:03, Arik Hadas 
mailto:aha...@redhat.com>> wrote:



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

On 27 Aug 2020, at 05:08, Michal Skrivanek 
mailto:michal.skriva...@redhat.com>> wrote:



On 26 Aug 2020, at 20:50, Vinícius Ferrão via Users 
mailto: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:



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';

Sure, there you go:

 46ad1d80-2649-48f5-92e6-e5489d11d30c | 
energy.versatushpc.com.br | VM  | 
   1 | | d19456e4-0051-456e-b33c-57348a78c2e0 |
 http://schemas.dmtf.org/ovf/envelope/1/; 
xmlns:rasd="http://schemas.dmtf.org/wbem/wscim/1/cim
-schema/2/CIM_ResourceAllocationSettingData" 
xmlns:vssd="http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_VirtualSystemSettingData;
 xmlns:xsi="http://ww
w.w3.org/2001/XMLSchema-instance" 
ovf:version="4.1.0.0">List of networks
List of Virtual Diskshttp://www.vmwa
re.com/specifications/vmdk.html#sparse"
 ovf:volume-format="RAW" ovf:volume-type="Sparse" 
ovf:disk-interface="VirtIO_SCSI" ovf:read-only="false" ovf:shareable
="false" ovf:boot="true" ovf:pass-discard="false" 
ovf:disk-alias="energy.versatushpc.com.br_Disk1" ovf:disk-description="" 
ovf:wipe-after-delete="false">energy.versatushpc.com.brHolds
 Kosen backend and frontend prod
 services (nginx + 
docker)2020/08/19 
20:11:332020/08/20 18:37:41falseguest_agentfalse1Etc/GMT984.31AUTO_RESUME2730falsefalsefalse16ea16f22-45d7-11ea-bd83-00163e518b7c0falsetruetruetrueLOCK_SCREEN016384truefalseBlastoise----Blanktrue032644894-755e-4588-b967-8fb9dc3277952false000
0----Blankfalse2020/08/20 17:52:35Guest Operating 
Systemother_linux_ppc642 CPU, 4096 MemoryENGINE 
4.1.0.02 virtual 
cpuNumber of virtual 
CPU132111624096 
>MB of memoryMemory Size24MegaBytes4096energy.versatushpc.com.br_Disk1b1d9832e-076f-48f3-a300-0b5cdf0949af17775b24a9-6a32-431a-831f-4ac9b3b31152/b1d9832e-076f-48f3-a300-0b5cdf0949af--------d19456e4-0051-456e-b33c-57348a78c2e06c54f91e-89bf-45b4-bc48-56e74c4efd5e2020/08/19 
20:13:051970/01/01 
00:00:002020/08
/20 
18:37:41diskdisk{type=drive,
 bus=0, controller=1, target=0, unit=0}<
BootOrder>1truefalseua-775b24a9-6a32-431a-831f-4ac9b3b31152Ethernet adapter on 
legacyserverse6e37ae1-f263-4986-a039-e8e01e72d1f410legacyservers3legacyserverstruenic1nic156:6f:f0:b3:00:23

[ovirt-users] Re: POWER9 (ppc64le) Support on oVirt 4.4.1

2020-08-27 Thread Arik Hadas 
On Thu, Aug 27, 2020 at 8:40 PM Vinícius Ferrão via Users 
wrote:

> Hi Michal,
>
> On 27 Aug 2020, at 05:08, Michal Skrivanek 
> wrote:
>
>
>
> On 26 Aug 2020, at 20:50, Vinícius Ferrão via Users 
> 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:
>
> 
>
> 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 
> 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

[ovirt-users] Re: POWER9 (ppc64le) Support on oVirt 4.4.1

2020-08-27 Thread Vinícius Ferrão via Users 
Hi Michal,

On 27 Aug 2020, at 05:08, Michal Skrivanek 
mailto:michal.skriva...@redhat.com>> wrote:



On 26 Aug 2020, at 20:50, Vinícius Ferrão via Users 
mailto: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:



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…

[cid:254FDE4F-5CBC-472A-9C89-0B728E4B0894]

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.


Thanks,
michal


Ideias?

On 26 Aug 2020, at 15:04, Vinícius Ferrão 
mailto: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.

[ovirt-users] Re: POWER9 (ppc64le) Support on oVirt 4.4.1

2020-08-27 Thread Michal Skrivanek 


> On 26 Aug 2020, at 20:50, Vinícius Ferrão via Users  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?

> 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?

> 
> 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:
> 
> 
> 
> 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

Thanks,
michal

> 
> Ideias?
> 
>> On 26 Aug 2020, at 15:04, Vinícius Ferrão > > 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

[ovirt-users] Re: POWER9 (ppc64le) Support on oVirt 4.4.1

2020-08-26 Thread Vinícius Ferrão via Users 
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:
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.

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:

[cid:78A36F83-2CAF-4A52-B0CA-FCF35177F0F9]

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…

Ideias?

On 26 Aug 2020, at 15:04, Vinícius Ferrão 
mailto: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:

[ovirt-users] Re: POWER9 (ppc64le) Support on oVirt 4.4.1

2020-08-26 Thread Vinícius Ferrão via Users 
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 
mailto: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-users] Re: POWER9 (ppc64le) Support on oVirt 4.4.1

2020-08-26 Thread Vinícius Ferrão via Users 
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 
mailto:aha...@redhat.com>> wrote:



On Mon, Aug 24, 2020 at 1:30 AM Vinícius Ferrão via Users 
mailto: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: 51200
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/

[ovirt-users] Re: POWER9 (ppc64le) Support on oVirt 4.4.1

2020-08-26 Thread Arik Hadas 
On Mon, Aug 24, 2020 at 1:30 AM Vinícius Ferrão via Users 
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: 51200
> 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/FRKCP33JX4OHY2NHUHVIAWCCHG52SA6L/