One place for hosting & domains


      An Overview of the Linode Cloud Manager

      Updated by Linode

      Contributed by

      The Linode Cloud Manager provides a user-friendly interface to manage your infrastructure, user accounts, billing and payments, and to open and track support tickets. You can easily create Linode instances, managed Kubernetes clusters, add backups to your Linodes, deploy One-Click Apps, track event notifications, create Object Storage buckets, and more. The Cloud Manager is implemented solely atop our public APIv4, which gives you access to all our latest products and services.

      In this Guide

      This guide provides an overview of the features and services available in Linode’s Cloud Manager. Some of the topics that will be discussed are:

      • An introduction to each section of the Cloud Manager, including links to related guides throughout our documentation library.
      • The location of commonly used Cloud Manager features.
      • Settings that might make your overall Cloud Manager experience better


      The Linodes section of Cloud Manager allows you to create and manage your Linodes. Each Linode instance in Cloud Manager includes:

      • Summary information about your Linode, like CPU usage, IPv4 and IPv6 traffic, and Disk IO
      • Access to any of your Linode’s attached Volumes and the ability to create a Volume
      • Networking information and features, including the ability to add IPv4 and IPv6 addresses, IP transfer and IP sharing
      • The ability to resize your Linode, boot your Linode into Rescue Mode, and rebuild your Linode
      • Access to Linode’s Backup service
      • An Activity Feed that displays any relevant events related to this Linode
      • Settings that allow you to update your Linode’s label, reset your Linode’s root password, manage system usage email notifications, manage Watchdog (Linode’s automatic reboot feature), and delete your Linode
      • An area to manage and create disks and configuration profiles
      • Cross data center migrations

      Find Your Disks

      You can find your Linode’s disks in the Disks/Configs tab of the Linode’s detail page.

      1. Click the Linodes link in the sidebar menu and select the Linode whose disks you’d like to see.

      2. Then click the Disks/Configs tab. The disks are located in the Disks panel. Here you can add a disk, or for each individual disk, you can click the more options ellipses to get a drop down menu which will allow you to choose options such as Rename, Resize, Imagize, Clone, and Delete.

        Location of Cloud Manager Disks

      Reboot Your Linode

      You can reboot a Linode from two places within the Cloud manager.

      1. From your Linodes listing page, click the More Options Ellipses and select Reboot.

        Cloud Manager Linode List Menu Reboot Option

        If you have more than one Configuration Profile, a panel will appear to allow you to select which Configuration to boot. Select a Config and click the Submit button. Otherwise, a confirmation dialog will appear.

        Cloud Manager Reboot Detail Panel

      2. You can also reboot your Linode from within any Linode details page by clicking on the Status Icon. A drop down menu will appear, select Reboot.

        Cloud Manager Linode Detail Menu Reboot Option

        Again, if you have more than one Configuration Profile, a panel will appear to allow you to select which Configuration to boot. Select a Config and click the Submit button. Otherwise, a confirmation dialog will appear.

      Delete a Public IP Address

      You can delete a public IP addresses within the Cloud Manager from the Networking tab in a Linode’s details page.

      1. Click Linodes from the sidebar menu.

      2. Choose the Linode you wish to modify to enter the Linode detail screen. Then, click on the Networking tab. Your IPv4 and IPv6 addresses will be listed here.

      3. Next to the public IPv4 address you wish to delete, click on the more options ellipses. Select the option to Delete IP from the drop down menu.

        Cloud Manager Delete a Public IP Address

      4. A confirmation popup will appear where you can confirm the operation.


        You must have at least one public IP on a Linode. If you attempt to delete the last public IP on a Linode you will receive an error message after you confirm the deletion.


      The Volumes section of Cloud Manager gives you access to Linode’s Block Storage service. To learn how to create, and manage Block Storage volumes using Cloud Manager, see our How to Use Block Storage with Your Linode guide.

      Object Storage

      The Object Storage section of Cloud Manager gives you access to Linode’s Object Storage service which is a globally-available, S3-compatible method for storing and accessing data.

      To learn how to begin using Object Storage, view our How to Use Linode Object Storage guide. To access all available Object Storage guides, see the Object Storage section of our documentation site.


      Linode’s NodeBalancers service provides load balancing for your applications and services ensuring that they are highly available for users. To learn how to get started with NodeBalancers using Cloud Manager, see our Getting Started with NodeBalancers guide.

      Domains (DNS Manager)

      The DNS Manager allows you to control and manage your domains. You can access the DNS Manager by navigating to the Domains link in the Cloud Manager’s sidebar.

      Cloud Manager Domains

      For more information on Cloud Manager’s DNS Manager, see the following guides:

      Zone Files

      The Cloud Manager automatically ensures that your Domain’s zone file does not contain any errors when a Domain Record is created or updated.


      This Cloud Manager and API v4 functionality is currently under active development.
      • When creating a Zone File for a Domain, the Linode API v4 checks for any errors that may exist. If an error is found, the Cloud Manager will respond with the corresponding error. This means that the Cloud Manager will not allow you to create an invalid zone file.

      • Once your Domain and corresponding Zone File is created, you can use the dig command to further verify that each domain record contains the information you expect. It will take a few moments before a newly created domain record will show up when issuing the dig command.

        dig MX

        See the Use dig to Perform Manual DNS Queries guide for more details on the dig command.


      The Longview section of Cloud Manager gives you access to Linode’s system data graphing service. It tracks metrics for CPU, memory, and network bandwidth, both aggregate and per-process, and it provides real-time graphs that can help expose performance problems. The Longview service offers both free and paid plan tiers.

      To get started using Longview, see the Understanding Linode Longview guide.

      One-Click Apps

      The One-Click Apps section of Cloud Manager gives you access to apps that make it easy to deploy and configure software on a Linode. Some popular One-Click Apps are WordPress, Minecraft, and GitLab. We are actively adding new and useful One-Click apps. When a One-Click App is deployed, a new Linode is created and the appropriate software is installed with the configurations you provide.

      See How to Use Linode’s One-Click Apps to get started using One-Click Apps in Cloud Manager.


      The Kubernetes section of Cloud Manager gives you access to our managed Kubernetes service, the Linode Kubernetes Engine (LKE). LKE is a fully-managed container orchestration engine for deploying and managing containerized applications and workloads. LKE combines Linode’s ease of use and simple pricing with the infrastructure efficiency of Kubernetes.

      To get started using LKE, see our Tutorial for Deploying and Managing a Cluster with Linode Kubernetes Engine.


      StackScripts provide Linode users with the ability to automate the deployment of custom systems on top of our default Linux distribution images. StackScripts are usually Bash scripts, stored in the Linode Cloud Manager, and can be accessed when you deploy a Linode. Linodes deployed with a StackScript run the script as part of the first boot process.

      To get started using StackScripts in Cloud Manager, see the Automate Deployment with StackScripts guide.


      The Images section of Cloud Manager gives you access to Linode Images which allow you to take snapshots of your disks, and then deploy them to any Linode under your account. This can be useful for bootstrapping a master image for a large deployment, or retaining a disk for a configuration that you may not need running, but wish to return to in the future.

      To get started using Images with Cloud Manager, see Linode Images.

      Account (Management and Billing)

      The Account section of Cloud Manager allows you to manage your account’s billing information and users, and to configure various account-wide settings.

      You can manage the following account and billing settings in the Account section of Cloud Manager:

      Find Credit Remaining

      To find the amount of available credit that you have:

      1. Click on the Account link from the sidebar menu.

      2. On the right hand side of the screen you’ll see the Billing Information section. If you have credit stored on your account, it’ll appear in green under the Current Balance field.

      Credits Listed under Current Balance

      Printing an Invoice

      You can download a printable PDF of your billing invoice from your list of invoices or from within an individual invoice.

      1. Navigate to your Account by clicking on Account in the sidebar.

      2. Click on the Recent Invoices menu item in the Billing section. This will expand to show you a list of your recent invoices. Each invoice has a Download PDF link next to it.

        Cloud Manager Download Invoice from Recent Invoices List

      3. You can also click on any invoice to view it within the Cloud Manager. At the top of the invoice there is a Download PDF button.

        Cloud Manager Download Invoice from Detail View

      Password Management

      The Cloud Manager does not support forcing password expirations. Forcing password resets on a schedule is bad practice from a security perspective. Current security research indicates that forced password changes do more harm than good. If you want to force password resets for users of your Linode account, we recommend using a password manager for this purpose.

      Linode’s Cloud Manager and API v4 allow you to create tags to help organize and group your Linode resources. Tags can be applied to Linodes, Block Storage Volumes, NodeBalancers, and Domains. See the Tags and Groups guide to learn how to create, apply, and search for tags.

      Events and Activity Feeds

      Tasks performed using the Linode Cloud Manager or other account specific tools like Linode’s CLI or API will be logged to an individual Linode’s activity feed, or on your account’s Events Page. The events and activity pages are user accessible logs, or histories of events taking place on your account. They contain details regarding the most notable events affecting your Linodes, like reboots, shutdowns, migrations, and more.

      For more details, see the Understanding the Cloud Manager Events and Activity Feeds guide.

      My Profile

      The My Profile section of Cloud Manager provides access to various settings related to your Linode account’s profile. This area of Cloud Manager contains access to the following features and settings:

      API Keys / API Tokens

      API Tokens (personal access tokens) are used in token-based authentication to provide users or programming scripts with different levels of access to your Linode account’s resources and services via the Linode API v4. You can create and manage your API tokens using the Cloud Manager.

      1. To generate a new personal access token, navigate to your profile by clicking on your username and select My Profile from the drop down menu. Then click on the API Tokens tab.

        Cloud Manager Add a Personal Access Token

      2. Click Add a Personal Access Token. A panel will display allowing you to give this token a label and choose the access rights you want users authenticated with the new token to have.

        Cloud Manager Add a Personal Access Token Panel

      3. When you have finished, click Submit to generate a new Personal Access Token. Copy the token and save it to a secure location before closing the popup. You will not be able to view this token through the Cloud Manager after closing the popup.

      OAuth Apps

      The Cloud Manager supports the OAuth 2 authorization protocol. OAuth 2 allows a user to safely grant a third-party app permission to act on their behalf. This means that a user could authorize an app to access data and / or make changes to their Linode account and services that are exposed by the Linode APIv4. For example, an app could create or destroy Linodes, manage a NodeBalancer, or alter a domain.

      To learn how to get started with OAuth Apps see the How To Create an OAuth App with the Linode Python API Library guide. For details on the Linode API v4’s OAuth workflow see the Linode API v4 documentation.

      Manage Email Event Notifications

      Email event notifications alert you when new events such as booting, shutting down, or updates to a Linode occur on your account. You can enable or disable email event notifications using the Cloud Manager.

      You can manage your event notifications in the Settings tab from the My Profile section of the Cloud Manager.

      Cloud Manager Notification Settings

      User Interface Enhancements

      Compact Mode and Dark Mode

      Cloud Manager provides three different UI themes that you can toggle on and off depending on your preference. By default, Normal mode will be selected. You can also choose Compact Mode which compresses any extra screen space and allows more information to be displayed on the screen. This setting is located at the bottom left hand corner of the screen when the gear icon is clicked. This is also where you can toggle on Dark Mode, which changes your UI’s color scheme. Light mode is selected by default.

      Compact Mode Enabled


      The Linode Cloud Manager has been built with accessibility in mind. Currently, the Cloud Manager is actively being developed to achieve WCAG 2.0 Level AA.

      We have received a lot of helpful feedback from our users regarding accessibility. While we have addressed a lot of your feedback, this is still a work in progress and will be iterated upon with time. Please contact [email protected] with any comments or requests regarding accessibility.

      This guide is published under a CC BY-ND 4.0 license.

      Source link

      How to Migrate from Google Cloud Platform to Linode

      Updated by Linode

      Contributed by

      This guide describes the recommended strategy for migrating your services from a Google Cloud Platform (GCP) VM instance to Linode. The specific steps you’ll need to carry out will vary depending on the software you use, but the high-level outline is generally the same regardless of the nature of your service. The Migrate to Linode section offers other guides which describe migrating particular services in more detail.

      Deciding on a Migration Strategy

      There are three general strategies for migrating from another hosting provider:

      1. Migration Strategy 1: Manually Install Each Service Individually – Recommended Method

        • Create a Linode, deploy a Linode-provided Linux image to it, and copy over only the configuration and data relevant to your services. This results in a Linux environment that is guaranteed to boot normally on the Linode platform.

          Re-installing your services can take time, but any issues that come up when setting up your applications are usually easier to troubleshoot than low-level configuration problems. This is the recommended strategy when migrating.

      2. Migration Strategy 2: Use Configuration Management and Orchestration – Recommended Method

        • If you use configuration management and orchestration tools, like Ansible, Salt, Chef, and Terraform, you can use the same tools to deploy a new Linode instance. You can use your existing configuration management files as a foundation to deploy Linode instances with the same configurations used by your GCP instance.

          We have an extensive configuration management section in our Guides and Tutorials library that you can use to get started with your preferred tool.

      3. Migration Strategy 3: Transfer your Disk Images – Not Recommended

        • Create a Linode and perform a full clone of your existing disks from your GCP instance to the Linode. This will create an exact copy of your disks on the Linode platform. This strategy is not recommended because low-level system configuration files can be different on different hosting providers.

          These differences can prevent your Linode from booting normally. It is possible to adjust these settings sufficiently to allow your Linode to run normally, but getting the right values for these settings can be difficult, and it can be difficult to troubleshoot when they are incorrect. However, if you are confident in using this method, you can proceed to the Transfer your GCP disks to Linode section of this guide.

      Migration Strategy 1: Manual Migration Strategy

      Deploy a New Linode

      There are two considerations when creating a new Linode: which data center the Linode should reside in, and which hardware resource plan the Linode should run under.

      1. Data Center Location

        • To choose a data center location, run speed tests to the different regions that Linode offers from the speedtest page. This page allows you to download a 100MB file from each location. Compare the speed of each download to determine the bandwidth between your location and the data center.

          You can also run MTR tests to the speed test servers at each location (e.g. These tests will report latency between your location and the data center–a lower latency is more desirable.

      2. Plan Size

        • To determine which plan to choose, review the Linode Pricing page. At a minimum, choose a plan which offers enough storage capacity for the data you store on your current GCP VM instance.

          CPU and RAM allocations are also important since a service with a higher workload/higher traffic will require more of each. If you’re not sure what your workload will require, start with a smaller Linode and then resize your plan up or down as needed.

      Deploy a Linux Distribution to your Linode

      Determine the Linux distribution your current GCP instance uses and deploy that to your new Linode. If your current deployment uses an older version of a Linux distribution, deploy the newest version available for your new Linode to ensure the latest security enhancements and software availability.

      For further details on deploying your new Linux image, follow the Getting Started with Linode guide. It is also recommended that you follow the How to Secure Your Server guide once you have deployed your new image.

      Install Software on your Linode

      1. Install the same software stack that is present on your GCP instance onto your new Linode. You can use your GCP instance’s package manager to retrieve a list of all installed packages. For example, if you are using Debian or Ubuntu you can issue the following command:

        apt list --installed
      2. Once you have identified the software you would like to migrate to your Linode, you can reference our Guides & Tutorials to learn how to set up your system’s software on your new Linode.

        For example, if your GCP instance is used to run a WordPress site, you should install WordPress, PHP, MySQl, and Apache or Nginx (web server) on your Linode instance.

      Create a Snapshot of your GCP Data

      Locate and backup the data on your GCP instance by creating a snapshot. Identify:

      • Which software configuration settings should be preserved (e.g. web server, virtual host information, database connection settings, and which files contain these settings, etc.).

      • Where your data is stored on disk (e.g. as files in a directory, in a database process, etc.).

      If your data is stored in a database, you will likely need to perform a database dump. This will result in a file on disk that encapsulates your database data and can be copied over the network as a normal file:

      Use rsync to Transfer Your GCP Data to Your Linode

      • Transfer your data to your Linode using a network transfer tool like rsync. The Introduction to rsync guide is a good place to become more familiar with this tool.

        For example, the following command will upload files from /path/to/source_folder on the current host to /path/to/destination_folder on the new Linode. Run this command from your current GCP instance. Replace example_user with the Linux user on your Linode, and linode_ip_address with your Linode’s IP address:

        rsync -avzh /path/to/source_folder [email protected]_ip_address:/path/to/destination_folder
      • If you have uploaded a database dump file to your new Linode, you will also need to restore the dump file so that your database software can use the data normally. The database guides linked to in the Create a Snapshot of your GCP Data section include instructions for restoring those files.

      Test the New Environment

      When you have finished setting up your software and restoring your data, test the installation to make sure it works normally. At this point, you have not yet updated DNS records to point to your Linode deployment, but there are still methods for previewing your services without DNS.

      Take this time to perform load testing on your new service. ApacheBench is a popular benchmarking tool for web services. If you discover that the hardware resource plan you chose originally is not enough when completing these load tests, then resize your plan and continue testing.

      When you have finished testing, move on to the last step in migrating: updating your DNS records.

      If you are managing your GCP instance with configuration management and orchestration tools, you can use the same tools to manage your Linode. This means you can use configuration management tools to execute a migration from GCP to Linode. At a high-level this process would entail

      • Using an orchestration tool, like Terraform, to deploy a Linode instance(s) of the required size and region. See the Deploy a New Linode section of this guide for tips on choosing a Linode data center and plan size.

      • Using a configuration management tool, like Ansible, to install system software and perform system configurations. In many cases, you could use the same configuration management files to configure your Linode. For example, if you were using an Ansible Playbook to deploy and configure a LAMP stack on your GCP instance, you can likely use the same Playbook to manage your Linode instance.

      • Migrating any additional GCP instance data to your new Linode instance using rsync.

      • Testing your new Linode environment.


      Migration Strategy 3: Transfer your Disk Images

      GCP Prerequisites

      This section contains all of the preparation steps that you will need to complete on the Google Cloud Platform and on your GCP instance in order to migrate your disk images to Linode. At a high-level, you will disable Google specific daemons running on your GCP instance, create and export an image of your instance, and store the image in a GCP object storage bucket.


      While it is possible to migrate a GCP disk image to Linode, due to differences in low-level system configurations between GCP and Linode, you may encounter some unexpected results that require additional troubleshooting steps. Continue with this method only if you are confident in your understanding of the Google Cloud Platform, GCP IAM roles, and GCP disks and images.

      Install and Set Up gcloud


      If you have already installed the Google Cloud SDK on your computer, you can skip this section.

      The Google Cloud SDK gives you access to the gcloud command-line tool. You will need gcloud to create and export an image of your GCP instance. You will create the instance image later on in this guide.

      1. Download and install the latest Google Cloud SDK for your operating system.

      2. Setup gcloud compute by running the following command:

        gcloud init


        gcloud init will guide you through a setup process and ask to use your browser to log in to your Google account. If you do not have access to a browser, you can use the following command to force console only setup. This method will give you a URL to paste into a browser for verification, which in turn, will give you a verification code to paste back into your console:

        gcloud init --console-only

        The setup will ask you for your project id, region, and zone. You can find these values from your Google Cloud Platform account. Check the GCP documentation for a full list of Google regions and zones.

      Create a GCP Object Storage Bucket

      When you create an image of your GCP instance you will temporarily store it in a GCP object storage bucket. Follow the steps in this section to create the GCP object storage bucket.


      Using the GCP object storage service will incur additional charges outside of the cost of your GCP instance.

      1. Navigate to your GCP dashboard. From the left sidebar menu, under the Storage section, click Storage.

      2. Create an object storage bucket. You can follow GCP’s inline steps to complete this process. For more information on GCP object storage access control options, see their official documentation.

      Prepare Your GCP Instance

      Now that you have completed the prerequisite steps, you are ready to prepare your GCP instance for its migration to Linode. This will require creating a root password, turning off Google daemons, and creating and exporting a GCP image.

      Root Password

      GCP instances don’t have root or user passwords setup by default, you will create these so that you can log into your machine after you migrate it.

      1. SSH into your GCP instance.

      2. Once you’re logged into your GCP instance with ssh, run the following command to set a root password:

        sudo passwd
      3. If you want to set a password for your user account, switch to root and then set user account passwords. Ensure you replace username with the username for which you want to set a password:

        passwd username
      4. Return to your normal user, if desired:


      Inspect your GCP Instance’s Disks

      Before continuing with the preparation to migrate, you should inspect your GCP instance for the following information:

      • The number of non-volatile disks located on your instance.
      • The amount of storage space each disk takes up. In the Prepare Your Linode section, you will need to know the size of each disk you would like to migrate in order to select the appropriate plan size for the Linode you will be migrating to.
      • Determine which disk(s) you would like to migrate to your new Linode. You will need to repeat the steps in the Create and Export Image and the Create New Disks and Configurations sections for each non-volatile disk on your GCP instance that you would like to migrate to your Linode.


        At minimum, you will migrate your GCP instance’s boot disk. On a Linux system, without a custom boot disk configured, this is likely /dev/sda1.

      1. To inspect your GCP instance’s disks, ssh into your GCP instance and issue the following command to view disk size on each mounted disk:


        The usable disk space that is reported by df reflects only 90 percent of full capacity.

        df -h

        You should see a similar output:

        Filesystem      Size  Used Avail Use% Mounted on
        udev            3.7G     0  3.7G   0% /dev
        tmpfs           749M  9.9M  739M   2% /run
        /dev/sda1       9.8G  1.2G  8.2G  13% /
        tmpfs           3.7G     0  3.7G   0% /dev/shm
        tmpfs           5.0M     0  5.0M   0% /run/lock
        tmpfs           3.7G     0  3.7G   0% /sys/fs/cgroup

        You can also issue the following command, which displays all available block devices:


        Your output should resemble the following:

        sda      8:0    0  10G  0 disk
        └─sda1   8:1    0  10G  0 part /

        In this example, you will create a disk image for /dev/sda1 and you will need, at minimum, 10GB of storage. For more details related to Linode plan size considerations see the Create a Linode section.

      Turn Off Google Daemons

      Before you migrate the instance, turn off the daemons that communicate with Google servers. If you don’t do this, once you move to Linode, these services will continually try to access Google servers and fail if the daemons are still running.

      1. With the text editor of your choice, create a new file called /etc/default/instance_configs.cfg.template file. Copy and paste the configurations in the example file:

        sudo nano /etc/default/instance_configs.cfg.template
        accounts_daemon = false
        clock_skew_daemon = false
        network_daemon = false
        ip_forwarding_daemon = false
      2. Regenerate the instance_configs.cfg file with your changes by running the following script:

        sudo /usr/bin/google_instance_setup

        Verify that the changes took effect by viewing the contents of the /etc/default/instance_configs.cfg file. The [Daemons] section should resemble the file you created in step 1.

        cat /etc/default/instance_configs.cfg
      3. Stop and disable the daemons:

        sudo systemctl stop google-accounts-daemon
        sudo systemctl disable google-accounts-daemon
        sudo systemctl stop google-clock-skew-daemon
        sudo systemctl disable google-clock-skew-daemon
        sudo systemctl stop google-network-daemon
        sudo systemctl disable google-network-daemon
        sudo systemctl stop google-ip-forwarding-daemon
        sudo systemctl disable google-ip-forwarding-daemon


        If your GCP instance was not created with IP forwarding enabled, then you may see a similar message after attempting to stop and disable the google-ip-forwarding-daemon:

        sudo systemctl disable google-ip-forwarding-daemon
        Failed to disable unit: No such file or directory
        [email protected]:~$ sudo systemctl --status
        systemctl: unrecognized option '--status'
        [email protected]:~$ sudo systemctl status

      Stop Your GCP Instance

      In order to create your instance’s disk image in the next section, you will first need to stop the instance. This will prevent any new data from being written to the persistent disk.


      GCP recommends stopping your instance prior to creating a disk image, however, it is possible to keep the instance running while you create your image. See their official documentation for details.
      1. Navigate to your GCP dashboard. From the left sidebar menu, under Compute, click Compute Engine.

      2. Viewing your VM instances, click on the more options ellipsis for your instance and select Stop.

      Create and Export a Disk Image

      You are now ready to create and export an instance image using the gcloud command-line tool. If you have not installed the Google Cloud SDK, you will need to do so before proceeding.

      1. Create an instance disk image with the command below. Replace migrate-gcp-img with a name you want to give your image, test-gcp-instance with the name of your instance’s disk, us-east1-b with the zone for your instance, debian-9 with the distribution image family for your instance, and us-east1 with the region where you want your image to be stored.

        gcloud compute images create migrate-gcp-img --source-disk test-gcp-instance --source-disk-zone us-east1-b --family debian-9 --storage-location us-east1
      2. The output will look similar to the following:

        Created [].
        NAME             PROJECT             FAMILY    DEPRECATED  STATUS
        migrate-gcp-img  speedy-area-263218  debian-9              READY
      3. Export the image to object storage with the command below. Replace lin-docs-test-bucket with your bucket name, migrate-gcp-img with your image name, and speedy-area-263218 with your project id. This process may take a few minutes to complete.

        gcloud compute images export --destination-uri gs://lin-docs-test-bucket/migrate-gcp-img.tar.gz --image migrate-gcp-img --project speedy-area-263218


        You may need to respond to some command-line prompts before the image is exported.

      4. The output will look similar to the following:

        [image-export]: 2020-01-03T18:05:46Z Step "image-export-export-disk" (IncludeWorkflow) successfully finished.
        [image-export]: 2020-01-03T18:05:46Z Serial-output value -> source-size-gb:10
        [image-export]: 2020-01-03T18:05:46Z Serial-output value -> target-size-gb:1
        [image-export]: 2020-01-03T18:05:46Z Workflow "image-export" cleaning up (this may take up to 2 minutes).
        [image-export]: 2020-01-03T18:05:52Z Workflow "image-export" finished cleanup.
      5. From your GCP dashboard, navigate to your Storage Browser and click on the GCP object storage bucket that you exported your instance image to.

      6. You will see your instance image listed. Click on its corresponding more options ellipses and select Edit Permissions from the drop down menu.


        If you do not see the Edit Permissions option, then your bucket may have been created with uniform access controls. To make the image publicly accessible, see GCP’s official documentation for information on making data public. When you have completed the steps listed in the GCP documentation proceed to step 8 of this section.

        Google Object Storage Bucket Edit Permissions

      7. In the dialog box popup, click the Add Item button to add a new row to the table. Select User for Entity, all Users for Name, and Reader for Access. Then click the Save link.

        Google Object Storage Bucket Permissions Add Item

      8. Now you will see that the status under the Public access column for this bucket item is set to Public with a link icon.

        Google Object Storage Bucket Public

      9. Right click the link icon and click Copy Link Address to copy this object’s link address. Paste it into a text file somewhere to save for later. It will resemble the following link:

      Prepare Your Linode

      In this section you will create a new Linode, add a new disk and configuration profile in order to boot the Linode from your GCP instance’s image, import the GCP image to your Linode, and finally, boot your Linode using your GCP instance’s image.


      You will be importing your GCP image onto a raw disk with the direct disk boot option. This will result in a working custom installation; however, it will not support advanced Linode features such as disk resizing or the Backup Service by default. These features require an ext4 formatted disk.

      If you would like access to these features after completing your migration, ensure you complete the following steps:

      Create a Linode

      You will first create a new Linode to import your GCP image to and then, boot the Linode from that image. Before creating your Linode, verify the storage size of your original GCP disk if you have not already.

      1. Log into the Cloud Manager.

      2. Access the Linode create page by clicking Create at the top of the screen and selecting Linode from the dropdown menu.

      3. Create a Linode by making the desired selections on the Linode create page. For more detailed steps, see the Create a Linode section in our Getting Started guide.


        When selecting your Linode’s plan, if you want to have access to advanced features like resizing your Linode and our Backup Service, choose one that will be large enough to hold twice the size of the entire expanded disk image that you created from your GCP instance (not just the size of the compressed tar file). This is needed so that later you can move your installation over to an ext4 formatted disk. Once the move to an ext4 formatted disk is complete, you can delete the raw disk and resize to a smaller plan.
      4. Once the Linode is finished provisioning, power it down. Click on the Running status at the top of the Cloud Manager and select Power Off from the drop down menu.

      5. Disable Watchdog, also known as Lassie, which is a Linode Cloud Manager feature capable of automatically rebooting your Linode if it powers off unexpectedly. Click the Settings tab, then Shutdown Watchdog. Toggle the Enabled switch to Disabled.

      6. Disable your Linode’s Auto Resize capability. Click the Resize tab and scroll to the bottom of the screen. Uncheck the box for Auto Resize Disk.

      Create New Disks and Configurations

      In this section you will create a new disk and boot configuration in order to be able to boot your Linode from your GCP image.

      1. Access your Linode’s Disks/Configs tab.

      2. Under the Disks panel click the more options ellipses next to the main disk (for example, Debian 9 Disk) and select Resize from the drop down menu. Resize this disk to make room for the new raw disk you will create in the next step. The new raw disk is where your GCP image will be installed.


        If, for example, your GCP disk image’s size is 10GB, ensure that you resize the main disk to make enough room for a a new disk that is slightly larger than 10 GB (11 GB, for example). This will ensure that you can safely reboot your Linode from the extracted image (you will complete that step in a later section).

      3. Click Add a Disk and create a new Empty Disk. Give it a label like “New Google”, for filesystem, select raw, and for size, enter a size that will accommodate the entire extracted image. Click the Add button.

        Linode Create New Raw Disk

      4. Click Add a Configuration and setup a new Linode Configuration with the following settings:

        • Label: Google
        • Kernel: Direct Disk
        • /dev/sda: New Google (your new disk)
        • /dev/sdb: select the default swap disk when the Linode was created
        • Root Device: /dev/sda
        • Filesystem/Boot Helpers: disable all of these settings
      5. Click on the Submit button to complete creating the new configuration.

      Import the Image

      1. Click the Rescue tab.

      2. Set /dev/sda to your new disk. In this example, the disk is named “New Google”. Set all remaining options to None.

      3. Click the Reboot into Rescue Mode button. The Linode will reboot into Rescue mode.

      4. Once booting is complete, click Launch Console at the top of the screen. This opens the Weblish and Glish console window. You will be presented with a Finnix rescue terminal and root prompt.

      5. Run the following command to pull your image from Google cloud storage, unpack it, and copy it to the Linode. Replace the URL with the one you copied from your GCP object storage bucket.

        curl -k | tar -xzO  | dd of=/dev/sda
      6. The output will look similar to the following:

          % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                         Dload  Upload   Total   Spent    Left  Speed
        100  667M  100  667M    0     0  1156k      0  0:09:51  0:09:51 --:--:-- 81996
        20971520+0 records in
        20971520+0 records out
        10737418240 bytes (11 GB) copied, 593.648 s, 18.1 MB/s
      7. When this completes, close the console and return to the Cloud Manager. Click the Running status, select Reboot, choose the Google configuration that you created above, and click on Submit.

        Cloud Manager Reboot Into New Configuration

      8. Once booting is complete, click Launch Console at the top of the screen. Again, this opens the Weblish and Glish console window. This time, you should have a regular Lish shell. You should also be able to SSH to your Linode at this time.


        If you are having trouble with ssh starting, you may have to run the following command to start the service from Lish:

        sudo service ssh start

        You may also need to update your SSH server’s configuration file to temporarily allow password authentication. Your GCP instance may have been configured to disallow password authentication and it may not have your computer’s SSH keys stored.

        1. Open your SSH server’s configuration file with your preferred text editor:

           sudo nano /etc/ssh/sshd_config
        2. Find the PasswordAuthentication configuration and set its value to yes:

            PasswordAuthentication yes

        See the SSH guide for more SSH troubleshooting tips.

      Remove Google Packages

      You disabled the Google services from calling out before creating and migrating your image, however, there are a few Google packages that you may want to remove. From the console run the following commands:

      sudo dpkg -r google-osconfig-agent
      sudo dpkg -P google-osconfig-agent
      sudo dpkg -r --force-depends google-compute-engine-oslogin
      sudo dpkg -r google-cloud-sdk
      sudo dpkg -r google-cloud-packages-archive-keyring

      Optional: Transfer Disk to ext4

      As stated above, to take advantage of features like resizing your disks in Cloud Manager and Backup Service, you’ll need to move your new disk to an ext4 formatted disk. To do this, follow the procedures in the Linode Manager Compatibility section of the Install a Custom Distribution on a Linode guide.

      Cleaning Up

      When you’re done:

      Additional Migration Considerations

      Migrating DNS Records

      To direct your visitors to your Linode, associate your domain with your new Linode’s IP. There are two options for moving your DNS records:

      • Use Linode’s fast, stable DNS hosting which is free as long as you have one active Linode on your account.

      • Continue to use your current nameserver authority and update your DNS records with your new Linode’s IP address. You should check with your current provider to see if there are any costs for their DNS services. If you are using your domain name registrar’s nameservers, then they are generally free.

      (Optional) Prepare Your Domain Name to Move

      A recommended first step is to lower the Time to Live (TTL) setting for your domain so that the migration won’t have a negative impact on your site’s visitors. TTL tells DNS caching servers how long to save information about your domain. Because DNS addresses don’t often change server IP addresses, default TTL is typically about 24 hours.

      When changing servers, however, make the TTL shorter to make sure that when you update your domain information, it takes effect quickly. Otherwise, your domain could resolve to your old server’s IP address for up to 24 hours.

      1. Locate your current nameservers. If you’re not sure what your nameservers are, use a Whois Search tool. You will see several nameservers listed, probably all at the same company. nameservers

        You can usually derive the website of your nameserver authority (the organization that manages your DNS) from the nameservers you find in the Whois report (e.g. corresponds with Sometimes the labeling for the nameservers is not directly related to the organization’s website, and in those cases you can often find the website by plugging the nameserver into a Google search.

      2. Contact your nameserver authority for details on how to shorten the TTL for your domain. Every provider is a little different, so you may have to ask for instructions.

        Updating TTL at common nameserver authorities

        Most nameserver authorities will allow you to set the TTL on your domain or on individual records, but some do not allow this setting to be edited. Here are support documents from some common authorities that mention how they manage TTL:
      3. Make a note of your current TTL. It will be listed in seconds, so you need to divide by 3600 to get the number of hours (e.g. 86,400 seconds = 24 hours). This is the amount of time that you need to wait between now and when you actually move your domain.

      4. Adjust your TTL to its shortest setting. For example, 300 seconds is equal to 5 minutes, so that’s a good choice if it’s available.

      5. Wait out the original TTL from Step 3 before actually moving your domain–otherwise, DNS caching servers will not know of the new, lower TTL yet. For more information on domain TTL, see our DNS guide.

      Use Linode’s Nameservers

      1. Follow Linode’s instructions on adding a domain zone to create DNS records at Linode for your domain. Recreate the DNS records listed in your current nameserver authority’s website, but change the IP addresses to reflect your Linode IPs where appropriate.

      2. Locate your domain’s registrar, which is the company you purchased your domain from. If you’re not sure who your registrar is, you can find out with a Whois Search tool. nameservers

        Your registrar may not be the same organization as your current nameserver authority, though they often are, as registrars generally offer free DNS services.

      3. Log in to your domain registrar’s control panel and update the authoritative nameservers to be Linode’s nameservers:


        Updating authoritative nameservers at common registrars

        The following support documents describe how to update the authoritative nameservers of common registrars:
      4. Wait the amount of time you set for your TTL for the domain to propagate. If you did not shorten your TTL, this may take up to 48 hours.

      5. Navigate to your domain in a web browser. It should now show the website from Linode, rather than your old host. If you can’t tell the difference, use the DIG utility. It should show the IP address for your Linode.

      6. Set reverse DNS for your domain. This is especially important if you are running a mail server.


        If you’re having trouble seeing your site at the new IP address, try visiting it in a different browser or in a private browsing session. Sometimes your browser will cache old DNS data, even if it has updated everywhere else.

      Alternative: Use Your Current Nameservers

      If you’d like to continue with your current nameservers, update all of the DNS records that are assigned to your old host’s IP address to use your new Linode’s IP. Contact your nameserver authority for instructions on how to update your DNS records.

      Updating DNS records at common nameserver authorities

      The following support documents describe how to update DNS records at common nameserver authorities:

      After DNS propagation has finished, set reverse DNS for your domain. This is especially important if you are running a mail server.

      Next Steps

      After completing the steps above, your service should be fully migrated to Linode. It is a good idea to wait a few days before cancelling your shared hosting service to make sure that everything is running smoothly, and to confirm that you don’t need to obtain more files from your shared host.

      This guide is published under a CC BY-ND 4.0 license.

      Source link

      Troubleshooting Linode Longview

      Updated by Linode

      Written by Linode

      This guide discusses basic troubleshooting steps to help you diagnose and resolve any issues you may encounter while using Longview. If you’re experiencing problems with the Longview client, follow the steps outlined in this guide to help determine the cause.

      Basic Diagnostics

      1. Ensure that your system is fully updated.


        Longview requires Perl 5.8 or later.

      2. Verify that the Longview client is running. Use the command that is appropriate for your distribution’s initialization system:

        CentOS, Debian, and Ubuntu

        sudo systemctl status longview   # For distributions with systemd.

        Other Distributions

        sudo service longview status     # For distributions without systemd.

        If the Longview client is not running, start it with the command appropriate for your distribution’s initialization system:

        CentOS, Debian, and Ubuntu

        sudo systemctl start longview

        Other Distributions

        sudo service longview start

        If the service fails to start, check Longview’s log for errors. The log file is located in /var/log/linode/longview.log.

      Debug Mode

      Restart the Longview client in debug mode for increased logging verbosity.

      1. First stop the Longview client:

        CentOS, Debian, and Ubuntu

        sudo systemctl stop longview   # For distributions with systemd.

        Other Distributions

        sudo service longview stop     # For distributions without systemd.
      2. Then restart Longview with the debug flag:

        sudo /etc/init.d/longview debug
      3. When you’re finished collecting information, repeat the first two steps to stop Longview and restart it again without the debug flag.

        If Longview does not close properly, find the process ID and kill the process:

        ps aux | grep longview
        sudo kill $PID

      Firewall Rules

      If your Linode has a firewall, it must allow communication with Longview’s aggregation host at (IPv4: You can view your firewall rules with one of the commands below, depending on the firewall controller used by your Linux distribution:


      sudo firewall-cmd --list-all



      sudo iptables -S



      sudo ufw show added


      If the output of those commands show no rules for the Longview domain (or for, which is the IP for the Longview domain), you must add them. A sample iptables rule that allows outbound HTTPS traffic to Longview would be the following:

      iptables -A OUTPUT -p tcp --dport 443 -d -j ACCEPT


      If you use iptables, you should also make sure to persist any of your firewall rule changes. Otherwise, your changes will not be enforced if your Linode is rebooted. Review the iptables-persistent section of our iptables guide for help with this.

      Verify API key

      The API key given in the Linode Cloud Manager should match that on your system in /etc/linode/longview.key.

      1. In the Linode Cloud Manager, the API key is located in the Installation tab of your Longview Client instance’s detailed view.

      2. SSH into your Linode. The Longview key is located at /etc/linode/longview.key. Use cat to view the contents of that file and compare it to what’s shown in the Linode Cloud Manager:

        cat /etc/linode/longview.key

        The two should be the same. If they are not, paste the key from the Linode Cloud Manager into longview.key, overwriting anything already there.

      Cloned Keys

      If you clone a Linode which has Longview installed, you may encounter the following error:

      Multiple clients appear to be posting data with this API key. Please check your clients' configuration.

      This is caused by both Linodes posting data using the same Longview key. To resolve it:

      1. Uninstall the Longview agent on the cloned system.


        sudo yum remove linode-longview

        Debian or Ubuntu:

        sudo apt-get remove linode-longview

        Other Distributions:

        sudo rm -rf /opt/linode/longview
      2. Add a new Linode Longview Client instance. This will create a new Longview API key independent from the system which it was cloned from.


        The GUID provided in the Longview Client’s installation URL is not the same as the Longview API key.

      3. Install the Longview Agent on the cloned Linode.

      If you still need assistance after performing these checks, please open a support ticket.

      This guide is published under a CC BY-ND 4.0 license.

      Source link