Installing Oracle VM Manager on Fedora

Although my Oracle VM Manager was running on OEL, I reinstalled the machine with Fedora and obviously I wanted the OVM Manager back on it.

The installation was pretty straight forward. Two tiny things had to be done in order to convince the installer to proceed. I needed to comment out the checks for the OS and the libaio package. After this the installer was on its way.

During the Oracle XE installation I adapted the swapfile (created a big additional swapfile) as the XE installer decided to stop when tere was not enough swap space.

Conclusion: OVM Manager runs fine on Fedora.

Starting with my OVM

Added a 1 TB disk to my OVM machine :-)

[root@ovm ~]# mkfs -t ext3 /dev/sdb
mke2fs 1.39 (29-May-2006)
/dev/sdb is entire device, not just one partition!
Proceed anyway? (y,n) y
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
122109952 inodes, 244190646 blocks
12209532 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=0
7453 block groups
32768 blocks per group, 32768 fragments per group
16384 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
102400000, 214990848

Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 38 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
[root@ovm ~]#


So - now the fun part can start.

dbca - Exception in thread "main"

Sometimes error messages are very misleading. If you see an error stating:

Exception in thread "main"

you expect that this is some java-related issue. Maybe the classpath is wrong, your JAVA_HOME is not set, etc.

I had this error when I was starting up the Oracle dbca.

After some checks and different tries I found out that the DISPLAY environment was set, but to a different screen, which I was not using. So even when you check the dbca shell script, you will find a build-in check for the DISPLAY environment.
But now the check passed with flying flags - as it was set. The problem that my dbca was unable to use this DISPLAY lead to the java error.

Setting the DISPLAY to the one I was using (and setting xhost to allow all) solved this.