Bug 1436247
| Summary: | Can't turn stateless check box back for stateless VMs after making changes to their configuration and making a snapshot from them. | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [oVirt] ovirt-engine | Reporter: | Nikolai Sednev <nsednev> | ||||||
| Component: | BLL.Virt | Assignee: | Michal Skrivanek <michal.skrivanek> | ||||||
| Status: | CLOSED DUPLICATE | QA Contact: | Nikolai Sednev <nsednev> | ||||||
| Severity: | high | Docs Contact: | |||||||
| Priority: | high | ||||||||
| Version: | 4.1.1.6 | CC: | astepano, bugs, devel, jbelka, jniederm, mbetak, michal.skrivanek, nsednev, spice-qe-bugs, tjelinek | ||||||
| Target Milestone: | --- | Keywords: | Regression, Triaged | ||||||
| Target Release: | --- | Flags: | nsednev:
planning_ack?
nsednev: devel_ack? nsednev: testing_ack? |
||||||
| Hardware: | x86_64 | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | 1430009 | Environment: | |||||||
| Last Closed: | 2017-04-04 06:18:19 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: | |||||||||
| Bug Depends On: | 1430009 | ||||||||
| Bug Blocks: | |||||||||
| Attachments: |
|
||||||||
|
Description
Nikolai Sednev
2017-03-27 13:49:27 UTC
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. 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. Hi Marcus, I tried to reproduce your issue, following your steps with changing the stateless flag after snapshot but didn't find any issues - I was able to snapshot, edit, run the VM, even create a new one from the snapshot and run that one. Could you please provide logs or any more details about the VM (cluster version, ...) Thank you very much in advance, Martin Created attachment 1266720 [details] Output from ovirt-shell showing Blank template and VM This seems very related to bug #1430009. I noted that the "usb-enabled" setting differed between the template and the VM, so on a chance I switched usb-enabled from False to True in the VM, and that worked! After doing that operation I can switch usb-enabled back to False, or do any other changes in the VM including enabling stateless mode and then disable stateless mode. I would thus guess that something in the past brought the USB state of these VMs to some weird state. show vm vmname --all_content looks exactly the same before and after "fixing" the VM as above, so I'm not really sure where the state that makes things break is stored? Let me know if you want some data dumped from postgresql, as I still have couple of VMs in the broken state. Can you provide more details on reproduction please? From which version you're making an upgrade to which version? When did you made the initial template? I've tried to reproduce this scenario on clean environment on 4.1.1.6 and not reproduced it. I've followed these steps: 1. Login to Admin portal. 2. Create a template. Video type must be QXL. Guest OS doesn't matter (Linux/Windows). 3. Start creation of a new VM. 4. Change template from "Blank" to template created at step #2. 5. Go to "Console" tab. Change "Video type" == "VGA". 6. Confirm creation of new VM. (OK) 7. Start created VM. Step 7 was successful. The system has been continuously upgraded from 3.5 to 3.6 to 4.0 to 4.1 over a couple of years. The template is the "Blank" template. I do not have a changelog for it, but like I said it has not been changed for several months. The problematic VMs were created in October, which means we were then running 4.0.4. Created attachment 1266889 [details]
Log trying to update VM first unsuccessfully, and then successfully
Attaching log showing first the failing:
update vm vmname
and then the successful:
update vm vmname --usb-enabled True
Hi Marcus, db dump of or just a screenshot of VM Devices subtab of that VM would be great. Also, any chance you ever tried a PCI hotplug of a USB? Not even once or long time ago? Thanks. Too late for a screenshot as we needed the VMs to be brought up and fixed (using the fix described in comment #8). I do have the DB dump from when the VMs were still broken, I'm however reluctant to make that publicly available as the complete list of VM names gives away internal information. Could you provide an SQL query that I can run that would give you enough information about the affected VMs without needing the entire DB dump? This should give us all the devices of the VM which failed from comment 8: select d.* from vm_static s inner join vm_device d on s.vm_guid = d.vm_id where s.vm_guid = '5ccc7003-7a17-4d06-8f59-d1ffadd04646' or, you can do: select d.* from vm_static s inner join vm_device d on s.vm_guid = d.vm_id where s.vm_name = 'THE VM NAME' to filter by vm name. We hit the same issue on a different setup. The exact flow what happens is described in https://bugzilla.redhat.com/show_bug.cgi?id=1438188#c3 So, to not to track this same issue on 2 places, closing this bug as duplicate. *** This bug has been marked as a duplicate of bug 1438188 *** My bug is the original and was reported on 2017-03-27 09:49 EDT by Nikolai Sednev and was opened earlier than 1438188, latest was opened on 2017-04-01 14:59 EDT by Israel Pinto. Please close 1438188 as duplicate of 1436247 and not vice versa. the order of bugs opened is not relevant, the https://bugzilla.redhat.com/show_bug.cgi?id=1438188 is shorter and easier to navigate in, leaving that one opened. |