Description of problem: When reimporting an existing storage domain to RHV 4.4.1 within the engine all the ppc64le VM's are classified as x86_64. The engine runs on x86_64 architecture, but this should not be an issue. Version-Release number of selected component (if applicable): ovirt-engine-4.4.1.10-0.1.el8ev.noarch How reproducible: 100% Steps to Reproduce: 1. Reinstall engine without backup on x86_64 architecture 2. Import a pre-existing Storage Domain 3. All VM's are detected as x86_64 Actual results: Unable to import the VM's to the correct cluster since the interface does not allows an override. Trying to import it on x86_64 anyway leads to an error regarding incompatible architecture, which is correct. Expected results: Proper classification base on the architecture Additional info: Entire description, with photos logs and debugging, of the issue was described on the mailing list: https://lists.ovirt.org/archives/list/users@ovirt.org/thread/RV6FHRGKGPPZHVR36WKUHBFDMCQHEJHP/ Workaround proposed by Arik Hadas <ahadas>: engine=# update unregistered_ovf_of_entities set architecture = 2;
The names within osinfo-defaults.properties (os.X.name.value) are supposed to be unique. We rely on that when reading an OVF (not from OVA) - as we look for the Os identifier by its name. However, "Linux" is not only set as the name of other_linux but also of other_linux_ppc64 and other_linux_s390x. Therefore when we encounter either of the last two types (other_linux_ppc64/other_linux_s390x), we get the first one (other_linux) and determine that the architecture according to this type (which is x86_64). Need to see if in addition to rename other_linux_ppc64 and other_linux_s390x we can also look for the OS by its identifier rather than by its name when reading OVFs.
The documentation text flag should only be set after 'doc text' field is provided. Please provide the documentation text and set the flag to '?' again.
The problem is not the OS name or the unique names. In the reporter mail thread we see the unique OS set correctly: <Section ovf:id="46ad1d80-2649-48f5-92e6-e5489d11d30c" ovf:required="false" xsi:type="ovf:OperatingSystemSection_Type"> <Info>Guest Operating System</Info> <Description>other_linux_ppc64</Description> </Section> And we consume the architecture accordingly as written in comment #1. The problem is when reading the OVF from unregistered_ovf_of_entities table, we are using OvfUtils::getOsSection. In this method, it tries to read the whole section element and look for the OS ID, which doesn't exists. This results in getting OS ID = 0 (Other OS on x86_64 arch), making the VM architecture x86_64. We should read the data within the 'Description' node in order to get the right unique name and accordingly the right architecture to that VM.
I verified it on RHV 4.4.3-7. I want also to test it with a Power9 machine, even when it's not really related to the change. But I had problems verifying it using that machine. Currently it's occupied, so I will try in other day. Env: - x86 Engine instance with RHV 4.4.3-7 (ovirt-engine-4.4.3.5-0.5.el8ev) and RHEL 8.3 installed. - Power8 Engine instance with RHV 4.4.3-7 (ovirt-engine-4.4.3.5-0.5.el8ev) and RHEL 8.3 installed. - 3 hosts with RHV 4.4.3-7 and RHEL 8.3, vdsm-4.40.32-1.el8ev on each engine. Steps: In Power8 engine: 1. Create a 4.4 data center, cluster. 2. Add power8 host and 2 NFS data domains. 3. Create a VM with a virtual disk from template Blank on the first data domain. 4. Create a VM from a template with RHEL 8.2 disk cloned on the first data domain. 5. Put the the first data domain to maintenance and detach it. 6. Put one of the Power8 hosts to maintenance. In x86_64 engine: 1. Create a 4.4 data center, cluster. 2. Add a power8 host and an NFS data domains. 3. Import the nfs domain from the power8 engine and activate it. 4. Import the VMs from the nfs domain. Results (As Expected): In Power8 engine: 1. The 4.4 data center and cluster were created. 2. The power8 host and the 2 data domains were added. 3. The VM with a virtual disk from template Blank on the first data domain was created. 4. The VM from a template with RHEL 8.2 disk cloned on the first data domain was created. 5. The first data domain is detached. 6. One of the Power8 hosts is in maintenance. In x86_64 engine: 1. The 4.4 data center and cluster were created. 2. The power8 host and the data domain were added. 3. The nfs domain was imported and it's activated. 4. The VMs from the nfs domain were imported as ppc.
This bugzilla is included in oVirt 4.4.3 release, published on November 10th 2020. Since the problem described in this bug report should be resolved in oVirt 4.4.3 release, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.