Bug 1148379

Summary: In case of using new template version (sealed with sysprep) for a pool, VMs get stuck in minisetup
Product: Red Hat Enterprise Virtualization Manager Reporter: Tomas Dosek <tdosek>
Component: ovirt-engineAssignee: Omer Frenkel <ofrenkel>
Status: CLOSED ERRATA QA Contact: Nisim Simsolo <nsimsolo>
Severity: medium Docs Contact:
Priority: high    
Version: 3.4.0CC: bkorren, ecohen, iheim, lpeer, lsurette, mavital, michal.skrivanek, nyechiel, ofrenkel, rbalakri, Rhev-m-bugs, yeylon
Target Milestone: ---   
Target Release: 3.5.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: virt
Fixed In Version: org.ovirt.engine-root-3.5.0-19 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-02-11 18:09:16 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Tomas Dosek 2014-10-01 10:26:54 UTC 
Description of problem:
If users create new version of template and seal it with sysprep, start of the VMs will get stuck in minisetup.

The reason is that the vm_init record of the VM is cleared after first start of pool VM and hence the data relevant to sysprep are not correctly passed on the run with newer template version.

Current workaround is something similar to:

DO $do$ DECLARE v_vm_guid uuid; BEGIN FOR v_vm_guid IN (SELECT vm_guid FROM vm_static WHERE vm_name LIKE '%32TEST1%') LOOP INSERT INTO vm_init (vm_id,domain,regenerate_keys,time_zone) VALUES (v_vm_guid,'example.domain.com','f','time_zone'); END LOOP; END; $do$;

Version-Release number of selected component (if applicable):
Any 3.4 version

How reproducible:
100 %

Steps to Reproduce:
1.Create a Pool from template (using the 'latest' template versiong policy)
2.Create new version of template and seal it with sysprep
3.Try to run a VM from the pool

Actual results:
VM stucks in minisetup

Expected results:
VM should go through minisetup and run correctly
Comment 1 Tomas Dosek 2014-10-01 10:30:00 UTC 
Just for clarification 32TEST1 in the query refers to the core pool name from which we derive the VM name for VM in pool.
Comment 2 Tomas Dosek 2014-10-01 10:41:47 UTC 
Also is_initialized parameter needs to be updated for the workaround to be complete:

DO $do$ DECLARE v_vm_guid uuid; BEGIN FOR v_vm_guid IN (SELECT vm_guid FROM vm_static WHERE vm_name LIKE '%NAME_OF_POOL%') LOOP INSERT INTO vm_init (vm_id,domain,regenerate_keys,time_zone) VALUES (v_vm_guid,'example.domain.com','f','Central European Standard Time'); UPDATE vm_static SET is_initialized = 'f' WHERE
vm_guid = v_vm_guid; END LOOP; END; $do$;
Comment 3 Tomas Dosek 2014-10-08 12:34:38 UTC 
Complete query for upgrade of template version and fix for the behavior in this BZ is:

CREATE OR REPLACE FUNCTION test_func() 
RETURNS void 
AS $$ 
DECLARE v_vm_guid uuid; v_uuid uuid;
BEGIN 
   FOR v_vm_guid IN (SELECT vm_guid FROM vm_static WHERE vm_name LIKE '%VM_POOL_NAME%') LOOP 
      IF EXISTS (SELECT vm_id FROM vm_init WHERE vm_id = v_vm_guid) THEN
          RAISE NOTICE 'Not updating vm_init, record exists';
      ELSE
          INSERT INTO vm_init (vm_id,domain,regenerate_keys,time_zone) VALUES (v_vm_guid,'vdiaules.uv.es','f','Central European Standard Time'); 
      END IF;
      UPDATE vm_static SET is_initialized = 'f' WHERE vm_guid = v_vm_guid; 
      UPDATE vm_static SET template_version_number=null WHERE vm_guid = v_vm_guid;
      IF EXISTS (SELECT device_id FROM vm_device where vm_id = v_vm_guid and device = 'floppy') THEN 
          RAISE NOTICE 'Not updating, floppy exists'; 
      ELSE 
          v_uuid := (select uuid_generate_v1()); 
          INSERT INTO vm_device VALUES(v_uuid,v_vm_guid,'disk','floppy','{unit=0, bus=0, target=0, controller=0, type=drive}',0,'{ }');  
      END IF;      
   END LOOP; 
END; $$ LANGUAGE plpgsql;
SELECT test_func();
DROP FUNCTION test_func();
Comment 5 Nisim Simsolo 2014-12-15 15:11:57 UTC 
Verified. build used:
engine: rhevm-3.5.0-0.23.beta.el6ev.noarch
host: vdsm-4.16.8.1-2.el7ev.x86_64
libvirt-1.1.1-29.el7_0.4.x86_64
sanlock-3.1.0-2.el7.x86_64
qemu-kvm-rhev-1.5.3-60.el7_0.11.x86_64
Comment 7 errata-xmlrpc 2015-02-11 18:09:16 UTC 
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://rhn.redhat.com/errata/RHSA-2015-0158.html