Bug 1253263 - [PPC64LE] Failed to create vm via REST without define display type
[PPC64LE] Failed to create vm via REST without define display type
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine (Show other bugs)
3.6.0
ppc64le Linux
low Severity high
: ovirt-3.6.2
: 3.6.2
Assigned To: Marek Libra
Artyom
: Triaged
: 1270611 1291246 (view as bug list)
Depends On:
Blocks: RHEV3.6PPC 1277183 1277184
  Show dependency treegraph
 
Reported: 2015-08-13 07:09 EDT by Artyom
Modified: 2016-04-19 21:38 EDT (History)
15 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
If the display type is not specified in a REST API request to add a virtual machine, and the template's display type is not supported on the architecture, then first supported display type is used.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-04-19 21:38:07 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Virt
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 46559 master MERGED core: The default display type conforms the architecture Never
oVirt gerrit 46850 ovirt-engine-3.6 MERGED core: The default display type conforms the architecture Never
oVirt gerrit 49412 master MERGED restapi: Default display type for PPC 2015-12-17 10:22 EST
oVirt gerrit 50702 ovirt-engine-3.6 MERGED restapi: Default display type for PPC 2015-12-18 06:17 EST

  None (edit)
Description Artyom 2015-08-13 07:09:54 EDT
Description of problem:
Failed to create vm via REST without define display type

Version-Release number of selected component (if applicable):
ovirt-engine-restapi-3.6.0-0.0.master.20150726172446.git65db93d.el6.noarch

How reproducible:
Always

Steps to Reproduce:
1. Create vm with next rest code:
<vm>
    <name>test_2</name>
    <memory>536870912</memory>
    <cluster>
        <name>your_cluster_name</name>
    </cluster>
    <cpu_profile id="some_cpu_profile_id"/>
    <template id="00000000-0000-0000-0000-000000000000"/>
</vm>
2.
3.

Actual results:
<fault>
<reason>Operation Failed</reason>
<detail>[Cannot add VM. Selected display type is not supported by the operating system.]</detail>
 </fault>

Expected results:
If display not specified, for PPC architecture VNC must be chosen as default one and vm creation must succeed

Additional info:
Comment 1 Juan Hernández 2015-08-17 12:44:42 EDT
The RESTAPI doesn't set the display type of the VM unless explicitly given by the caller.

If I understand correctly what happens here is that the backend sets it to QXL in the constructor of the VmStatic class, and then it performs the validation when starting the VM (not when creating it).
Comment 2 Michal Skrivanek 2015-08-18 10:22:17 EDT
WA: define console type on VM creation
Comment 3 Yaniv Kaul 2015-09-16 11:16:40 EDT
Why is the severity high? The workaround is simple, risk-free, makes sense, can be documented, etc.
Comment 4 Artyom 2015-09-16 12:33:43 EDT
W/A easy when you work manually, if you take in account that you have some automation scripts(python, java), that create vms for you and now in every place where you create vm you need add explicitly display type it can be really annoying.
That main reason why I set high priority to this bug.
Comment 5 Yaniv Kaul 2015-09-16 15:19:37 EDT
(In reply to Artyom from comment #4)
> W/A easy when you work manually, if you take in account that you have some
> automation scripts(python, java), that create vms for you and now in every
> place where you create vm you need add explicitly display type it can be
> really annoying.

Every place? I assume it's a single place in any well written code (I hope so). How many lines of code does it add? Please check. 
And that's just for Power users. And it's a bug we surely can fix - but not urgently for 3.6.0.

And it's REST/CLI/SDKs only, right? Not via the UI?

> That main reason why I set high priority to this bug.

I'll make sure we have clear definition of severity ratings - this doesn't like a good fit IMHO.
Comment 6 Michal Skrivanek 2015-09-24 06:21:16 EDT
it might make sense to have this in 3.6 since PPC is a (re)introduced platform support.
I would backport it into 3.6.z
Comment 7 Michal Skrivanek 2015-10-16 04:01:36 EDT
*** Bug 1270611 has been marked as a duplicate of this bug. ***
Comment 9 Artyom 2015-11-29 13:42:07 EST
Checked on rhevm-3.6.1-0.2.el6.noarch
Try to add new vm via REST:
<vm>
<name>test</name>
<memory>1073741824</memory>
<cpu>
<topology sockets="1" cores="1"/>
</cpu>
<cluster href="/ovirt-engine/api/clusters/1484ad18-aa90-4cdc-994c-d5468e4202d1" id="1484ad18-aa90-4cdc-994c-d5468e4202d1" />
<template href="/ovirt-engine/api/templates/00000000-0000-0000-0000-000000000000" id="00000000-0000-0000-0000-000000000000" />
</vm>

Action failed:
<fault>
<reason>Operation Failed</reason>
<detail>[Cannot add VM. Selected display type is not supported by the operating system.]</detail>
 </fault>
Comment 10 Marek Libra 2015-11-30 06:01:42 EST
New patch set is pushed to gerrit.

Verified on our testing PPC with the #c9 REST call, for which the display/graphics type is read from osinfo-defaults.properties (key: os.other_ppc64.devices.display.protocols.value).
Comment 11 Michal Skrivanek 2015-11-30 06:20:43 EST
postponing since the workaround is to use a template with VNC type - all of PPC tempaltes should be as such. The only issue is with the default Blank which has SPICE.
Comment 12 Artyom 2015-12-27 08:17:52 EST
Verified on rhevm-3.6.2-0.1.el6.noarch
Send:
<vm>
<name>test_display</name>
<cluster href="/ovirt-engine/api/clusters/2d5db03a-7a36-490b-84b6-a0722411e588" id="2d5db03a-7a36-490b-84b6-a0722411e588" />
<template href="/ovirt-engine/api/templates/00000000-0000-0000-0000-000000000000" id="00000000-0000-0000-0000-000000000000" />
</vm>

Create new vm with display:
<display>
<type>vnc</type>
<monitors>1</monitors>
<single_qxl_pci>false</single_qxl_pci>
<allow_override>false</allow_override>
<smartcard_enabled>false</smartcard_enabled>
<file_transfer_enabled>true</file_transfer_enabled>
<copy_paste_enabled>true</copy_paste_enabled>
<disconnect_action>LOCK_SCREEN</disconnect_action>
 </display>
Comment 13 Ondra Machacek 2016-03-14 03:53:58 EDT
*** Bug 1291246 has been marked as a duplicate of this bug. ***

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