Red Hat Bugzilla – Bug 1148379
In case of using new template version (sealed with sysprep) for a pool, VMs get stuck in minisetup
Last modified: 2015-10-27 19:57:30 EDT
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
Just for clarification 32TEST1 in the query refers to the core pool name from which we derive the VM name for VM in pool.
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$;
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();
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
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