Description of problem: Preview of memory snapshot created in 4.1 erroneously warns of reverting to cluster compatabilty ver 3.6. After selecting the snapshot is previewed as usual. Nothing of the said warning happens. Version-Release number of selected component (if applicable): ovirt-engine-4.1.1.6-0.1.el7.noarch rhevm-4.1.1.6-0.1.el7.noarch vdsm-4.19.10-1.el7ev.x86_64 How reproducible: 100% Steps to Reproduce: 1. Create a VM with disks using 4.1 latest 2. Create 3 snapshots of Vm with data written to disks 3. Delete a snapshot and cold merge is performed 4. Select to preview one of the remaining snapshots >>>>> Get an erroneous message that if selecting the Memory check box the snapshot which was created with a Cluster compatability version of 3.6 will revert to that version. Actual results: Get message that if selecting the Memory check box the snapshot which was created with a Cluster compatability version of 3.6 will revert to that version. Expected results: SEE SCREEN SHOT A different message should be displayed indicating what actually is ment Additional info:
Created attachment 1268475 [details] server, engine, vdsm logs and screen shot
Im unable to reproduce this and don't see in code any obvious place how it could happen. Any chance you could let me to an env where it happens?
@Kevin? Removing blocker flag in meanwhile, this does not seem to happen to anyone else so does not look too serious.
Does not happen to me. Please feel free to reopen when you will have an environment where it happens.
This bug easily reproduced on latest master 4.2 - 4.2.0-0.0.master.20170822172135.git20a2fee.el7.centos
I will provide log soon. Please contact me directly and i will provide the setup in order to prevent the need info ping pong. Thanks
Steps to reproduce are very easy and are the same as Kevin described in comment#0 " The selected snapshot's memory was taken in previous cluster version. If restored, the VM's Custom Compatibility Version will be set to 3.6. Please confirm the memory shall be restored." Reproduction rate is 100% 1) Create VM in cluster 4.2 and run it 2) Make 3 snapshots of it - snap1, snap2 and snap3 3) Shutdown the VM 4) Delete snap2 snapshot 5) Preview snap3 --> we get the wrong message
Created attachment 1317083 [details] engine log
I can't reproduce this problem according to steps in comment 8 on current master (commit f2d4194e5c) using snapshots both with and without memory.
(In reply to jniederm from comment #9) > I can't reproduce this problem according to steps in comment 8 on current > master (commit f2d4194e5c) using snapshots both with and without memory. As i asked in comment6# ^^, please contact me so we will stop this i can't reproduce this problem thing. The problem is there and we have logs. I have a setup with this bug and it is reproducible 100% indeed on latest master. SO why not just look into this issue in real time? Thanks,
somehow it doesn't happen to us, yet you say 100% reproduction rate. I suppose that is on different setups too? If so, can you please provide more detailed steps so we can doublecheck that we both reproduce it the same way? In general we do not have a capacity to look into your setup in real time, sorry.
Hi Michal, I'm using latest master version. The steps are - 1) Create VM in cluster 4.2 and run it 2) Make 3 snapshots of it - snap1, snap2 and snap3 3) Shutdown the VM 4) Delete snap2 snapshot 5) Preview snap3 --> we get the wrong message Follow the steps exactly and you will see the wrong message appears. I'm reproducing this issue in a few minutes only. I suppose we can continue with this endless 'i can't reproduce' and ' i can reproduce' . I can't help you more then this, i have provided everything needed: - Setup with the bug was suggested - Clear steps - Logs - Reproduction in real time was suggested There are no more detailed steps, this are the steps. Nothing more and nothing less. Please follow the steps. Regards,
Spoke with Vitali and taking the bug on me. Verified on - 4.2.0-0.5.master.el7 and 4.2.0-0.0.master.20171203210723.git12a8bd2.el7.centos
This bugzilla is included in oVirt 4.2.0 release, published on Dec 20th 2017. Since the problem described in this bug report should be resolved in oVirt 4.2.0 release, published on Dec 20th 2017, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.