Description of problem: A customer had encountered problems with their VM backup utility, which resulted in multiple locked snapshots. They restarted the ovirt-engine service, and thereafter were unable to login to the Admin Portal, which displayed the following error in the browser window; "(org.ovirt.engine.core.common.action.ActionType,org.ovirt.engine.core.common.action.ActionParametersBase,org.ovirt.engine.core.bll.context.CommandContext): javax.ejb.EJBException: org.apache.commons.lang.SerializationException: org.codehaus.jackson.map.JsonMappingException: No default constructor for [collection type; class java.util.HashMap$KeySet, contains [simple type, class org.ovirt.engine.core.compat.Guid]] (through reference chain: org.ovirt.engine.core.common.action.CreateSnapshotForVmParameters["diskIds"])" The 'command-entities' table contained 124 entries with the 'command_params_class' field containing one of the following; - "org.ovirt.engine.core.common.action.CreateSnapshotForVmParameters" - "org.ovirt.engine.core.common.action.CreateSnapshotDiskParameters" When these were removed, the Admin Portal became accessible. Version-Release number of selected component (if applicable): RHV 4.2.5 How reproducible: It happened every time until some 'command_entities' entries were removed from the database. Steps to Reproduce: 1. 2. 3. Actual results: Admin Portal was inaccessible as a result of multiple snapshot creation failures. Expected results: Access to the Admin Portal should be allowed regardless of existing snapshot creation command entities. Additional info:
Ravi, is this the same issue as in BZ1588738 or do we need a different fix for that?
Posted a patch to fix the issue in BackendSnapshotsResource which was setting CreateSnapshotForVmParameters.setDiskIds with HashMap.keySet. This passes the internal class java.util.HashMap$KeySet to the serializer and jackson cannot deserialize the object.
Snapshots on down/up VM successfully created/deleted via API without any login issue. verified in ovirt-engine-4.3.0-0.5.alpha1.el7.noarch If you run into snapshot problem again, feel free to reopen this BZ.
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, 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/RHEA-2019:1085
Running sanity for creating/deleting snapshot should test it.