Thursday, October 30, 2014

Peoplesoft HCM92 image #9

It has been released earlier this week, time to move to VMWare ESXi.
My workaround I described here is still working. To make it short, updating the ovf file as below:
1. ovf:capacity=(ovf:capacity*2)-64512 (I used diskMode=thin in the VM disks’ definition for the import)
2. <OperatingSystemSection ovf:id="101">
3. <Description>oracleLinux64Guest</Description>
       <vbox:OSType ovf:required="false">oracleLinux64Guest</vbox:OSType>
4. <vssd:VirtualSystemType>vmx-08</vssd:VirtualSystemType>

And the VM starts properly.

Enjoy,

Nicolas.

Thursday, October 09, 2014

PS JOB

PS_JOB is probably the most popular and well known table in Peoplesoft HCM… The name explains by itself the content, job data component is in there.
If I would have a table on my own, I’d like to add line(s) with my name in it…
It just means that I’m always looking for a new contract. This is the intent of that blog entry. Sorry to the people who are seeking a technical subject, it’s definitely not.

Who am I ?
I hope this blog name is clear enough about my job. I’m an Oracle and Peoplesoft administrator.

I have 19 years of experience. For the last the 14 years I worked on a various of projects which gave me strong skills on my areas. Implementation of Peoplesoft from scratch, upgrade, maintenance. Oracle administration, tuning, always in Peoplesoft context. On Unix (HP, AIX), Linux or Windows, that’s the daily task.
I worked for small as well as large organizations, I used Oracle from version 7 up to 12, OEM 8 up to 12. You can find several posts across my blog for technical articles on all these different aspects regarding my job.

My job is however more than a job, it’s really a passion. I hope this 8-years old blog is showing the high level of my motivation. Everything here has been tested on my own, within my own lab I invested in. Because I think reading documentation and testing are the secret of learning and being up to date of the latest version and new introduced features…
Building my own lab also showed here by a lot of articles, made me going through other technologies like virtualization software, such as Oracle VM and VMWare ESXi.

I also spent a lot of time trying to help people on the Oracle Database General and Peoplesoft forums. It’s a very good way to learn a lot.

Find out more on my LinkedIn page.

What am I looking for ?
Always looking for new opportunity, I’d like to continue in this exciting Oracle/Peoplesoft world !
Having new contract, on site or remotely, everything can be discussed. Do not hesitate to contact me for the details, I’ll give an answer. You have my words.

The show must go on on the Peoplesoft road.

Nicolas.

Monday, September 29, 2014

psadmin 8.54

Peoplesotools 8.54 made few changes in the main menu of psadmin. I thought to find easily docs in Peoplebooks PSADMIN utility description, but it’s not really straight away. So, I decided to write it down to keep ref.

Application domain :
Whether there’s still 28 options in the menu, one has been added, one has been removed.

Let’s see first the menu. Left side psadmin menu from Peopletools 8.53, right side Peopletools 8.54.
 PSADMIN_001
The option 13 (right side) has been added. The “Push Notifications” is an entire new concept. It seems promising even though quite complex to build. Once set in the configuration file, you have to do a lot of configurations from the front-end.
Find out more here in the Peoplebooks : Understanding the Push Notification Framework.
Pay attention to the system requirements, it’s not yet supported on WebSphere, only available for Weblogic.

The option 24 (left side) has been dropped. I suppose this is following the Peopletools end support for Sybase and Informix announced a month ago, since this was only required for those plateform. Amusingly, the Peoplebooks 8.54 have not been updated, this is still referenced (see Sartup Option).

Process Scheduler :
One option dropped, 2 added.

As above, here below screenshot for Process scheduler psadmin menu. Left side psadmin menu from Peopletools 8.53, right side Peopletools 8.54.
 PSADMIN_002
The option 13 “ServerName” (left side) has been removed. Same remark as above, only required for Sybase and Informix, since there are out of support, that’s fine.

From the right side – Peopletools 8.54 - two more options. Option 3) “Domains Gateway” and 4) “Push Notifications”. Nothing in the Peoplebooks regarding those two parameters for Process Scheduler. We have to assume it’s functioning the same way as for the Application server.

Other :
Do you want one more ?
Check the configuration file of application server (actually process scheduler as well), you‘ll see the added feature “InMemory” options:
 PSADMIN_003
The result search on Peoplebooks 8.54 returns nothing but “Your search term inmemorydbname did not match any topics.” I’d expect a reference to this configuration file description. Too bad. How are we supposed to use it ?

Sorry Oracle, but that documentation is weak.

Nicolas.

Friday, September 26, 2014

Script PIA and psadmin

Depending of how you are coding your script to start/stop your webserver, it might not work.

Small example:
[root@vv-cephei-b ~]# cat start_hcm92dmo_web.sh
su - hcm92 <<EOF
psadmin -w start -d peoplesoft
exit
EOF
[root@vv-cephei-b ~]# sh ./start_hcm92dmo_web.sh
Last login: Fri Sep 26 10:33:57 CEST 2014

Starting the domain [peoplesoft].
General Exception: null

java.lang.NullPointerException
        at com.peoplesoft.pt.psadmin.ui.Progress.<init>(Progress.java:135)
        at com.peoplesoft.pt.psadmin.ui.Progress.getInstance(Progress.java:123)
        at com.peoplesoft.pt.psadmin.pia.DomainBootHandler.BootWlsServer(DomainBootHandler.java:84)
        at com.peoplesoft.pt.psadmin.pia.DomainBootHandler.run(DomainBootHandler.java:62)
        at com.peoplesoft.pt.psadmin.pia.PIAAdminCmdLine.startDomain(PIAAdminCmdLine.java:270)
        at com.peoplesoft.pt.psadmin.pia.PIAAdminCmdLine.run(PIAAdminCmdLine.java:481)
        at com.peoplesoft.pt.psadmin.PSAdmin.runSwitched(PSAdmin.java:170)
        at com.peoplesoft.pt.psadmin.PSAdmin.main(PSAdmin.java:232)
[root@vv-cephei-b ~]#

It seems to be a known bug prior Peopletools 8.54:
Trying to Start or Stop WebLogic using psadmin while using Cron Results in Error - General Exception: null - java.lang.NullPointerException (Doc ID 1908227.1)
According to the note, it should be solved in Peopletools 8.54, and obviously it is not for me... even though I'm on the newest one, 8.54.03.

Now, rewording the script:
[root@vv-cephei-b ~]# cat start_hcm92dmo_web.sh
su - hcm92 -c "psadmin -w start -d peoplesoft"
[root@vv-cephei-b ~]# sh ./start_hcm92dmo_web.sh

Starting the domain [peoplesoft].......
Server state changed to STARTING.........
Server state changed to STANDBY..
Server state changed to STARTING..............
Server state changed to ADMIN..
Server state changed to RESUMING....
Server state changed to RUNNING..
Verifying domain status.
The domain has started.

[root@vv-cephei-b ~]#

