Description of problem: On a VM that has a serial console enabled, adding a ISO/CDROM (for example for installation purposes) will disable the serial console. Version-Release number of selected component (if applicable): ovirt-engine-restapi-4.2.5.2-0.1.el7ev.noarch How reproducible: Always Steps to Reproduce: 1. Create a new VM 2. Using the API, enable serial console ~~~ curl -s -k --header 'Accept: application/xml' --request PUT --header 'Content-Type: application/xml' --data ' <vm> <console> <enabled>true</enabled> </console> </vm>' -u 'admin internal:<password>' https://rhvm.example.com/ovirt-engine/api/vms/17226e86-1ccc-4b17-8ebe-f1685a2ffe98 | grep -A 2 '<console>' <console> <enabled>true</enabled> </console> ~~~ 3. Adding ISO: ~~~ curl -s -k --header 'Accept: application/xml' --request PUT --header 'Content-Type: application/xml' --data ' <cdrom> <file id="rhel-server-6.9-x86_64-dvd.iso"/> </cdrom> ' -u 'admin internal:<password>' 'https://rhvm.example.com/ovirt-engine/api/vms/17226e86-1ccc-4b17-8ebe-f1685a2ffe98/cdroms/00000000-0000-0000-0000-000000000000?current=false' ~~~ Actual results: Right after adding the ISO, the serial console is disabled: ~~~ curl -s -k --header 'Accept: application/xml' --request GET --header 'All-Content: true' --header 'Content-Type: application/xml' \ -u 'admin internal:<password>' https://rhvm.example.com/ovirt-engine/api/vms/17226e86-1ccc-4b17-8ebe-f1685a2ffe98 | grep -A 2 '<console>' <console> <enabled>false</enabled> </console> ~~~ Expected results: Serial console setting to be unchanged! Additional info: Adding an ISO (either in run-once or general) using the webUI does not alter the serial console setting.
has the VM been restarted after your step 1? If not then serial console is a change which cannot be done while VM is running and as such the actual configuration change is just scheduled to be done after restart. If you want to make another non-live change in the meantime you need to either - tell API to make the modification in the "next_run_ snapshot by using the next_run=1 parameter - send both(all) changes in one request However, changing CDROM *is* a change that can be done live, so in your case you can see the result in permanent configuration right away. Reboot the VM and the serial console should be there. Please reopen if it's not the case
Reopening. Even if I do not start the VM, just created it + enable the serial console. Then when I add a CDROM, it gets disabled! Similar workflow in the webUI does work as it should: 1. Create VM with NIC assigned and disk created 2. Edit the VM to add serial console 3. Edit once more and add a CDROM under boot options. The serial console is kept in the correct state, being enabled! In detail using the API: # Create VM curl -s -k --header 'Accept: application/xml' --request 'POST' --header 'Content-Type: application/xml' --data '<vm> ... ' -u "${upw}" "https://${host}/ovirt-engine/api/vms" # Add NIC curl -s -k --header 'Accept: application/xml' --request 'POST' --header 'Content-Type: application/xml' --data ' ... ' -u "${upw}" "https://${host}/ovirt-engine/api/vms/2409c422-fd16-48e8-9d3a-75b4dd6e7f22/nics" # Add disk curl -s -k --header 'Accept: application/xml' --request 'POST' --header 'Content-Type: application/xml' --data ' ... ' -u "${upw}" "https://${host}/ovirt-engine/api/vms/2409c422-fd16-48e8-9d3a-75b4dd6e7f22/diskattachments" # Check console curl -s -k --header 'Accept: application/xml' --request GET --header 'All-Content: true' --header 'Content-Type: application/xml' \ -u "${upw}" https://${host}/ovirt-engine/api/vms/2409c422-fd16-48e8-9d3a-75b4dd6e7f22 | grep -A 2 '<console>' <console> <enabled>false</enabled> </console> # Enable serial console curl -s -k --header 'Accept: application/xml' --request 'PUT' --header 'Content-Type: application/xml' --data ' <vm> <console> <enabled>true</enabled> </console> </vm> ' -u "${upw}" "https://${host}/ovirt-engine/api/vms/2409c422-fd16-48e8-9d3a-75b4dd6e7f22" # Add CDROM curl -s -k --header 'Accept: application/xml' --request 'PUT' --header 'All-Content: true' --header 'Content-Type: application/xml' --data ' <cdrom> <file id="rhel-server-6.9-x86_64-dvd.iso"/> </cdrom> ' -u "${upw}" "https://${host}/ovirt-engine/api/vms/2409c422-fd16-48e8-9d3a-75b4dd6e7f22/cdroms/00000000-0000-0000-0000-000000000000?current=false" # Check serial console curl -s -k --header 'Accept: application/xml' --request GET --header 'All-Content: true' --header 'Content-Type: application/xml' -u "${upw}" https://${host}/ovirt-engine/api/vms/2409c422-fd16-48e8-9d3a-75b4dd6e7f22 | grep -A 2 '<console>' <console> <enabled>false</enabled> ^^^^^--------------------> notice it being disabled after inserting the CDROM </console>
interesting. Yeah, for powered down VM it should work. Thanks for clarification
reproduced. weird...
Re-targeting to 4.3.1 since it is missing a patch, an acked blocker flag, or both
It seems that values for console enablement and affinity labels are reset to defaults (console enabled = false, no affinity labels) if they are not specified in the request. This happens not only after modifying ISO/CDROM but also when modifying other VM parameters, e.g. comment.
sync2jira
WARN: Bug status (ON_QA) wasn't changed but the folowing should be fixed: [Found non-acked flags: '{}', ] For more info please contact: rhv-devops: Bug status (ON_QA) wasn't changed but the folowing should be fixed: [Found non-acked flags: '{}', ] For more info please contact: rhv-devops
Verified with: - ovirt-engine-4.4.0-0.13.master.el7.noarch - ovirt-engine-restapi-4.4.0-0.13.master.el7.noarch Verification steps (all done by REST API requests): 1. Create a VM. 2. Enable serial console. 3. Add VM comment. 4. Verify serial console is remains enabled after the comment has been added. Result: - Serial Console is enabled after a comment has been added.
WARN: Bug status (VERIFIED) wasn't changed but the folowing should be fixed: [Found non-acked flags: '{}', ] For more info please contact: rhv-devops: Bug status (VERIFIED) wasn't changed but the folowing should be fixed: [Found non-acked flags: '{}', ] For more info please contact: rhv-devops
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Important: RHV Manager (ovirt-engine) 4.4 security, bug fix, and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2020:3247