Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1431138

Summary: After a host removal VMs is still pinned to this host in DB
Product: [oVirt] ovirt-engine Reporter: Jiri Belka <jbelka>
Component: GeneralAssignee: Jenny Tokar <jtokar>
Status: CLOSED WONTFIX QA Contact: Jiri Belka <jbelka>
Severity: medium Docs Contact:
Priority: medium    
Version: ---CC: bugs, danken, fsun, jtokar, msivak, pstehlik, smaudet
Target Milestone: ---Flags: sbonazzo: ovirt-4.2-
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-04-04 09:32:14 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: SLA RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
screenshot none

Description Jiri Belka 2017-03-10 12:54:07 UTC 
Description of problem:

After a host removal VMs is still pinned to this host in DB. IIUC it was discovered later after upgrade from 3.6 engine to 4.0 engine while bumping up cluster, the cluster compat level increase failed because of this issue.

engine=# select vm_name,dedicated_vm_for_vds from vm_static where vds_group_id = '00000002-0002-0002-0002-000000000173' and vm_name = 'vm4-test3';
  vm_name  |         dedicated_vm_for_vds         
-----------+--------------------------------------
 vm4-test3 | 815aad77-7372-44e8-9d83-fea8571e14cb
(1 row)

compare with screenshot.

Version-Release number of selected component (if applicable):
rhevm-3.6.10.2-0.2.el6.noarch

How reproducible:
100%

Steps to Reproduce:
1. have 3.6 engine
2. pin a vm to specific host
3. remove the host after putting it into maintenance

Actual results:
orphan in db

Expected results:
should not be in db as it caused later some issue with cluster level increase

Additional info:
Comment 2 Jiri Belka 2017-03-10 12:55:50 UTC 
Created attachment 1261933 [details]
screenshot
Comment 3 Jiri Belka 2017-03-10 13:01:47 UTC 
surprisingly this DB records doesn't affect running the VM on other host if the pinned-to host does not exist:

engine=# select vm_name,vm_guid,dedicated_vm_for_vds from vm_static where vds_group_id = '00000002-0002-0002-0002-000000000173' and vm_name = 'vm4-test3';                                                          
  vm_name  |               vm_guid                |         dedicated_vm_for_vds         
-----------+--------------------------------------+--------------------------------------
 vm4-test3 | 8443a9e4-dbb5-44b9-95d7-d3ea57ef42b2 | 815aad77-7372-44e8-9d83-fea8571e14cb
(1 row)

engine=# select vm_guid,run_on_vds from vm_dynamic where vm_guid = '8443a9e4-dbb5-44b9-95d7-d3ea57ef42b2';                                                                                                          
               vm_guid                |              run_on_vds              
--------------------------------------+--------------------------------------
 8443a9e4-dbb5-44b9-95d7-d3ea57ef42b2 | 65f883e7-c5a5-44de-a96c-678ab2759b65
(1 row)

engine=# select vds_id,vds_name from vds;
                vds_id                |    vds_name    
--------------------------------------+----------------
 65f883e7-c5a5-44de-a96c-678ab2759b65 | dell-r210ii-13
(1 row)
Comment 5 Dan Kenigsberg 2017-03-21 15:16:26 UTC 
Martin, unpinning VMs is a required step to allow upgrade from 3.5 (otherwise InCluster migration would not fly). If the bug is real, we may need to backport it to 3.6.z. Please consider it for 4.1.2.
Comment 6 Martin Sivák 2017-03-21 16:07:51 UTC 
We do not have a fix yet so there is nothing to backport right now.
Comment 7 Dan Kenigsberg 2017-03-21 16:13:07 UTC 
I know, but I am asking to set the target milestone to 4.1.2, so looking into this may take place earlier.
Comment 8 Jenny Tokar 2017-03-22 14:14:16 UTC 
The current situation:
 
If a vm has a dedicated host and is non migratable (pinned):
When the host is being removed, we have a clear error message that prevents the removal. 

If the vm has a dedicated host but can be migrated: 
When removing the host the dedicated host column in the db is not cleared, but since the vm is migratable it can be started on some other host with no issues. 
To clear the dedicated hosts column one can open the edit vm dialog and save the vm (without making changes). This will clear the db.
Comment 9 Martin Sivák 2017-04-04 09:32:14 UTC 
This is a minor data issue only according to #8. The engine will clear the stale records automatically in due course.