+++ This bug is a downstream clone. The original bug is: +++ +++ bug 1468242 +++ ====================================================================== Description of problem: This seems to be a regression of bug 1026885. All new deployments of RHV-M seem to assign fixed UUID 00000001-0001-0001-0001-000000000311 to the Default datacenter and fixed UUID 00000002-0002-0002-0002-00000000017a to the Default cluster. Version-Release number of selected component (if applicable): ovirt-engine-dbscripts-4.1.2.2-0.1.el7.noarch How reproducible: Always Steps to Reproduce: 1. Deploy a new RHV-M 2. Check the UUID of the Default datacenter 3. Actual results: Default DC has UUID 00000001-0001-0001-0001-000000000311. Default cluster has UUID 00000002-0002-0002-0002-00000000017a. Expected results: UUID of the Default datacenter and the Default cluster are different across different RHV-Ms. Additional info: # pwd /usr/share/ovirt-engine/dbscripts # grep -r 00000001-0001-0001-0001-000000000311 data/00300_insert_storage_pool.sql:INSERT INTO storage_pool (id, name, description, storage_pool_type, storage_pool_format_type, status, master_domain_version, spm_vds_id, compatibility_version, _create_date, _update_date, quota_enforcement_type, free_text_comment, is_local) VALUES ('00000001-0001-0001-0001-000000000311', 'Default', 'The default Data Center', 1, NULL, 0, 0, NULL, '4.1', '2016-07-05 12:03:14.099256+03', NULL, NULL, NULL, NULL); # grep -r 00000002-0002-0002-0002-00000000017a data/00400_insert_vds_groups.sql:INSERT INTO vds_groups (vds_group_id, name, description, cpu_name, _create_date, _update_date, storage_pool_id, max_vds_memory_over_commit, compatibility_version, transparent_hugepages, migrate_on_error, virt_service, gluster_service, count_threads_as_cores, emulated_machine, trusted_service, tunnel_migration, cluster_policy_id, cluster_policy_custom_properties, enable_balloon, free_text_comment, detect_emulated_machine, architecture, optimization_type, spice_proxy, ha_reservation, enable_ksm, serial_number_policy, custom_serial_number, optional_reason, required_rng_sources) VALUES ('00000002-0002-0002-0002-00000000017a', 'Default', 'The default server cluster', NULL, '2016-07-05 12:03:14.797477+03', NULL, '00000001-0001-0001-0001-000000000311', 100, '4.1', true, 1, true, false, false, NULL, false, false, 'b4ed2332-a7ac-4d5f-9596-99a439cb2812', NULL, false, NULL, true, 0, 0, NULL, false, true, NULL, NULL, false, 'RANDOM'); (Originally by Julio Entrena Perez)
(In reply to Oved Ourfali from comment #9) > Note that the fix makes sure the ids are different between environments. > It doesn't affect upgrade at all. Thanks Oved, this is understood. In the meantime, is there any manual workaround that can be applied to either: - ensure that a new deployment will use different UUIDs? or - change the UUIDs for default DC and cluster for an already deployed RHV-M?
IDs for DC and cluster are still the same ovirt-engine-4.1.4.1-0.1.el7.noarch (clean installation)
Verified on ovirt-engine-4.1.4.2-0.1.el7.noarch Only works on clean installation of course.
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-2017:1814