cloudstack-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chiradeep Vittal <Chiradeep.Vit...@citrix.com>
Subject Re: duplicate system UUID's with KVM
Date Tue, 10 Dec 2013 20:01:04 GMT
It should be the same as the VM UUID, which is a pseudo-random UUID.

On 12/10/13 10:59 AM, "Bryan Whitehead" <driver@megahappy.net> wrote:

>(Sorry, meant to say Cloudstack 3.0.x boxes are running CentOS6.2
>still...)
>
>
>On Tue, Dec 10, 2013 at 10:59 AM, Bryan Whitehead
><driver@megahappy.net>wrote:
>
>> In all cases these are CentOS boxes. The 3.0.x boxes are still in
>> CentOS6.x land but the 4.1 Cloudstack boxes are 6.4+updates (as of
>>6months
>> ago).
>>
>> I don't know if the UUID internal to the VM is generated by cloudstack,
>> libvirtd, or qemu-kvm. Since the mac addresses have never had a
>>collision I
>> suspect the UUID is random with a common seed. Just not sure what piece
>>is
>> doing creating the UUID for a fresh VM.
>>
>>
>> On Mon, Dec 9, 2013 at 10:04 PM, Chiradeep Vittal <
>> Chiradeep.Vittal@citrix.com> wrote:
>>
>>> What is the OS of the KVM host?
>>> I believe vm uuids are type 4 uuids and are hence independent of time.
>>> http://docs.oracle.com/javase/6/docs/api/java/util/UUID.html
>>>
>>>
>>>
>>> On 12/9/13 12:01 PM, "Bryan Whitehead" <driver@megahappy.net> wrote:
>>>
>>> >I have 3 independent Cloudstack installs. One is 3.0.x and the others
>>>are
>>> >4.1.0.
>>> >
>>> >Using KVM (i'm only using KVM so I don't have anything else for
>>> >comparison), between 3.0.x and 4.1.0 I'm getting instances with UUID's
>>> >that
>>> >are the same.
>>> >
>>> >I get the UUID by running this on the console (CentOS):
>>> >
>>> >dmidecode -s system-uuid
>>> >
>>> >Here is example output from 1 host:
>>> >[root@fortress ~]# dmidecode -s system-uuid
>>> >C1260F04-F171-3136-85A7-F0B77699DA33
>>> >[root@fortress ~]# ifconfig eth0
>>> >eth0      Link encap:Ethernet  HWaddr 06:9A:36:00:00:AF
>>> >          inet addr:removed  Bcast:70.33.251.255  Mask:255.255.255.0
>>> >          inet6 addr: fe80::49a:36ff:fe00:af/64 Scope:Link
>>> >          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>>> >          RX packets:20586 errors:0 dropped:0 overruns:0 frame:0
>>> >          TX packets:1796 errors:0 dropped:0 overruns:0 carrier:0
>>> >          collisions:0 txqueuelen:1000
>>> >          RX bytes:1764556 (1.6 MiB)  TX bytes:197329 (192.7 KiB)
>>> >
>>> >
>>> >here is another:
>>> >[root@db-sla01 ~]# dmidecode -s system-uuid
>>> >C1260F04-F171-3136-85A7-F0B77699DA33
>>> >[root@db-sla01 ~]# ifconfig eth0
>>> >eth0      Link encap:Ethernet  HWaddr 06:5E:9A:00:00:C9
>>> >          inet addr:removed  Bcast:64.13.168.255  Mask:255.255.255.0
>>> >          inet6 addr: fe80::45e:9aff:fe00:c9/64 Scope:Link
>>> >          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>>> >          RX packets:7644414 errors:0 dropped:0 overruns:0 frame:0
>>> >          TX packets:3073765 errors:0 dropped:0 overruns:0 carrier:0
>>> >          collisions:0 txqueuelen:1000
>>> >          RX bytes:735505477 (701.4 MiB)  TX bytes:519743789 (495.6
>>>MiB)
>>> >
>>> >NOTE: The IP's are not in the same nor in the same subnet
>>> >
>>> >The time between creation is pretty long... weeks.
>>> >
>>> >Any ideas?
>>> >
>>> >I've just been killing VM's that have collisions with UUID's but it
>>> >happens
>>> >pretty often.
>>> >
>>> >-Bryan
>>>
>>>
>>


Mime
View raw message