Bug 1057108 - Detaching vm disk doesn't lead to ovf update
Summary: Detaching vm disk doesn't lead to ovf update
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: oVirt
Classification: Retired
Component: ovirt-engine-core
Version: 3.4
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: 3.5.0
Assignee: Liron Aravot
QA Contact: Elad
URL:
Whiteboard: storage
: 1131539 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-01-23 13:18 UTC by Yaniv Bronhaim
Modified: 2016-02-10 18:29 UTC (History)
10 users (show)

Fixed In Version: ovirt-3.5.0_rc1.1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-10-17 12:44:24 UTC
oVirt Team: Storage
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 31009 0 master MERGED core: increment the vm generation when disk is being unplugged Never
oVirt gerrit 31279 0 ovirt-engine-3.5 MERGED core: increment the vm generation when disk is being unplugged Never

Description Yaniv Bronhaim 2014-01-23 13:18:14 UTC
Description of problem:
Detaching vm disk doesn't update ovf file 

How reproducible:
100%

Steps to Reproduce:
1. attach 2 disk to vm
2. detach one disk (or both of them)
3. Ovf file stays with no update

Expected results:
Ovf file should be updated with new vm structure

Comment 1 Itamar Heim 2014-01-26 08:11:44 UTC
Setting target release to current version for consideration and review. please
do not push non-RFE bugs to an undefined target release to make sure bugs are
reviewed for relevancy, fix, closure, etc.

Comment 2 Ayal Baron 2014-02-17 20:44:05 UTC
(In reply to Yaniv Bronhaim from comment #0)
> Description of problem:
> Detaching vm disk doesn't update ovf file 
> 
> How reproducible:
> 100%
> 
> Steps to Reproduce:
> 1. attach 2 disk to vm
> 2. detach one disk (or both of them)
> 3. Ovf file stays with no update
> 
> Expected results:
> Ovf file should be updated with new vm structure

1. ovf update is not synchronous after operation but rather happens async every few minutes.  Did you check immediately after detach or did you wait sufficient time (Liron can update what the default value is)?

2. I'm guessing this was part of the oVirt 3.4 test day? (if so, ovf on any domain feature did not make it into ovirt 3.4...)

Comment 3 Liron Aravot 2014-02-17 20:47:48 UTC
The issue is that detach of a disk never led to a update of the vm ovf (even before the ovf updater was added).

Comment 4 Yaniv Bronhaim 2014-02-18 08:07:54 UTC
this issue does not directly relate to the ovf uploading part. deataching the disk didn't lead to the update and therefore the new update was not created at all.

the ovf uploading feature made it to 3.4 eventually. and this bug will be fixed separately to the feature

Comment 5 Liron Aravot 2014-08-19 14:26:20 UTC
*** Bug 1131539 has been marked as a duplicate of this bug. ***

Comment 6 Elad 2014-08-26 08:36:01 UTC
Detaching a disk from a VM, trigger an update for its OVF file in the OVF_STORE disk. After the removal of the disk from the VM, the disk no longer exists in the OVF file of the VM.
Also, in case a VM has only one disk on a domain, the OVF file of the VM will be removed in the ovf update when detaching this disk from the VM.
Before the removal, OVF 78e13c28-6b5b-494b-96e3-0b034b42a308.ovf exists in the OVF_STORE disk:

[root@green-vdsb /]# tar -xvf ovf2
info.json
92127c29-3741-4f43-ac0b-458ed6a0b140.ovf
c5f6f2bf-8a7d-406c-9fec-1956edb1af6e.ovf
78e13c28-6b5b-494b-96e3-0b034b42a308.ovf


After the removal of the disks from the VM, the OVF of VM 78e13c28-6b5b-494b-96e3-0b034b42a308 no longer exists in the OVF_STORE disk:

[root@green-vdsb /]# tar -xvf ovf3
info.json
92127c29-3741-4f43-ac0b-458ed6a0b140.ovf
c5f6f2bf-8a7d-406c-9fec-1956edb1af6e.ovf

Checked on block and file domains

Verified by testing the scenario described in https://tcms.engineering.redhat.com/case/336108/?from_plan=12239
Using ovirt-3.5 RC1.1

Comment 7 Sandro Bonazzola 2014-10-17 12:44:24 UTC
oVirt 3.5 has been released and should include the fix for this issue.


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