├── Troubleshooting and Resolution
│ ├── command
│ │ ├── Could be the system-related command to which non-root user 
        does not have the access
│ │ ├── Could be the user-defined script/command
│ ├── Troubleshooting
│ │ ├── permission/ownership of the command/script
│ │ ├── sudo permission
│ │ ├── absolute/relative path of command/script
│ │ ├── not defined in user $PATH variable
│ │ ├── command is not installed
│ │ ├── command library is missing or deleted

├── Troubleshooting and Resolution
│ ├── System reboot/crash reasons
│ │ ├── CPU stress
│ │ ├── RAM stress
│ │ ├── Kernel fault
│ │ ├── Hardware fault
│ ├── Process restart
│ │ ├── System reboot
│ │ ├── Restart itself
│ │ ├── Watchdog application
│ │ │ ├── To prevent high stress on system resources
│ │ │ ├── If the application causing stress, so it will restart or 
          terminate
│ ├── Troubleshooting
│ │ ├── After logging in, check the status by using commands like 
        uptime, top, dmesg, journalctl, iostat -xz 1
│ │ ├── syslog.log, boot.log, dmesg, messages.log, etc
│ │ ├── custom log path of an application
│ │ ├── if not completely accessible, so take the virtual console 
        like ILO, IDRAC, etc.
│ │ ├── open a case and reach out to a vendor

├── IP Assignment Methods
│ ├── DHCP
│ │ ├── Fixed Allocation
│ │ ├── Dynamic Allocation
│ ├── Static
├── Troubleshooting
│ ├── check network settings from virtualization environments like 
      VMware, VirtualBox or etc.
│ ├── check whether the IP address is assigned or not
│ ├── check the NIC status from the host side using #lspci, #nmcli 
      etc.
│ ├── restart network service

├── Troubleshooting
│ ├── The best option is to create the ACL file of Dir/Files 
      before changing the permissions in bulk
│ │ ├── Create the ACL file before changing the permission (or 
        backup the file permission): ~$ getfacl -R <dir> > 
        permissions.acl
│ │ ├── Restore File Permissions: ~$ setfacl -- 
        restore=permissions.acl
│ ├── Restore from the VM Snapshot (But not always a good option 
      for production)
│ ├── Rebuild the VM (this option is safe for the future)

├── Tips
│ ├── After adding/attaching a new disk to a VM, we can get its 
      status from lsblk command by doing ~$echo 1 > 
      /sys/block/sda/device/rescan
│ ├── If we increase the disk size of the existing disk then the 
      additional space gets appended to the existing disk without 
      affecting the already existing Filesystem and Partition.
│ ├── We can also recreate the filesystem on the block device as 
      it will automatically format the old one
│ ├── If we have a disk (with created partition/FS) we can share 
      the .vmdk to another VM. So, after mounting we would have 
      the same data as it was on the previous one.