# Debugging VMs

Debugging your new VM image might be necessary if it does not integrate into tiCrypt infrastructure. Once the VM is integrated, you can access it through the tiCrypt frontend. This section provides solutions to access the VM that booted your VM Image directly.

In the rest of this section, we assume that you installed your image, created a VM Brick that uses the image and booted up a VM using the brick.

# Set up debugging for Nutanix VM Images

You need access and credentials to the Nutanix PRISM interface.

To debug a Nutanix VM image, login in PRISM and activate the VM

# Set up debugging for Libvirt VM Images

You need root access to the VM Host that runs your VM. All commands need to be executed as root.

In order to debug VM Images, you need to set the video attribute to "VNC" for the brick before you boot the VM image. This will place the VM in debug mode.

To facilitate debugging, make sure the parameter registration-timeout-debug has a value of at least 1 hour.

## List all running VMs​

virsh list

A typical result looks like:

IdNameState

7

vm-6779c0be-5819-4343-ba69-b1cd14b93645

running

23

vm-7a62441f-052a-4878-96cb-1106fc82fd82

running

30

vm-121c0e1b-cff4-42cb-be09-044bbc60248a

running

Your VM is likely the last entry in the result. I our case vm-121c0e1b-cff4-42cb-be09-044bbc60248a

## Find the VNC port for your VM​

virsh vncdisplay vm-121c0e1b-cff4-42cb-be09-044bbc60248a

Result looks like:

127.0.0.1:0

Notice the number after the ":", the X11 display port.

## Setting up a a tunnel to access the VNC port​

Typically, the VM Host does not allow GUI programs. It is then necessary to make the VNC end-point available to your desktop. You can accomplish this with SSH using port forwarding. From your desktop, you can use:

ssh -L 5901:localhost:5900 vm-host

The above command will forward display :1 on your local machine to display :0 on the VM host. If the display port on the VM host is :10, the last port in the command changes from 5900 to 5910.

Use a VNC client on you desktop to access the VM. Point it to localhost:1.

# Debugging Linux Images

## Check that the network is up​

nmcli d

Look for the information for eth0. If it is missing or disabled, the networking is not set up properly.

If networking is not set up properly, the entire process is broken

## Verify that the VM Stub is running​

systemctl status ticrypt-vm-controller.service

If it shows errors, view them with

journalctl -u ticrypt-vm-controller.service

The log should also show any problems with the VM Controller

## Verify that OpenSSH is deactivated​

systemctl status sshd

The output should indicate that it is inactive

# Modifying images in place

Should errors arise, the VM Image needs to be fixed. To avoid transporting a possibly large image with fixes, the following procedure allows the image to be changed using a KVM virtual machine.

Make sure that all the VMs using the image you are about to edit are shut down.

## Crate a KVM virtual machine running on the disk image​

Make sure that virt-install is available. If not, install with yum install virt-install -y

Let’s asume that we need to fix linux.qcow2 image. We do:

# run as rootvirt-install --name linux --vcpus 1 --ram 1024 --controller type=scsi,model=virtio-scsi --disk /ticrypt/libvirt/pools/ticrypt-bricks/linux.qcow2,bus=scsi,size=80 --import --graphics vnc --noautoconsole --network bridge=virbr0

Check that the VM is running

virsh list

should list it under the name linux.

## Connect the VNC terminal​

First, run

virsh vncdisplay linux

to determine the display port used. Then follow the instructions earlier in this section describing how to connect to VNC.