Bug 1014035 - Can't make persistent CDRom change while VM is running
Summary: Can't make persistent CDRom change while VM is running
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-restapi
Version: 3.3.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: 3.4.0
Assignee: Martin Betak
QA Contact: Pavel Novotny
URL:
Whiteboard: virt
Depends On:
Blocks: 1059085 rhev3.4beta 1142926
TreeView+ depends on / blocked
 
Reported: 2013-10-01 09:52 UTC by Christophe Fergeau
Modified: 2014-09-18 12:24 UTC (History)
11 users (show)

Fixed In Version: ovirt-engine-3.4.0-0.11.beta3
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1059085 (view as bug list)
Environment:
Last Closed:
oVirt Team: ---
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 20288 0 None None None Never
oVirt gerrit 20994 0 None None None Never

Description Christophe Fergeau 2013-10-01 09:52:33 UTC
Using the REST API (https://access.redhat.com/site/documentation//en-US/Red_Hat_Enterprise_Virtualization/3.2/html/Developer_Guide/Virtual_Machine_CD-ROMs_Sub-Collection.html), it's possible to 
- change the CD used by a VM while it's running using ?current, however the change will be lost when the VM is stopped
- change the CD used by a VM while it's stopped, in which case it will be persistent across VM stops/starts

However, trying to persistently change the CD used by the VM while it's running is not possible:

> PUT //api/vms/d14e4ddc-3dc5-4157-8e4d-f0f807856884/cdroms/00000000-0000-0000-0000-000000000000 HTTP/1.1
> Soup-Debug-Timestamp: 1380620827
> Soup-Debug: SoupSessionAsync 1 (0x6b1960), SoupMessage 4 (0xa44390), SoupSocket 5 (0x73aa80)
> Host: rhevm33.spice.lab.eng.brq.redhat.com
> Content-Type: application/xml
> Filter: true
> Connection: Keep-Alive
> Authorization: Basic [teuf.eng.brq.redhat.com:*********]
>
> <cdrom>
>       <file id="10Zig.iso"/>
> </cdrom>

< HTTP/1.1 400 Bad Request
< Soup-Debug-Timestamp: 1380620828
< Soup-Debug: SoupMessage 4 (0xa44390)
< Date: Tue, 01 Oct 2013 09:47:05 GMT
< Content-Type: application/xml
< Content-Length: 262
< Vary: Accept-Encoding
< Connection: close
<
< <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
< <fault>
<     <reason>Operation Failed</reason>
<     <detail>[There was an attempt to change VM values while the VM is not down. Please shut down the VM in order to modify these properties.]</detail>
< </fault>

Combined with the fact that it's not possible to GET the name of the ISO that was set using ?current (I'll file a bug about that), this makes CD changing through the REST API difficult.

Comment 1 Michael Pasternak 2013-10-01 09:56:19 UTC
please also file documentation bug, 'current' is a matrix and not query param,
e.g /api/vms/d14e4ddc-3dc5-4157-8e4d-f0f807856884/cdroms/00000000-0000-0000-0000-000000000000;current

Comment 2 Christophe Fergeau 2013-10-01 10:27:46 UTC
This is indeed documented as a 'matrix' parameter in the rsdl description, but using ; or ? does not seem to make a difference, both seem to be working when talking to a 3.3 instance (and ?current was also working on a 3.2 instance). Should things be made more strict?

Comment 3 Michael Pasternak 2013-10-01 10:31:46 UTC
(In reply to Christophe Fergeau from comment #2)
> This is indeed documented as a 'matrix' parameter in the rsdl description,
> but using ; or ? does not seem to make a difference, both seem to be working
> when talking to a 3.3 instance (and ?current was also working on a 3.2
> instance). Should things be made more strict?

"query" (?current) is deprecated and supported in 3.3 in sake of backward
comparability only,

IIRC docs folks had a BZ to document that.

Comment 4 Christophe Fergeau 2013-10-01 10:41:40 UTC
(In reply to Michael Pasternak from comment #1)
> please also file documentation bug, 'current' is a matrix and not query
> param,
> e.g
> /api/vms/d14e4ddc-3dc5-4157-8e4d-f0f807856884/cdroms/00000000-0000-0000-0000-
> 000000000000;current

Filed as bug #1014057

Comment 7 Pavel Novotny 2014-02-18 13:28:27 UTC
FailedQA in ovirt-engine-3.4.0-0.7.beta2.el6.noarch.

Changing CD permanently on a running VM still returns error.

Verification steps:
1. Have a running VM without CD-ROM image attached (I used Fedora 19).
2. Attach CD permanently:
>>> request:
PUT /api/vms/5d4f3c8a-7514-400d-a0f7-5c6c51178ba8/cdroms/00000000-0000-0000-0000-000000000000

<cdrom>
<file id="CentOS-6.5-x86_64-minimal.iso"/>
</cdrom>

>>> response:
<fault>
<reason>Operation Failed</reason>
<detail>
[There was an attempt to change VM values while the VM is not down. Please shut down the VM in order to modify these properties.]
</detail>
</fault>


The reason seems to be that none of the attached Gerrit patches was merged to ovirt-engine-3.4 branch and therefore is missing in oVirt 3.4.

Comment 8 Juan Hernández 2014-02-18 13:34:04 UTC
Martin, please backport to 3.4.

Comment 9 Martin Betak 2014-02-19 14:13:47 UTC
Checking git log the 3.4 branch already contains this fix and has for a long time now. I also built the 3.4 upstream branch and verified the above flow.

Comment 10 Martin Betak 2014-02-19 14:38:58 UTC
Should be fixed in beta3.

Comment 11 Pavel Novotny 2014-02-19 14:49:14 UTC
Confirmed and verified in ovirt-engine-3.4.0-0.11.beta3.el6.noarch (updated Fixed In Version).

Verification steps:
1. Have a running VM without CD-ROM image attached (I used VM with Fedora 19).
2. Attach CD permanently:
>>> request:
PUT /api/vms/5d4f3c8a-7514-400d-a0f7-5c6c51178ba8/cdroms/00000000-0000-0000-0000-000000000000

<cdrom>
<file id="CentOS-6.5-x86_64-minimal.iso"/>
</cdrom>

>>> response:
<cdrom href= "/ovirt-engine/api/vms/5d4f3c8a-7514-400d-a0f7-5c6c51178ba8/cdroms/00000000-0000-0000-0000-000000000000" id="00000000-0000-0000-0000-000000000000">
<vm href= "/ovirt-engine/api/vms/5d4f3c8a-7514-400d-a0f7-5c6c51178ba8" id="5d4f3c8a-7514-400d-a0f7-5c6c51178ba8"/>
<file id="CentOS-6.5-x86_64-minimal.iso"/>
</cdrom>


The CD is not changed on-the-fly while the VM is running (which is correct), however the change is persistent and survives after the VM is stopped & started again.

Comment 12 Itamar Heim 2014-06-12 14:08:32 UTC
Closing as part of 3.4.0


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