Description of problem: 4.4.10 Gluster based cluster w/ 3 nodes. I'm backing up all VMs before upgrading the setup to 4.5. (Hopefully done right before 4.5.1 w/ Gluster fix is released). When trying to export a VM to another data domain, several VMs show the following error: "Export VM Failed. o.original_template is undefined". Following a debug session w/ Benny Zlotnik (Thanks!) it was verified that indeed original_template_id field is empty. $ psql engine select original_template_id engine-# from vm_static engine-# where vm_guid = '16b5df4b-c3b5-4899-b5b1-336c3462494c'; original_template_id ---------------------- (1 row) Following an manual field update, export worked as advertised. update vm_static set original_template_id = '00000000-0000-0000-0000-000000000000' where vm_guid = '16b5df4b-c3b5-4899-b5b1-336c3462494c'; UPDATE 1 select original_template_id from vm_static where vm_guid = '16b5df4b-c3b5-4899-b5b1-336c3462494c'; original_template_id -------------------------------------- 00000000-0000-0000-0000-000000000000 (1 row) Version-Release number of selected component (if applicable): 4.4.10.7-1.el8 How reproducible: Always.
I've got at least 10 other VMs showing this problem. Should I simply manually fix them using an SQL query, or do I have another option?
(In reply to Gilboa Davara from comment #1) > I've got at least 10 other VMs showing this problem. do you remember if these VMs were imported to that setup? > Should I simply manually fix them using an SQL query, or do I have another > option? yeah, I don't see an alternative for fixing it without code changes besides changing the database directly
(In reply to Arik from comment #2) > (In reply to Gilboa Davara from comment #1) > > I've got at least 10 other VMs showing this problem. > > do you remember if these VMs were imported to that setup? Yes. The VMs were imported from another CentOS 7 / 4.3 cluster. $ select vm_guid from vm_static where original_template_id is NULL; vm_guid -------------------------------------- 00000003-0003-0003-0003-0000000000be 00000005-0005-0005-0005-0000000002e6 00000009-0009-0009-0009-0000000000f1 0000000b-000b-000b-000b-00000000021f 00000007-0007-0007-0007-00000000010a bd9c9082-d6d6-4b4f-b4e7-ec3b4a322c7c 821a1f86-c6da-42e8-8011-86807c33d7a0 9748bb37-fd84-449a-8e9e-4d26b3a0f668 483d6303-adf1-4235-973a-acd1b61c6d0f abf0abae-f909-4c68-9e37-93a707676589 2753f8c6-8ae5-46b2-963f-6dfbbb5cdc94 8e235a6b-c685-4aa9-a89f-4e4e87c8908b 7f1eb68e-eb3b-4a66-923c-13fcd0a20dc0 63b72513-657e-4ca8-9c5a-6bb8645df1d6 c5a6b9be-af9a-495d-b000-c61e652790d1 aa4f7f4c-6f0c-4503-98fe-46baef060089 be227de0-ad70-4119-97be-8b4d4ed14ea5 7acada61-d382-4f26-89e8-fbaafa218399 6021aa08-f5da-4582-a413-9c642b468e0a 42ce57b2-c04e-44c4-902e-b0814d8f010d 9d32f610-27e2-4e8e-9c7c-81cc5396c913 1cf3ac26-0879-44c5-ab01-b7a4cb9bf4a3 789d1641-0ff1-44a8-b643-3a02f068dff8 5f52991b-ac17-424b-87c8-ac38807e02e9 d98d0ced-2608-42c0-8e13-deb1bd3194a8 e4189193-d80b-417e-83e6-c398c7cc1dba c1f3fed9-b050-46f8-970b-20b235f0d3c0 8d3e3b79-113b-45a7-b307-0ed0f5aaac69 7e803a19-7f3a-4434-b4a9-96ddfa3f28bb 81743e1f-285b-4e2d-90c1-7ab47589681f d3751e21-705f-4dc6-8304-ab9023c684fb 8f7db762-8496-408b-a39e-16e30c164576 5d0caeb1-cbef-4b37-86d1-9f79c409e7e0 00000000-0000-0000-0000-000000000000 d3dad14b-d03b-496d-ace1-f79100275f88 d28a3642-c7d0-4d7d-8fe4-812ee52ad53e d72f64df-57f7-4801-a1c9-554517979eb5 776e446e-606c-4960-8dfd-91ebe8665dde 74cfd987-d84d-4554-adc9-736ddc8ce57d 0f1d7fc8-7725-4603-b320-317cb7bab73f (40 rows) > > > Should I simply manually fix them using an SQL query, or do I have another > > option? > > yeah, I don't see an alternative for fixing it without code changes besides > changing the database directly I can do: $ update vm_static set original_template_id = '00000000-0000-0000-0000-000000000000' where original_template_id is NULL; ... But it will also change the default VM types (Tiny, Large, etc). Ideas? - Gilboa
(In reply to Gilboa Davara from comment #3) > (In reply to Arik from comment #2) > > (In reply to Gilboa Davara from comment #1) > > > I've got at least 10 other VMs showing this problem. > > > > do you remember if these VMs were imported to that setup? > > Yes. > The VMs were imported from another CentOS 7 / 4.3 cluster. thanks > > > > > Should I simply manually fix them using an SQL query, or do I have another > > > option? > > > > yeah, I don't see an alternative for fixing it without code changes besides > > changing the database directly > > I can do: > $ update vm_static set original_template_id = > '00000000-0000-0000-0000-000000000000' where original_template_id is NULL; > ... But it will also change the default VM types (Tiny, Large, etc). > Ideas? you can add: and entity_type='VM'
$ update vm_static set original_template_id = '00000000-0000-0000-0000-000000000000' where original_template_id is NULL and entity_type = 'VM'; UPDATE 34 Works like a charm. Thanks. - Gilboa
This bug has low overall severity and is not going to be further verified by QE. If you believe special care is required, feel free to properly align relevant severity, flags and keywords to raise PM_Score or use one of the Bumps ('PrioBumpField', 'PrioBumpGSS', 'PrioBumpPM', 'PrioBumpQA') in Keywords to raise it's PM_Score above verification threashold (1000).
This bug has low overall severity and passed an automated regression suite, and is not going to be further verified by QE. If you believe special care is required, feel free to re-open to ON_QA status.