+++ 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)
Comment 10Julio Entrena Perez
2017-07-10 16:00:20 UTC
(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?
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