Created attachment 1055381 [details] snaphost Description of problem: Snapshot deletion of powered off VMs takes longer. Version-Release number of selected component (if applicable): Version 3.5.1-0.4.el6ev How reproducible:Always Steps to Reproduce: 1.Create a snapshot of powered off VM 2.Try to delete the snapshot 3.Snapshot will be in locked state for more than 10-15 mins which is huge when compared to live VM snapshot removal which is taking 1-2 mins. Actual results: Expected results: Additional info:
Created attachment 1055382 [details] VDSM Logs
Created attachment 1055383 [details] Engine Logs
This needs some initial analysis to see what's taking up the time here. Nir - can you take a look please?
(In reply to dev-unix-virtualization from comment #0) > 3.Snapshot will be in locked state for more than 10-15 mins which is huge > when compared to live VM snapshot removal which is taking 1-2 mins. Both tests were done on same storage and same wipe-after-delete settings?
Yes, There was no change w.r.t to storage and settings, Also reproducible every time on our 2 test setups. One setup is on iSCSI storage domain and one is on local storage/NFS.
(In reply to dev-unix-virtualization from comment #5) > Yes, There was no change w.r.t to storage and settings, Also reproducible > every time on our 2 test setups. One setup is on iSCSI storage domain and > one is on local storage/NFS. Can you provide detailed description, how to reproduce this issue? - Vm configuration - Disk configuration (format, virtual size, actual size) - What os to install - How to create the snapshot/delete (using the rest api?)
RHEV-M:- Version 3.5.1-0.4.el6ev RHEVH:- RHEV Hypervisor - 7.1 - 20150420.0.el7ev Kernel Version:- 3.10.0 - 229.1.2.el7.x86_64 VDSM Version:vdsm-4.16.13.1-1.el7ev CPU Model:- Intel(R) Xeon(R) CPU E5620 @ 2.40GHz CPU Type: Intel Westmere Family Model:- PowerEdge R410 VM Configuration. OS:- Windows 2012 Virtual size:- 32GB Actual size :- 8GB Interface type:- VirtIO Storage type:- iSCSI from Dell Compellent array. Allocation Policy:- Thin Provisioned RestAPI used to create and delete the snapshot. For Create Snapshot: <VM ID> POST REAT API: [https://rhevm.devemc.commvault.com/api/vms/8f7eccd9-156e-4790-9ef7-db090e4662cf/snapshot] Body: [<?xml version="1.0" encoding="UTF-8" standalone="no" ?> <snapshot> <description>_GX_BACKUP_vm1_25_20111_392cd700</description> </snapshot>] For Delete Snapshot: <VM ID> <Snapshot Id> DELETE REST API: [https://rhevm.devemc.commvault.com/api/vms/8f7eccd9-156e-4790-9ef7-db090e4662cf/snapshots/6195d4a0-7d85-404e-a659-06f7852289e4] Body: [<?xml version="1.0" encoding="UTF-8" standalone="no" ?> <action> <async>false</async> <detach>false</detach> </action>]
Any update on this issue ?
Can you please elaborate upon what info is being asked for ? We have provided requested information in Comment#7 as a response to Comment#6.
The need info was on the assignee, restoring it.
(In reply to dev-unix-virtualization from comment #8) > Any update on this issue ? Cold snapshot delete is implemented differently and is less efficient than live snapshot delete, since "qemu-img commit" was not available when cold snapshot was developed. We still need to investigate further to see if the the timing info in comment 0 is normal.
this is an automated message. oVirt 3.6.0 RC3 has been released and GA is targeted to next week, Nov 4th 2015. Please review this bug and if not a blocker, please postpone to a later release. All bugs not postponed on GA release will be automatically re-targeted to - 3.6.1 if severity >= high - 4.0 if severity < high
*** Bug 1206328 has been marked as a duplicate of this bug. ***
*** Bug 1275652 has been marked as a duplicate of this bug. ***
We will be rewriting this flow in RHEV 4 to make it faster and more similar to live merge. This is not a task possible for RHEV 3.6.
Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.
Happens also on FC storage domain.
I just realized that this is a regression (following comment #2 on bug 1275652 which was closed as duplicate of this one) As it affects our automation and as this is a regression , I would like to raise and try to get a fix on 3.6.
This bug is marked for z-stream, yet the milestone is for a major version, therefore the milestone has been reset. Please set the correct milestone or drop the z stream flag.
This bug report has Keywords: Regression or TestBlocker. Since no regressions or test blockers are allowed between releases, it is also being identified as a blocker for this release. Please resolve ASAP.
(In reply to Aharon Canan from comment #18) > I just realized that this is a regression (following comment #2 on bug > 1275652 which was closed as duplicate of this one) Cold merge is slower than live merge, even in 3.5 (as comment 2 states). This is not a regression. > As it affects our automation and as this is a regression , I would like to > raise and try to get a fix on 3.6. The solution is to rewrite the flow. Hardly a 3.6 item.
We merged the new api, but it is not implemented yet.
Ala, please update the doc text with the feature page or a relevant text