Troubleshooting (CLI)

EOL and Deprecation list:

• Anka Virtualization + CLI < 2.0 EOL

We recommend using our diagnostic package collection script. This script collects logs and usage statistics from the host and archives them.

bash -c "$(curl -fsSL https://raw.githubusercontent.com/veertuinc/scripts/main/generate-anka-node-diagnostics.bash)"

It is also best to run this as close to when an issue happens as several commands grab a window in time.

Once you have collected the logs, go through the below mentioned troubleshooting steps and then contact support.

Anka Virtualization

Troubleshooting Checklist

• Ensure that you’ve run sudo anka license accept-eula on the host.
• Make sure you’ve got a valid license with sudo anka license validate.
• Check df -h and other host or VM resource usage (CPU/RAM) and be sure that the host resources are not exhausted.
• Check [~]/Library/Logs/Anka/ logs for any indication of why the failure happened.
• Ensure that all components in your Anka environment can communicate. This includes connectivity between CI/CD tooling we do not support.
• Disable anti-virus and firewalls on the host.

Logs

Anka runs as any user on the host, so the paths and locations described below can sometimes be under $HOME/~.

• Anka CLI commands executed as root/sudo: /Library/logs/anka
• Anka CLI commands as a non-root user: $HOME/Library/logs/anka

The above logs are rotated at 1MB and maintains a maximum of 10 files. This is not configurable.

In these directories you will find the following logs:

1. anka.log - The primary log including anka commands (Anka CLI, Anka run) STDOUT and STDERR

2. lupd.log - License auto-upgrade service logs; it’s rarely used and most likely not related to VMs runtime

3. ankanetd.log - Anka VM network service logs; useful for troubleshooting VM networking related problems

4. {UUID}.log - ({UUID} is the specific VM’s UUID) Specific VM logs; useful if VM exits abnormally or fails to start.

ARM USERS: When starting VMs with -v, VM logs will be written to anka.log instead of their {UUID}.log.

If you’re using the Anka Build Cloud Controller to start and terminate VMs, you need to set an ENV so the Node Agent doesn’t delete the {UUID}.log on termination. This requires editing the agent’s plist:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>EnvironmentVariables</key>
    <dict>
        <key>ANKA_DELETE_LOGS</key>
        <string>0</string>
    </dict>
    <key>Label</key>
    <string>com.veertu.anka.cluster.agent</string>
    <key>ProgramArguments</key>
    <array>
      <string>/Library/Application Support/Veertu/Anka/bin/anka_agent_helper</string>
      <string>--controller-addr</string>

5. /var/log/install.log - Install related STDOUT/ERR

Anka and Apple will also report crashes in /Library/Logs/DiagnosticReports as .crash or .hang.

Build Cloud (optional)

Only relevant if you’ve joined your Node to the Build Cloud Controller & Registry.

• Logs location: /var/log/veertu
• Format: regd.HOSTNAME.USER.LOG.LOGTYPE.TIMESTAMP

There are 5 type of symlinks in the logs location pointing to the latest active logs. The verbosity of the logs are from highest (INFO) to the lowest (ERROR):

• anka_agent.INFO - contains all of the below except for CMD log.
• anka_agent.WARNING - contains WARNNIGS & ERRORS.
• anka_agent.ERROR - contains just ERRORS.
• anka_agent.FATAL - only FATAL ERRORS.
• anka_agent.CMD - (new in 1.20.0) contains the various anka commands the agent is executing on the host as well as the returned data.

You can also read and download the logs via the UI in the Controller dashboard. Though, only relevant if you’ve joined your Node to the Build Cloud Controller & Registry.

Troubleshooting Guides