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:
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).
WA: define console type on VM creation
Why is the severity high? The workaround is simple, risk-free, makes sense, can be documented, etc.
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.
(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.
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
*** Bug 1270611 has been marked as a duplicate of this bug. ***
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>
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).
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.
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>
*** Bug 1291246 has been marked as a duplicate of this bug. ***