Bug 1278738 - The "virtio_scsi" element isn't populated when a VM is requested
Summary: The "virtio_scsi" element isn't populated when a VM is requested
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: RestAPI
Version: 3.5.5
Hardware: Unspecified
OS: Unspecified
Target Milestone: ovirt-4.0.0-alpha
: 4.0.0
Assignee: Juan Hernández
QA Contact: Shira Maximov
Depends On:
Blocks: 1213937
TreeView+ depends on / blocked
Reported: 2015-11-06 10:32 UTC by Juan Hernández
Modified: 2016-08-17 14:37 UTC (History)
3 users (show)

Fixed In Version: ovirt 4.0.0 alpha1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2016-08-17 14:37:40 UTC
oVirt Team: Virt
rule-engine: ovirt-4.0.0+
rule-engine: planning_ack+
rule-engine: devel_ack+
mavital: testing_ack+

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
oVirt gerrit 50160 0 master MERGED restapi: Document the use of "All-Content" for VMs Never

Description Juan Hernández 2015-11-06 10:32:15 UTC
When a VM is requested using the RESTAPI the "virtio_scsi" element isn't populated. The expected result should be the following:

  GET /vms/{vm:id}

As a side effect, when using the Python SDK the following code used to disable VirtIO SCSI will fail:

  vm = api.vms.get(name="myvm")

It will fail because "vm.get_virtio_scsi()" returns "None".

As a workaround Python SDK users can do the following:


Comment 1 Juan Hernández 2015-11-06 10:51:10 UTC
The reason for this missing information is that computing it is expensive, as it requires an additional query per VM, so it has been made optional, it will only be returned when the "All-Content" header is "true":

  GET /vms/{vm:id}
  All-Content: true

    <virtio_scsi enabled="true|false"/>

Note also that "enabled" is an attribute, not an inner element as in the description of the bug.

In the Python SDK the "All-Content" header can be activated using the "all_content" parameter of the operation that retrieves the VM:

  vm = api.vms.get(name="myvm", all_content=True)

As this was a design decision and there are workarounds I think that we aren't going to change it.

Comment 2 Michal Skrivanek 2015-12-04 14:59:47 UTC
I agree with comment #1. I guess the bug can be closed, right

Comment 3 Petr Spacek 2015-12-04 15:14:41 UTC
Honesly I cannot believe that either RHEV or Python SDK will not be fixed. How can I as a mere user know that this workaround is necessary?

Speaking as a regular SDK user, I would like something which acts consistently and does not blow up in unexpected ways.

Comment 4 Juan Hernández 2015-12-09 10:29:13 UTC
I this kind of situation we can change the server so that it returns always all the information by default. That hurts performance, so we aren't doing it.

We can improve things for users documenting it. That is what the proposed patch does.

In version 4.0 the documentation will be available from the server, and will look like this:


This documentation will eventually also added to the SDK itself.

But other than documenting it I don't see how we can make the system more consistent in these regards, unless we always return all the information.

Comment 5 Shira Maximov 2016-08-16 13:39:26 UTC
verified on :
Red Hat Virtualization Manager Version:

verification steps:
  GET /vms/{vm:id}
  All-Content: true


Note You need to log in before you can comment on or make changes to this bug.