Bug 1014035

Summary:	Can't make persistent CDRom change while VM is running
Product:	Red Hat Enterprise Virtualization Manager	Reporter:	Christophe Fergeau <cfergeau>
Component:	ovirt-engine-restapi	Assignee:	Martin Betak <mbetak>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Pavel Novotny <pnovotny>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	3.3.0	CC:	acathrow, bazulay, iheim, istein, juan.hernandez, mavital, mbetak, michal.skrivanek, oramraz, Rhev-m-bugs, yeylon
Target Milestone:	---	Keywords:	Triaged, ZStream
Target Release:	3.4.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	virt
Fixed In Version:	ovirt-engine-3.4.0-0.11.beta3	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:
Clones:	1059085 (view as bug list)		Environment:
Last Closed:		Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1059085, 1078909, 1142926

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