Description of problem: In ovirt 4.1 we added a new feature for supporting a headless VM (a VM that run without any graphical console and without any video device). The backward compatibility for REST API is fully supported but the new headless feature is not and we need to add this support (i.e. adding/creating a headless VM, headless template, pool, instance type etc) and also consider adding a property of "video-device" to the <display> section so that the user can set it via REST API. Version-Release number of selected component (if applicable): 4.1
As discussed with Juan Hernández, the REST api changes for supporting Headless is as follows: 1. Add a new Boolean attribute 'headless' which will be at the <vm> level with default value set to 'false'. This attribute setting is mandatory only if you want to edit a VM and change it from headless to non-headless and vice versa. Meaning that the only way to indicate to the server that you want to change the value of the 'headless' attribute is to send the'headless' attribute. For editing other VM attributes, you can omit it. 2. Add a new 'video_card_type' attribute which will be in the <display> level with default value set to 'qxl' and with possible values: 'qxl', 'cirrus', 'vga'. For example: <vm> <display> <video_card_type>cirrus</video_card_type> </display> </vm> Consider adding it also to the graphicsconsoles api: GET /vms/123/graphicsconsoles <graphics_consoles> <graphics_console id=".." href="..."> <video_card_type>cirrus</video_card_type> <protocol>vnc</protocol> ... </graphics_console> Use cases: 1. as long as you want to create/edit a non headless VM, the syntax is the same way as done today. It's not mandatory to set the 'headless' attribute to 'false'. You can still set the <display> properties if you want to change console's default values. 2. For creating a headless VM, you should set the 'headless' attribute to 'true' and omit the 'display' attribute since it is no relevant for a headless VM. For example: <vm> <headless>true</headless> </vm> 3. For editing a Headless VM, you can choose if to omit the 'headless' attribute but you must omit the 'display' attribute's properties. 4. For editing a non-Headless VM and change it to a Headless VM, you should set the 'headless' attribute to 'true' and omit the display property (it doesn't make much sense to send additional display attributes, as they won't be used for headless). For example: PUT /vms/123 <vm> <headless>true</headless> </vm> 5. For editing a Headless VM and change it to non-Headless VM, you should set the 'headless' attribure to 'false' and you may or may not set the 'display' entity attributes (if not set they should take the default values). For exanple: PUT /vms/123 <vm> <headless>false</headless> ... [ optional: <display> ... </display> ] ... </vm> Note that sending only the 'display' attributes, and not the `headless` attribute shouldn't change the headless/non-headless state of the VM. 6. A non-headless VM information: GET /vms <vm id="123"> <headless>false</headless> <display> ... </display> ... </vm> 7. A headless VM information: GET /vms <vm id="123"> <headless>true</headless> ... </vm> We should probably not report the display attributes, as they don't make sense for a headless virtual machine.
*** Bug 1325638 has been marked as a duplicate of this bug. ***
*** Bug 1429471 has been marked as a duplicate of this bug. ***
*** Bug 1429516 has been marked as a duplicate of this bug. ***
Sharon, any reason to do that and not just use high performance VM type?
Don't we want to support headless also for a server VM type? If we permit disabling of other devices for a VM just because they are not needed (regardless to the 'optimized for') so why not graphics consoles? The UI currently supports that so why not supporting it via rest api also?
This will not make it in a reasonable time. Please re-open if you still feel this should be fixed