Portal:Cloud VPS/Admin/Runbooks/NewVMFailure

Often the first symptom of an Openstack failure is a user reporting that they can't access a VM they just created. Here are some things to check:

Widespread VM creation failure

First, make sure that this isn't an issue with VM creation in general.

The novafullstack daemon creates VMs all the time, only deleting ones that are created properly. Check the admin-monitoring project (either on Horizon or via the CLI) and see if all recent creations are failing.

andrew@cloudcontrol1006:~$ sudo wmcs-openstack server list --project admin-monitoring -c name -c ID
+--------------------------------------+---------------------------+
| ID                                   | Name                      |
+--------------------------------------+---------------------------+
| 5a4a96c2-d939-47eb-a42d-e63ff9f73341 | fullstackd-20251124082306 |
| dcc67d84-f357-42b8-a152-66a4cc7675a2 | fullstackd-20251119031020 |
+--------------------------------------+---------------------------+

In the above example, things look pretty good, without a lot of recent creation failures leftover. If the list was long and full of recent timestamps, go to the fullstack leak runbook.

New user ldap issues

If the user only just now created their account, they may not have been added to the 'bastion' project. This is tracked as T379550 and can be resolved by manually adding the user:

andrew@cloudcontrol1006:~$ sudo wmcs-openstack role add --user <username> --project bastion reader

Ssh mishaps

If other users can access the VM (or an admin can with a cloud-wide root key) then most likely the issue is user error. Most often this is the user failing to specify their username on the ssh commandline; evidence of this can be seen in auth.log on the affected VM.

Often the user will have to return to the access guide and start again.