Much better ! Bug solved.

Nicolas.

Thursday, September 25, 2014

Oracle Linux 7 : ps command as root produces a WARNING

When running a “ps” command as root user on Oracle Linux 7 (and CentOS 7), you may see the following :

root       694     1  0 09:01 ?        00:00:00 /usr/bin/abrt-watch-log -F Backtrace /var/log/Xorg.0.log -- /usr/bin/abrt-dump-xorg -xD
root       692     1  0 09:01 ?        00:00:00 /usr/bin/abrt-watch-log -F BUG: WARNING: at WARNING: CPU: INFO: possible recursive locking detected ernel BUG at list_del corruption list_add corruption do_IRQ: stack overflow: ear stack overflow (cur: eneral protection fault nable to handle kernel ouble fault: RTNL: assertion failed eek! page_mapcount(page) went negative! adness at NETDEV WATCHDOG ysctl table check failed : nobody cared IRQ handler type mismatch Machine Check Exception: Machine check events logged divide error: bounds: coprocessor segment overrun: invalid TSS: segment not present: invalid opcode: alignment check: stack segment: fpu exception: simd exception: iret exception: /var/log/messages -- /usr/bin/abrt-dump-oops –xtD

Note that, at the least, we can read “ernel” where we could expect “kernel”, “eneral” instead of “general”, “nable” instead of “unable”, “ysctl” instead of “sysctl”. Not very nice.

Whether it looks like a bug, it seems not to be. Please read that interesting description Red Hat Bugzilla – Bug 976581. It’s explained the first letter is explicitly not there to be able to catch both capital/lower letter.
It’s an old bug report, a new one has also been reported more recently for CentOS 7 on CentOS bug Tracker. Minor, but it’s worth to keep an eye.

Nicolas.

Restart CREATE_TEMP_TABLE won’t work

Whilst I was running the database setup of a brand new FSCM 92 Peopletools 8.54 database, the server has all of sudden crashed down.
Once restarted, checking the logs files produced by the DMS script, I was able to determine the step it was doing when it stopped. It was the very last step, CREATE_TEMP_TABLE.
Here’s the beginning of that log :
TMP_854_004
Since the server crashed without notice, it ends in the middle of nowhere and without error. There is nothing much about restarted this step in the Peopletools installation guide, I thought restart would simply work straight away…

And here start the troubles :
TMP_854_001  
As you may see, the command restarts from the beginning. But it dramatically failed on a table it was successful at the first place.
The guilty here is the table PSPTMATVWDEP which does not exists. What ?
TMP_854_002 
Indeed, it does not.
And now what ? Looking at all the logs files of load (epengs.log, epengl.log…), that table is “missing”.

I found a very old note on MOS – actually from 2010 !, “How can you restart Data Mover for the CREATE_TEMP_TABLE command (Doc ID 660214.1)”. It is clearly mentioned that CREATE_TEMP_TABLE cannot be restarted. If it fails for some reason, two ways :
1. if you don’t have to upgrade your database to the latest Peopletools release, open AppDesigner, create a new project, insert all the temp tables (or from the first it failed on till the end, cf log file) and build.
You should see something like this :
TMP_854_006

2. if you have to update your database to the latest Peopletools release, then continue (Task 7-2: Updating Database to Latest PeopleTools Release) and run what described above afterwards.
Just for info, that table PSPTMATVWDEP is created in rel854xx :
TMP_854_003

It was new to me. Never late for learning…

Should I say that whether table is mandatory, it is empty ? Also empty on image FSCM92008… Hmmm.

Enjoy,

Nicolas.

Thursday, September 18, 2014

Windows Power Shell does not know psae

I’ve never notice it before, probably already known by most of you guys. But whilst I was building a Peoplesoft database from within Windows 2012R2, I ran psae (PSADMIN AppEngine) from a Windows Power Shell command prompt.
And here what I got:

PS E:\pt854\bin\client\winx86> psae
psae : The term 'psae' is not recognized as the name of a cmdlet, function, script file, or operable program. Check
the spelling of the name, or if a path was included, verify that the path is correct and try again.
At line:1 char:1
+ psae
+ ~~~~
    + CategoryInfo          : ObjectNotFound: (psae:String) [], CommandNotFoundException
    + FullyQualifiedErrorId : CommandNotFoundException

Suggestion [3,General]: The command psae was not found, but does exist in the current location. Windows PowerShell does
    not load commands from the current location by default. If you trust this command, instead type ".\psae". See "get-help
    about_Command_Precedence" for more details.
PS E:\pt854\bin\client\winx86>

Well, probably not a big deal, but good to know and worth a try what is recommanded, since I trust this psae command:

PS E:\pt854\bin\client\winx86> .\psae
Invalid command line argument list.
  process command line:
  GUID command line   : <unavailable>
Usage:
    psae -CT <dbtype>
         -CS <server>
         -CD <database name>
         -CI <connect id>
         -CW <connect password>
         -CO <oprid>
         -CP <oprpswd>
         -R  <run control id>
         -AI <program id>
         -I  <process instance>
         -DEBUG <Y|N>
         -DR <Y|N>
         -NOCOMMIT <Y|N>
         -TRACE <value>
         -DBFLAGS <value>
         -TOOLSTRACESQL <value>
         -TOOLSTRACEPC <value>
         -OT <output type>
         -OF <output format>
         -FP <file path>
  or
    psae <parmfile>
PS E:\pt854\bin\client\winx86>

Of course, we can also still use the good old Windows DOS cmd :
PS E:\pt854\bin\client\winx86> cmd
Microsoft Windows [Version 6.3.9600]
(c) 2013 Microsoft Corporation. All rights reserved.

E:\pt854\bin\client\winx86>psae
Invalid command line argument list.
  process command line:
  GUID command line   : <unavailable>
Usage:
    psae -CT <dbtype>
         -CS <server>
         -CD <database name>
         -CI <connect id>
         -CW <connect password>
         -CO <oprid>
         -CP <oprpswd>
         -R  <run control id>
         -AI <program id>
         -I  <process instance>
         -DEBUG <Y|N>
         -DR <Y|N>
         -NOCOMMIT <Y|N>
         -TRACE <value>
         -DBFLAGS <value>
         -TOOLSTRACESQL <value>
         -TOOLSTRACEPC <value>
         -OT <output type>
         -OF <output format>
         -FP <file path>
  or
    psae <parmfile>

E:\pt854\bin\client\winx86>

Nicolas.

Wednesday, September 17, 2014

We’ve detected that your operating system is not supported by this website

For many, many years, the Peoplesoft users know this (infamous) message on the login page when using, well, a non-supported OS by Peoplesoft.
I remember Duncan found a workaround to hide this message, find out more here. Already 4 years ago…

Maybe I’m out of date by using my old – but very well running – laptop on Windows XP Pro SP3, here it is within the image HCM92004 (Peopletools 8.53.xx) :
PTOOLS854_WEB_OS_002 

What a surprise with the last image HCM92008 (Peopletools 8.54.02), using the same browser and of course the same old laptop and OS, the message is just gone :
PTOOLS854_WEB_OS_004

Nice, but probably time for an OS upgrade anyway !

Nicolas.

Addendum (19-Sept-2014): if my test was done on Firefox 30.0, it’s worth to read PeopleTools Simplifies Internet Explorer Certifications

Monday, September 15, 2014

VMWare ESXi vSphere 5.5 update 2 and guest OS

As of the 1st of August 2014, VMWare ESXi 5.5 supports Oracle Linux 7. 1.5 months after RHEL 7 and 2-3 weeks after CentOS 7.
And good news, from the 5.5 update 2 released last week, we can set it for new guests from the Client:
HCM92008_027 
Note that’s only for the 64-bit version of OS. Surprisingly, whether RHEL 7 64-bit is officially also supported, it’s not listed here…
Or, from within an existing guest:
HCM92008_029  

Find out more about VMWare Compatibility Guide.

Nicolas.

Wednesday, September 10, 2014

VirtualBox Appliances for PeopleSoft on VMWare ESXi (bis)

Written in April last year, my procedure to move the Peoplesoft appliance to VMWare ESXi – see here – seems to be broken since image #6… My test was on image #3…
One of the reader found its own way and kindly shared experience, you can find here how to work around.

Right now we are on image #8, the first one ever on Peopletools 8.54. Time to have a shot.

1. I decided first to follow my own procedure and see.
1.1 OVF changes
First, the ovf file setting changes, very few are needed compared to last year :
[root@omsa:/nfs/software/PeopleSoftCD/OVA/HCM-920-UPD-008_OVA]# diff HCMDB-SES-854-01.ovf HCMDB-SES-854-01.ovf.tmp
34c34
<     <OperatingSystemSection ovf:id="109">
---
>     <OperatingSystemSection ovf:id="101">
36,37c36,37
<       <Description>Oracle_64</Description>
<       <vbox:OSType ovf:required="false">Oracle_64</vbox:OSType>
---
>       <Description>oracleLinux64Guest</Description>
>       <vbox:OSType ovf:required="false">oracleLinux64Guest</vbox:OSType>
45c45
<         <vssd:VirtualSystemType>virtualbox-2.2</vssd:VirtualSystemType>
---
>         <vssd:VirtualSystemType>vmx-07</vssd:VirtualSystemType>
Nothing else.

1.2 ovftool control file
[root@omsa:/nfs/software/PeopleSoftCD/OVA/HCM-920-UPD-008_OVA]# echo "lax" > .ovftool
[root@omsa:/nfs/software/PeopleSoftCD/OVA/HCM-920-UPD-008_OVA]# echo "datastore=vm" >> .ovftool
[root@omsa:/nfs/software/PeopleSoftCD/OVA/HCM-920-UPD-008_OVA]# echo "skipManifestCheck" >> .ovftool
[root@omsa:/nfs/software/PeopleSoftCD/OVA/HCM-920-UPD-008_OVA]# echo "overwrite" >> .ovftool
[root@omsa:/nfs/software/PeopleSoftCD/OVA/HCM-920-UPD-008_OVA]# echo "powerOffTarget" >> .ovftool
[root@omsa:/nfs/software/PeopleSoftCD/OVA/HCM-920-UPD-008_OVA]# echo "net:HostOnly=VM Network 2" >> .ovftool
[root@omsa:/nfs/software/PeopleSoftCD/OVA/HCM-920-UPD-008_OVA]# echo "annotation=Peopletools 8.54">> .ovftool
[root@omsa:/nfs/software/PeopleSoftCD/OVA/HCM-920-UPD-008_OVA]# echo "name=HCM92008" >> .ovftool

1.3 Push to ESXi
[root@omsa:/nfs/software/PeopleSoftCD/OVA/HCM-920-UPD-008_OVA]# ovftool --version
VMware ovftool 3.5.0 (build-1274719)
[root@omsa:/nfs/software/PeopleSoftCD/OVA/HCM-920-UPD-008_OVA]# ovftool HCMDB-SES-854-01.ovf vi://root:pwd@192.168.1.10:443
Opening OVF source: HCMDB-SES-854-01.ovf
Opening VI target: vi://root@192.168.1.10:443/
Deploying to VI: vi://root@192.168.1.10:443/
Transfer Completed
Warning:
- Wrong file size specified in OVF descriptor for 'HCMDB-SES-854-01-disk1.vmdk' (specified: -1, actual 2258674176).
- Wrong file size specified in OVF descriptor for 'HCMDB-SES-854-01-disk2.vmdk' (specified: -1, actual 3552615424).
- Wrong file size specified in OVF descriptor for 'HCMDB-SES-854-01-disk3.vmdk' (specified: -1, actual 8894975488).
- Wrong file size specified in OVF descriptor for 'HCMDB-SES-854-01-disk4.vmdk' (specified: -1, actual 7227696640).
- Wrong file size specified in OVF descriptor for 'HCMDB-SES-854-01-disk5.vmdk' (specified: -1, actual 144896).
- Wrong file size specified in OVF descriptor for 'HCMDB-SES-854-01-disk6.vmdk' (specified: -1, actual 15863050240).
Completed successfully
[root@omsa:/nfs/software/PeopleSoftCD/OVA/HCM-920-UPD-008_OVA]#

Those warnings – which were not here last year on previous images- are really scary. If, like me you want to get rid off these, modify the ovf file.
First check the vmdk files size on disk:
[root@omsa:/nfs/software/PeopleSoftCD/OVA/HCM-920-UPD-008_OVA]# ls -l *vmdk
-rw------- 1 root root  2258674176 Aug 12 08:30 HCMDB-SES-854-01-disk1.vmdk
-rw------- 1 root root  3552615424 Aug 12 08:35 HCMDB-SES-854-01-disk2.vmdk
-rw------- 1 root root  8894975488 Aug 12 08:53 HCMDB-SES-854-01-disk3.vmdk
-rw------- 1 root root  7227696640 Aug 12 09:04 HCMDB-SES-854-01-disk4.vmdk
-rw------- 1 root root      144896 Aug 12 09:04 HCMDB-SES-854-01-disk5.vmdk
-rw------- 1 root root 15863050240 Aug 12 09:24 HCMDB-SES-854-01-disk6.vmdk
[root@omsa:/nfs/software/PeopleSoftCD/OVA/HCM-920-UPD-008_OVA]#

Take all the size and add them into ovf file (ovf:size=…):
<File ovf:href="HCMDB-SES-854-01-disk1.vmdk" ovf:id="file1" ovf:size="2258674176"/>
<File ovf:href="HCMDB-SES-854-01-disk2.vmdk" ovf:id="file2" ovf:size="3552615424"/>
<File ovf:href="HCMDB-SES-854-01-disk3.vmdk" ovf:id="file3" ovf:size="8894975488"/>
<File ovf:href="HCMDB-SES-854-01-disk4.vmdk" ovf:id="file4" ovf:size="7227696640"/>
<File ovf:href="HCMDB-SES-854-01-disk5.vmdk" ovf:id="file5" ovf:size="144896"/>
<File ovf:href="HCMDB-SES-854-01-disk6.vmdk" ovf:id="file6" ovf:size="15863050240"/>

That’s it for the warning.

1.4 Start the VM
Unfortunately, despite ovftool specified a successful work, it’s not possible to boot the new VM. It systematically tries to boot from within the network card, ignoring all the hard drives. And of course, it fails.
 HCM92008_005

2. The systems’ disks are broken.
In the link of the other blog I mentioned above, someone found a way by setting the disk capacity to a dummy size, say 98Gb (see the comment). Using the option “diskMode=thin” of the ovftool properties, it should not be a problem in space. And it works.
2.1 The new ovf
[root@omsa:/nfs/software/PeopleSoftCD/OVA/HCM-920-UPD-008_OVA]# diff HCMDB-SES-854-01.ovf HCMDB-SES-854-01.ovf.orig
4,9c4,9
<     <File ovf:href="HCMDB-SES-854-01-disk1.vmdk" ovf:id="file1" ovf:size="2258674176"/>
<     <File ovf:href="HCMDB-SES-854-01-disk2.vmdk" ovf:id="file2" ovf:size="3552615424"/>
<     <File ovf:href="HCMDB-SES-854-01-disk3.vmdk" ovf:id="file3" ovf:size="8894975488"/>
<     <File ovf:href="HCMDB-SES-854-01-disk4.vmdk" ovf:id="file4" ovf:size="7227696640"/>
<     <File ovf:href="HCMDB-SES-854-01-disk5.vmdk" ovf:id="file5" ovf:size="144896"/>
<     <File ovf:href="HCMDB-SES-854-01-disk6.vmdk" ovf:id="file6" ovf:size="15863050240"/>
---
>     <File ovf:href="HCMDB-SES-854-01-disk1.vmdk" ovf:id="file1"/>
>     <File ovf:href="HCMDB-SES-854-01-disk2.vmdk" ovf:id="file2"/>
>     <File ovf:href="HCMDB-SES-854-01-disk3.vmdk" ovf:id="file3"/>
>     <File ovf:href="HCMDB-SES-854-01-disk4.vmdk" ovf:id="file4"/>
>     <File ovf:href="HCMDB-SES-854-01-disk5.vmdk" ovf:id="file5"/>
>     <File ovf:href="HCMDB-SES-854-01-disk6.vmdk" ovf:id="file6"/>
13,18c13,18
<     <Disk ovf:capacity="107374182400" ovf:diskId="vmdisk1" ovf:fileRef="file1" ovf:format="
http://www.vmware.com/interfaces/specifications/vmdk.html#streamOptimized" vbox:uuid="34649586-c43a-4df3-af9c-2445fd543fdf"/>
<     <Disk ovf:capacity="107374182400" ovf:diskId="vmdisk2" ovf:fileRef="file2" ovf:format="
http://www.vmware.com/interfaces/specifications/vmdk.html#streamOptimized" vbox:uuid="f108476c-e701-49f8-b8f0-f6a2b4d6c4d5"/>
<     <Disk ovf:capacity="107374182400" ovf:diskId="vmdisk3" ovf:fileRef="file3" ovf:format="
http://www.vmware.com/interfaces/specifications/vmdk.html#streamOptimized" vbox:uuid="6ca0b490-9258-4643-888c-1b0722199fe5"/>
<     <Disk ovf:capacity="107374182400" ovf:diskId="vmdisk4" ovf:fileRef="file4" ovf:format="
http://www.vmware.com/interfaces/specifications/vmdk.html#streamOptimized" vbox:uuid="1a394121-3721-4d20-8c09-cd4f9b7f2053"/>
<     <Disk ovf:capacity="107374182400" ovf:diskId="vmdisk5" ovf:fileRef="file5" ovf:format="
http://www.vmware.com/interfaces/specifications/vmdk.html#streamOptimized" vbox:uuid="3bbbc232-080d-4536-916c-262fe5b2d379"/>
<     <Disk ovf:capacity="107374182400" ovf:diskId="vmdisk6" ovf:fileRef="file6" ovf:format="
http://www.vmware.com/interfaces/specifications/vmdk.html#streamOptimized" vbox:uuid="696b9eac-bbe8-4e49-84c2-c0c5d8b84480"/>
---
>     <Disk ovf:capacity="10092418560" ovf:diskId="vmdisk1" ovf:fileRef="file1" ovf:format="
http://www.vmware.com/interfaces/specifications/vmdk.html#streamOptimized" vbox:uuid="34649586-c43a-4df3-af9c-2445fd543fdf"/>
>     <Disk ovf:capacity="5782371840" ovf:diskId="vmdisk2" ovf:fileRef="file2" ovf:format="
http://www.vmware.com/interfaces/specifications/vmdk.html#streamOptimized" vbox:uuid="f108476c-e701-49f8-b8f0-f6a2b4d6c4d5"/>
>     <Disk ovf:capacity="41957153280" ovf:diskId="vmdisk3" ovf:fileRef="file3" ovf:format="
http://www.vmware.com/interfaces/specifications/vmdk.html#streamOptimized" vbox:uuid="6ca0b490-9258-4643-888c-1b0722199fe5"/>
>     <Disk ovf:capacity="15743185920" ovf:diskId="vmdisk4" ovf:fileRef="file4" ovf:format="
http://www.vmware.com/interfaces/specifications/vmdk.html#streamOptimized" vbox:uuid="1a394121-3721-4d20-8c09-cd4f9b7f2053"/>
>     <Disk ovf:capacity="24675840" ovf:diskId="vmdisk5" ovf:fileRef="file5" ovf:format="
http://www.vmware.com/interfaces/specifications/vmdk.html#streamOptimized" vbox:uuid="3bbbc232-080d-4536-916c-262fe5b2d379"/>
>     <Disk ovf:capacity="27793221120" ovf:diskId="vmdisk6" ovf:fileRef="file6" ovf:format="
http://www.vmware.com/interfaces/specifications/vmdk.html#streamOptimized" vbox:uuid="696b9eac-bbe8-4e49-84c2-c0c5d8b84480"/>
34c34
<     <OperatingSystemSection ovf:id="101">
---
>     <OperatingSystemSection ovf:id="109">
36,37c36,37
<       <Description>oracleLinux64Guest</Description>
<       <vbox:OSType ovf:required="false">oracleLinux64Guest</vbox:OSType>
---
>       <Description>Oracle_64</Description>
>       <vbox:OSType ovf:required="false">Oracle_64</vbox:OSType>
45c45
<         <vssd:VirtualSystemType>vmx-09</vssd:VirtualSystemType>
---
>         <vssd:VirtualSystemType>virtualbox-2.2</vssd:VirtualSystemType>
[root@omsa:/nfs/software/PeopleSoftCD/OVA/HCM-920-UPD-008_OVA]#

2.2 The ovftool file content (thin option is used)
[root@omsa:/nfs/software/PeopleSoftCD/OVA/HCM-920-UPD-008_OVA]# cat .ovftool
lax
datastore=vm
skipManifestCheck
overwrite
powerOffTarget
net:HostOnly=VM Network 2
diskMode=thin
annotation=HCM9.2 - Peopletools 8.54.01
name=HCM92008

2.3 Push to ESXi
[root@omsa:/nfs/software/PeopleSoftCD/OVA/HCM-920-UPD-008_OVA]# ovftool HCMDB-SES-854-01.ovf vi://root:pwd@192.168.1.10:443
Opening OVF source: HCMDB-SES-854-01.ovf
Opening VI target: vi://root@192.168.1.10:443/
Deleting VM: HCM92008
Deploying to VI: vi://root@192.168.1.10:443/
Transfer Completed
Completed successfully
[root@omsa:/nfs/software/PeopleSoftCD/OVA/HCM-920-UPD-008_OVA]#

2.4 Boot of the new VM
HCM92008_009

HCM92008_015
Then you are back to the business and prompted to setup your brand new VM.

3. Capacity from vmdk file
Setting a larger value than needed is fine but a bit hazardous.
Looking in the vmdk file, we also can see the real disk capacity of the target. For instance, here for the disk1:
[root@omsa:/nfs/software/PeopleSoftCD/OVA/HCM-920-UPD-008_OVA]# cat HCMDB-SES-854-01-disk1.vmdk|more
KDMV

version=1
CID=aa3d0432
parentCID=ffffffff
createType="streamOptimized"

# Extent description
RDONLY 19711755 SPARSE "HCMDB-SES-854-01-disk1.vmdk"
The size is in Kb, so it should be 19711755*1024=20184837120.
”Surprisingly”, it’s exactly the double of the specified capacity in the original ovf file for the disk1. And the same is true for all the other disks.
Using that size’s capacity is also a failure… Same as above, it’s booting from within the network.

4. Size from vmdk disk
WMWare is coming with a small tool, vmware-mount (version 5.1). Very useful in our case.
[root@omsa:/nfs/software/PeopleSoftCD/OVA/HCM-920-UPD-008_OVA]# for i in `ls |grep vmdk`
> do
> echo $i
> vmware-mount -p $i
> done
HCMDB-SES-854-01-disk1.vmdk
Nr      Start       Size Type Id Sytem
-- ---------- ---------- ---- -- ------------------------
1         63     530082 BIOS 83 Linux
2     530145   10779615 BIOS 83 Linux
3   11309760    8401995 BIOS 82 Linux swap
HCMDB-SES-854-01-disk2.vmdk
Nr      Start       Size Type Id Sytem
-- ---------- ---------- ---- -- ------------------------
1         63   11293632 BIOS 83 Linux
HCMDB-SES-854-01-disk3.vmdk
Nr      Start       Size Type Id Sytem
-- ---------- ---------- ---- -- ------------------------
1         63   81947502 BIOS 83 Linux
HCMDB-SES-854-01-disk4.vmdk
Nr      Start       Size Type Id Sytem
-- ---------- ---------- ---- -- ------------------------
1         63   30748347 BIOS 83 Linux
HCMDB-SES-854-01-disk5.vmdk
Nr      Start       Size Type Id Sytem
-- ---------- ---------- ---- -- ------------------------
1         63      48132 BIOS 83 Linux
HCMDB-SES-854-01-disk6.vmdk
Nr      Start       Size Type Id Sytem
-- ---------- ---------- ---- -- ------------------------
1         63   54283572 BIOS 83 Linux

The size is given in Kb.
Let’s take the first, (530082+10779615+8401995)*1024=20184772608
Ok, we are not that far from the double of the original size (from vmdk, see above), are we ? See.
20184837120 (original capacity) – 20184772608 = 64512. And 64512 is nothing but 63 (start) *1024…

Verifying on the second drive:
[root@omsa:/nfs/software/PeopleSoftCD/OVA/HCM-920-UPD-008_OVA]# cat HCMDB-SES-854-01-disk2.vmdk|more
KDMV

version=1
CID=8bdea51b
parentCID=ffffffff
createType="streamOptimized"

# Extent description
RDONLY 11293695 SPARSE "HCMDB-SES-854-01-disk2.vmdk"

11293695 * 1024 = 11564743680 (in other word original capacity*2, 5782371840*2).
Then, from the last output of vmware-mount, we have 11293632*1024=11564679168.
11564743680 - 11564679168 = 64512. Again.

So, I think we are safe to say the required capacity should be the double of the initial capacity minus 64512.

5. Let’s have a new try with this hypothesis.
5.1 New ovf
[root@omsa:/nfs/software/PeopleSoftCD/OVA/HCM-920-UPD-008_OVA]# diff HCMDB-SES-854-01.ovf HCMDB-SES-854-01.ovf.orig
4,9c4,9
<     <File ovf:href="HCMDB-SES-854-01-disk1.vmdk" ovf:id="file1" ovf:size="2258674176"/>
<     <File ovf:href="HCMDB-SES-854-01-disk2.vmdk" ovf:id="file2" ovf:size="3552615424"/>
<     <File ovf:href="HCMDB-SES-854-01-disk3.vmdk" ovf:id="file3" ovf:size="8894975488"/>
<     <File ovf:href="HCMDB-SES-854-01-disk4.vmdk" ovf:id="file4" ovf:size="7227696640"/>
<     <File ovf:href="HCMDB-SES-854-01-disk5.vmdk" ovf:id="file5" ovf:size="144896"/>
<     <File ovf:href="HCMDB-SES-854-01-disk6.vmdk" ovf:id="file6" ovf:size="15863050240"/>
---
>     <File ovf:href="HCMDB-SES-854-01-disk1.vmdk" ovf:id="file1"/>
>     <File ovf:href="HCMDB-SES-854-01-disk2.vmdk" ovf:id="file2"/>
>     <File ovf:href="HCMDB-SES-854-01-disk3.vmdk" ovf:id="file3"/>
>     <File ovf:href="HCMDB-SES-854-01-disk4.vmdk" ovf:id="file4"/>
>     <File ovf:href="HCMDB-SES-854-01-disk5.vmdk" ovf:id="file5"/>
>     <File ovf:href="HCMDB-SES-854-01-disk6.vmdk" ovf:id="file6"/>
13,18c13,18
<     <Disk ovf:capacity="20184772608" ovf:diskId="vmdisk1" ovf:fileRef="file1" ovf:format="
http://www.vmware.com/interfaces/specifications/vmdk.html#streamOptimized" vbox:uuid="34649586-c43a-4df3-af9c-2445fd543fdf"/>
<     <Disk ovf:capacity="11564679168" ovf:diskId="vmdisk2" ovf:fileRef="file2" ovf:format="
http://www.vmware.com/interfaces/specifications/vmdk.html#streamOptimized" vbox:uuid="f108476c-e701-49f8-b8f0-f6a2b4d6c4d5"/>
<     <Disk ovf:capacity="83914242048" ovf:diskId="vmdisk3" ovf:fileRef="file3" ovf:format="
http://www.vmware.com/interfaces/specifications/vmdk.html#streamOptimized" vbox:uuid="6ca0b490-9258-4643-888c-1b0722199fe5"/>
<     <Disk ovf:capacity="31486307328" ovf:diskId="vmdisk4" ovf:fileRef="file4" ovf:format="
http://www.vmware.com/interfaces/specifications/vmdk.html#streamOptimized" vbox:uuid="1a394121-3721-4d20-8c09-cd4f9b7f2053"/>
<     <Disk ovf:capacity="49287168" ovf:diskId="vmdisk5" ovf:fileRef="file5" ovf:format="
http://www.vmware.com/interfaces/specifications/vmdk.html#streamOptimized" vbox:uuid="3bbbc232-080d-4536-916c-262fe5b2d379"/>
<     <Disk ovf:capacity="55586377728" ovf:diskId="vmdisk6" ovf:fileRef="file6" ovf:format="
http://www.vmware.com/interfaces/specifications/vmdk.html#streamOptimized" vbox:uuid="696b9eac-bbe8-4e49-84c2-c0c5d8b84480"/>
---
>     <Disk ovf:capacity="10092418560" ovf:diskId="vmdisk1" ovf:fileRef="file1" ovf:format="
http://www.vmware.com/interfaces/specifications/vmdk.html#streamOptimized" vbox:uuid="34649586-c43a-4df3-af9c-2445fd543fdf"/>
>     <Disk ovf:capacity="5782371840" ovf:diskId="vmdisk2" ovf:fileRef="file2" ovf:format="
http://www.vmware.com/interfaces/specifications/vmdk.html#streamOptimized" vbox:uuid="f108476c-e701-49f8-b8f0-f6a2b4d6c4d5"/>
>     <Disk ovf:capacity="41957153280" ovf:diskId="vmdisk3" ovf:fileRef="file3" ovf:format="
http://www.vmware.com/interfaces/specifications/vmdk.html#streamOptimized" vbox:uuid="6ca0b490-9258-4643-888c-1b0722199fe5"/>
>     <Disk ovf:capacity="15743185920" ovf:diskId="vmdisk4" ovf:fileRef="file4" ovf:format="
http://www.vmware.com/interfaces/specifications/vmdk.html#streamOptimized" vbox:uuid="1a394121-3721-4d20-8c09-cd4f9b7f2053"/>
>     <Disk ovf:capacity="24675840" ovf:diskId="vmdisk5" ovf:fileRef="file5" ovf:format="
http://www.vmware.com/interfaces/specifications/vmdk.html#streamOptimized" vbox:uuid="3bbbc232-080d-4536-916c-262fe5b2d379"/>
>     <Disk ovf:capacity="27793221120" ovf:diskId="vmdisk6" ovf:fileRef="file6" ovf:format="
http://www.vmware.com/interfaces/specifications/vmdk.html#streamOptimized" vbox:uuid="696b9eac-bbe8-4e49-84c2-c0c5d8b84480"/>
34c34
<     <OperatingSystemSection ovf:id="101">
---
>     <OperatingSystemSection ovf:id="109">
36,37c36,37
<       <Description>oracleLinux64Guest</Description>
<       <vbox:OSType ovf:required="false">oracleLinux64Guest</vbox:OSType>
---
>       <Description>Oracle_64</Description>
>       <vbox:OSType ovf:required="false">Oracle_64</vbox:OSType>
45c45
<         <vssd:VirtualSystemType>vmx-09</vssd:VirtualSystemType>
---
>         <vssd:VirtualSystemType>virtualbox-2.2</vssd:VirtualSystemType>
[root@omsa:/nfs/software/PeopleSoftCD/OVA/HCM-920-UPD-008_OVA]#

5.2 ovftool control file
[root@omsa:/nfs/software/PeopleSoftCD/OVA/HCM-920-UPD-008_OVA]# cat .ovftool
lax
datastore=vm
skipManifestCheck
overwrite
powerOffTarget
net:HostOnly=VM Network 2
diskMode=thin
annotation=HCM9.2 - Peopletools 8.54.01
name=HCM92008

5.3 Push to ESXi
[root@omsa:/nfs/software/PeopleSoftCD/OVA/HCM-920-UPD-008_OVA]# ovftool HCMDB-SES-854-01.ovf vi://root:pwd@192.168.1.10:443
Opening OVF source: HCMDB-SES-854-01.ovf
Opening VI target: vi://root@192.168.1.10:443/
Deploying to VI: vi://root@192.168.1.10:443/
Transfer Completed
Completed successfully
[root@omsa:/nfs/software/PeopleSoftCD/OVA/HCM-920-UPD-008_OVA]#


5.4 Booting VM
The new VM starts as expected. Back to normal.


Ok, I hope it is clear, briefly speaking, in the ovf file change the capacity as (capacity*2)-64512 for each file.

Successfully tested on HCM92008 and FSCM92008 images.

Nicolas.

Monday, September 08, 2014

Peopletools 8.54 client silent installation

Digging around the last Oracle VM appliance HCM92008 (based on Peopletools 8.54.01), I just discovered a file with a nice name.
Check at /opt/oracle/psft/pt/tools/setup/Client/Disk1/resp_file_client.txt
Does this mean we can install Peopletools client in silent mode ? Well, probably not so easily in fact. According to the documentation, it’s still not supported : “Note. Only the command line options listed in this documentation are supported for PeopleSoft installation. Note that the use of a response file for silent installation is not supported for the installer for PeopleSoft PeopleTools 8.54. For some of the installations described elsewhere in this documentation, such as PeopleSoft Pure Internet Architecture, the same options apply.”

Fair enough, looking across Internet, it seems I missed a very interesting blog entry, worth to go through :
http://otherdutiesasrequired.com/?p=17

Nice catch up !

Nicolas.

Tuesday, August 12, 2014

Peoplesoft stops certification on Sybase and Informix

Due to a low number of customers using Sybase and Informix, Peoplesoft team recently decided to stop supporting their products on these databases, please see MOS note Oracle Modifies Supported Platforms for PeopleSoft (Doc ID 1915316.1)
According to the note, the Peoplesoft application 9.1 will be the terminal release for these databases. However, you’ll still be able to go for Peopletools 8.54, it will be the last supported.
Anyway, most likely better to go for a database support change as soon as possible.

It reminds me a poll that I did 5 years ago (!), that was not a scientific nor official statistics but none of the readers here was already using these two db… http://gasparotto.blogspot.nl/2009/11/polls-results.html

Will DB2 next one ?

Nicolas.

Thursday, August 07, 2014

JDK for Peopletools 8.54 on Linux 7

On Linux, once you installed JDK provided on edelivery for Peopletools 8.54 (jdk-7u55-linux-x64.rpm), you make a go for Weblogic.
Here you go:
java -jar wls_121200.jar

On Oracle Linux 7, it ends quickly by the following error :
OpenJDK JVM not supported on this platform.

Also tried with 7u65, no luck. To solve it, install the JDK 7u67 – the latest available. You can download it here :
http://www.oracle.com/technetwork/java/javase/downloads/jdk7-downloads-1880260.html

Weblogic install should run now - do not forget to set JAVA_HOME before hands.
There’s a warning though about unsupported platform (Oracle Linux 7 is not yet), but it does not hurt.

Nicolas.

Tuesday, November 26, 2013

Peoplesoft on Windows 2012 : Peopletools 8.53 install

After having installed Oracle and middleware on Windows 2012, time for the Peopletools.

Note, Peopletools 8.53 is certified on Windows 2012.
However, as soon as we start the installer, something is going wrong:
PTOOLS853_W2012_TOOLS85300_002
PTOOLS853_W2012_TOOLS85300_003
PTOOLS853_W2012_TOOLS85300_004
It does not seem to like the user interface working onto Windows 2012. As far as I remember of my previous installation on Windows 2008, there was no such problem.
So, the only work around is the use of command line, enforcing the console mode:
PTOOLS853_W2012_TOOLS85300_005
As of now, it will follow all the steps you can already see when installing Peopletools onto a Unix/Linux server :
PTOOLS853_W2012_TOOLS85300_006
PTOOLS853_W2012_TOOLS85300_008
PTOOLS853_W2012_TOOLS85300_010
PTOOLS853_W2012_TOOLS85300_012
PTOOLS853_W2012_TOOLS85300_013
Surprisingly, in the end of the process a reboot is triggered.   I wouldn’t expect this to happen ! Especially without notice. 
PTOOLS853_W2012_TOOLS85300_020 

The Peopletools 8.53 patch 4 does not have such problems as described above.
The GUI works perfectly fine, and it does not reboot the server in the end:
PTOOLS853_W2012_TOOLS85304_001
PTOOLS853_W2012_TOOLS85304_002
PTOOLS853_W2012_TOOLS85304_003
<…snipped…>
PTOOLS853_W2012_TOOLS85304_014   

And finally, the psadmin menu:
PTOOLS853_W2012_TOOLS85304_015

And if I change the settings for PS_CFG_ HOME:

PTOOLS853_W2012_TOOLS85304_017
PTOOLS853_W2012_TOOLS85304_018
PTOOLS853_W2012_TOOLS85304_019
PTOOLS853_W2012_TOOLS85304_020
PTOOLS853_W2012_TOOLS85304_021     

Nicolas.

Wednesday, November 13, 2013

How to shutdown Peoplesoft OVA after init

The Peoplesoft team continues to provide the PUM images on schedule. Great work. The last image HCM 9.2.003 has been released about two-three weeks ago.
I’m still using VMWare ESXi vSphere Hypervisor 5.1 and my workaround to move these OVA to VMWare is still working fine, find out more about this workaround I wrote about few months ago here.

There’re few changes though. The number of updates required in the ovf file have been dramatically dropped down. Right now, we’ve only have two parts to modify:
From
<     <OperatingSystemSection ovf:id="109">
<       <Description>Oracle_64</Description>
<       <vbox:OSType ovf:required="false">Oracle_64</vbox:OSType>
To
>     <OperatingSystemSection ovf:id="101">
>       <Description>oracleLinux64Guest</Description>
>       <vbox:OSType ovf:required="false">oracleLinux64Guest</vbox:OSType>
And From
<         <vssd:VirtualSystemType>virtualbox-2.2</vssd:VirtualSystemType>
To
>         <vssd:VirtualSystemType>vmx-07</vssd:VirtualSystemType>
Apart from that, other changes in the file are no longer necessary.
Note that the sound card tag is not there anymore as many of the others which caused incompatibilities with VMWare.

Then I deployed the OVA with ovftool (the link points to the latest version 3.5, but I’m still using the previous version 3.0.1, it probably does not make any difference for this case):
[root@omsa:/nfs/software/PeopleSoftCD/OVA/HCMDB-85307-PI003_OVA]# ls -la
total 16223832
drwxrwxrwx 2 root root       4096 Nov  8 13:16 .
drwxrwxrwx 7 root root       4096 Oct 31 15:13 ..
-rw------- 1 root root 1235787776 Oct 10 11:36 HCMDB-853-07-disk1.vmdk
-rw------- 1 root root 2931841536 Oct 10 11:39 HCMDB-853-07-disk2.vmdk
-rw------- 1 root root 4845944320 Oct 10 11:46 HCMDB-853-07-disk3.vmdk
-rw------- 1 root root 7583338496 Oct 10 11:54 HCMDB-853-07-disk4.vmdk
-rw------- 1 root root      13757 Nov  8 09:37 HCMDB-853-07.ovf
-rw------- 1 root root      13747 Nov  7 08:32 HCMDB-853-07.ovf.orig
-rw-r--r-- 1 root root        103 Nov  8 12:03 .ovftool
[root@omsa:/nfs/software/PeopleSoftCD/OVA/HCMDB-85307-PI003_OVA]# more .ovftool
lax
datastore=vm
skipManifestCheck
overwrite
powerOffTarget
net:HostOnly=VM Network 2
name=HCM92003
[root@omsa:/nfs/software/PeopleSoftCD/OVA/HCMDB-85307-PI003_OVA]# ovftool HCMDB-853-07.ovf vi://root:<mypwd>@192.168.1.10:443
Opening OVF source: HCMDB-853-07.ovf
Opening VI target: vi://root@192.168.1.10:443/
Deploying to VI: vi://root@192.168.1.10:443/
Transfer Completed
Completed successfully
[root@omsa:/nfs/software/PeopleSoftCD/OVA/HCMDB-85307-PI003_OVA]#

Of course, if you’re working on VirtualBox you don’t have any of these above problems.

And finally booting the VM from the console works like a charm:
HCM92003_boot_002

In the end of this boot, and as expected, we are prompted for the Terms of Use, root password, network properties, database name…
HCM92003_boot_003

HCM92003_boot_005 
etc.
Then, last screen, the setup is completed. We are now ready to go to the front-end:
HCM92003_boot_006
Note that all these actions above are done from within the console, you don’t actually have other choice for the configuration (vm-template init script triggered on 1st VM’s boot).
!!! For the sake of my article I deliberately leave the console like this, not touching the keyboard anymore from here, do not press any key !!!

We can really appreciate all the effort done by the Peoplesoft team. It has never been simpler to deploy a working environment. Now, login page:
HCM92003_boot_007
HCM92003_boot_008
So far, so good. All works as expected.

Now the heck, and I’m coming on the subject of the article.

Not long after setting up this new VM, I wanted to shutdown my host server for some maintenance reason. I have had to shutdown this VM first. How to do it ? Should I go to the console ? Or can I do it through putty (I know the IP, so why not) ?

CASE 1: shutting down the VM when connected through Putty
Note that at this very moment the console is still pending with the message (Will continue in 1800 seconds…) whilst I’m shutting down the VM as root connected to the VM through Putty (most of the time I don’t use the console to work on the VM):
HCM92003_boot_010
Now nothing wrong to want to restart the VM. Let’s see:
HCM92003_boot_011 
And here we go to the nowhere:
HCM92003_boot_012
For some reason, we are going to reinit the VM ! What’s the heck ?!?!? I don’t even want do go any further, I’m too scared about the VM stability now.
For the record, here are the last lines of /var/log/oraclevm-template.log
[LOG]  Nov 12 09:12:04 S96psft-abw: Started PIA Domain peoplesoft
[LOG]  Nov 12 09:12:04 oraclevm-template: ==> 2013-11-12 09:12:04: oraclevm-template --config <==
[LOG]  Nov 12 09:12:04 oraclevm-template: Running oraclevm-template --config
[LOG]  Nov 12 09:12:04 oraclevm-template: Loading parameters from config file: /etc/sysconfig/oraclevm-template
[LOG]  Nov 12 09:12:04 oraclevm-template: Reconfiguring OS
[INFO] Nov 12 09:12:06 oraclevm-template: Regenerating SSH host keys.
[LOG]  Nov 12 09:12:08 oraclevm-template: calling /opt/oracle/psft/vm/oraclevm-template.sh
[LOG]  Nov 12 09:12:08 oraclevm-template.sh: Creating Virtual Environment. Date: Tue Nov 12 09:12:08 UTC 2013

We can really see that the configuration is recalled…
And before rebooting:
[root@hcm92003 ~]# more /etc/sysconfig/oraclevm-template
#
# Template configuration
#

#
# Allow configuration of the template when the service is enabled
#
RUN_TEMPLATE_CONF=YES

According to this, this is very logic that it returns to a pre-config state.

CASE 2: shutting down the VM when connected through the VM console
Restarting from scratch, but now instead of going to shutdown the VM with Putty, we do that from within the VM console itself. Let’s see how it is behave.
HCM92003_boot_014  
On that screen which was still pending for the 1800 seconds, I finally press a key (actually “Enter”). Please note the message “Template configuration disabled”, I’m sure it plays a role somewhere.
Now restarting the same VM:
HCM92003_boot_015 
Much better, now everything looks to work fine, and actually does:
HCM92003_boot_016
As of now, no matter how/where we are shutting down the VM, it will always work.
And the log file is pretty clear, all looks ok now:

[LOG]  Nov 12 08:56:52 oraclevm-template: ==> 2013-11-12 08:56:51: oraclevm-template --disable <==
[LOG]  Nov 12 08:56:52 oraclevm-template: Running oraclevm-template --disable
[LOG]  Nov 12 08:56:53 oraclevm-template: Changed RUN_TEMPLATE_CONF=NO in /etc/sysconfig/oraclevm-template
[INFO] Nov 12 08:56:53 oraclevm-template: Template configuration disabled.

And the config file:
[root@hcm92003 log]# more /etc/sysconfig/oraclevm-template
#
# Template configuration
#

#
# Allow configuration of the template when the service is enabled
#
RUN_TEMPLATE_CONF=NO
This time, no doubt, it won’t reconfigure the VM.

HOW DOES IT ALL WORK ?
After a little digging on oraclevm-template scripts triggered on the boot, I think I found why this behavior.
In order to understand, I’ll try to go step by step:

1. In the very beginning, the first script to be called on the VM boot is /etc/rc.d/init.d/oraclevm-template.
In this script, we can see a configuration file CONFFILE=/etc/sysconfig/oraclevm-template… the same as shown above, which contains whether the VM has to be set or not (RUN_TEMPLATE_CONF=YES).
If the VM has to be configured, it calls an other script with the flag “-config”, as following: “/usr/sbin/oraclevm-template –config”. And eventually disable the template, calling the same script with the flag “–disable” which set RUN_TEMPLATE_CONF=NO.
Here we go (just an extract):
CONFFILE=/etc/sysconfig/oraclevm-template
...
                . $CONFFILE
                case "$RUN_TEMPLATE_CONF" in
                    YES|yes|Yes|1)
                        doconfig=1
