Bug 1899768
Summary: | Live merge fails on invoking callback end method 'onSucceeded' for a VM with Cluster Chipset/Firmware Type "Cluster default" or "Legacy". | ||
---|---|---|---|
Product: | Red Hat Enterprise Virtualization Manager | Reporter: | Bimal Chollera <bcholler> |
Component: | ovirt-engine | Assignee: | Arik <ahadas> |
Status: | CLOSED ERRATA | QA Contact: | meital avital <mavital> |
Severity: | high | Docs Contact: | |
Priority: | unspecified | ||
Version: | 4.4.2 | CC: | ahadas, dfodor, emarcus, gveitmic, michal.skrivanek, mkalinin |
Target Milestone: | ovirt-4.4.4 | ||
Target Release: | 4.4.4 | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | ovirt-engine-4.4.4.2 | Doc Type: | Bug Fix |
Doc Text: |
Previously, live-merge failed on snapshots of virtual machines that are set with bios-type = CLUSTER-DEFAULT.
In this release, live-merge works on snapshots of virtual machines that are set with bios-type = CLUSTER-DEFAULT.
|
Story Points: | --- |
Clone Of: | Environment: | ||
Last Closed: | 2021-02-02 13:58:29 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: |
Description
Bimal Chollera
2020-11-20 00:03:27 UTC
this is a major flow and serious impact, raising to Urgent Reducing back to high severity since the likelihood of having a cluster that live-merge can be executed in and yet set with bios-type=CLUSTER-DEFAULT is rather low This is most likely solved already by other changes in this area, but needs to make sure Changing back to urgent since this could happen also when the cluster's bios type is set to 'Legacy'. It is kind of fixed already in 4.4.3 but not entirely - there is no NPE anymore so the live-merge operation succeeds but the VM configuration within the snapshot that is modified during the live-merge operation would lack the original cluster's bios-type. The posted patch would address that. Looking for a workaround, I noticed that a CL 4.4 with 'Cluster Default' setting will set the VMs to Legacy (i440fx+SeaBIOS). Is this right? I was expecting Q35+SeaBIOS. So to workaround this one needs to change the cluster to Q35+Bios and then power cycle all VMs? (In reply to Germano Veit Michel from comment #6) > Looking for a workaround, I noticed that a CL 4.4 with 'Cluster Default' > setting will set the VMs to Legacy (i440fx+SeaBIOS). > Is this right? I was expecting Q35+SeaBIOS. That 'Cluster Default' setting on the cluster is a bit confusing - what it actually means is something like 'Auto Detect' and once there's an active host in the cluster this bios-type field should change to a different value. We blocked the ability to change a cluster that is set with bios-type!='Cluster Default' back to 'Cluster Default' (IIRC, in 4.4.3) so it should not be possible anymore to start VMs in a cluster which is set with 'Cluster Default'. It could be that in 4.4.2 it caused VMs to be set with the legacy bios but this scenario of a cluster with an active host that is set with 'Cluster Default' should really be avoided. > > So to workaround this one needs to change the cluster to Q35+Bios and then > power cycle all VMs? Actually this one can happen regardless of the cluster's bios-type so even changing it to Q35+BIOS wouldn't help here. Setting the VMs with custom bios-type can prevent this. keeping open for comment #5, it's still worth a fix. But the original issue shouldn't happen anymore in 4.4.3 How do I know in each setup what Cluster Default equals to? If it was upgraded from RHV 4.3, would Cluster Default mean Legacy? Where do we set Cluster Default and when is it changed, if it is changed automatically with upgrade at any point? (In reply to Marina Kalinin from comment #13) > How do I know in each setup what Cluster Default equals to? think of Cluster-Default as 'Auto-Detect' with the following logic: on PPC, it will become Legacy on pre 4.4 clusters, it will become legacy otherwise, it will become Q35+SeaBIOS > If it was upgraded from RHV 4.3, would Cluster Default mean Legacy? it will actually be set to Legacy, there's no auto-detection in this case. > Where do we set Cluster Default and when is it changed, if it is changed > automatically with upgrade at any point? it is the default value when creating new clusters. it changes when the first host is activated in the cluster. it doesn't change on upgrade. Verified with: - ovirt-engine-4.4.4.2-0.1.el8ev.noarch - vdsm-4.40.38-1.el8ev.x86_64 - libvirt-6.6.0-7.module+el8.3.0+8424+5ea525c5.x86_64 Verification steps: 1. Create a VM with 2 disks 2. Make sure the VM's 'Custom Chipset/Firmware Type' is 'Cluster Default' (the cluster default in this case is 'Q35 Chipset with BIOS') 3. Start the VM and create a snapshot (with memory) 3. Delete the snapshot created in section 3 Result: - Snapshot deleted successfully and no NPE appears on engine.log Beni, can you please also check the following: 1. Create a VM with a single disk 2. Run the VM 3. Create a snapshot - snapshot1 4. Create a snapshot - snapshot2 5. Remove 'snapshot1' 6. Preview 'snapshot2' 7. Run the VM in preview mode Verified by automation (same env. as on comment 27) Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (RHV Engine and Host Common Packages 4.4.z [ovirt-4.4.4]), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2021:0312 |