Are Virtualisation Platforms Supported

Only providing there are no issues “only found” under virtualisation. Use must be user acceptance tested. Updated Jul 27, 2016.

Reality is only supported on the platforms listed for each release, refer to the Reality documentation’s home page under Release Information, in the Prerequisites document.

When it comes to using a virtualisation product on Reality platforms, either built-in to the platform or using a third party, then Reality is likely to work as you desire. Providing this is within your current Reality license agreement with NEC Software Solutions you may deploy Reality in this way, following your own acceptance tests carried out for all end-to-end applications required by your users. While issues are not anticipated, the world of virtualisation is very complex and this may have to be eliminated from apparent issues with Reality – this is common across “system/database level” applications and virtualisation.

The support of “any issues” that are found to be as a direct result of using virtualisation cannot be guaranteed to be resolved by NEC Software Solutions. Any request for support may result in you initially having to re-test issues found under a non-virtualised supported platform. Providing the issue is still present then this will be covered under your current support contract. If the issue is not present then you may have to resolve this yourself, with any support you can obtain from the virtualisation vendor and any advice or support that NEC Software Solutions is able to offer at the time.

Known Issues:

1. Under VMware, V Sphere, Reality V14.0 cannot be installed within an existing virtualised machine, it will have to be installed on an existing physical machine and then transferred to create a virtual machine – requires update #317. Installing in V Sphere has been resolved as of V14.2.
2. Any transfer of Reality to a new physical or virtual machine will require you to contact your Reality account management in order to discuss licensing conditions.
3. The level of performance and delivered scaling is dependent on the efficiency of the chosen virtualisation product as well as the underlying host platform. It is recommended that full acceptance tests are undertaken using the required workload and system configuration to be deployed. The key resources are typically CPU, Physical Memory, Disk & Networking bandwidth that is being shared concurrently across the one physical machine.

Sun Systems: LDOMS(VM for SPARC), ZONES(kernal level separation), Containers, Dynamic Domains…
When it comes to Sun Systems, as above, Reality is only certified to run under Solaris on SPARC based standalone Systems. However, Reality has been tested and does run in “the global zone” implement from Solaris 10 of a multi-zoned System – i.e. you can’t use Reality in other zones(deploying on multiple application systems). Reality also runs in a T-Server/CP-Blade LDOM (VM for SPARC) and recent hypervisor enabled SPARC Systems, as each is seen as an actual physical System, described above, with configured H/W and Solaris O/S as self-contained systems – these were also called “containers”. Reality will also run in a H/W Dynamic Domain, where one System is split into definable sets of CPU and Memory – for example, the M9000 can have up to 24 domains.

Reality Database Isolation:
You may like to consider Reality’s Database Isolation resilient feature, which was made available from V12.0. While this does not allow a single system’s resources to be “divided up” per database, like system platform virtualisation products, it does protect each isolated Reality instance from each other in all ways… i.e. operational or security issues within one instance cannot affect another. Each system platform can be configured with up to 10 instances, including the base instance, and each instance can contain up to 15 live databases.
Refer to Products page under Resilience and in the Documentation under Database Isolation in the index.

Back to articles