List View

The server list shows all servers that a user has view permissions for, as determined by their group and role membership. The list can be filtered by various facets (click Show Filters button) or searched using the table’s search field. If tags are set on any servers, clicking on one also searches the table for that word or phrase.

Users may perform actions on one or more servers by selecting rows and using the table toolbar to, e.g. change the Group, power off, or even run custom-defined Server Actions.


Detail View

A server’s detail view shows its status, hardware configuration, disks, networking information, history, and more. The screenshot below shows an AWS server with some tags and a plethora of custom-defined Server Actions. From this view, users with the right permissions can manage things like server ownership, reassign group and environment, and manage hardware, tags, and parameters.


Change Resources

One noteworthy management action that qualified users can take on servers on some Resource Handlers is to change the CPU and memory for that server. This change can optionally be scheduled to occur at a later time. The job for that change will not progress past the pending status until that scheduled time has been reached.

Like the order form, the parameter options and constraints configured on the server’s group and environment will be used to limit the values that users can enter for CPUs and Mem Size. If one or both of these parameters are part of a preconfiguration, the preconfiguration will be displayed in place of the parameter(s).

To allow a role to be able to use this action, give the role the server.change_resources permission.

Remote Server Access

The Remote Server Access features (Console and RDP/SSH) allow users to connect to their servers remotely via the Console feature on VMware and OpenStack and via Microsoft Remote Desktop Protocol (RDP) on Windows servers or Secure Shell (SSH) on servers which support SSH. Users can access these features by clicking the ‘Console’, ‘Remote Desktop’, or ‘SSH’ buttons on a server’s details page. These features are supported on modern browsers which support HTML5+WebSockets, so no plugins or third-party applications need to be installed on the user’s computer or browser to use these features.

Remote Server Access Prerequisites

The Console and RDP/SSH features require some setup in order to use them. Further, some platforms provide more or less support for these features.

Resource Technology Support Matrix

Resource Technology Console 1 SSH 2 RDP 2
Private Clouds:
VMware vSphere 3 YES YES YES
OpenStack 4 YES YES YES
Other Private Clouds NO YES YES
Public Clouds:
Azure N/A 5 YES YES
Google Compute N/A 5 YES YES
IBM SoftLayer N/A 5 YES YES
CenturyLink Cloud N/A 5 YES YES
Oracle Compute Cloud N/A 5 YES YES
Other Public Clouds N/A 5 YES YES
  • 1: See Console Prerequisites
  • 2: See RDP/SSH Prerequisites
  • 3: See VMware Console Requirements
  • 4: See OpenStack Console Requirements
  • 5: Platform did not provide Console support at time of writing

RDP/SSH Prerequisites

To use this feature:

  1. The feature must be supported on the specific resource technology (see the Resource Technology Support Matrix above)
  2. The RDP/SSH feature must be enabled in Miscellaneous Settings
  3. The user must have permission to use the feature (server.remote_terminal or CloudBolt super admin)
  4. The remote server must be online
  5. The remote server must have an IP Address shown in its Server Details page
  6. That IP address must be routable from the CloudBolt server
  7. TCP port 22 (SSH) or 3389 (RDP) must be open between the CloudBolt server and the remote server
  8. The SSH server must be configured to accept password-based connections
  9. If the remote server is configured to use Network Level Authentication, the server must have the ‘nla_for_rdp’ parameter set in CloudBolt
  10. The user must use a modern browser (supported browsers are the latest versions of Chrome, Firefox, Safari, and Internet Explorer) with JavaScript enabled

Console Prerequisites

To use these features:

  1. The feature must be supported on the specific resource technology (see the Resource Technology Support Matrix above)
  2. The Console feature must be enabled on the server’s resource handler. This can be managed from Miscellaneous Settings or from the resource handler’s Overview tab.
  3. The end-user’s browser must be able to communicate to the CloudBolt server over TCP ports 5900-6900 (configurable range, see Firewall Considerations below) for VMware and 6080 for OpenStack (see OpenStack Specific Requirements below).
  4. The resource technology (e.g. ESX and OpenStack servers) must be configured to accept such connections
  5. The remote server must be online

VMware Console Requirements

