I've duped this twice, so I'm not sure if I'm doing something wrong or not.

I have a XEN guest that runs SLES 10 SP3/OES2 SP2 64-bit.
I have given the guest 2.0 GB of RAM and 2 virtual CPU
The host is 64-bit SLES with 8.0 GB of RAM

The OES2 install went fine and all is/was well

I then mounted the ZCM 10.3 ISO (via mount -o loop /mnt) and ran the setup.sh (display in terminal) and the GUI came up and I installed it

I am using an EXTERNAL Oracle Database.

After the install, I had to reboot the server as the NON-HTTPS status would not work (obviously I had to change the default port numbers from 80/443/8009 and I used: 81, 8443, 8010)

After I rebooted, I could login on :81 and :443 into the ZCC just fine

A few minutes later, the httpstkd and java processes sit at 9999% CPU

I cannot install/stop anything once it reaches this point (I cannot even STOP the ZCM services)

This is a test system with NO USERS on the VM. It's been running at 9999% CPU for 4 hours now

I opened an SR and was told it was normal for it to do that because it would try to download a PRU update. However, I've not configured system updates at all, let alone set it up for a proxy server (so it won't be able to download anything anyway)

I don't see any errors in the /var/log/messages that would explain this, let alone anything in the zen logs.

The only thing I can think of is that all the other testing I've done was on 32-bit machines. I think ZCM 10.3 can use a 64-bit JVM, (and it did install a JDK or something that I saw on the install logs).

I CAN manually kill -9 all the services cranking up the CPU and then wait a while and then the server will return to normal.

But I just find it odd. I'm going to setup/test on a vmware machine now as well and see if it's just OES2 or 64-bit OES2 that's the culprit. (I've never had a problem on plain SLES 10 SP2 32-bit). But I don't really want to put it on XEN mainly because I don't have livemotion and Vmware isn't a good candidate either for a production setup like this without making poor use of our resources (ie, to compensate I'd have to crank up the RAM and CPU and disk and it would decrease the number of VM's we can put on the vm host)