I’ve been working with the brand new 184.108.40.206 ODA update on an X5-2 and Oracle has made a number of changes that impact how an install and configuration is done.
220.127.116.11 is the first release that supports a ‘reflash’ of an ODA with Oracle Linux 6. Previously update 18.104.22.168 had Oracle Linux 5 and updated 22.214.171.124 had Oracle Linux 6, but the only way to move to 126.96.36.199 was to first already be at 188.8.131.52 and then patch to 184.108.40.206.
220.127.116.11 is the first release that will support (re-)deployment of an ODA in a virtualized configuration where you load the Oracle VM ISO into each ILOM and then deploy the ODA_BASE virtual machine. Note that if your ODA was at 18.104.22.168 or earlier you will still have to download the 22.214.171.124 patch to ODA_BASE after you deploy ODA_BASE to patch some of the server and storage components. Oracle has changed from the old patch –infra, –grid, –database options and now has a –server (that does some hardware and the grid infrastructure) and –storage (which patches the shared storage hardware).
One very major change which is especially important for those of us who manage virtualized ODA installs remotely is that /etc/xen/xend-config.sxp on ODA_BASE now has the following section:
# The interface for VNC servers to listen on. Defaults # to 127.0.0.1 To restore old 'listen everywhere' behaviour # set this to 0.0.0.0 #(vnc-listen '127.0.0.1')
This means that you when you attempt to create a VM and connect to the console the same way you did in past ODA versions you’re probably going to get something like this:
[root@oda-base-node0 ~]# oakcli show vmconsole OL7U2 OAKERR:8006 Error in VNC display configurations : DISPLAY=localhost:10.0
You can either modify the /etc/xen/xend-config.sxp file, or you can update the vm.cfg file for a particular VM that you’ve imported. Since the ODA will be using ACFS it might be a bit hard to find the vm.cfg file since it ends up in the hidden .ACFS directory on the shared repository ACFS file system.
I had created my VMs on a shared repository named sharedrepo so my vm.cfg file ended up here:
[root@oda-base-node0 OL7U2]# pwd /u01/app/sharedrepo/sharedrepo/.ACFS/snaps/OL7U2/VirtualMachines/OL7U2 [root@oda-base-node0 OL7U2]# vim vm.cfg
Update the vm.cfg file and add the following:
vnclisten = '0.0.0.0'
Note that vnclisten ‘0.0.0.0’ didn’t work and neither did vnclisten = 0.0.0.0. It had to be vnclisten = ‘0.0.0.0’ for the VM to start.
Now that you’ve got a ‘listen anywhere’ vnc console running, you can just use a VNC client on your workstation (I used Tiger VNC) and connect to your node0-dom0:590X where X is the number of VMs you’ve started past ODA_BASE. ODA_BASE is at :5900 and if this is the first additional VM you’ve created you’ll be able to reach the console at :5901. Note that once you’ve done the initial network configuration of your VM you’ll probably want to take the vnclisten parameter out of the vm.cfg file.
I’m also currently working with Oracle support on an issue. We’ve got a RAC One Node multitenant database and catcon.pl won’t run scripts in the ‘root container and all pluggables’. For example:
[oracle@oda-base-node0 ~]$ $ORACLE_HOME/perl/bin/perl $ORACLE_HOME/rdbms/admin/catcon.pl -u SYS -d $ORACLE_HOME/rdbms/admin -b utlrp_output utlrp.sql catcon: ALL catcon-related output will be written to utlrp_output_catcon_77673.lst catcon: See utlrp_output*.log files for output generated by scripts catcon: See utlrp_output_*.lst files for spool files, if any Enter Password: catconInit: database is not open on the default instance Unexpected error encountered in catconInit; exiting
This is important because apxremov_con.sql is just a wrapper for catcon.pl so you can’t remove APEX from the root container (CDB$ROOT) and PDB$SEED so that new pluggable databases won’t have APEX in them. We do this so that we’ll be able to potentially have different versions of APEX in different pluggable databases in the same container database.
Oracle has opened a P1 bug on this and has actively been working this for a few days.