...
        if [ $forceconfig -eq 1 ] || [ $doconfig -eq 1 ]; then
               /usr/sbin/oraclevm-template --config
                ret=$?
...
            # Just disable no matter firstboot reconfig succeeds or not.
            /usr/sbin/oraclevm-template –disable

2. If the VM has to be configured (RUN_TEMPLATE_CONF=YES), we can see that the script /usr/sbin/oraclevm-template is launched with flag “config”. A function is called, “do_config”. It goes through every single step to initialize the VM, including a call an other script /opt/oracle/psft/vm/oraclevm-template.sh which will run all the necessary.
When this script /usr/sbin/oraclevm-template is called with config flag, it is ending by running the function “ovm_press_anykey 1800”.

3. This last function can be found in /usr/lib/oraclevm-template/functions:
function ovm_press_anykey
{
    local to=0
    [ -n "$1" ] && to=$1 || to=$DEFAULT_TIMEOUT
    echo
    stty -echo
    if [ $to -eq 0 ]; then
      read -n 1 -p "Press any key to continue..."
    else
      read -t $to -n 1 -p "Will continue in $to seconds, or press any key to continue..."
    fi
    echo
    stty echo
}
We find here the last message when the console is pending as I showed in the screenshots above.

To make it short: in the end of the first VM configuration, it will wait for 1800 seconds or that a key is pressed (step 3, function ovm_press_anykey) to continue (step 2, exit from the script /usr/sbin/oraclevm-template)  and do so to disable the template (step 1, /etc/rc.d/init.d/oraclevm-template) with the command “/usr/sbin/oraclevm-template –disable”…
If you don’t press enter or do not wait for 1800 seconds before doing a shutdown from outside the console, then the template is never going to be disabled…

CONCLUSION:
To my point of view, it’s a mistake. This is a template deployment script bug. It should turn RUN_TEMPLATE_CONF to NO as soon as we finished the configuration as stated in the console screen “The setup of the Peoplesoft Virtual Machine is completed” and not after we press a key or wait for 1800 seconds… Probably not an easy fix though since a lot interaction between different scripts is involved here.
Maybe disabling the template immediately after configuration would be the simplest way ? At the step 2, the “config” function should trigger the “disable” function (as it does at step 1) before any pending action.

What should we do now ?
Awaiting a fix, after the very first boot and configuration of the VM, always, always press enter from within the console !!! No matter what you will do later on, press a key ! Then and only then, you can close the console.

Thanks and enjoy the appliances !

Nicolas.