Harihara Sudhan

Contributed By: Pradeep Kumar M Overview The NetScaler VPX product is a virtual application delivery controller that can be hosted on a wide variety of virtualization and cloud platforms. Several VPX users encounter disk size constraints for various reasons including the VPX instance upgrade, necessitating a minimum of 6GB free space in the /var partition. This guide offers comprehensive steps to resolve this issue by expanding the disk space to meet higher capacity requirements. Note: This is not supported for VPXs on SDX. For SDX, Please refer : https://docs.netscaler.com/en-us/citrix-adc/current-release/deploying-vpx/deploy-vpx-faq.html#can-we-add-a-new-hard-drive-to-increase-space-on-netscaler-vpx-instance Default Behavior Upon VM creation using the Netscaler build package/template, the default disk space allocated to the the VPX is 20GB. Notably, the /var partition size remains fixed at 14GB, as indicated below. Note: Screenshots in this article are taken from the Netscaler VPX running on ESXi Hypervisor. Note: Before changing the disk size, it is recommended to take the snapshot of the VM. Steps to Increase the Disk space on VPX Increase the disk size from Hypervisor or Cloud To expand the disk size, begin by shutting down the virtual machine (VM) and then proceed to increase the current disk capacity, elevating it from 20GB to either 30GB or 40GB. (In the case of Azure, this involves scaling from an existing 32GB to 64GB) Jump into the boot prompt Power on the VM and boot into the boot prompt. i.e: OK prompt or the boot prompt. This can be achieved by pressing "Ctrl + C" during boot time. Enter single user mode Run the following command to log into single user mode. boot -s Note: To enable access in the single-user mode for Azure, it's necessary to configure the com console instead of the default console. This can be done by executing the following command at the ok prompt before initiating the 'boot -s' command. set console=“comconsole” Setup the COM port and connect with Putty. Verify the disk space Check the newly allocated disk space using the following command. gpart show In this instance, the disk space has been expanded to 30GB, resulting in 10GB of available free space as indicated in the output of the "gpart show" command for da0. Also, note the partition name. For this VM it is da0, but for other hypervisor or in cloud it may have different names (For example - AWS has nv0). Resize the disk partition The partitions can be resized by running below commands. Resize the da0 MBR partition to include the 10GB free space by running below command. gpart resize -i 1 da0 Incase a permission denied error is encountered while running the above command, run below mentioned command and rerun the previous resize command. sysctl kern.geom.debugflags=16 The partition looks like below after successfully running the commands. Currently, it is observable that the da0 partition size has expanded to 30GB, with noticeable available free space on the da0s1 partition. Merge the free space to the last partition Run below command to merge the free space to the last partition on da0s1. i.e da0s1e gpart resize -i 5 da0s1 The partition looks like below after successfully running the above command. Now, the 10GB free space has added to 5th partition under the da0s1 partition. i.e /var Run the below command to extend the filesystem to include newly allocated free space. growfs /dev/ada0s1e Now the additionally allocated 10GB is successfully added to /var. Verify the increased disk space Reboot the instance and verify the new disk space by running the following command in the VPX shell prompt. df -h

Author : Farhan Ali If your AWS default route is being modified after reboot, there could be several reasons for this behavior. Here are some common causes and troubleshooting steps: 1. Internet Connectivity:The reason default route is getting modified could be if the Netscaler is not able to contact the meta-data server during boot up. To check if the internet connectivity is present/not, execute the below commands: show route Now, check the route for 169.254.169.254 and verify the route is proper via management 1/1 interface.If the route is missing, then create a static route for 169.254.169.254 via management interface gateway (normally it will be VPC subnet ending with .1 i.e x.x.x.1 where x.x.x is VPC subnet). Verify if the instance is created with metadata option IMDSv2 only. If yes, then stop the instance and change the setting to imdsv1 and v2 both OR upgrade to 13.1.46.x and above release. 2. Automation Scripts or Configuration Management Tools: Check if you have any automation scripts or configuration management tools (e.g., AWS CloudFormation, AWS OpsWorks, Ansible) running that might be modifying the route during bootstrapping or configuration updates. 3. User Actions: Ensure that no one with appropriate permissions is manually modifying the default route. AWS IAM (Identity and Access Management) policies should be reviewed to see who has permission to modify route tables. 4. Instance Metadata Service: Make sure that there are no scripts or services running on the instance that are fetching instance metadata and modifying routes based on that information. 5. Incorrect Route Table Association: Ensure that the instance is associated with the correct route table. If it's associated with multiple route tables, there might be conflicts in route configurations. 6. Network ACLs and Security Groups: Check if there are any network ACLs or security group rules that might be affecting the routing behavior. 7. VPC Peering or VPN Connections: If you have VPC peering or VPN connections set up, verify that the routes and configurations are correct in those connections. 8. AWS Managed Services: Some AWS managed services might automatically modify routes based on certain conditions. For example, AWS Direct Connect or AWS VPN might modify routes based on BGP advertisements. 9. Ephemeral Storage: If your instance is using ephemeral storage for configuration or scripts, ensure that the changes are persisted or re-applied after reboot. 10. Check Route Table Logs: AWS CloudTrail logs can provide insights into who made changes to route tables and when they were made. Check the CloudTrail logs for any relevant events.