Bug 1057108
| Summary: | Detaching vm disk doesn't lead to ovf update | ||
|---|---|---|---|
| Product: | [Retired] oVirt | Reporter: | Yaniv Bronhaim <ybronhei> |
| Component: | ovirt-engine-core | Assignee: | Liron Aravot <laravot> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Elad <ebenahar> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 3.4 | CC: | amureini, bugs, ebenahar, gklein, iheim, kgoldbla, laravot, rbalakri, ybronhei, yeylon |
| Target Milestone: | --- | ||
| Target Release: | 3.5.0 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | storage | ||
| Fixed In Version: | ovirt-3.5.0_rc1.1 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2014-10-17 12:44:24 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | Storage | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Yaniv Bronhaim
2014-01-23 13:18:14 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. (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...) The issue is that detach of a disk never led to a update of the vm ovf (even before the ovf updater was added). 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 *** Bug 1131539 has been marked as a duplicate of this bug. *** 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 oVirt 3.5 has been released and should include the fix for this issue. |