The PCA is built on Oracle VM Server for x86 and Oracle VM Manager. Ok, then you have OEM Cloud Control (unfortunately) on top. OVMM uses a clustered MySQL database, which contents are encrypted (probably to keep DBAs away, and force you to use the CLI). OEM Cloud Control uses an Oracle Database, not encrypted, that you can't touch! As it is now (Feb 2020) the PCA has no automation, there is one Ansible module to start/stop VMs.. that's all the automation. You need to build tools on your own, in 2020, you think of AWS and laugh at the PCA..The Cloud Control interface is slow and crippled, there is no Identity and Access Management, i mean a proper solution. It is a pretty closed system. The overall engineered system is years behind other vendors, i'm thinking of VMware, OpenStack, Azure Stack. The only selling point is the savings on Oracle licensing. The platform can only be improved. In my opinion, and i might be horribly wrong here, i would rebuild the system from scratch. There is a great Infiniband infrastructure (SDN), wonderful, keep it. Oracle is moving away from Oracle VM Server to land on KVM, great. Why can't you have one single database, maybe even based on Oracle Database 18c (or later). Not encrypted, with a license that allows sysadmins to use it to store data useful to the platform. An engine to manage the hypervisors, one engine to manage assets (system provisioning, customers and users), one engine to provide services to customers. Yes, i'm talking of getting rid of OEM! Technically it can be done, but Oracle won't let you. It's easier to have one million Java developers building plugins for what has now become a monster: OEM. I think that Oracle is not really investing in the PCA because they are far behind the competition, and they can only compete by providing Hard Partitioning. Yeeah.. sorry, not enough to have my million pounds. This kind of engineered system, in my vision, should have: System provisioning, Identity Management integrated. An Automation engine that taps into the main (a single database) repository to carry out tasks on the platform. Those actions that are scheduled in the internal Job Scheduler (which uses, again, the single database). Messaging between node is done using a message broker, no not AQ, a better one like RabbitMQ (and it's open source). They need a central location to collect logs, and run analytics on them (again, open source solutions here availables). More storage options, the ZFSSA works great for block storage and file (NFS). But you need to have access to object storage, where is it? You could use Apache Cassandra to do that.. (look at Cloudian). Monitoring: do we really have to say that OEM is not exactly the best way to do it? Even Nagios works better for monitoring. I would use collectd (open source) and RabbitMQ to transport metrics. Have Redis on one of the nodes used for management, and have an all in-memory repository, for realtime notifications/alerting (with a monitoring engine here). When you have the basics, for those workloads that use Oracle Databases, you can introduce a CI tool (i have already built one). Like a version control system for Oracle Databases. That could be used to have automated deployments against the rdbms. Building CI pipelines at that point would be the next logical move. Don't forget that this kind of systems (because it's Oracle) should host an internal DBaaS infrastructure. Again, i could be wrong on the subject. This is the platform that shines in my dreams. I'm trying to build it, but being alone makes the project long to complete. All i know is that it can be done, and it could be a wonderful platform for virtual machines, and databases, to graze in.
