As quoted from Wikipedia:
A universally unique identifier (UUID) is an identifier standard used in software construction. A UUID is simply a 128-bit value. The meaning of each bit is defined by any of several variants.
For human-readable display, many systems use a canonical format using hexadecimal text with inserted hyphen characters. For example:
The intent of UUIDs is to enable distributed systems to uniquely identify information without significant central coordination. In this context the word unique should be taken to mean “practically unique” rather than “guaranteed unique”. Since the identifiers have a finite size, it is possible for two differing items to share the same identifier. This is a form of hash collision. The identifier size and generation process need to be selected so as to make this sufficiently improbable in practice. Anyone can create a UUID and use it to identify something with reasonable confidence that the same identifier will never be unintentionally created by anyone to identify something else. Information labeled with UUIDs can therefore be later combined into a single database without needing to resolve identifier (ID) conflicts.
Adoption of UUIDs is widespread with many computing platforms providing support for generating UUIDs and for parsing/generating their textual representation.
As an expression of just how unique a UUID actually is, you would have to create 1 trillion UUIDs every nanosecond for 10 billion years to exhaust the number of UUIDs available.
Oracle VM uses UUID’s in multiple places, as does Linux itself. Below, we will identify the more important usage of UUID’s in Oracle VM and Linux in general.
Storage Repository UUID:
Generated at filesystem creation time, this UUID is stored in a few places including the path of the actual repository when it’s mounted:
[root@OVM ~]# df -h Filesystem Size Used Avail Use% Mounted on /dev/sda2 19G 9.3G 8.8G 52% / /dev/sda1 99M 48M 46M 52% /boot tmpfs 903M 0 903M 0% /dev/shm none 903M 336K 902M 1% /var/lib/xenstored /dev/mapper/36001f9300200e0000007000200000000 12G 359M 12G 3% /poolfsmnt/0004fb0000050000d465e496e0f1a989 /dev/mapper/36001f9300200e000001d000200000000 800G 449G 352G 57% /OVS/Repositories/0004fb0000010000c93e88783207de86 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
It’s also located in the .ovsrepo file identified by OVS_REPO_UUID= inside the filesystem when the repository is created by OVM Manager:
OVS_REPO_UUID=0004fb0000010000c93e88783207de86 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ OVS_REPO_VERSION=3.0 OVS_REPO_MGR_UUID=0004fb0000010000d395249d92ccea86 OVS_REPO_ALIAS=My Big Fat Repository
Also you can see the UUID of the repository by using the mounted.ocfs2 command:
# mounted.ocfs2 -d Device Stack Cluster F UUID Label /dev/sdb1 o2cb ocfs2demo 0004fb0000010000c93e88783207de86 ocfs2demo ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
OVM Manager UUID:
When OVM Manager is installed, it generates a UUID that gets linked to the database instance for that installation and is stored in numerous locations. The first place it is stored is in the configuration file on the OVM Manager system itself which is located at /u01/app/oracle/ovm-manager-3/.config. It is identified by UUID=
[root@ovmmgr ~]# cd /u01/app/oracle/ovm-manager-3/ [root@ovmmgr ovm-manager-3]# cat .config DBTYPE=MySQL DBHOST=localhost SID=ovs LSNR=49500 OVSSCHEMA=ovs APEX=8080 WLSADMIN=weblogic OVSADMIN=admin COREPORT=54321 UUID=0004fb00000100008edf7365808c02d3 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ BUILDID=184.108.40.2065
It can also be located inside the /.ovspoolfs file on the pool filesytstem LUN. It is identified by OVS_POOLFS_MGR_UUID=. It’s also found on each OVM server in the /.ovsrepo file on each repository filesystem LUN identified by OVS_REPO_MGR_UUID=.
When a LUN is created on a SAN, it is given a UUID or sometimes called a GUID (same difference). With a local disk on Linux, the OS assigns a UUID to each disk so it can identify it uniquely. When LUN’s are presented to Linux (as well as most other OS’s), the OS reads page 83 of the LUN’s VPD (Vital Product Data) table and determines its UUID. This is how the dm-multipath driver in the linux kernel for example is smart enough to know that /dev/sdk, /dev/sdl, /dev/sdm and /dev/sdn are all different paths to the same LUN. The /dev/sd# construct is just an enumeration of each device that is presented to the kernel in the order it’s presented each time the system boots. This is also why it’s generally a good idea to identify a LUN or chunk of storage which is presented to a server by it’s UUID rather than the /dev/sd# label. In Linux, depending on the boot process and the order in which LUN’s are enumerated by the kernel, there’s no guarantee that the first time the system boots it will see each LUN in the same exact order as the second time. What is currently /dev/sdk could wind up getting enumerated as /dev/sdp the next time it boots. It’s all about timing, and certainly not a way to maintain consistency when trying to mount filesystems.
This is why you may sometimes see the following type of notation in /etc/fstab:
# # /etc/fstab # Created by anaconda on Mon Jul 29 16:36:37 2013 # # Accessible filesystems, by reference, are maintained under '/dev/disk' # See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info # UUID=978c7340-c929-4321-859a-2b168a258ebc / ext4 defaults 1 1
instead of this:
# # /etc/fstab # Created by anaconda on Mon Jul 29 16:36:37 2013 # # Accessible filesystems, by reference, are maintained under '/dev/disk' # See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info # /dev/sda1 / ext4 defaults 1 1
In part 2, I’ll talk about ways to correlate the different locations of UUID’s to figure out why things aren’t working and how to fix them. I’ll give a few common scenarios and walk through how to deal with them. Stay tuned!