All console related traffic is sent to the ESX/ESXi server hosting the virtual machine by way of CloudBolt. For the feature to work is necessary for CloudBolt to be enabled direct connectivity with each ESX/ESXi host.

Firewall Considerations

The considerations below apply to vCenter versions 6.0 and below. Console in vCenter 6.5+ uses the HTML Console and only requires port 443 to be open on CloudBolt and the ESXi host.

CloudBolt listens for connections that should be routed for console access in ports 5900 to 6900 by default, and this can be controlled by adding parameters to /var/opt/cloudbolt/ (/var/opt/cloudbolt/proserv/ for versions < 5.1):


It’s also important that each ESX/ESXi be configured to allow incoming connections on the TCP ports used for console. This can be accomplished with the following steps:

  1. Open the configuration for each ESX/ESXi host.
  2. Select “Security Profile” under the “Software” heading.
  3. Open the Firewall properties.
  4. Check to enable “VM serial port connected over network”.

OpenStack Console Requirements

CloudBolt delegates console access to the nova-novncproxy on your OpenStack resource handler. It is therefore a requirement that the user’s browser have the ability to reach the novnc proxy on the port listening for console related connection – usually port 6080.

For more information on the nova-novncproxy and help setting it up refer to the openstack documentation:

Using Remote Server Access

As long as the prerequisites specified above have been met, a Console, Remote Desktop, or SSH button will appear on the server’s Server Details page. Clicking that button will open a new browser window or tab which will initiate the remote connection to the server (either via the resource technology or directly). The window size will be based on the current size of your browser window or tab, and cannot be resized after the session has been initiated. When using SSH or RDP, a login prompt will appear 1; when using Console, you may need to move the mouse or press a benign key to get the screen to refresh if the console session has blanked out. To close the session, simply close the window or tab. To restart a disconnected session, simply reload the window or tab.

  • 1: SSH connections prompt you for username and password prior to attempting the connection to the remote server. If you enter valid credentials and all you get is a black screen and a disconnection message, the RDP/SSH Prerequisites may not have been fully met. You can perform some simple diagnostics from the CloudBolt server as described in the RDP/SSH Troubleshooting section.

Keyboard Limitations

This table lists keyboard commands that are known not to work under Console and/or RDP/SSH. If you absolutely require any of these keyboard shortcuts to work in the browser, contact CloudBolt Support to file a feature request. If you find other keyboard shortcuts that do not work properly, you may send that information to support as well and we can update this document (and file a feature request on your behalf).

