Cisco ISE 3.2 OVA instable crashes

[Tom -K]

Hi  Everyone,

Cisco ISE 3.2 keeps crashing several days after the installation.
The installation has been done successfully without any problems.
After a couple of days the installation is malfunctioning.

After several installations and change of the selected OVA file the problem remains present , the application ISE cashed . (see the attachment)

After a reboot of the Appliance, the VM no longer boots. ( Cursor continues to be shown in the boot screen)

Used OVA including Patch 5
ISE-3.2.0.542a-virtual-SNS3615-SNS3655-300.ova

The 3715 OVA version has the same symptoms
ESXi version 7.0.u3

I
Cisco writes about a BUG however it tells nothing.
https://quickview.cloudapps.cisco.com/quickview/bug/CSCvb13922

Is it  a BUG or known issue?
( I start worrying the DISK on the ESXi  seems to be corrupt)

With regards 

Tom

The Netherlands

[davidgfriedman]

You wrote OVA, so this is a VM, IIRC, you'll need to be sure you have turned off live migrations, snapshots, and ensure dedicated vCPU and RAM, oversubscribing is bad, you need dedicated resources for your VM, no half measures. I'm sure others will chime in with more VM settings I'm not recalling off the top of my head.

[ahollifield]

Exactly.  With the exception that compute vMotion is supported with ISE 3.1+.    These symptoms sound exactly like snapshots or other hypervisor level backups tools are enabled on the ISE VM. 

[Tom -K]

There's no snapshot or hypervisor level backups tool enabled or even present on the ISE IVM.

I know TACS, the down like that for sure

[adamscottmaster2013]

I am currently running ISE 3.2 with patch 5 on ESXi 6.7 without any issues so far.   I installed 3.2 from the OVA file and patched to patch-5.  I have live migrations, snapshots on the ESXi.  I am also using on 16GB on the VM instead of the usual 32GB recommended by Cisco.  Again, no issue so far.

[Tom -K]

I'll think it's the SSD in the ESXi server.  I have to check the disk with the cli ESXi tools again.

[Aref Alsouqi]

Not sure if this helps, but just to share that I ran into similar scenarios multiple times with different Palo Alto virtual firewalls and it ended up being an issue with the hypervisor storage.