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.

curl https://raw.githubusercontent.com/veertuinc/scripts/main/generate-anka-node-diagnostics.bash -O && \
chmod +x generate-anka-node-diagnostics.bash && \
./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.
  • Ensure that the user running Anka VMs is logged in and that Sleep and passworded Screensaver are disable. The hypervisor will not work without an active/logged in user.
  • 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>
  1. /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.

Anka Build Cloud Controller Agent Logs

  • 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.
  • vlaunchd.log: Holds communication logs between registry <—> agent —> controller.

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

Troubleshooting Guides