Bug 1120232
| Summary: | Taking snapshot of vm in suspend state doesn't work | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Retired] oVirt | Reporter: | Raz Tamir <ratamir> | ||||||
| Component: | ovirt-engine-core | Assignee: | Michal Skrivanek <michal.skrivanek> | ||||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Israel Pinto <ipinto> | ||||||
| Severity: | high | Docs Contact: | |||||||
| Priority: | high | ||||||||
| Version: | 3.5 | CC: | amureini, bugs, ecohen, gklein, istein, michal.skrivanek, ratamir, rbalakri, tnisan, yeylon | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | 3.6.0 | ||||||||
| Hardware: | Unspecified | ||||||||
| OS: | Unspecified | ||||||||
| Whiteboard: | virt | ||||||||
| Fixed In Version: | ovirt-engine-3.6.0-0.0.master.20150412172306.git55ba764 | Doc Type: | Bug Fix | ||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2015-11-04 11:20:55 UTC | Type: | Bug | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | Virt | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
Raz, how is it an automation blocker? It should be Regression not automation blocker. I have a hard time finding anything in the noise of vdsm. Would it be possible to retry, as there are several issues in the log already addressed in recent 3.5 builds Created attachment 927420 [details]
vdsm and engine logs
still quite a noise…which version did you use for comment #4? I don't see any issues so far decreasing severity as easy workaround exists Hi Michal, What do you expect to see? I wrote in the description that the issue is that the file that was part of the isn't restored after we delete the file and and preview. In logs all is good. So I think the severity should be urgent since this basic operation could cause a data loss Ok thanks to Raz i got this reproduced, i think we already seen a similar issue before, the problem is that when resuming from hibernation, vdsm is using the saved configuration file to start the vm, in this file, the volume id is the previous snapshot volume, and vdsm ignore the new snapshot volume id sent from the engine. this means that the vm is still using the previous snapshot, and only after fresh restart the vm will use the new snapshot. not sure if we need to fix vdsm to handle this situation, or just decide to block snapshot for suspended vm also, i dont think this is a regression, Raz, did this flow ever worked? Hi Omer, According to previous test runs it used to work removing regression flag, i verified the same behaviour in 3.4 please let me know if you are able to see this working on previous version. since we dont have hibernation information saved in the snapshot (ovf) i am in favor of blocking snapshot for suspended vm. Michal what do you think? (In reply to Omer Frenkel from comment #9) +1 Verify with: Engine RHEVM: 3.6.0-0.13.master.el6 VDSM: vdsm-4.17.5-1.el7ev Scenario: 1. Create VM with OS 2. Run VM 3. Suspend VM 4. Take snapshot on this VM Results: Operation canceled with message: "Cannot create Snapshot because the VM is in Suspended status" Test PASS oVirt 3.6.0 has been released on November 4th, 2015 and should fix this issue. If problems still persist, please open a new BZ and reference this one. |
Created attachment 918410 [details] vdsm and engine logs Description of problem: Setup: 1 vm with OS. Creating new file on vm and suspend it. When in suspend state, take snapshot. After snapshot operation complete, delete the file and preview. The expected result is that the file will be found on the vm's disk. The file is not fount in the vm's disk Version-Release number of selected component (if applicable): ovirt-engine-3.5.0-0.0.master.20140629172257.git0b16ed7.el6.noarch vdsm-4.16.0-3.git601f786.el6.x86_64 How reproducible: 100% Steps to Reproduce: 1. explained above 2. 3. Actual results: Expected results: The file should be restore after previewing the snapshot Additional info: