Bug 1049080

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