Bug 842115
| Summary: | - 3.1 - beta3 - [vdsm] Migration fails as both source and destination shares the same UUID | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Ilanit Stein <istein> |
| Component: | vdsm | Assignee: | Yaniv Bronhaim <ybronhei> |
| Status: | CLOSED ERRATA | QA Contact: | Barak Dagan <bdagan> |
| Severity: | urgent | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 6.3 | CC: | abaron, bazulay, cpelland, danken, dyasny, hateya, iheim, ilvovsky, jhenner, lpeer, michal.skrivanek, oramraz, pstehlik, Rhev-m-bugs, sgrinber, sputhenp, yeylon, ykaul |
| Target Milestone: | rc | ||
| Target Release: | 6.3 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | virt | ||
| Fixed In Version: | vdsm-4.9.6-31.0 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-12-04 19:03:10 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: | |||
I noticed a weird thing:
Both source and destination hosts have the same uuid suffix from some reason:
[root@cinteg14 ~]# vdsClient -s 0 getVdsCaps | grep -i uuid
networks = {'rhevm': {'addr': '10.35.148.66', 'cfg': {'IPV6INIT': 'yes', 'DHCP_HOSTNAME': 'cinteg14.ci.lab.tlv.redhat.com', 'HOSTNAME': 'cinteg14.ci.lab.tlv.redhat.com', 'MTU': '1500', 'DELAY': '0', 'NM_CONTROLLED': 'no', 'BOOTPROTO': 'dhcp', 'DEVICE': 'rhevm', 'TYPE': 'Bridge', 'ONBOOT': 'yes', 'UUID': '6939f13e-47bf-47ae-b90a-62b8d1c40ba8'}, 'mtu': '1500', 'netmask': '255.255.252.0', 'stp': 'off', 'bridged': True, 'gateway': '10.35.151.254', 'ports': ['em1', 'vnet0', 'vnet1', 'vnet2']}}
uuid = 4C4C4544-0043-4610-805A-C2C04F37354A_00:26:6C:FF:B2:64
[root@cinteg16 ~]# vdsClient -s 0 getVdsCaps | grep -i uuid
networks = {'rhevm': {'addr': '10.35.148.70', 'cfg': {'IPV6INIT': 'yes', 'DHCP_HOSTNAME': 'cinteg16.ci.lab.tlv.redhat.com', 'HOSTNAME': 'cinteg16.ci.lab.tlv.redhat.com', 'MTU': '1500', 'DELAY': '0', 'NM_CONTROLLED': 'no', 'BOOTPROTO': 'dhcp', 'DEVICE': 'rhevm', 'TYPE': 'Bridge', 'ONBOOT': 'yes', 'UUID': 'a24ed2b9-8ed4-49da-96e9-8195dd92468f'}, 'mtu': '1500', 'netmask': '255.255.252.0', 'stp': 'off', 'bridged': True, 'gateway': '10.35.151.254', 'ports': ['em1', 'vnet0', 'vnet1']}}
uuid = 4C4C4544-0043-4610-805A-C2C04F37354A_00:26:6C:FF:B6:44
I see that in /usr/lib64/python2.6/site-packages/vdsm/utils.py the uuid computed as follows:
p = subprocess.Popen([constants.EXT_SUDO,
constants.EXT_DMIDECODE, "-s", "system-uuid"],
Is it possible that two hosts gets the same uuid ?
(In reply to comment #1) > I noticed a weird thing: > Both source and destination hosts have the same uuid suffix from some reason: > > [root@cinteg14 ~]# vdsClient -s 0 getVdsCaps | grep -i uuid > networks = {'rhevm': {'addr': '10.35.148.66', 'cfg': {'IPV6INIT': > 'yes', 'DHCP_HOSTNAME': 'cinteg14.ci.lab.tlv.redhat.com', 'HOSTNAME': > 'cinteg14.ci.lab.tlv.redhat.com', 'MTU': '1500', 'DELAY': '0', > 'NM_CONTROLLED': 'no', 'BOOTPROTO': 'dhcp', 'DEVICE': 'rhevm', 'TYPE': > 'Bridge', 'ONBOOT': 'yes', 'UUID': '6939f13e-47bf-47ae-b90a-62b8d1c40ba8'}, > 'mtu': '1500', 'netmask': '255.255.252.0', 'stp': 'off', 'bridged': True, > 'gateway': '10.35.151.254', 'ports': ['em1', 'vnet0', 'vnet1', 'vnet2']}} > uuid = 4C4C4544-0043-4610-805A-C2C04F37354A_00:26:6C:FF:B2:64 > > > > [root@cinteg16 ~]# vdsClient -s 0 getVdsCaps | grep -i uuid > networks = {'rhevm': {'addr': '10.35.148.70', 'cfg': {'IPV6INIT': > 'yes', 'DHCP_HOSTNAME': 'cinteg16.ci.lab.tlv.redhat.com', 'HOSTNAME': > 'cinteg16.ci.lab.tlv.redhat.com', 'MTU': '1500', 'DELAY': '0', > 'NM_CONTROLLED': 'no', 'BOOTPROTO': 'dhcp', 'DEVICE': 'rhevm', 'TYPE': > 'Bridge', 'ONBOOT': 'yes', 'UUID': 'a24ed2b9-8ed4-49da-96e9-8195dd92468f'}, > 'mtu': '1500', 'netmask': '255.255.252.0', 'stp': 'off', 'bridged': True, > 'gateway': '10.35.151.254', 'ports': ['em1', 'vnet0', 'vnet1']}} > uuid = 4C4C4544-0043-4610-805A-C2C04F37354A_00:26:6C:FF:B6:44 > > I see that in /usr/lib64/python2.6/site-packages/vdsm/utils.py the uuid > computed as follows: > p = subprocess.Popen([constants.EXT_SUDO, > constants.EXT_DMIDECODE, "-s", "system-uuid"], > > Is it possible that two hosts gets the same uuid ? Indeed: [root@cinteg16 ~]# dmidecode |grep UUID UUID: 4C4C4544-0043-4610-805A-C2C04F37354A [root@cinteg16 ~]# ssh root@cinteg14 "dmidecode |grep UUID" root@cinteg14's password: UUID: 4C4C4544-0043-4610-805A-C2C04F37354A I have a partial(!) suggested patch http://gerrit.ovirt.org/4881 which generates a random uuid upon bootstrap/installation. If we store this uuid in /etc/libvirt/libvirtd.conf, it would be used by libvirt for host identification. Note that attaching <_rhevm-mac> to a non-unique uuid is broken, since macs change when nics fail or reconfigured. (In reply to comment #7) > I have a partial(!) suggested patch http://gerrit.ovirt.org/4881 which > generates a random uuid upon bootstrap/installation. If we store this uuid > in /etc/libvirt/libvirtd.conf, it would be used by libvirt for host > identification. > > Note that attaching <_rhevm-mac> to a non-unique uuid is broken, since macs > change when nics fail or reconfigured. it's not entirely broken - the fact we didn't store it (and use it) after creation is. isn't changing the logic of uuid generation will cause rhev-h nodes to re-register themselves as new entities based on their now new uuid? What if hypervisor generated UUID upon it's installation? Couldn't some RHN registration number be used as UUID? Or it's hash? (In reply to comment #9) > isn't changing the logic of uuid generation will cause rhev-h nodes to > re-register themselves as new entities based on their now new uuid? it is. and it is the first "known issue" of http://gerrit.ovirt.org/4881 . (In reply to comment #10) > What if hypervisor generated UUID upon it's installation? Couldn't some RHN > registration number be used as UUID? Or it's hash? sorry, I did not get the question. (In reply to comment #11) > (In reply to comment #9) > > isn't changing the logic of uuid generation will cause rhev-h nodes to > > re-register themselves as new entities based on their now new uuid? > > it is. and it is the first "known issue" of http://gerrit.ovirt.org/4881 . > > (In reply to comment #10) > > What if hypervisor generated UUID upon it's installation? Couldn't some RHN > > registration number be used as UUID? Or it's hash? > > sorry, I did not get the question. I was just suggesting how the host identity could be generated. I have one more suggestion: hash of the ssh public key could be used as UUID. (In reply to comment #12) > > I was just suggesting how the host identity could be generated. I have one > more suggestion: hash of the ssh public key could be used as UUID. Thanks, but I see no problem in using `uuidgen` or Python's uuid.uuid4(). There is no need for cryptographic safety here. *** Bug 760087 has been marked as a duplicate of this bug. *** suggest patch: http://gerrit.ovirt.org/#/c/7332/ 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. http://rhn.redhat.com/errata/RHSA-2012-1508.html |
Description of problem: There is a logical problem having VM migrating to original host, in case migration to a 2nd host fail. How reproducible: always Steps to Reproduce: 1.Setup with 2 active hosts. 2. Make sure that VMs migration will fail to 2nd host, 3. see that migration to the original host starts in vdsm log, and fail of course Actual results: Migration to original host From vdsm log: Thread-1758::ERROR::2012-07-21 12:41:38,261::vm::176::vm.Vm::(_recover) vmId=`b373f0fd-c1d8-423b-ba1e-7372ce65a2d3`::internal error Attempt to migrate guest to the same host 44454c4c-4300-1046-805a-c2c04f37354a Thread-1756::ERROR::2012-07-21 12:41:38,332::vm::240::vm.Vm::(run) vmId=`703bf2f9-9cbd-422b-8022-5addcd21c752`::Failed to migrate Traceback (most recent call last): File "/usr/share/vdsm/vm.py", line 223, in run self._startUnderlyingMigration() File "/usr/share/vdsm/libvirtvm.py", line 451, in _startUnderlyingMigration None, maxBandwidth) File "/usr/share/vdsm/libvirtvm.py", line 491, in f ret = attr(*args, **kwargs) File "/usr/lib64/python2.6/site-packages/vdsm/libvirtconnection.py", line 82, in wrapper ret = f(*args, **kwargs) File "/usr/lib64/python2.6/site-packages/libvirt.py", line 1104, in migrateToURI2 if ret == -1: raise libvirtError ('virDomainMigrateToURI2() failed', dom=self) For logs of engine\2 hosts vdsm please see: ========================================== https://bugzilla.redhat.com/show_bug.cgi?id=840553