02-20-2023 03:40 AM - edited 02-20-2023 03:47 AM
Greetings to the community,
I am experiencing a problem with my CUCM 14.0, i see many alarms LowActivePartitionAvailableDiskSpace.
I imagine that the problem is due to the trace files that are using up too much space.
I don't want to use the RTMT to delete the trace files and I don't know which files should I delete via CLI.
So my questions are:
04-07-2023 01:54 PM
Hello John,
Trace files are stored in the common partition, not active. You are most likely encountering this condition https://bst.cisco.com/bugsearch/bug/CSCvt97709.
04-08-2023 10:04 PM
To free some space in the Common partition, you can try to:
Reduce the values of LogPartitionLowWaterMarkExceeded to 40% and LogPartitionHighWaterMarkExceeded to 45%, restart "Cisco Log Partition Monitoring Tool" service and after 2-3 hours check whether the used space decreased;
Use RTMT Trace/Log Central to collect logs/traces with "Delete Collected Log Files from Server" option (for active and inactive partitions);
Delete the old unused files from the TFTP server (old phone software);
Use ciscocm.free_common_space_v1.1.cop.sgn – this file runs a script that deletes all files from an inactive Common partition. After using it you won't be able to switch CUCM version to the previous one.
To reduce the partition usage, you can try to:
Deactivate Detail/Debug trace level;
Reduce the number of trace files to be stored;
For CDR: reduce the High Water Mark, reduce the occupied disk space, reduce the number of preservation days.
Pls rate if its "Helpful". If this answered your question pls click "Accept As Soulution".
Sadav Ansari
06-06-2024 12:09 PM
The bug id/defect says a rebuild is only resolution. I have a 250GB vdisk with CUCM 14Su1 and 98% reported. Server was built probably ten years with CUCM 7 with 80GB vdisk.
Total Free Used
Disk/active 14154188K 366580K 13626096K (98%)
Disk/inactive 14154188K 398628K 13594048K (98%)
Disk/logging 225034732K 193895300K 21471788K (10%)
06-06-2024 12:11 PM
06-07-2024 06:01 AM
FWIW,
Older CUCM systems (8.x,9.x) are installed as ext3 filesystem types. If these VMs have not been migrated/redeployed and instead directly upgraded over the years by increasing the vDisk size, it will fail when attempting to go to v15.
Upgrade to version 15 will block due to the following:
1. Legacy vDisk layouts
2. Legacy filesystem types (ext3)
3. Legacy guest OS partitions.
Version 15 upgrade will only accept ext4 filesystem.
V/R,
Rob Profit
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide