Using UUID’s to troubleshoot and understand Oracle VM (part 1 of 2)

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
                       12G  359M   12G   3% /poolfsmnt/0004fb0000050000d465e496e0f1a989
                      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_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

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!


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s