Bug 1823674 - On creating a template during importing an image from OpenStack, an invalid machine type is generated
Summary: On creating a template during importing an image from OpenStack, an invalid m...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: BLL.Virt
Version: 4.4.0
Hardware: Unspecified
OS: Unspecified
urgent
high
Target Milestone: ovirt-4.4.1
: ---
Assignee: Shmuel Melamud
QA Contact: Nisim Simsolo
URL:
Whiteboard:
Depends On: 1824472
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-04-14 08:59 UTC by Dominik Holler
Modified: 2021-05-13 06:25 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-06-08 14:40:55 UTC
oVirt Team: Virt
Embargoed:
pm-rhel: ovirt-4.4+


Attachments (Terms of Use)
logs from network-suite master (1.85 MB, application/x-xz)
2020-04-14 08:59 UTC, Dominik Holler
no flags Details

Description Dominik Holler 2020-04-14 08:59:32 UTC
Created attachment 1678641 [details]
logs from network-suite master

Description of problem:
On creating a template during importing an image from OpenStack, the machine type
pc-i440fx-rhel8.1.0
is generated. Booting a VM created from such a template fails, because no host provides this machine type.

Version-Release number of selected component (if applicable):


How reproducible:
100%

Steps to Reproduce:
1. Import image from glance as template
2. Create a VM from the template
3. Start the VM

Actual results:
Starting the VM fails with 
2020-04-13 21:56:07,334-04 INFO  [org.ovirt.engine.core.bll.utils.EmulatedMachineUtils] (default task-2) [4b558c6d-f3ab-46f6-978a-e0a667875c8a] Emulated machine 'pc-i440fx-rhel8.1.0' which is different than that of the cluster is set for 'vm0'(c09235a7-e6d1-40a0-a7a3-3a652888b451)
2020-04-13 21:56:07,334-04 DEBUG [org.ovirt.engine.core.bll.scheduling.SchedulingManager] (default task-2) [4b558c6d-f3ab-46f6-978a-e0a667875c8a] Scheduling started, correlation Id: 4b558c6d-f3ab-46f6-978a-e0a667875c8a
2020-04-13 21:56:07,343-04 DEBUG [org.ovirt.engine.core.common.di.interceptor.DebugLoggingInterceptor] (default task-2) [4b558c6d-f3ab-46f6-978a-e0a667875c8a] method: getAllForClusterWithStatus, params: [a0042b44-7df0-11ea-8c99-5452c0a8c902, Up], timeElapsed: 9ms
2020-04-13 21:56:07,344-04 DEBUG [org.ovirt.engine.core.common.di.interceptor.DebugLoggingInterceptor] (default task-2) [4b558c6d-f3ab-46f6-978a-e0a667875c8a] method: getVmManager, params: [c09235a7-e6d1-40a0-a7a3-3a652888b451, false], timeElapsed: 0ms
2020-04-13 21:56:07,348-04 DEBUG [org.ovirt.engine.core.bll.scheduling.policyunits.EmulatedMachineFilterPolicyUnit] (default task-2) [4b558c6d-f3ab-46f6-978a-e0a667875c8a] Host lago-network-suite-master-host-1 was filtered out as it doesn't support the VM required emulated machine (pc-i440fx-rhel8.1.0). Host supported emulated machines are: pc-i440fx-rhel7.4.0,pc-i440fx-rhel7.1.0,pc-q35-rhel7.3.0,pc-q35-rhel7.4.0,pc-i440fx-rhel7.2.0,pc-q35-rhel7.5.0,pc-q35-rhel7.6.0,pc-q35-rhel8.0.0,q35,pc-i440fx-rhel7.0.0,pc-i440fx-rhel7.6.0,pc-i440fx-rhel7.3.0,pc-i440fx-rhel7.5.0,pc-q35-rhel8.1.0,pc.
2020-04-13 21:56:07,348-04 DEBUG [org.ovirt.engine.core.bll.scheduling.policyunits.EmulatedMachineFilterPolicyUnit] (default task-2) [4b558c6d-f3ab-46f6-978a-e0a667875c8a] Host lago-network-suite-master-host-0 was filtered out as it doesn't support the VM required emulated machine (pc-i440fx-rhel8.1.0). Host supported emulated machines are: pc-i440fx-rhel7.4.0,q35,pc-q35-rhel7.3.0,pc-i440fx-rhel7.5.0,pc-q35-rhel7.4.0,pc-i440fx-rhel7.3.0,pc-q35-rhel8.0.0,pc-q35-rhel7.5.0,pc,pc-i440fx-rhel7.0.0,pc-q35-rhel7.6.0,pc-i440fx-rhel7.6.0,pc-i440fx-rhel7.1.0,pc-i440fx-rhel7.2.0,pc-q35-rhel8.1.0.
2020-04-13 21:56:07,348-04 INFO  [org.ovirt.engine.core.bll.scheduling.SchedulingManager] (default task-2) [4b558c6d-f3ab-46f6-978a-e0a667875c8a] Candidate host 'lago-network-suite-master-host-1' ('74a3bf4d-5f8e-4e0b-8f2d-b3dbe4ba60bc') was filtered out by 'VAR__FILTERTYPE__INTERNAL' filter 'Emulated-Machine' (correlation id: 4b558c6d-f3ab-46f6-978a-e0a667875c8a)
2020-04-13 21:56:07,348-04 INFO  [org.ovirt.engine.core.bll.scheduling.SchedulingManager] (default task-2) [4b558c6d-f3ab-46f6-978a-e0a667875c8a] Candidate host 'lago-network-suite-master-host-0' ('7aad8b80-79d4-4b28-991d-9a3cf431fbdf') was filtered out by 'VAR__FILTERTYPE__INTERNAL' filter 'Emulated-Machine' (correlation id: 4b558c6d-f3ab-46f6-978a-e0a667875c8a)
2020-04-13 21:56:07,349-04 DEBUG [org.ovirt.engine.core.bll.scheduling.SchedulingManager] (default task-2) [4b558c6d-f3ab-46f6-978a-e0a667875c8a] Scheduling ended, correlation Id: 4b558c6d-f3ab-46f6-978a-e0a667875c8a
2020-04-13 21:56:07,349-04 ERROR [org.ovirt.engine.core.bll.RunVmCommand] (default task-2) [4b558c6d-f3ab-46f6-978a-e0a667875c8a] Can't find VDS to run the VM 'c09235a7-e6d1-40a0-a7a3-3a652888b451' on, so this VM will not be run.

