It should be the same as the VM UUID, which is a pseudo-random UUID. On 12/10/13 10:59 AM, "Bryan Whitehead" <dri...@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 ><dri...@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.vit...@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" <dri...@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 >>> >>> >>
