Description of problem: Importing VM template fails with ERROR: insert or update on table "vm_static" violates foreign key constraint "fk_vm_static_lease_sd_i d_storage_domain_static_id" Version-Release number of selected component (if applicable): ovirt-engine-4.2.6 How reproducible: 100% Steps to Reproduce: 1. Create a template of a VM 2. Edit the template and lease it from a storage domain (HA options) 3. Export the template to export domain. 4. Remove the above leased storage domain from the environment. 5. Try to import the template in the other data domain. Actual results: Import fails with following error: 2018-10-22 12:54:04,848+05 ERROR [org.ovirt.engine.core.bll.exportimport.ImportVmTemplateCommand] (EE-ManagedThreadFactory-engine-Thread-566) [09fc1168-3dae-4079-be75-24bbf35a5181] Exception: org.springframe work.dao.DataIntegrityViolationException: CallableStatementCallback; SQL [{call insertvmtemplate(?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)}]; ERROR: insert or update on table "vm_static" violates foreign key constraint "fk_vm_static_lease_sd_i d_storage_domain_static_id" Detail: Key (lease_sd_id)=(bb0ba4d9-76d6-47a2-af06-2b596e88f2c5) is not present in table "storage_domain_static". . . . at org.glassfish.enterprise.concurrent.ManagedThreadFactoryImpl$ManagedThread.run(ManagedThreadFactoryImpl.java:250) [javax.enterprise.concurrent.jar:1.0.0.redhat-1] at org.jboss.as.ee.concurrent.service.ElytronManagedThreadFactory$ElytronManagedThread.run(ElytronManagedThreadFactory.java:78) Caused by: org.postgresql.util.PSQLException: ERROR: insert or update on table "vm_static" violates foreign key constraint "fk_vm_static_lease_sd_id_storage_domain_static_id" Detail: Key (lease_sd_id)=(bb0ba4d9-76d6-47a2-af06-2b596e88f2c5) is not present in table "storage_domain_static". Where: SQL statement "INSERT INTO vm_static( . . . 2018-10-22 12:54:04,913+05 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (EE-ManagedThreadFactory-engine-Thread-566) [09fc1168-3dae-4079-be75-24bbf35a5181] EVENT_ID: IMPORTEXPORT_IMPORT_TEMPLATE_FAILED(1,159), Failed to import Template testimp to Data Center Default, Cluster Default Expected results: Either ovirt-engine should not allow to export the template/VM when there is HA lease on it or import to other domain should be successful. Additional info:
I have a few questions on this issue. I was able to follow steps 1-3 although I had to create an export domain first. I noticed that when I performed step 3, the lease_sd_id field of the vm_static table for the template entry is still set to the original data domain and not to the new export domain. For step 4, The Remove button for the Export Domain was disabled, so I clicked on the export_domain name, put the export domain into maintenance and then destroyed the domain. The lease_sd_id field of the vm_static table is still set to the original data domain. Step 5 is not clear. The Import functionality on the Template screen is only for Importing an export domain (which was already deleted) or Virtual Appliance, with no choice for a data domain. Of cause trying to export again does detect that the export domain no longer exists in my case. A few questions: 1. Please clarify the procedures based upon my description. 2. How to complete step 5 in order to simulate the results? 3. Please check the database tables for the values before and after each procedure via say: select storage_name, storage, id from storage_domain_static; select vm_name, lease_sd_id from vm_static; Does the lease_sd_id change to the export domain's id on any of the steps? 4. The assumption is that lease id = bb0ba4d9-76d6-47a2-af06-2b596e88f2c5 is for the export domain that was deleted (which would make sense), but please verify. Of cause if we deleted the storage_domain_static entry for the export domain and tried to update the vm_static table's entry for the template with that id, we would simulate the problem. The question is how that could happen if the export domain was already deleted (or "removed" as per your description).
(In reply to Steven Rosenberg from comment #1) > I have a few questions on this issue. > > I was able to follow steps 1-3 although I had to create an export domain > first. > > I noticed that when I performed step 3, the lease_sd_id field of the > vm_static table for the template entry is still set to the original data > domain and not to the new export domain. > > For step 4, The Remove button for the Export Domain was disabled, so I > clicked on the export_domain name, put the export domain into maintenance > and then destroyed the domain. The lease_sd_id field of the vm_static table > is still set to the original data domain. > > Step 5 is not clear. The Import functionality on the Template screen is only > for Importing an export domain (which was already deleted) or Virtual > Appliance, with no choice for a data domain. Of cause trying to export again > does detect that the export domain no longer exists in my case. > > A few questions: > > 1. Please clarify the procedures based upon my description. > 2. How to complete step 5 in order to simulate the results? > 3. Please check the database tables for the values before and after each > procedure via say: > > select storage_name, storage, id from storage_domain_static; > > select vm_name, lease_sd_id from vm_static; > > Does the lease_sd_id change to the export domain's id on any of the steps? > > 4. The assumption is that lease id = bb0ba4d9-76d6-47a2-af06-2b596e88f2c5 is > for the export domain that was deleted (which would make sense), but please > verify. > > Of cause if we deleted the storage_domain_static entry for the export domain > and tried to update the vm_static table's entry for the template with that > id, we would simulate the problem. The question is how that could happen if > the export domain was already deleted (or "removed" as per your description). In Step 4 we need to remove the data storage domain which was used to set the lease and not the export domain. In Step 5 we need to import the template which was exported to export storage domain. So, let me re-phrase the steps: 1. Create a template of a VM 2. Edit the template and lease it from a data storage domain (HA options) 3. Export the template to export domain. 4. Remove the above leased data storage storage domain from the environment. 5. Try to import the exported template in the other data domain.
I simulated this issue. The problem is that we delete the Data Storage Domain while the lease is still referenced by the vm via the vm_static table. We have two options: 1. When deleting the data storage domain we can remove the lease id from all vm_static table entries that reference it along with any other cleanup that is required. 2. Block the deletion of the Data Storage Domain when it is leased by a vm and warn the user to remove all leases before deleting. The second option is the simplest solution, but users may want a more advanced and automatic approach.
I'd favor #2, since there may be negative side effects with #1
(In reply to Steven Rosenberg from comment #3) > I simulated this issue. The problem is that we delete the Data Storage > Domain while the lease is still referenced by the vm via the vm_static table. > > We have two options: > > 1. When deleting the data storage domain we can remove the lease id from all > vm_static table entries that reference it along with any other cleanup that > is required. > > 2. Block the deletion of the Data Storage Domain when it is leased by a vm > and warn the user to remove all leases before deleting. > > The second option is the simplest solution, but users may want a more > advanced and automatic approach. Why not have the option for both? The first solution is already exist and the second one will improve significantly the user experience. If the user has no clear indication where the vm leases are reside, it can be a huge problem which can lead to opening an RFE to implement the second option
Supporting both is really the first solution where the user is warned first and can choose to continue (which will preform the adjustments) or cancel accordingly. It will require more work and testing to avoid the "negative side affects" as per Ryan's comments. Please advise concerning the approval process, rfe, etc.
(In reply to Raz Tamir from comment #5) > (In reply to Steven Rosenberg from comment #3) > > I simulated this issue. The problem is that we delete the Data Storage > > Domain while the lease is still referenced by the vm via the vm_static table. > > > > We have two options: > > > > 1. When deleting the data storage domain we can remove the lease id from all > > vm_static table entries that reference it along with any other cleanup that > > is required. > > > > 2. Block the deletion of the Data Storage Domain when it is leased by a vm > > and warn the user to remove all leases before deleting. > > > > The second option is the simplest solution, but users may want a more > > advanced and automatic approach. > Why not have the option for both? > The first solution is already exist and the second one will improve > significantly the user experience. > If the user has no clear indication where the vm leases are reside, it can > be a huge problem which can lead to opening an RFE to implement the second > option The user didn't remove the domain, he destroyed it. We cannot block this because from a DR point of view we need to remove the domain no matter what. The solution will probably be to verify that the storage domain which holds the VM template lease exists and active and if not: Option 1: Set the VM template lease to a different default SD Option 2: Ignore the VM lease I think that the first option is more correct and this logic is already done when importing a VM with a lease.
(In reply to Steven Rosenberg from comment #3) > I simulated this issue. The problem is that we delete the Data Storage > Domain while the lease is still referenced by the vm via the vm_static table. > > We have two options: > > 1. When deleting the data storage domain we can remove the lease id from all > vm_static table entries that reference it along with any other cleanup that > is required. > > 2. Block the deletion of the Data Storage Domain when it is leased by a vm > and warn the user to remove all leases before deleting. > > The second option is the simplest solution, but users may want a more > advanced and automatic approach. I would also vote for Option 1 in comment 7 -- Set the VM template lease to a different default SD which would keep the config intact as much as possible.
Steps for Simulating: 1. Storage → Domain → New Domain 2. Create a new data domain here Note: create a new directory on the storage, chown vdsm:kvm directory and specify as Data Path. 3. Create a new export domain here Note: create a new directory on the storage, chown vdsm:kvm directory and specify as Export Path. 4. Compute → Virtual Machine → more → Make Template 5. Compute → Templates 6. Choose the new template and → Edit 7. Choose High Availability, check HA and enter a data domain for the lease (only allows for data domains). 8. Compute → Template → Export → Export to Export Domain Note: make sure the correct Template is chosen 9. Check the vm_static lease_sd_id value of the template in question. select storage_name,id from storage_domain_static; select vm_name, lease_sd_id from vm_static; 10. Storage → Domain → click on the Data Domain’s name 11. Choose Data Center and Put in Maintenance. 12. Wait until it unlocks 13. More → Destroy (or Detach and then Remove) 14. Compute → Templates → Import → Load → OK → clone name → ok
WARN: Bug status (ON_QA) wasn't changed but the folowing should be fixed: [Found non-acked flags: '{'rhevm-4.3-ga': '?'}', ] For more info please contact: rhv-devops: Bug status (ON_QA) wasn't changed but the folowing should be fixed: [Found non-acked flags: '{'rhevm-4.3-ga': '?'}', ] For more info please contact: rhv-devops
Verification version: ovirt-engine-4.3.0-0.8.master.20190122121624.git9a8a519.el7 vdsm-4.30.8-1.el7.x86_64 qemu-kvm-ev-2.12.0-18.el7_6.1.1.x86_64 libvirt-client-4.5.0-10.el7_6.3.x86_64 Verification scenario: 1. Create a template of a VM 2. Edit the template and lease it from a storage domain (HA options) 3. Export the template to export domain. 4. Remove the above leased storage domain from the environment. 5. Import the template in the other data domain. 6. Create VM from above template. 7. Run VM and verify VM is running properly.
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