Servers

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.

_images/server-list.png

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.

_images/server-detail.png

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
KVM NO YES YES
RHEV (Red Hat) NO YES YES
Xen NO YES YES
Other Private Clouds NO YES YES
Public Clouds:
AWS N/A 5 YES YES
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 (NLA; common starting with Windows Server 2008 R2), 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/customer_settings.py (/var/opt/cloudbolt/proserv/customer_settings.py for versions < 5.1):

LOW_CONSOLE_PORT=XXXX
HIGH_CONSOLE_PORT=YYYY

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: http://docs.openstack.org/admin-guide-cloud/content/nova-vncproxy-replaced-with-nova-novncproxy.html

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  

Troubleshooting

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.

Snapshots

CloudBolt supports managing single-level snapshots on VMware and Nutanix 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.

Note

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 or Nutanix 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.

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”.