Description of problem: When trying to set the VM domain value through the REST API, the call returns successfully but the value is not actually set Version-Release number of selected component (if applicable): rhevm-3.2.4-0.44.el6ev rhevm-restapi-3.2.4-0.44.el6ev How reproducible: 100% Steps to Reproduce: 1. Create new Desktop VM with OS type windows_7x64 through admin portal or REST API 2. Run the following command to set the domain through the REST API: curl -k -u admin@internal:password -X PUT -H "Content-Type: application/xml" -d "<vm><domain>ad.example.com</domain></vm>" https://rhevm.example.com/api/vms/c9a2c705-7c5e-4465-9a93-f529d65da85a Actual results: command completes successfully and API returns "edited" XML for VM, but no <domain> value is set Expected results: command completes successfully and API returns new XML for VM with correct <domain> value set
I tested this on current 3.3.beta (rhevm-3.3.0-0.38.rc.el6ev). And I see the problem: - the command in the description of the bug is incorrect and it is missing <name> inside the domain xml specification. (so that is should look like: <vm><domain><name>ad.example.com</name></domain></vm> - but even running the command this way, with the incorrect xml, the return code is 200 OK, when it should be reporting a failure. If the xml is not formed correctly, an error should be returned. ================== On the same note, I tested it with giving it other domain that the one available in RHEV UI (the one that RHEV-M is registered). While this option is not available in UI, it succeeded on API. Sounds like another bug to me, but maybe it is a feature?
The RESTAPI doesn't validate the received XML against the XML schema, so any unrecognized XML element is just ignored. This means that in general it can't distinguish missing and incorrect elements. However, in this specific case, we can validate the the "name" is provided when the "domain" element is provided.
In accordance to Comment 3 above, I submitted a patch that validates that if <domain> element is supplied for VM update, <domain><name> provided as well: http://gerrit.ovirt.org/23983
Failed QA PASSWD - password to setup VMID - id of vm in setup ADDR - ip address of setup used command:[lsvaty@~] $ curl -k -u admin@internal:$PASSWD -X PUT -H "Content-Type: application/xml" -d "<vm><domain>ad.example.com</domain></vm>" https://$ADDR/api/vms/$VMID <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <vm href="/api/vms/38806261-b7df-4387-a236-625a9c1c185d" id="38806261-b7df-4387-a236-625a9c1c185d"> <actions> <link href="/api/vms/38806261-b7df-4387-a236-625a9c1c185d/ticket" rel="ticket"/> <link href="/api/vms/38806261-b7df-4387-a236-625a9c1c185d/migrate" rel="migrate"/> <link href="/api/vms/38806261-b7df-4387-a236-625a9c1c185d/reboot" rel="reboot"/> <link href="/api/vms/38806261-b7df-4387-a236-625a9c1c185d/cancelmigration" rel="cancelmigration"/> <link href="/api/vms/38806261-b7df-4387-a236-625a9c1c185d/move" rel="move"/> <link href="/api/vms/38806261-b7df-4387-a236-625a9c1c185d/detach" rel="detach"/> <link href="/api/vms/38806261-b7df-4387-a236-625a9c1c185d/export" rel="export"/> <link href="/api/vms/38806261-b7df-4387-a236-625a9c1c185d/shutdown" rel="shutdown"/> <link href="/api/vms/38806261-b7df-4387-a236-625a9c1c185d/start" rel="start"/> <link href="/api/vms/38806261-b7df-4387-a236-625a9c1c185d/stop" rel="stop"/> <link href="/api/vms/38806261-b7df-4387-a236-625a9c1c185d/suspend" rel="suspend"/> </actions> <name>d</name> <link href="/api/vms/38806261-b7df-4387-a236-625a9c1c185d/applications" rel="applications"/> <link href="/api/vms/38806261-b7df-4387-a236-625a9c1c185d/disks" rel="disks"/> <link href="/api/vms/38806261-b7df-4387-a236-625a9c1c185d/nics" rel="nics"/> <link href="/api/vms/38806261-b7df-4387-a236-625a9c1c185d/cdroms" rel="cdroms"/> <link href="/api/vms/38806261-b7df-4387-a236-625a9c1c185d/snapshots" rel="snapshots"/> <link href="/api/vms/38806261-b7df-4387-a236-625a9c1c185d/tags" rel="tags"/> <link href="/api/vms/38806261-b7df-4387-a236-625a9c1c185d/permissions" rel="permissions"/> <link href="/api/vms/38806261-b7df-4387-a236-625a9c1c185d/statistics" rel="statistics"/> <link href="/api/vms/38806261-b7df-4387-a236-625a9c1c185d/reporteddevices" rel="reporteddevices"/> <link href="/api/vms/38806261-b7df-4387-a236-625a9c1c185d/watchdogs" rel="watchdogs"/> <type>desktop</type> <status> <state>down</state> </status> <memory>2147483648</memory> <cpu> <topology sockets="1" cores="1"/> <architecture>X86_64</architecture> </cpu> <cpu_shares>0</cpu_shares> <os type="windows_7x64"> <boot dev="hd"/> </os> <high_availability> <enabled>true</enabled> <priority>1</priority> </high_availability> <display> <type>spice</type> <monitors>1</monitors> <single_qxl_pci>false</single_qxl_pci> <allow_override>false</allow_override> <smartcard_enabled>false</smartcard_enabled> </display> <cluster href="/api/clusters/00000001-0001-0001-0001-000000000253" id="00000001-0001-0001-0001-000000000253"/> <template href="/api/templates/00000000-0000-0000-0000-000000000000" id="00000000-0000-0000-0000-000000000000"/> <stop_time>2014-02-26T19:31:17.558+01:00</stop_time> <creation_time>2014-02-26T18:53:13.693+01:00</creation_time> <origin>ovirt</origin> <stateless>false</stateless> <delete_protected>false</delete_protected> <sso> <methods> <method id="GUEST_AGENT"/> </methods> </sso> <console enabled="false"/> <initialization> <configuration> <type>ovf</type> <data>...(lot of data suff)...</data> </configuration> </initialization> <placement_policy> <affinity>migratable</affinity> </placement_policy> <memory_policy> <guaranteed>2147483648</guaranteed> <ballooning>true</ballooning> </memory_policy> <usb> <enabled>false</enabled> </usb> <migration_downtime>-1</migration_downtime> <virtio_scsi enabled="true"/> </vm>
Ori, please make sure that this change is backported to the ovirt-engine-3.4 branch.
The fix has been merged to the upstream 3.4 branch, so it will be available with the next rebase.
verified in av7
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, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHSA-2014-0506.html
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days