Feature Shortcut Notes
RDP/SSH Win+M Opens the Start menu on Windows instead of minimizing all windows.
RDP/SSH Shift+Left  
RDP/SSH Shift+Right  
RDP/SSH Cmd+` Switches same-app windows on OSX, but is passed through to the remote server.
RDP/SSH RightCtrl Remapped to LeftCtrl
RDP/SSH Ctrl+a Left  
RDP/SSH Ctrl+a Right  


RDP/SSH Troubleshooting

My remote connections cannot be established
  1. Verify that the RDP/SSH Prerequisites have been satisfied.
  2. Check your CloudBolt logs for error messages.
  3. Log into the CloudBolt server via SSH and verify that the guacd and guacg services are running.
  4. Log into the CloudBolt server via SSH and verify that you are able to telnet to the server’s relevant TCP port (22 for SSH, 3389 for RDP).
  5. Check your browser’s JavaScript console for error or warning messages or other diagnostic information.
  6. Add -d to the list of args to guacg in /etc/init.d/guacg and restart the guacg service; then check /var/log/cloudbolt/guacg.log for error messages.
  7. Review /var/log/cloudbolt/guacd.log for error messages.

If none of these steps indicate a problem, contact CloudBolt Support with your CloudBolt logs and a screenshot of your browser with the JavaScript console open and any errors shown.


CloudBolt supports managing single-level snapshots on VMware servers. Two actions are provided: creating a new snapshot and reverting to a previous snapshot. Both can be seen on a server’s detail page.


All snapshots taken outside of CloudBolt are ignored. CloudBolt does not support reverting to these snapshots nor will CloudBolt ever delete them.

What is a snapshot?

Snapshotting a server saves the state of the machine at its current point in time. This means marking the state of the server’s hard disk (but not virtual memory). This tool can be very useful when doing development work. If a mistake has been made, or the user otherwise wants to revert their server to the saved state, they can do so by reverting a recent snapshot.

Creating a new snapshot

From the server detail page of a VMware server, on the left hand side of the page a button called “Create snapshot” will be present. It will be there whether the server is currently powered on or off. To take a new snapshot of the server, click this button. A dialog will appear asking for two input values. Give the snapshot a name and description.

Submitting this dialog will create a new snapshot on the server. This snapshot will be listed in the details tab.

Note that when creating a new snapshot, CloudBolt will automatically delete any existing snapshots that it knows about. This will be done as part of a job. A link to this job will appear as a message at the top of the page once the new snapshot has been created.

Reverting to a previous snapshot

To revert a server to a snapshot, a snapshot must first exist on the server that CloudBolt has taken. On the server’s detail page, if a snapshot does exist that CB knows about, on the left hand side of the page a button called “Revert to snapshot” will be present. To revert the server to the most recent snapshot, click this button. Note that when reverting to snapshot, the current state of the server’s memory and disk will be lost.

Automatically Powering On/Off Servers on a Schedule

CloudBolt is able to power off & on servers on a daily schedule, with times specified on a per-server basis. This can be useful for servers that do not need to run at night, to save on public cloud costs/resource consumption during those times of the day.

To enable this feature:

  1. Go to Admin > Recurring Jobs and enable the Auto-power control servers recurring job.
  2. Navigate to a server to test with and click on its Power Schedule tab.
  3. Click the Edit button to set a schedule for that server.
  4. Run the Auto-power control servers recurring job to test. If the server is scheduled to be powered on or off at a time that matches the current hour of the current day, the job will power it on or off, respectively.

Note that the local time on the CloudBolt server is used to determine when servers should be powered on/off.

To set the Power Schedule at order time:

  1. Add the Power Schedule parameter to a group or environment so it is included on the order form.
  2. Choose a schedule on the order form with the custom widget, or select from a set of options defined on the group or environment.
  3. During provision, the parameter value will be transformed into a power schedule.
  4. After provision, the Power Schedule parameter will not be seen on the server’s Parameters tab, but the defined schedule will be on the Power Schedule tab.

If you would like to have all servers provisioned within a certain environment or for a certain group get the same power schedule, you can set the value of the Power Schedule parameter on the environment or group, and CloudBolt will set that value on all servers provisioned for that environment or group.

End users or admins can set the Power Schedule on an existing server by navigating to its detail page and using the Power Schedule tab as described above. A prediction of the schedule’s impact on costs will be shown on this tab once a schedule is set. Admins can also view the Savings from Server Power Schedules report to see savings by resource technology over various time periods.

If you want to use more complex logic, you can send us a request for enhancement via our support team, and you can also make the change to the recurring job’s plugin code yourself if you do not want to wait.

Physical Server Discovery

CloudBolt has the ability to scan networks to find physical servers and create server records for them so they can be managed and reported on from CloudBolt. These servers would not be detected via CloudBolt’s traditional mechanism of querying virtualization systems and public cloud providers for VM inventories, so scanning the network is necessary to find these servers.

To begin a scan, go to Admin > Rules and look for the rule called “Scan Network for Physical Servers”. This rule can be run from the UI even though automatic, recurring execution is disabled . Executing this rule will identify any IPs within the specified range that have a device listening, but are not already tracked in CloudBolt, and create server records for them. After that, they can be seen and managed in CloudBolt, and will be included in reports.

Optional Extended Discovery

If provided with a potential password for discovered servers, CloudBolt will attempt to authenticate using that password (and either a default username of Administrator/root or the specified username). If the credentials work, CloudBolt will store them on the new server record, then run any CB Plugins whose name starts with “Discover <OS Family>” for the OS Family of the server, and each ancestor of that OS Family. Thus, if this feature discovers an ESXi server, it will run any plugins whose name starts with “Discover ESXi”, then any plugins that start with “Discover Linux”. For an example, go to All Actions and look for an action called “Discover Windows Info”.