Bug 1685110
| Summary: | Error inserting event into audit_log when VM template name is bigger than 40 characters | |||
|---|---|---|---|---|
| Product: | [oVirt] ovirt-engine | Reporter: | Ilan Zuckerman <izuckerm> | |
| Component: | Database.Core | Assignee: | Dana <delfassy> | |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Lucie Leistnerova <lleistne> | |
| Severity: | medium | Docs Contact: | ||
| Priority: | unspecified | |||
| Version: | 4.3.0 | CC: | bugs, lleistne, mperina | |
| Target Milestone: | ovirt-4.3.3 | Keywords: | ZStream | |
| Target Release: | --- | Flags: | pm-rhel:
ovirt-4.3+
lleistne: testing_ack+ |
|
| Hardware: | x86_64 | |||
| OS: | Linux | |||
| Whiteboard: | ||||
| Fixed In Version: | ovirt-engine-4.3.3.1 | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 1688782 (view as bug list) | Environment: | ||
| Last Closed: | 2019-04-16 13:58:11 UTC | Type: | Bug | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | Infra | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Embargoed: | ||||
| Bug Depends On: | ||||
| Bug Blocks: | 1688782 | |||
It seems that either template name or storage pool name exceeded 40 characters, so let's align those sizes in audit_log table with maximum allowed size of name in relevant table (In reply to Martin Perina from comment #2) > It seems that either template name or storage pool name exceeded 40 > characters, so let's align those sizes in audit_log table with maximum > allowed size of name in relevant table The template name is less than 40 chars for sure. I am almost sure that the storage pool as well. Wasn't able to reproduce, but added a fix that should solve this issue Template with long name from VM with long name successfully created with no error in log (on updated and clean install). Appropriate events visible. verified in ovirt-engine-4.3.3.1-0.1.el7.noarch This bugzilla is included in oVirt 4.3.3 release, published on April 16th 2019. Since the problem described in this bug report should be resolved in oVirt 4.3.3 release, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report. |
Description of problem: When creating template out of vm, the following error is seen in engine.log : "2019-03-03 22:08:33,129Z ERROR [org.ovirt.engine.core.bll.RemoveVmTemplateCommand] (default task-16) [f914a19b-9cc5-4ca0-be85-d6d113877e0f] Error during log command: org.ovirt.engine.core.bll.RemoveVmTemplateCommand. Exception CallableStatementCallback; SQL [{call insertauditlog(?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)}ERROR: value too long for type character varying(40)" Full error can be found here: https://paste.fedoraproject.org/paste/ZLROkxCytAAUHiest5ys8w However, the template is being created despite this ERROR. Version-Release number of selected component (if applicable): ovirt-engine-4.3.1.1-0.1.el7.noarch rpm -qa | grep rhv-release rhv-release-4.3.1-3-001.noarch Lab Topology using Hosted Engine: 9 DC and 9 Clusters 536 Hosts of which 35 real servers and 501 nested hosts 11 Storage Domains composed of: 7 FC Domains 2 ISCSI Domains 2 NFS Domains (Export + Data) 4091 VMS are up Hosted Engine running on dedicated host: 24vcpu with 32GB ram How reproducible: Always Steps to Reproduce: 1. Create template out of VM with the following details: "Thin disk: 20 GB (os) Data disk: 100 GB raw 50% utilization) direct luns: 0 snapsots: 0 Mem size: "4096 MB Mem Max size: 4096 MB Mem Guaranteed: 4096 MB" cores 2 cores per socket: 1 threads per core: 1 Optimized for Server: Y I/O Threads Enabled: TRUE "Network Interfaces: 2 Actual results: The template is being created, but exception can be seen in engine.log Expected results: There should be no errors Additional info: log collector files are in Gmail location attached in private message below. They include HE vm, and both VDSM hosts from ISCSI cluster.