cloudstack-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryan Whitehead <dri...@megahappy.net>
Subject Re: duplicate system UUID's with KVM
Date Tue, 10 Dec 2013 18:59:44 GMT
(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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message