Expected results:
VM boots.

Additional info:
Work around is to set a valid machine type manually.
https://lists.ovirt.org/archives/list/devel@ovirt.org/thread/O42NTZMEMFAZ5E2AKMOKAD3CVELG5R3L/

Comment 1 Lukas Svaty 2020-04-14 09:31:25 UTC
After checking with automation ovirt_template ansible module can't edit machine types, thus QE would be indeed blocked on this. Sorry for confusion.

https://docs.ansible.com/ansible/latest/modules/ovirt_template_module.html

Comment 2 Michal Skrivanek 2020-04-16 12:15:52 UTC
the swapping of machine types is wrong. On el8 there's not a complete overlap in i440fx and q35 types so we must stop just swapping the substring.
it needs to be set correctly in emulated_machine filed of cluster table, probably on bios type change in cluster. i.e. q35-rhel-8.1.0 for type 2,3 and i440fx-rhel-7.6.0 for type 1

Comment 3 Dominik Holler 2020-04-20 08:31:22 UTC
Can this bug changed to MODIFIED?

Comment 4 Shmuel Melamud 2020-04-20 12:58:08 UTC
(In reply to Dominik Holler from comment #3)
> Can this bug changed to MODIFIED?

No.

Comment 5 Michal Skrivanek 2020-05-18 13:01:20 UTC
please review if there's really a test this bug is blocking. 
AFAICT it should not anymore. If it's indeed the case please remove AutomationBlocker.

Comment 6 Dominik Holler 2020-05-18 14:09:05 UTC
Meital, can you please confirm that you are not aware of any test case which is blocked by this bug?

Comment 7 Michael Burman 2020-05-18 14:19:09 UTC
(In reply to Michal Skrivanek from comment #5)
> please review if there's really a test this bug is blocking. 
> AFAICT it should not anymore. If it's indeed the case please remove
> AutomationBlocker.

As far as i know, this is not blocking automation anymore or any specific test. But maybe Meital knows about blocked test because of it.

Comment 8 meital avital 2020-05-25 13:10:15 UTC
(In reply to Dominik Holler from comment #6)
> Meital, can you please confirm that you are not aware of any test case which
> is blocked by this bug?

I'm not aware of any automation case that blocked by this bug

Comment 9 Arik 2020-06-08 14:40:55 UTC

*** This bug has been marked as a duplicate of bug 1830840 ***


Note You need to log in before you can comment on or make changes to this bug.